When are arrays useful
An EXEC often has to deal with many instances of the same data type, for example: a number of unit addresses, TSO/E user names, job names, and so on.
Often these data types are part of a record type. In addition to a job name, a job also has a jobstep name, a start time, elapsed CPU time, EXCPs and any amount of additional information.
These data fields can be manipulated by using REXX stem variables but only for a single column or field in a record. TSO/E CLISTs cannot handle this type of data at all. When dealing with multiple fields, you might use several REXX stem variables with the same index but many inefficient operations can result when swapping records or assigning them to a third record. Instead of referring to a single record, REXX stem variables force you to deal with fields only, never considering them as related items.
Furthermore, scanning these records for particular contents or sorting and creating specific subsets of information becomes cumbersome and resource intensive.
This dilemma is where arrays come in: arrays represent data in row-column format where data items are kept together in rows or records. Instead of manipulating this data manually, certain operations may be performed against an array as an entirety, such as sorting it based upon the contents of a column.
To process an array, you create a reference to a specific row (also called a record) and retrieve the entire row into REXX variables. This operation potentially sets a great number of variables all at once. A row is always treated as one unit and the individual fields will never lose synchronization (which might occur when using individual REXX stem variables).
Other advantages to arrays include
- Rows can be filtered so that only those rows whose columns meet certain criteria are visible.
- Rows can be sorted with one command.
- Arrays can be shared among multiple EXECs and saved to permanent storage (DASD).
As a debugging aid, a sample EXEC (DUMPARY) that writes the contents of an array to the BBI journal is included in the BBSAMP library. You can schedule this EXEC from a BBI command line by passing to it, the name of the array and the number of rows and columns to be displayed, for example:
wherearray is the name of an array saved on disk, and 50 rows with 10 columns in each row will be displayed. Additionally, you can schedule DUMPARY from within your own EXEC by specifying one of the following commands:
or
call DUMPARY 'ARRAY(array) ROWS(n) COLS(n) CON(N)'
where array is the name of an array currently accessed by your EXEC. ARRAY is the only required parameter. All parameters can be abbreviated for convenience. The parameter CON(N) is used when your EXEC already has a connection to the array. For more information about abbreviations and examples of how to schedule the DUMPARY EXEC, schedule it from the BBI journal command line, passing to it, the text ' help '. Then read the output in the BBI journal. For example, specify