The batch submission program lists the Query(ies), Form(s) or Procedure(s) that are being requested to be submitted.
The batch submission screen program will create SYSPRT cards based on the sample that is in the MDLBATCH member of the hghlvl.MODEL dataset. PRF takes the SYSPRT01 card from the model and then models all other SYSPRT cards based on this model.
The note in the model states:
//* - PRF WILL CREATE AS MANY SYSPRT## CARDS AS NEEDED TO *
//* UNIQUELY CATAGORIZE THE OUTPUT INTO *
//* CLASS/FORM/DESTINAT/COPIES GROUPS. *
//* ALL OUTPUT MATCHING THE GIVEN CRITERIA WILL BE GROUPED *
//* WITH OTHER SIMILAR OUTPUT. *
PRF will not create a separate output DD for each report.
So looking at the model SYSPRT01 card that is distributed by PRFDEV:
//SYSPRT01 DD SYSOUT=(%CLASS,,%FORM),DEST=%DESTINAT,COPIES=%COPIES,
PRF will create as many SYSPRTnn cards as necessary to have as many unique DDNames as is required by the objects being executed in batch. THIS IS DONE WHEN THE BATCH JOB IS CREATED. PRF analyzes all of the print parameters on the Batch submission screen and groups the objects into the similar requirements. Conceivably, there could be up to 40 SYSPRT cards as there can be up to 40 objects submitted in a batch run, the limit of the batch submit screen.
The uniqueness of the DD cards is based on the substitution parameters noted in the example by the %. So in our default sample, uniqueness is based on class, form, destination, copies and FCB.
Now, the customer CAN customize the model. If SYSPRT01 in the model is changed, then the changed DD statement is used for the modeling of ALL generated DDNames.
PRF writes the batch control cards then with the appropriate SYSPRTDD= subcommand for each PRF object in the batch submission list.
If an object is included in a PRF PROCEDURE, the batch submission screen will not know what its required parameters are, AND there could be several objects in a procedure that have different requirements. PRF does not look into the procedure to determine the current needs of the procedure since the procedure could change at a later date. PRF solves this dilemma by the concept of dynamic printing. When objects are processed in batch at runtime, PRF adds a SYSPRTDD=DYN subcommand to the beginning of the subcommand list. The order is important because PRF parses the subcommands in order, keeping only the last of any repeated subcommand. If there is no other SYSPRTDD subcommand, PRF processes the print using a dynamically allocated DD at RUNTIME using the object's parameters as saved with the object. In this case EACH object is printed to its own DD regardless of similar attributes. If the objects noted in the PRF PROCEDURE have a SYSPRTDD coded in the subcommand list, then that SYSPRT will be used when the object is run in batch based on the subcommand order precedence noted above.
DDs with specific attributes for a report or a class of reports can be included in the match model. These DDs will be generated with each batch job but will only be used when required. Our recommendation is that DD's with specific attributes be numbered higher than 40. These DDs should also be published and standard as PRF will not manipulate these DD's from the model. Anyone can then code a SYSPRTDD=nn, where 40 < nn < 99, to use the DD with the specific attributes.
Using or defaulting to SYSPRTDD=DYN will have PRF generate dynamic DDs with names following the pattern: SYSnnnnn where nnnnn is a sequential number usually starting at 00001.
So, the concept then is that from the batch submission screen, all queries and forms are sent to a SYSPRT DD based on the parameters noted AND PRF will generate these DDNAMES based on the model's SYSPRT01 card. If the user submits a PROC in batch, PRF has no way at submit time to discern the contents of the PROC and therefore its default action is to dynamically allocate the DD at runtime for each object in the PROC. This default processing is overridden by a SYSPRTDD= subcommand in the RUN commands that are contained in the PROC. If this is done, the DD MUST be predefined in the batch job that is submitted.