× 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.



My bad, Jim. My brain just skipped over that part of James' question. You and Sharon are correct that the LDA is not updated for use outside of the program until the program ends or an explicit OUT is issued to update it. I don't use the LDA in this manner. I'll use a selector program, which populates the LDA by simply setting the field values and ends; the next program is, in my cases, called next in the process (CL or OCL).

In a case such as James described, I'll use a data structure. The calling program (PGMA), for example, may have:

D SIPROTO DS
D #End 1A
D blitm#
D blsqty

Where blitem# and blsqty are fields in a file.

D PGMB PR ExtPgm('PGMB')
D SIUAddr Like(SiProto)

With the invocation:

IF blclas = '500;'
PGMB(SiProto);
ENDIF;

On the receiving end (PGMB) the interface is:

D PGMB PR
D Parms Like(SiProto)

D PGMB PI
D InParms Like(SiProto)

D SiProto DS Based(pSiProto)
D #End 1A
D #Item 5S 0
D #Qty 5S 0

First line of code is:

pSiProto = %Addr(inParms);

In this manner there is no IN/OUT, just setting the address. PGMA simply uses a data structure with the database fields defined in it (although program-defined fields can be used, too). The EVAL to PGMB.

There are advantages, though, to using the Local Data Area, which is also a data structure. Most typical being the one Frank mentioned (not having to add a new parm to the prototype). I tend to use the LDA for global settings, but that doesn't make it wrong to use it for program-to-program communication. The major "problem" with the LDA, in my opinion, is that people overuse it and abuse it; i.e., they get their wires crossed and step all over the LDA fields' values. Which is why I limit myself to using it for global settings and a copy book so that the values are consistent (you'll never get a level check because of a mis-defined LDA field, though you might get a decimal data error).

Jerry C. Adams
IBM System i Programmer/Analyst
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Franz
Sent: Tuesday, August 26, 2008 1:39 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Stuck on accessing the LDA -- manuals no help so far

(pardon me if i'm not 100% on the cycle timing in this..
I beleive lda is read into a pgm when pgm is init.
Even though we can move values to fields in UDS throughout pgm, the actual
data area not updated till LR.

So if PGMA moves new values to lda, then (before ending) calls another pgm
which will read that lda - you must do an explicit OUT to force the update
of the local data area.

must be a named data structure - here name is "LDA"

D LDA UDS
D LDAC# 400 401 0
D LDADV 402 404 0
D LDALC 405 406 0

This defines it - put this at top of calcs or in *inzsr subroutine
C *DTAARA DEFINE *LDA LDA

This updates it. Do this before calling other pgms needing new lda values.
C OUT *DTAARA
UPDATE LDA

*or*

pass parms.... kill the lda.

Jim Franz




----- Original Message -----
From: "James Lampert" <jamesl@xxxxxxxxxxxxxxxxx>
To: <rpg400-l@xxxxxxxxxxxx>
Sent: Tuesday, August 26, 2008 2:31 PM
Subject: Stuck on accessing the LDA -- manuals no help so far


Can somebody point me in the direction of an example of two ILE RPG
programs, neither of which calls the other, communicating with each
other via the Local Data Area?

Preferably without doing an IN on all *DTAARAs known to the program?

When I RTFM on this one, all it does is make me go cross-eyed.

--
James H. H. Lampert
Touchtone Corporation

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


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.