The Local Data Area is a great tool for passing limited amounts of data from one program to the next. When you utilize an externally defined data structure to standardize your LDA definition, you have an extremely effective way to pass data from one program to the next. This combination can be helpful when you are trying to debug programs.

The Local Data Area, or LDA, as it is more commonly referred to, can be a powerful tool for program-to-program communications. The LDA requires very little overhead, is easy to code and maintain, and is automatically supplied with every AS/400 session. It is these very attributes which make it unique and special among the various methods of passing small amounts of information between your programs.

The data in the LDA is only available to the current job. Submitted jobs and jobs running in other workstation sessions each have their own LDAs. On the AS/400, the size of the LDA is 1K, or 1,024 bytes. You can use any or all of the LDA from any of your CL or high-level language (HLL) programs.

In addition, the LDA can be externally described in RPG programs and can be very useful in reducing (or eliminating entirely) the number of parameters that must be passed from one program to the next. This axiom is especially valuable if the data being passed needs to be accessible to only a few links within a long chain of programs. Instead of passing the same parameters from one program to the next, you can place the data in the LDA and access or update the data only in the programs that really need it.

In the case of submitted jobs, the LDA originally consists of a “snapshot” of the LDA from the workstation that submitted the job. Once the submitted job is running, however, the LDA for the submitted job takes on a life of its own. Changes to the data in the submitted job’s LDA do not affect the LDA of the job that submitted it.

Reading the Defense

Defining the LDA in your RPG programs is as simple as defining any other data structure. In Figure 1, we show the simplest definition of the LDA. The U in position 23 of the data structure definition specification (right before the DS) tells the system that we are providing a definition for the LDA.

Here, we have defined the first 43 bytes of the LDA. Even though the total size of the LDA is 1,024 bytes, the program in our example needed to define only the portion of the LDA that it was going to use. You can define subfields either by length or with “From” and “To” positions. In this example, we chose to specify the length of the subfields and let the system calculate the “From” and “To” positions for us.

Once the data is stored in the LDA, it will be available to any subsequent programs in the job.

The key to using the LDA effectively is to ensure that your definitions are consistent from program to program. It is for this reason that we recommend you define your LDA using an externally defined data structure.

What is an externally defined data structure? It is a physical file that is used for data definition instead of data storage. It is both defined with and created using DDS (exactly as you would define a physical file). In Figure 2, you can see DDS for a file used to externally define the LDA in our sample RPG program (Figure 3). If you take a look at the definition specifications, you can see where the LdaDefDS externally described data structure is used to define our LDA. The extname (external name) keyword in the DDS tells the compiler that the LdaDefDS externally described data structure should be used to describe the LDA within our program.

Externally defining the LDA has two major advantages:
1) There will be a consistent definition of the LDA from one program to the next. This will help you to avoid data decimal errors, field-name inconsistencies, and other annoying program termination errors.

2) Changing the definition of the LDA is as simple as changing the definition specifications of the externally defined data structure and recompiling the programs that reference the LDA. Obviously, the programs that need the new definition would need to be changed too, but the process is simplified.

There are a variety of OS/400 commands that are designed to work with data areas. A few of them were designed to work with the LDA, too. These are the Change Data Area (CHGDTAARA), (Display Data Area) DSPDTAARA, and Retrieve Data Area (RTVDTAARA) commands. You simply need to use *LDA as the first positional parameter or enter *LDA when prompted for the data area name.

Watch Out for the Blitz!

The RPG program prompts an operator for parameters required to run a report. (The prompt display is shown in Figure 4.) The operator is required to enter a range of transaction dates, as well as some additional options regarding the printed output. The program edits the entries for validity and issues any errors found. Once the entries are deemed to be error free, the LDA is updated, and the report program (named REPORTCL) is submitted to the job queue.

