A different job can use the LDA setup from another job.
When a job does a SBMJOB the contents of the LDA is passed to the
submitted jobs LDA.
Of course the LDA of the submitting job will not reflect
any changes done to the LDA in the submitted job.
That's the way you are able to 'pass parms'.
'pass parms' in quote stands for my disagreement in heavy use of the LDA
for passing parms between programs or to submitted jobs.
This because I am working with a system designed with the LDA holding lots
of parms accessed by many programs.
Even if there is a standard layout for the LDA, many
programs use 'own' positions in the LDA. The conflict will come soon or later,
but it isn't easy to change the use of LDA to parm usage in a few days when
the LDA definitions are cluttered among programs.
Use parms instead of LDA is also my recommendation.
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of James Lampert
Sent: Tuesday, August 26, 2008 11:32 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Stuck on accessing the LDA -- manuals no help so far
For pity's sake!
1. The problem has been solved, thanks to Helge Bichel's example, and my
extrapolation thereof. The confusion, once again, was because the manual
said nothing about the LDA being the exception to the rule that you have
to *LOCK the IN, in order to do an OUT.
2. The programs DO run in the same job, and MUST NOT communicate across
3. The programs DO NOT call each other; they are called from exit hooks
in an application, and CHANGES TO PARAMETER PASSING PROTOCOLS ARE OUT OF
This thread ...
Re: Stuck on accessing the LDA -- manuals no help so far, (continued)
This mailing list archive is Copyright 1997-2019 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