Joined: 05 Dec 2006 Posts: 177 Location: Seattle, WA
Here's something for us all to chew on.
I have a copybook that has 7 different record layouts defined, each layout with a specific, fixed length. For example, record type 1 is 28 bytes, 2 is 117 bytes, etc. Each record has its own 01 level name.
In the write program, there are 7 output FD's, as we want each record type to be written to its own file.
When the layout of a particular tecord type changes, we just want to have to recompile the program without having to change any coding. This suggests that the FD statement would not define the record length, but that the WRITE statement would pick up the length from the copybook.
Joined: 28 May 2009 Posts: 20 Location: Oklahoma City, OK USA
The answer will depend on how you defind each FD and the WRITE statement.
I have not written COBOL is several years, but I'd suggest you define each FD with one record type by using an 01 then an 05 FILLER with the PIC defining the length.
Then as you write a record, use WRITE record FROM copybook name.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
How about "nesting" the copybooks?
Separate copybook for each 01. Copybook for input file with seven copy statements. Seven individual output files with their individual copybook. WRITE ... FROM ... for the specific 01. When one of the copybooks changes, just recompile (assuming record-type does not change/move).
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
COBOL must know the record length for fixed-length files at compile time. COBOL must know the maximum record length for variable-length files at compile time (although using RECORD VARYING with DEPENDING ON allows you to defer record length determination for output records until execution time, the maximum record length must still be known at compile time).
As long as your code meets these restrictions, you will not have any problems.
Robert mentioned variable-length which I use very much. Example something likeā¦
Code:
FD OUTPUT-FILE
RECORDING MODE IS V
RECORD IS VARYING
IN SIZE FROM 1 TO 3000 CHARACTERS
DEPENDING ON WS-OUTPUT-LENGTH
BLOCK CONTAINS 0 RECORDS.
01 OUTPUT-FILE-REC PIC X(3000).
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Yes, if variable-length records of a fixed-length are required(!), use the same field as specified on the VARYING for the input file on all the seven output files.
One problem will come when a record is changed but the file is not converted yet. You'd want that to be noticed. So test the VARYING against the LENGTH OF for the record-layout, and deal with it however you like...
Joined: 05 Dec 2006 Posts: 177 Location: Seattle, WA
More information: the 7 records are concatenated in fixed lengths within a fixed length copybook:
Code:
01 ACT10ETL-RECORD.
03 some header stuff, also fixed length
03 RECORD-TYPE-1.
03 RECORD-TYPE-2.
etc.
A record type could be absent, but its positions in the full record as maintained by spaces.
Until the copybook (record layout) changes, the individual lengths will remain constant (as will the overall length of the complete ACT10ETL record.
I understand that COBOL has to know the length of the record at compile time - I was just wondering if there was a way to pick up a length from the copybook....maybe something like
Code:
FD SNAPSHOT-FILE
LABEL RECORDS ARE STANDARD
BLOCK CONTAINS 0 RECORDS
RECORDING MODE IS F
RECORD CONTAINS LENGTH(RECORD-TYPE-1).
That looks like I'm mixing JAVA & COBOL....Well, this is probably just wishful thinking on my part.
I've considered dynamic file allocation, but it looks like a maintenance nightmare.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
RECORD CONTAINS requires an unsigned integer so using LENGTH or a variable name will generate a compile error. You may use RECORD CONTAINS 0 to defer final determination of record length until execution time. However, if the length of your 01 under the FD does not match the actual file LRECL in the JCL, you will have problems (such as data truncation) that could be difficult to find.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
OK, an unexpected development :-)
I'd suggest using SORT (you still using SyncSort?).
Make up a "stub" COBOL program that has the copybook in. Compile, putting the output listing in a dataset.
Process the output listing (SORT, REXX, whatever you like) to generate symbols for your group items representing the records you want to extract. Put these symbols in a member.
Code:
ACT10ETL-RECORD,1,whateverlength
some header stuff, also fixed length,=,length,CH
RECORD-TYPE-1,*,length,CH
RECORD-TYPE-2.,*,length,CH
....
I have a copybook that has 7 different record layouts defined, each layout with a specific, fixed length. For example, record type 1 is 28 bytes, 2 is 117 bytes, etc. Each record has its own 01 level name.
In the write program, there are 7 output FD's, as we want each record type to be written to its own file.
When the layout of a particular record type changes, we just want to have to recompile the program without having to change any coding. This suggests that the FD statement would not define the record length, but that the WRITE statement would pick up the length from the copybook.
Is this possible?
It's more than possible. in fact you might consider merely coding only the FD parameters that are necessary and let the operating system do the rest for you. i.e.
FD filename1 BLOCK 0.
COPY A1.
FD filename2 BLOCK 0.
COPY A2.
FD filename3 BLOCK 0.
COPY A3.
FD filename4 BLOCK 0.
COPY A4.
FD filename5 BLOCK 0.
COPY A5.
FD filename6 BLOCK 0.
COPY A6.
FD filename7 BLOCK 0.
COPY A7.
That's all you need for each file. then when the record length changes you not only don't have to rewrite the FD statement you don't even have to worry about the JCL as the operating system takes the DCB from COBOL. Therefore with COBOL don't waste your time coding any DCB parameter in JCL so you won't have anything else to change. i.e.
notice that you don't need to code UNIT because at most shops the default is DASD and you don't need to code anything in the DCB because the operating system does your work for you therefore if your LRECL changes you're home free and only need to change your copybook and recompile as you've desired. Of course you DO need to run a test because your file now is different!!!
notice that you do need to code BLOCK in order to invoke SDB [system determined blocksize] so you don't lapse into buffoonery.
Also if you wish to make all of those fixed length files into a variable length file use IEBGENER as it is one of the best and easiest ways to do that. if you like i'll write that for you if you really need it. it's a snap.
Also if your shop allows compressed extended sequential data sets then by compression or compaction using DATACLAS= you will not even have to use variable length files to get the same result - that of better utilizing space at your shop.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Dale, please use the Code tags.
It is not good to just leave compiler diagnostics lying around in a program. I've not worked anywhere that allows it.
soccer_dad changed the requirement part-way through the topic. Did you see that?
The topic has been inactive for over a month. Usually means the TS is not taking part, so suggested solutions are not much use, as they will never be tested by the TS.
Please try to go for questions which are currently active.