A data area is kind of like a single-column, single-row TABLE. It is intended to store a single value, although the value can be a data structure up to 2000 bytes in length.
A data area is an object that holds a single value (which may be a structure.)
It has getter and setter methods (RTVDTAARA and CHGDTAARA), constructor (CRTDTAARA), and destructor (DLTDTAARA.).
A “local data area” is one of the special instances of data area objects. It is created when a job starts and destroyed when the job ends. It is accessible only by that job. Its name is always “*LDA”.
But when one job submits another job for batch execution, the <i>content</i> of the *LDA of the submitting job is copied to the new *LDA of the submitted job. That means there are two copies of the data, stored in two objects.
If the submitting job has placed a particular value in its *LDA, then that value will be passed into the other *LDA at the moment the second job is submitted. After the submission, any changes to the first *LDA will have no effect on the second job’s *LDA. Further, changes to the second *LDA will never affect the first *LDA.
There isn’t much to show for a coding example. A trivial example works from a command line:<pre>
SBMJOB CMD(DSPDTAARA DTAARA(*LDA)) JOB(TSTLDA)
CHGDTAARA DTAARA(*LDA) VALUE(‘Here”s a value to display!’)
SBMJOB CMD(DSPDTAARA DTAARA(*LDA)) JOB(TSTLDA)</pre>
Simply submit a job twice, once before setting a value in your interactive job’s *LDA and once after. You can look at the spooled output for the two jobs to see the difference. The first job will display a blank value, where the second job will display a value of “Here’s a value to display!”
(Note that the first job will display a blank value <i>only</i> if your interactive job’s *LDA was in fact blank to start with.)
A practical example might be a little more difficult. Given the other capabilities of the system, there might not really be any practical uses. I generally wouldn’t use the *LDA to pass information under most circumstances; I’d probably use parameter values or a user index object instead, among other possibilities.
To arrive at a practical example, it’s almost necessary to start from an assumption that you are stuck with an old (potentially obsolete!) application that relied upon *LDA usage. If you submit a job that calls a program that expects to find a control variable value in *LDA, then you’re pretty much stuck with it.
But perhaps you need to obscure a value. You don’t want to use a parameter value because the command can be viewed in the joblog of the submitted job. Perhaps you want to pass an encryption key or password and you don’t want it easily viewable. It’s not strictly secure, but you can store it in your *LDA and submit the job without having the value (easily) visible outside the job.