Seeking inspiration ...

Ken,
This is exactly how Infinium from Infor passes parms to batch jobs.

The Master-Parm-File is defined with a key of 28 (10 for job, 10 for
user, and 6 for time and 6 for date).
The rest of the record is loaded with fields that some ancient
programmer guessed would be needed.
If the fields are not appropriate, then the maintenance pgmr steals and
remaps his values into the master-file fields to fit his needs.

Another method seen in some modules is one huge open area after the
key-fields. A copy of the submit screen is stored in this large area,
and data-structures based on the submit screen from the submitter are
loaded as a Struct. The submitted program uses the same Struct to
extract the fields the user entered on the submit screen.

Obviously, the submitted programs do need to get passed the "LDA-key" of
28A as a parm/data-structure. And submitter and submitted have a
contract between the two programs to know where to find the fields they
need.

another suggestion ...

A permanent file with two key fields and one or more non-key fields.
Key field 1 is the job identification of the submitting job (i.e. job

name plus user plus job number). Key field 2 is a timestamp keyed
descending. The non-key field(s) are whatever you need to store the
data you want > to pass.

Before the SBMJOB takes place, the submitting job runs a program to

write a record to the file with the submitting job's identification, the
current timestamp, and the data to be passed.

The submitted job runs a program which gets the submitting job's

identification and the timestamp of when the submitted job was
submitted. It does a setll to the file with those two pieces of
information followed by a > reade with just the job identification.

Unless someone changes the system date or time while the submitting

job is doing its thing, this should retrieve the record which contains
the data that this submitted job needs.