Your confusion reflects why Natural was changed to introduce the Global Data Area.
The AIV needs to have a definition before the program can be compiled. So, if you don’t want to put the definition in “SUBPROG”, then you have to do something to define the AIV before you can compile SUBPROG - such as running a program that already has the AIV defined. That puts the AIVs in the program in the AIV area in the workspace (try edit +V to see them). When you compile SUBPROG with reference to an AIV that is already in the AIV area, the definition is added to the compiled object.
Another approach was to always include the definition of the AIVs in the programs that were going to use them. The danger of this approach was that the definitions were not always compatible or correct, resulting in run time errors or data loss. So the alternative Graeme mentions became the best practice - always have a single module that does nothing but define the AIVs, catalog it and run it before compiling any programs. No format/length definitions should then be included in the programs/subprograms/etc.
Like all “global data”, AIVs are inherently non-modular and non-object oriented. Operations in one module can have side effects in other modules when global data (AIVs) is used.
You would add an AIV to a map the same way you define local variables:
Ob M Ob D CLS ATT DEL CLS ATT DEL
. . T D Blnk T I ?
. . A D _ A I )
. . A N ¬ M D &
. . M I : O D +
. . O I (
. .
008 --010—±—±—±–030—±—±—±–050—±—±—±–070—±—
ERROR-REPLY-QUEUE (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
DATA-REPLY-QUEUE (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
DATA-REQUEST-QUEUE (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
TRANS-REPLY-QUEUE (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
TRANS-REQUEST-QUEUE (XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ERROR-REPLY-HOBJ (9999999999
LE ID (XX
NATPROC (XXXXXXXX
Edit the field with .E to provide your AIV name and format/length and AD attribute for display-only:
