RE: Stuck on accessing the LDA -- manuals no help so far

Addition to the example provided earlier:

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.

Brgds

Helge





-----Original Message-----
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
job boundaries.

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
THE QUESTION.