Friday, June 19, 2026

RUNDATA

 

Over the past several years (since about 2021) I have been grooming my old tools and writing several new ones.   One of those old tools was named RUNDATA, and its purpose was to store persistent data that various applications might need.   I always thought of RUNDATA as a neat-o example of how to use extension variables in ISPF Tables, but over the years it has morphed into something else entirely.

Extension variables are one of the peculiarities of ISPF Tables.   Typically, an ISPF table is defined with (0-n) KEY fields and (0-n) NAME fields.   KEYs are what you would expect from the name: they designate a unique row.   NAMEs are data fields that may occur on each row.   Extension variables are neither of those.   Extension variables are (potentially) unique to each row.   There are even tables (usually ISPF profiles) that have zero KEYs and zero NAMEs;   They're one-row tables where everything is an extension variable!   That's a lot to get your head around, I know.   Stay with me.

Now, when a program, any program, reads an ISPF table row, every table variable that's on that row is populated into the program's data pool.   In REXX, assigning a value to any name creates that name.   What this means is that if (for example) you have a table whose key is RTNNAME, and you

       rtnname = Userid()
       TBGET thetable


EVERY variable on that row — NAME variables whether populated or not, and all extension variables — create new REXX variables or replace the values of existing REXX variables.

So...   you can store all manner of information for a given app as extension variables, TBGET the appropriate row for that app and all that data magically appears in your variable pool.   Slick... but...

For any of a dozen reasons, you may not want to populate every such variable.   So, there's RUNDATA.   RUNDATA does the heavy lifting and sends back via the data queue a series of tag+tagvalue pairs where the 'tag' is the extension variable name, and the 'tagvalue' is the value attached to the extension variable.   You can, if you want, only process certain tags and ignore others.   You can't do that if you read the table directly.

The most obvious use of RUNDATA is for software that needs to be customized site-by-site or user-by-user.   Software that needs to be thus customized can be 'rigged' to call RUNDATA to populate the site-specific or user-specific values.   Then each such site can have its own RUNDATA table pre-populated with the appropriate values.   For user-specific customization, each affected user can have a table row keyed by their userid and populated with the data that this user needs (and every user-specific row could be uniquely configured).

—==+++==—

Understand, RUNDATA is a solution, and it may not even be the best solution.   I've seen one such protocol that used a VSAM KSDS to great effect, and with RXVSAM, using VSAM files this way becomes a practical alternative, especially for non-ISPF use, but for TSO/ISPF applications RUNDATA is ready to rock-'n-roll.

To get your own copy of RUNDATA and its ancillary software, pop on over to the CBTTape site and download File 1056.   Detailed instructions for implementing RUNDATA for — really — any use you can dream up for it are included in the package.

But be careful...   it's addictive.

 

No comments:

Post a Comment