Storr Consulting - sc520-nat027


Home	The Company	Publications	Products	Links	Tips

Tips, Tricks, and Techniques

Last update: 30 April 2004

GDA, LDA, PDA or AIV?

Question

What is the efficient way to use GDA's, PDA's and LDA's, maybe AIV's? What is the standard of other companies?

My programming staff is arguing amongst themselves as to what is the effecient way of using LDA's & GDA'a. My question to all of you is what are your shop standards in this regard(if any), and would you be interested in sharing these with me. They are also starting to discuss Object Oriented methods, and would be interested to hear you comments on this also, Karen Ward (DBA) from LERETA Corp. wrote.

General information

NATURAL supports the following four types of data areas:

    DEFINE DATA                                           
1.    GLOBAL USING global-data-area  WITH block.block...  
2.    PARAMETER  USING parameter-data-area                
                 data-definition...         ...           
3.    LOCAL  USING  local-data-area                       
                    parameter-data-area                   
             data definition             ...              
4.    INDEPENDENT aiv-data-definition ...                 
    END-DEFINE

GLOBAL - data elements referenced by more than one program, routine, etc. (provided all are in same library).

PARAMETER - data elements used as parameters in a subprogram (format, length and sequence must match those of calling program's CALLNAT statement).

LOCAL - data elements to be used within a single NATURAL module.

INDEPENDENT - application independent data elements, which are global and can be shared with the STEPLIB.

For more information please see NATURAL Statements Manual Version 2.2, manual order number NAT228-031ALL, page 132.

Answers

Jeff Clark wrote:

We use a single GDA that contains security info, message info, printer ids, etc. and an A200 x 5 MU. We also have pre-established LDA's that can be mapped into each element of the GDA MU. In programs, we can move data into the LDA, then before exiting the program, we move the LDA to the GDA, making it available to other programs. This allows us to make changes to a LDA, forcing us to recompile only the programs that use that LDA, not the entire GDA.

Brian C Johnson, Cutler-Hammer, Pittsburgh, PA, wrote:

I personally don't like GDAs or AIVs, but I guess there's a time and a place for everything. However, one benefit to having many programs share common LDAs is the reduction in IFB translations. The LDA gets translated once to get into the buffer pool and doesn't need to be retranslated for any user unless it got flushed out. That's the way I understand it, anyway.

Richard Bryan, DBA, Austin American-Statesman wrote:

Brian,

External LDA's (GDA's and PDA'S) are incorporated into the program at STOW time and are not refrenced at execution time. How do you share data accross programs in an online environment if you don't use globals?

Brian Johnson, Cutler-Hammer, Pittsburgh, PA, responded:

Richard,

You're talking about the fact that the contents of the LDA are compiled into the object of the main program, and that's true. However, when an LDA is used, the LDA itself is loaded into the program buffer area, and it's the formats defined in the stowed LDA that get translated. The format translation into the internal format buffer is costly, so the less you have to do them (as in using the same LDA between many simultaneously used programs), the better. I don't think we're contradicting each other... we're just talking about two different parts of the process.

As for sharing data not contained in a file somewhere, I prefer parameter data areas over globals. That complies more with the 'structured programming techniques' I learned in college.

Al Blakey wrote:

GDA's are not OO friendly. Also by definition it is supposed to be GLOBAL DATA not PARAMETER DATA. I use GDA's BUT I would expect them to be very small in size in general. I much prefer to use SYSTEM variables where ever possible. *COM even!

PDA's (also useable as LDA's) and LDA's allow a flexibility and consistancy that can span an application and be shared as well.

You can pass the data as parameters to share data accross programs in an online environment if you don't use globals?"

How do you share GLOBALS across distributed platforms in an online environment?

Friedrich Wolf, Merck, Darmstadt, Germany wrote:

NATURAL, Vers. 2 is NOT an OO-language. If you try to make an OO-application with NATURAL, you violate the language. We had a bad experience with an application written in NATURAL on OO-foundation. First, we didn't use GDA's because OO-applications don't have a common memory, as far as I know. But finally, we had to store data in the ESIZE, because USIZE became too small (was long time ago with NAT217). At the end, this application had a bad performance, was full of heavy bugs, the users were uncontent and it costed a lot of man-power to bring it in order. My conclusion: Do not program OO with NATURAL vers. 2 !

Nevertheless, I like programming with modules, but I don't want to give up the common memory of the GDA. There is no better performance than to fetch a program and to have the access to the common memory. Subprograms and PDAs, I use for closed modules, which don't need the access to the common memory. "STACK TOP DATA" and "FETCH RETURN", I would forbid in every case.

Just my 2 cents ...

Christa Vollmer, SAG Systemhaus GmbH, Germany, responded:

Hello Fritz and other OO-fans,

You are right, of course: NATURAL, any known version, is NOT an OO-language! But as far as I know (private sources :-)) even Smalltalk, perfect OO-language, has a data structure very similar to FORTRAN Common or NATURAL GDA or whatever was used in the past days and will be needed in future to store an application's global information. So feel free to use the GDA whenever appropriate!

For experts: the above mentioned Smalltalk data structure is an instance of SystemDictionary called Smalltalk. But there are even more features...

Gordie Cochrane, Independent Consultant, Auto-Magic Systems, wrote:

I have always used GDA's for a sub system. They are especially beneficial when you need to create more than one program to perform a function. This was especially true before you could pass PDA's between subroutines. I have written a Natural Code Generator that required many screens of input with a tremendous amount of validation. All of the validation for each screen was performed in separate sub routines. However, information from one screen was required in subsequent screens. The GDA was a excellent tool for keeping all of the information required to generate the Natural objects in one place from subroutine to subroutine and program to program I have always used the LDA for the definition of user views and variables required in objects. I think it is important to define variables in LDA's because it is the only way to get them into cross reference lists.