Re: Mapped LDA - ILE common variables

[John Carr <74711.77@xxxxxxxxxxxxxx>]

RE:     Re: Mapped LDA - ILE common variables

Your suggestions are great AL.  But look at all the #$%#@ that's involved
when we just try to replicate what the LDA does.

Every trick you mention is to replicate the Garbage Collection function of 
a temporary, 'Unique to the job' , 'Clipboard type' , program to progam
communcation device that trancends the SBMJOB boundary.

Again I submit that no other mechanism possesses the following.

A) Automatically created by the OS for each unique job on the machine.
B) Can't be accessed by some other process/job (private)
C) Trancends the SBMJOB boundary by the OS
D) Gets destroyed by the OS as soon as job is destroyed(garbage collection)
E) Is easily accessable by all programs in the job

Jon P. you never offered a 'suitable' replacement either.

If you wish to debate its use,  I'll state some facts that will 
scare you so much that you would never let PARAMETERS be used again for 
program to program communication in your shop.

'Accident waiting to happen'   Indeed.   Right.   As If. 

P.S. How's the ice Jon?  you ok?

John Carr CDP
EdgeTech


-------------------------------------------
At 08:20 PM 1/12/98 -0500, you wrote:
>
>
>Al Barsa, Jr. wrote:
>
>> At 06:48 PM 1/9/98 -0500, you wrote:
>> >on 01/09/98at 04:32 PM,  our friend Dave Mahadevan <mahadevan@fuse.net>
>> >said:
>> >
>> >
>> >>Please remove the restriction on *LDA being only 1024 bytes.  Please make
>> >>it 1MB. 1024 is too little....:-(
>> >>--
>> >
>> >Even nicer, if possible, would be several *LDAs, all 1024 long.
>>
>> The System/38 did not have *LDA initially.  S/34 folks conplained, so it
>> was added for compatability.
>
>One of the reasons, S/34 people refused to buy oversold S/38.  IBM was
forced to
>introduce S/36 in 1983 (maybe the LDA did the trick!)
>
>>
>>
>> If you need more LDA like space, create a convention to create data areas
>> in QTEMP.
>>
>
>Unfortunately, you cannot pass an existing QTEMP to a job being invoked in
batch.

Dave:

Your comment about the *LDA not being passed to a batch program is
absolutely valid.  When *LDA was implemented (if I remember) it was not
passed to submitted programs, this was a latter addition.

One circumvention would be dedicate a library to the submission of batch jobs.

Submit the batch job, and have the submitted job do some sort of an
immediate wait (this is to insure that timing issues prevent it from taking
off immediately, before the step below completes).

Use the completion message of the submitted job to create a data area in
said library with the name DAVE123456, where DAVE is some sort of system
defined constant, and 123456 is the job number of the submitted job,
putting whatever data you want to pass in the in the data area.  Create a
shop standard for the length of the data area, but the maximum length is
2000 bytes.

This will accomplish passing the data, however it does beg the issue of
cleanup of the library.  If you are ABSOLUTELY POSITIVE that every batch
job will complete before the next IPL, you can use QRPLOBJ.  This will make
the system clean itself up nicely, as OS/400 doesn't use QRPLOBJ for data
areas.  (Caution, some vendors do, but this is relatively easy to check.)
The problem with QRPLOBJ is that this is a private library, and if you try
to make it public, IBM will change it back on you when you least expect it.
 To use QRPLOBJ, you need to create programs that adopt *ALLOBJ to create
the data area and to retrieve it.

If this is unpalitable, or if you can't count on the batch jobs completing
prior to the next IPL, you need to use your own library.  You can put the
proper clean up code in your batch CL program, but make sure that it's also
in your standard error handling routine.  Still this is not foolproof, and
will need to be hand checked periodically or with some other more
sophisticated processing, based on your own business rules.  (For example,
if the batch jobs cannot be hanging around before end-of-month, and in your
EOM processing, you determine that the job queue is empty and no other
batch is processing, clear the library.)

Hope this helps.  Again, I reiterate, don't look for IBM to increase the
size of the LDA.

Al



Al Barsa, Jr. - Account for Midrange-L
Barsa Consulting, LLC.  
400 > 390

Phone:  914-251-9400
Fax:    914-251-9406





Private mail should be sent to barsa@ibm.net
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
uucp
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---