× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 2/3/11 9:52 AM, Albert York wrote:
If you have a situation where you cannot change the parms (perhaps
because the program is called in multiple places) but you need
additional data the LDA is a good tool to use.

Is not the "proper" reaction to that situation to change all of the required programs to meet the design; i.e. change the parameters appropriately.? Of course "cannot change" really means "changing is difficult". But changing just some programs to receive their inputs from another place could instead be from any "named" location such as a queue or a file, just as well as the LDA? Rationalizing the LDA as an easy alternative to good coding practices does not make for a better choice, just an easier means to effecting some required changes; though possibly, only by having ignored the potential cost to any future [required] changes. The easiest change as resolution often may be an acceptable solution for a temporary reprieve, but not necessarily as a generally\overall better solution. The more often the LDA is chosen as an acceptable alternative, the more likely there will be conflicts that the standards will have to manage, and the more programs that will have to be changed when a shared definition must change [like when the parameters should have changed, but did not].

Using a named "data area" as implementation objects for an alternative to a new or changed command parameter is a typical example for OS commands. Many will ask "Why not just _fix_ the *CMD and\or PARM instead?"

Another example is setting up the environment so all of the programs
in a job have access to necessary data without the need to pass it
around. Using the LDA also has less of a performance hit than other
solutions.

The best use of the *LDA in my experience is for sending data to a batch job, especially for use by a subsystem routing program. Yet any data for the program being called as\for the submitted job would best be coded as parameters or obtained from a named location. Some people have changed to use environment variables and CPYENVVAR(*YES) to replace use of the LDA. Outside of SBMJOB...

Newer techniques using ILE could establish effectively the same thing as the LDA [non-object, unnamed] with negligible performance hit to establish the storage and the shared addressing to that storage, shared only amongst known [i.e. coded-as] participants. All of that can be well contained in, and tightly controlled, by that specific set of service or application programs. Such an implementation ensures the location of the data is separate, safe from any unexpected or undesirable references [for read or change] by other programs, such that established standards are more easily "enforced".

If you are concerned about standardization then you can create an
LDA standard for your shop, just like you do with other everything
else.

Standards are great, but only enforcement can ensure they are met; see "enforced" above.

Just because something is old doesn't mean it isn't useful.

Agreed. But when a feature was created for one purpose, and the utility of that feature is extended far beyond that original purpose, there may tend to be conflicts. The LDA is a classic example...

What are your objections to using the LDA?

No [strong] typing nor any other feature of a programming language to enforce the standards for the why, what, and where some data may or may not belong. And worse, nothing that prevents any program on the system [utility or vendor application] from "overlooking" those standards. Unfortunately the tiniest revision of the *LDA by some program operating outside of [even well-]established standards could have a potentially catastrophic outcome; i.e. unpredictable results are far worse [for noticing, in debug, and in possible effect] than a hard failure.

The choice of LDA for implementation of shared storage is conspicuously poor after some technique(s) must be or has been added either to "preserve" the LDA or to "recover" the data in the LDA as a result of some other program(s) "corrupting" the LDA. Until that situation arises [because some other program(s) are and will not be privy to the "standards"], many people will vigorously defend their use of the LDA. Once bitten however, many of those same people will come to revile its use. I have literally laughed out loud having seen a few examples of code performing effective PUSH and POP of the *LDA, changes flagged many years in the past; with me thinking "Why did they not correct this by eliminating the conflict, since they may need to add this same means of protection into several more of their application programs, each after encountering again a similar bug and then debugging and finally another 'fix'? Lather, rinse, repeat. ;-) "

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.