Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

COBOL records Write Problem

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
socker_dad

Active User


Joined: 05 Dec 2006
Posts: 147
Location: Columbia, MO

PostPosted: Tue Jun 04, 2013 12:34 am    Post subject: COBOL records Write Problem
Reply with quote

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.

Is this possible?
icon_wink.gif
Back to top
View user's profile Send private message

CaptBill

New User


Joined: 28 May 2009
Posts: 15
Location: Oklahoma City, OK USA

PostPosted: Tue Jun 04, 2013 1:01 am    Post subject: Reply to: Interesting COBOL Write Problem
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Tue Jun 04, 2013 1:40 am    Post subject: Reply to: Interesting COBOL Write Problem
Reply with quote

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).
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Tue Jun 04, 2013 3:23 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Tue Jun 04, 2013 5:11 am    Post subject: Reply to: Interesting COBOL Write Problem
Reply with quote

Review this previous post -

http://ibmmainframes.com/viewtopic.php?t=58351&highlight=wsinputlgth
Back to top
View user's profile Send private message
Gary McDowell

Active User


Joined: 15 Oct 2012
Posts: 139
Location: USA

PostPosted: Tue Jun 04, 2013 7:59 am    Post subject:
Reply with quote

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).

       WORKING-STORAGE SECTION.
       01  WS-OUTPUT-LENGTH        PIC 9(08) COMP.

       PROCEDURE DIVISION.
           MOVE LENGTH OF WS-COPYBOOK-1  TO WS-OUTPUT-LENGTH
           MOVE WS-COPYBOOK-1            TO OUTPUT-FILE-REC
           WRITE OUTPUT-FILE-REC

           MOVE LENGTH OF WS-COPYBOOK-2  TO WS-OUTPUT-LENGTH
           MOVE WS-COPYBOOK-2            TO OUTPUT-FILE-REC
           WRITE OUTPUT-FILE-REC

           Etc.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Tue Jun 04, 2013 1:11 pm    Post subject: Reply to: Interesting COBOL Write Problem
Reply with quote

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...
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Tue Jun 04, 2013 6:30 pm    Post subject:
Reply with quote

Is dynamic allocation a possibility?
Back to top
View user's profile Send private message
socker_dad

Active User


Joined: 05 Dec 2006
Posts: 147
Location: Columbia, MO

PostPosted: Tue Jun 04, 2013 8:25 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Tue Jun 04, 2013 8:42 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Wed Jun 05, 2013 4:00 am    Post subject: Reply to: Interesting COBOL Write Problem
Reply with quote

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
      ....

 OPTION COPY
 OUTFIL FILES=1,BUILD=(RECORD-TYPE-1)
 OUTFIL FILES=2,BUILD=(RECORD-TYPE-2)
 ...

Don't put any DCB info in the JCL for the output datasets.

When the COBOL copybook changes, regenerate the symbols.

If it is not Production and you want to stick to COBOL,you can consider this.
Back to top
View user's profile Send private message
Dale Robertson

New User


Joined: 21 Jun 2013
Posts: 44
Location: U.S.A.

PostPosted: Wed Jul 10, 2013 12:42 am    Post subject: Re: Interesting COBOL Write Problem
Reply with quote

dad,

socker_dad wrote:
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 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?
icon_wink.gif


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.

//filename1 DD DSN=OUT.FILE,DISP=(,C,D),SPACE=whatever
//filename2 DD DSN=OUT.FILE,DISP=(,C,D),SPACE=whatever
//filename3 DD DSN=OUT.FILE,DISP=(,C,D),SPACE=whatever
//filename4 DD DSN=OUT.FILE,DISP=(,C,D),SPACE=whatever
//filename5 DD DSN=OUT.FILE,DISP=(,C,D),SPACE=whatever
//filename6 DD DSN=OUT.FILE,DISP=(,C,D),SPACE=whatever
//filename7 DD DSN=OUT.FILE,DISP=(,C,D),SPACE=whatever

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.

r

"Trust me Marion."
--Indiana Jones.
Back to top
View user's profile Send private message
Dale Robertson

New User


Joined: 21 Jun 2013
Posts: 44
Location: U.S.A.

PostPosted: Wed Jul 10, 2013 2:35 am    Post subject:
Reply with quote

dad,

so if you want to allocate a RECFM=VB out of these items that you allocated FB:

Code:
//filename1 DD DSN=OUT.FILE1,DISP=(,C,D),SPACE=whatever
//filename2 DD DSN=OUT.FILE2,DISP=(,C,D),SPACE=whatever
//filename3 DD DSN=OUT.FILE3,DISP=(,C,D),SPACE=whatever
//filename4 DD DSN=OUT.FILE4,DISP=(,C,D),SPACE=whatever
//filename5 DD DSN=OUT.FILE5,DISP=(,C,D),SPACE=whatever
//filename6 DD DSN=OUT.FILE6,DISP=(,C,D),SPACE=whatever
//filename7 DD DSN=OUT.FILE7,DISP=(,C,D),SPACE=whatever

merely duplicate this 6 times:

...IEFBR14... to delete the old cataloged files...then

Code:
//JS2 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=OUT.FILE1,DISP=SHR,NCP=10
//SYSUT2 DD DSN=&T1,SPACE=(CYL,1,,MXIG),UNIT=VIO,NCP=10,
//                LRECL=32,RECFM=VB,DISP=(,PASS)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
 GENERATE MAXFLDS=1
     RECORD FIELDS=(28,1,,1)
/*

... you get the idea...then finally...

//JSFINAL EXEC PGM=IDCAMS
//SYSUT1 DD DSN=&T1,DISP=(OLD,DELETE)
//            DD DSN=&T2 etcetera for all 7.
//SYSUT2 DD DSN=FINAL.FILE,DISP=(,C,D),SPACE=whatever,
//               LRECL=highest lrecl +4,RECFM=VB 
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
 REPRO INFILE(SYSUT1) OUTFILE(SYSUT2)
/*
//
Code'd

good luck
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Wed Jul 10, 2013 12:10 pm    Post subject: Reply to: Interesting COBOL Write Problem
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Removing Duplicates based on certain ... chandracdac DFSORT/ICETOOL 8 Fri Dec 09, 2016 4:40 am
No new posts Limit duplicate records in the SORT pshongal SYNCSORT 6 Mon Nov 21, 2016 12:54 pm
This topic is locked: you cannot edit posts or make replies. RANDOM Function in COBOL swapnil781 COBOL Programming 2 Tue Nov 15, 2016 6:17 pm
No new posts Problem in writing Output file vickey_dw COBOL Programming 5 Mon Nov 14, 2016 11:14 pm
No new posts Regarding COBOL Stored Procedure opti... selvamsrinivasan85 DB2 4 Fri Nov 04, 2016 8:57 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us