Author: Sam Dodgers
Subject: PL/I: opening file w/ dynamically determined RECFM and LRECL
Posted: Wed Jul 27, 2016 4:05 pm (GMT 5.5)
Hi everyone,
for our test automation effort, I am writing a utility which is to concatenate datasets with various record lengths and write the concatenated contents to a single output file whose LRECL would be the same as the longest LRECL of the input datasets. (Reason is simple: IEBGENER abends when you concatenate datasets with differing LRECLs/RECFMs into it's SYSUT1 in the JCL.)
Since it's supposed to be universal ("because automation"), the utility needs to be very dynamic: any number of input datasets of FB or VB formats and any possible LRECL could be user-entered as input, and either FB or VB record format could be user-required as output.
I have a working prototype which determines the number of input files, the highest LRECL of all of them and expects user-specified RECFM. It does the actual copying/concatenating of any number of input files to the output file and detecting the highest LRECL encountered.
However, I've run into unsolvable problems as for trying to force the output file to have the desired LRECL and RECFM values which are being programatically auto-detected during runtime.
I've consulted the IBM PL/I Programming guide and Reference guide, and Joan Hughes's "PL/I structured programming", but to no avail.
So I was hoping you guys could give me some clue.
Here is what I've tried so far:
Now, I do know two things:
So this is just a matter of finding how to accomplish this feat in PL/I.
Or, if you all agree this really cannot be done, finding a way how to substitute the OPEN statement with calling assembler macro to which I could pass the LRECL and RECFM variables I have and then work with the opened dataset using the standard PL/I I/O statements. (My coworker could provide the HLASM functionality itself, I just don't know how to "interface it" with my PL/I variables.)
Any ideas, please?
Thanks
Sam
Subject: PL/I: opening file w/ dynamically determined RECFM and LRECL
Posted: Wed Jul 27, 2016 4:05 pm (GMT 5.5)
Hi everyone,
for our test automation effort, I am writing a utility which is to concatenate datasets with various record lengths and write the concatenated contents to a single output file whose LRECL would be the same as the longest LRECL of the input datasets. (Reason is simple: IEBGENER abends when you concatenate datasets with differing LRECLs/RECFMs into it's SYSUT1 in the JCL.)
Since it's supposed to be universal ("because automation"), the utility needs to be very dynamic: any number of input datasets of FB or VB formats and any possible LRECL could be user-entered as input, and either FB or VB record format could be user-required as output.
I have a working prototype which determines the number of input files, the highest LRECL of all of them and expects user-specified RECFM. It does the actual copying/concatenating of any number of input files to the output file and detecting the highest LRECL encountered.
However, I've run into unsolvable problems as for trying to force the output file to have the desired LRECL and RECFM values which are being programatically auto-detected during runtime.
I've consulted the IBM PL/I Programming guide and Reference guide, and Joan Hughes's "PL/I structured programming", but to no avail.
So I was hoping you guys could give me some clue.
Here is what I've tried so far:
- The ENV parameter. When I started writing the utility, I had hoped I could use this and easily solve the problem. However, I found out ENV only accepts STATIC variables, i.e. pre-set upon the program initialization, and thus I cannot pass it the LRECL computated during the actual program execution.
- ENV(<RECFM> BLKSIZE(0). I tried using two variables for the output file, one for cases when user requires RECFM=FB and other for RECFM=VB, with both pointing to the same DDname using the TITLE option of the subsequent OPEN statement, knowing that Blocksize=0 should cause auto-detection of LRECL and Blocksize. However, this just results in S013/R=00000034 Abend when the JCL does't specify the DCB of outfile (and the utility cannot require the user to do that - it would beat it's purpose).
- Using EXPORT DD_<DDNAME> statement with LRECL passed as non-static variable. I couldn't get this to work, the compiler keeps saying the statement is invalid. I probably don't understand the usage, the manuals aren't very verbose about this.
- Using the OPEN statement's TITLE with the /filespec attribute: this looked promising, but unfortunately, the TITLE could contain EITHER alternate_ddname OR /filespec, and /filespec seems to require hard-coded DSN. I couldn't have that, for the DSN is to be user-defined in the JCL calling the utility, and I also need the TITLE to point to an "alternate_ddname", because the output file's DD needs to be always reffered to as "OUTFILE" in the JCL.
- Falling back on implicit declarations (i.e. without record length or format being specified in the output file's DCL or OPEN statements). This works without abends and copies the infiles to the OUTFILE, but the output file seems to always be RECFM=VB,LRECL=255 (when testing with longest LRECL of 137 and all the "infiles" being FB) regardless of the length of the CHAR(<lrecl>) variables I am using to write to the OUTFILE.
Now, I do know two things:
- such utility could be programmed, because they are commercially available
- opening a file to write with it's LRECL and RECFM dynamically determined during runtime is possible, because my coworker has an assambler code which does that (I, being Test Automation, don't know HLASM)
So this is just a matter of finding how to accomplish this feat in PL/I.
Or, if you all agree this really cannot be done, finding a way how to substitute the OPEN statement with calling assembler macro to which I could pass the LRECL and RECFM variables I have and then work with the opened dataset using the standard PL/I I/O statements. (My coworker could provide the HLASM functionality itself, I just don't know how to "interface it" with my PL/I variables.)
Any ideas, please?
Thanks
Sam