In an MVS environment, I have a COBOL program to read a variable length input file that is a database dump. The fields are variable length, with a delimiter char between fields. The program will also read in a COBOL copybook that has each field defined with a maximum size, i.e. PIC X(014). The program creates a table of field lengths based on the PIC clauses, and then works through each record to expand each field to its fixed maximum length. The problem I have is with the output file - I want the program to be generic enough to work for several different files, so the output record will be fixed length in each execution, but a different length for different executions (different input file/copybook). I would like to define the output record to be long enough to handle all the files, and then let the JCL dictate the actual length of each output file. Any ideas?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Set output record length in JCL?
- Thread starter Red1
- Start date
Hi Red,
I don't think you can do what you want unless you use the envirnmental variable approach.
Since the pgm will be changed for the i/p and copybook, changing the o/p lrecl too shouldn't be a problem. Or is the c/b being used as another i/p file and you parse it to get the PIC sizes?
Other issues:
Just wondering why you're using a table and not using an unstring into the copybook fields.
What is the delim char?
How are empty fields represented?
Do the numeric fields contain ", . $" etc.?
I don't think you can do what you want unless you use the envirnmental variable approach.
Since the pgm will be changed for the i/p and copybook, changing the o/p lrecl too shouldn't be a problem. Or is the c/b being used as another i/p file and you parse it to get the PIC sizes?
Other issues:
Just wondering why you're using a table and not using an unstring into the copybook fields.
What is the delim char?
How are empty fields represented?
Do the numeric fields contain ", . $" etc.?
I'll bet you can change the LRECL of the DCB by using some fancy coding involving ADDRESS OF and USAGE IS POINTER fields.
See: and
In the old days, I'd do this sort of thing in an assembler subroutine.
Glenn
See: and
In the old days, I'd do this sort of thing in an assembler subroutine.
Glenn
Hi Glenn,
You may be able to do that, but in a COBOL pgm, in addition to the DCB, you have an FCB and an FIB (both off of the TGT) that you may have to contend with. There may be others.
It starts to get messy. Personally I'd leave it alone.
Regards, Jack.
You may be able to do that, but in a COBOL pgm, in addition to the DCB, you have an FCB and an FIB (both off of the TGT) that you may have to contend with. There may be others.
It starts to get messy. Personally I'd leave it alone.
Regards, Jack.
Hi Red1,
You can still do it in COBOL: you will need to use DDL (Data Definition Language), though.
If you have access to DDL, we'll show you how to do this; you may figure it out already, if you are familiar with the DDL dictionary. Everything you need will be in this dictionary: record type/length, field type/length/offset, etc... The JCL would only have to tell COBOL which record to process (or the data itself could do this).
Come to think of it, if you do not have access to DDL, we can show you how to build your own 'dictionary'.
Dimandja
You can still do it in COBOL: you will need to use DDL (Data Definition Language), though.
If you have access to DDL, we'll show you how to do this; you may figure it out already, if you are familiar with the DDL dictionary. Everything you need will be in this dictionary: record type/length, field type/length/offset, etc... The JCL would only have to tell COBOL which record to process (or the data itself could do this).
Come to think of it, if you do not have access to DDL, we can show you how to build your own 'dictionary'.
Dimandja
- Thread starter
- #6
The copybook is used as an input file in this program, so the pgm parses through it to table up the field lengths. Then the input data file is examined and each field (between delimiter characters) is expanded to the correct length (padded with spaces). The input data file is defined as varying in size with a maximum length much longer than really needed, so it can handle various input files.
I want to avoid having to change the output record length and compile the program again for each input file processed.
The delimiter char can vary, but is usually a tab char. Empty fields are represented by 2 delimiter chars side by side. I have other programs that examine each expanded field and validate the data, left or right justify, etc.
I don't want this to get too messy--I have considered making the output file extra long (the same for every file-no re-compile) and then cut the file down to size in a separate job step using a utility to copy the file.
I want to avoid having to change the output record length and compile the program again for each input file processed.
The delimiter char can vary, but is usually a tab char. Empty fields are represented by 2 delimiter chars side by side. I have other programs that examine each expanded field and validate the data, left or right justify, etc.
I don't want this to get too messy--I have considered making the output file extra long (the same for every file-no re-compile) and then cut the file down to size in a separate job step using a utility to copy the file.
Hi Red,
You can call some utils from a cobol pgm. IDCAMS comes to mind. I saw a presentation of a technique for calling icams @
What this will allow you to do is call idcams to write the recs and use the JCL lrecl to define the size of the rec. You don't define an FD for the o/p and use SYSUTx in your JCL. I didn't read it too closely, but it looked interesting.
On their home page go to the bottom RH side of the window and work your way straight up looking for "Full listing of tips and newsletters". Click there then look for "Developer Tips". There are about 9 pgs of tips. Click on page 9 and look for
"Horrible things COBOL can do with IDCAMS!" by Jim Keohane.
Your approach has development simplicity on its side; the IDCAMS approach has user transparency. Depends on what's most important in your circumstances.
HTH, Jack.Hi Red,
You can call some utils from a cobol pgm. IDCAMS comes to mind. I saw a presentation of a technique for calling icams @
What this will allow you to do is call idcams to write the recs and use the JCL lrecl to define the size of the rec. You don't define an FD for the o/p and use SYSUTx in your JCL. I didn't read it too closely, but it looked interesting.
On their home page go to the bottom RH side of the window and work your way straight up looking for "Full listing of tips and newsletters". Click there then look for "Developer Tips". There are about 9 pgs of tips. Click on page 9 and look for
"Horrible things COBOL can do with IDCAMS!" by Jim Keohane.
Your approach has development simplicity on its side; the IDCAMS approach has user transparency. Depends on what's most important in your circumstances.
HTH, Jack.Hi Red,
Hi Glenn,
It may work because Red mentioned he’d use IEBGENER or something downstream to get the file he really wants.
But, as a general concept, I like the idea of CALLing IDCAMS to do the read/writes in a situation where you’re writing a generalized utility that can handle files of varying lrecls. For example, I wrote a compare pgm that wrote a separator line that starred (*) the chars that didn’t match. I had to change the FD any time I used a different pair of files.
With the IDCAMS approach you can use the same pgm for any set of files.
Regards, Jack.
It may work because Red mentioned he’d use IEBGENER or something downstream to get the file he really wants.
But, as a general concept, I like the idea of CALLing IDCAMS to do the read/writes in a situation where you’re writing a generalized utility that can handle files of varying lrecls. For example, I wrote a compare pgm that wrote a separator line that starred (*) the chars that didn’t match. I had to change the FD any time I used a different pair of files.
With the IDCAMS approach you can use the same pgm for any set of files.
Regards, Jack.
- Status
Similar threads
- Locked
- Question