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
midrange.com