The first thing the RPG program does is read in the LDA (using the IN op code) and clears all current contents. We do not want whatever happens to be there to interfere with the operation of our report prompt program. We then call a simple CL program that retrieves the operator default printer ID and Output Queue names via the Retrieve Job Attributes (RTVJOBA) command. The retrieved values will be presented on the prompt screen as default values.

The program then establishes a loop that will present the prompt screen and perform an edit on the values entered. If the values entered are valid, the program writes the values out to the LDA using the OUT op code. The REPORTCL program will then be submitted to the job queue. If errors are found, they will be presented on the screen. The operator will remain in the loop until valid entries are keyed and the report is submitted, or the operator presses the F3 function key to exit.

We should note that the IN and OUT op codes in our RPG program were necessary only because we needed to read and write the contents of the LDA outside of the program

cycle. We could have omitted the op codes if we wanted the LDA read at program initialization and written at program termination.

Since the LDA of a submitted job is initially the same as that of the submitting job, the LDA established in our report prompt program is available to any program called within the submitted REPORTCL job.

Look for the Open Man

Submitted jobs can sometimes be a real pain to debug. That is not the case with our submitted REPORTCL job. Why? Because by simply using the DSPDTAARA command (with *LDA as the primary positional parameter), you can see the parameters that were submitted with the job.

The other reason it is easy to debug a program using the LDA is that you may now run the submitted job (REPORTCL, in our case) interactively. Since the data required in order for the report to run is stored in the LDA, we do not have to hassle with the parameters which would normally need to be passed to our called program. If we need to change one of the parameters for our test, we simply use the CHGDTAARA command to do so.

First Down!

When you combine the use of two pretty good tools, like the LDA and externally described data structures, you can end up with results that exceed expectations. In this particular case, we ended up with code that was easier to understand, debug, and maintain. Hopefully, this will allow us more time to work on the projects we would prefer to work on.

Figure 1: Program-described definition specifications defining the LDA Figure 2: Externally described data structure used to define the LDA

DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords
D LDA UDS
D DeviceID 10
D OutQueue 10
D Copies 3S 0
D DateFrom L
D DateTo L A R LDAREC TEXT('Local Data Area Desc')
A DEVICEID 10A TEXT('Printer ID')
A OUTQUEUE 10A TEXT('Name of OutQueue')
A COPIES 3S 0 TEXT('Number of Copies')
A DATEFROM L TEXT('Report "From" Date')
A DATETO L TEXT('Report "To" Date')

FLDA001Ds cf e workstn

D Command s 512
D Length s 15 5 *

d Lda euds extname(LdaDefDS)

c *dtaara define *lda Lda
c in Lda
c clear Lda
c eval Copies = 1 * retrieve USER ID default values for Printer ID and OutQ
c call 'LDA001CL'
c parm DeviceID
c parm OutQueue

c dou *InKc
c exfmt prompt * clear error indicators
c movea '0000000' *in(40) * eoj requested
c if *InKc
c leave
c endif * edit format entries
c *mdy test(d) FromDate 41
c *mdy test(d) ToDate 42 * "from" date must be less than "to" date
c if *in41 = *off and *in42 = *off
c *mdy move FromDate DateFrom
c *mdy move ToDate DateTo
c if DateFrom > DateTo
c eval *In43 = *On
c endif
c endif * must specify a printer and the number of copies
c DeviceID comp *blanks 44
c Outqueue comp *blanks 46
c Copies comp *zeros 45 * if any errors are found, set the alarm and re-submit display
c if *in41 or *in42 or *in43 or *in44 or
c *in45 or *in46
c eval *in40 = *on
c iter
c endif * free of errors, so submit report

* Write LDA
c out Lda * Submit report to the job queue
c eval command = 'sbmjob cmd(+
c CALL PGM(REPORTCL))'
c call 'QCMDEXC'
c parm command
c parm 28 length
c leave
c enddo
c eval *inlr = *on

Figure 3: RPG Report Prompt program

<>
<>
<>

Figure 4: Sample Report Prompt screen

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails