COBOL program for unknown Input file length

ParagChouguley · Posted: Fri Feb 27, 2009 4:04 pm

Can one write a cobol program which accepts FB input file but length of that file is unknown or varies?

Robert Sample · Posted: Fri Feb 27, 2009 4:30 pm

COBOL can work only with files whose record length can be determined at compile time, since the FD has to provide the record length in the associated 01 level. So the answer to your question is no, one cannot write such a COBOL program.

I've seen this done in the past by using an Assembler subroutine that handles all file activity; Assembler programs don't have to know the length of the file record until the file is opened.

ParagChouguley · Posted: Fri Feb 27, 2009 6:18 pm

Hi Robert,
Thanks for your responce on this. So is there any way to achive this requirement along with COBOL. I mean some other application writing this varying length data to fixed length file which goes as input to COBOL program. or something like that!

Robert Sample · Posted: Fri Feb 27, 2009 6:20 pm

Not with COBOL. COBOL has to know, at compile time, how long the FD record is and that cannot be changed. Unless you want to include a COBOL compile as part of your production job stream to change the length every time a new one is needed ... NOT a recommended practice!

PeD · Posted: Fri Feb 27, 2009 6:57 pm

Robert,

( this is true in PL/I ).
Are you sure you cannot specify a FD record without length and allocate dynamically the file via i.e. BPXWDYN and so allocate a file when its length is not known at compile time.

I repeat in PL/I it is feasable easily.

Robert Sample · Posted: Fri Feb 27, 2009 7:10 pm

Okay, the file is allocated via BPXWDYN. How does COBOL open the file? What does COBOL use for the READ? There no FD so the READ verb isn't going to be usable ...

CICS Guy · Posted: Fri Feb 27, 2009 7:33 pm

Have you looked at Requesting undefined format?
With an undefined format, you will have to do your own de-blocking, but that sould be a simple process.

Douglas Wilder · Posted: Fri Feb 27, 2009 9:03 pm

I have used a COBOL program for a sort exit 15 for this purpose.
Sort does the reading and writing of the files, without you having to specify the record length in your COBOL program, just a maximum record length.

superk · Posted: Sat Feb 28, 2009 1:07 am

Just to add my piddly little thoughts. I could swear that we already hashed this whole concept out in a few previous topics, and came to the consensus in the end that this just can't be done in COBOL alone.

Robert Sample · Posted: Sat Feb 28, 2009 1:38 am

Kevin, I think you're right -- it seems like deja vu all over again! Maybe this topic needs to be added to the FAQ list of no-no topics?

superk · Posted: Sat Feb 28, 2009 1:50 am

Maybe, right below the "reading a file backwards" topic.

William Thompson · Posted: Sat Feb 28, 2009 5:31 am

Robert Sample · Posted: Sat Feb 28, 2009 6:23 am

William -- the original request was for an FB file, which conflicts with the undefined format.

William Thompson · Posted: Sat Feb 28, 2009 5:46 pm

Robert Sample · Posted: Sat Feb 28, 2009 6:59 pm

I still foresee difficulty ... RECFM U has a block descriptor word to tell how long each block is. RECFM FB has no block descriptor word ... so either the first 4 bytes of the block become a nonsensical BDW, or the system generates one based on the block read (which would be pretty unique in my experience) ... but assuming I get some time today, I'll try a COBOL program to read an FB file as U and see what it says.

William Thompson · Posted: Sat Feb 28, 2009 7:16 pm

Back in the olden days, DASD & tape used inter-block gaps to determine the size of the block. The hardware would read the block and hand it to the channel and (as far as I know) would not care if the block was FB, VB or U.

jasorn · Active User Joined: 12 Jul 2006 Posts: 191 Location: USA

It's not only possible in COBOL to FB input file when the lrecl isn't known at compile time, it's pretty easy. The way I do this is:

1. code

Douglas Wilder · Posted: Mon Mar 02, 2009 10:16 pm

Thank you that is very great!

CICS Guy · Posted: Mon Mar 02, 2009 10:53 pm

jasorn · Active User Joined: 12 Jul 2006 Posts: 191 Location: USA

dick scherrer · Posted: Wed Mar 04, 2009 8:26 am

Hello,

Yup, it is also quite handy for generic file compare (the files need to be in sequence by "the key") - user specifies lrecl, key length, number of mis-matches after which to stop, "highlight" the differences, how much of the records to show, etc.

The first i used this was about 20 years ago - i remember where i was, but not which level of operating system and cobol compiler

Jasorn - which language was used to write your copybook parser?

jasorn · Active User Joined: 12 Jul 2006 Posts: 191 Location: USA

Dick,
I wrote the parser in cobol. Sometime in the 1990's. I was planning to use the cobol 2 eztrieve converter that comes with eztrieve somehow but never could get that to work well with redefines and occurs.

So I wrote my own. I recently modified it to also spit out a symnames file for dfsort after a couple hours of not being able to get the similar tool for that to work

Funny you should mention generic file compares because that's exactly why I wrote the parser. Two of the fields on it are key indicator and key sequence. The compare job builds a sort card based on those and sorts the files.

The compare program reads the parsed copybook into an array, uses records contains 0 and file compares are even easier than with eztrieve. I put in quite a few functions but never got around to implementing code to do some of the fancier things eztrieve compares can do such as first dup, last dup, no dup etc.

The nice part about my compare though is it matches on the key you define and then loops through the rest of the fields by looping through the parsed copybook and reports differences at the field level. I've yet to see another compare process do this.

And if you have a copybook for the file the coding is done.

Another nice thing is if you use the same field names you can compare two files with different layouts.

There are lots of other things I do with the parsed copybook and record contains 0. Basically since the code can be based on the fieldnames there is lots of potential.

jasorn · Active User Joined: 12 Jul 2006 Posts: 191 Location: USA

dick, actually, it does program does that too

. Since you created one for a client does that mean the one that comes with eztrieve is ;broken' and it's not just me?

Douglas Wilder · Posted: Wed Mar 04, 2009 9:00 pm

It sound difficult in COBOL to parse a copybook like this. But it would be very useful. It would be great if you were willing to share this, but I understand completely if you do not wish to or cannot share this code.

jasorn · Active User Joined: 12 Jul 2006 Posts: 191 Location: USA