View previous topic :: View next topic
|
Author |
Message |
ParagChouguley
Active User
Joined: 03 Feb 2007 Posts: 175 Location: PUNE(INDIA)
|
|
|
|
Can one write a cobol program which accepts FB input file but length of that file is unknown or varies? |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
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. |
|
Back to top |
|
|
ParagChouguley
Active User
Joined: 03 Feb 2007 Posts: 175 Location: PUNE(INDIA)
|
|
|
|
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! |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
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! |
|
Back to top |
|
|
PeD
Active User
Joined: 26 Nov 2005 Posts: 459 Location: Belgium
|
|
|
|
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. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
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 ... |
|
Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007 Posts: 2146 Location: At my coffee table
|
|
|
|
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. |
|
Back to top |
|
|
Douglas Wilder
Active User
Joined: 28 Nov 2006 Posts: 305 Location: Deerfield IL
|
|
|
|
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. |
|
Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
|
|
|
|
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. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
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? |
|
Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
|
|
|
|
Maybe, right below the "reading a file backwards" topic. |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
|
|
superk wrote: |
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. |
I am sorry Kevin, but I do think it is possible, undefined format kind of leaves the format and deblocking to the reader.... Grin.... |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
William -- the original request was for an FB file, which conflicts with the undefined format. |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
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. |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
|
|
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. |
|
Back to top |
|
|
jasorn Warnings : 1 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
In the FD statement.
e.g.
Code: |
FD IN-FILE
RECORDING MODE IS F
RECORD CONTAINS 0
LABEL RECORD STANDARD.
01 IN-FILE-REC PIC X(3000).
|
2. Make the PIC clause on the FD statement at least as long as the longest you'll need.
3. Pass the lrecl via linkage to the program that's going to read the file.
4. When the file is read, read it into a working storage variable using reference modification. I make the working storage variable the same length as the longest lrecl I expect is possible for this program. The read looks something like this:
Code: |
READ IN-FILE INTO WS-IN-FILE-REC(1:LRECL-PASSED-FROM-LINKAGE)
|
Then your program just has to be smart enough to figure out what to do with the different input lengths.
I haven't found any nice way to accomplish the same with the output file and still use FB.
Edit: Maybe this one. |
|
Back to top |
|
|
Douglas Wilder
Active User
Joined: 28 Nov 2006 Posts: 305 Location: Deerfield IL
|
|
|
|
Thank you that is very great! |
|
Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007 Posts: 2146 Location: At my coffee table
|
|
Back to top |
|
|
jasorn Warnings : 1 Active User
Joined: 12 Jul 2006 Posts: 191 Location: USA
|
|
|
|
CICS Guy wrote: |
Good call, even easier than I thought.....
|
Yeah it's pretty easy but not very many mainframers I meet think it's even possible without calling some sort of dynamic allocation program. I've used this for quite a while to write many generic utility programs and it's really a time saver.
Coupled with the process I wrote to parse out a copybook and load the field names, start and stop positions, etc into an array and this is very powerful indeed. Nearly magical.
But it's not without pitfalls, you have some extra or different type of validation to consider when using this method. The comments should be aplenty if this kind of thing is used in production. I recommend erroring on the side of not using in production unless options are weighed carefully, it's well documented and tested very well. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
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? |
|
Back to top |
|
|
jasorn Warnings : 1 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. |
|
Back to top |
|
|
jasorn Warnings : 1 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? |
|
Back to top |
|
|
Douglas Wilder
Active User
Joined: 28 Nov 2006 Posts: 305 Location: Deerfield IL
|
|
|
|
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. |
|
Back to top |
|
|
jasorn Warnings : 1 Active User
Joined: 12 Jul 2006 Posts: 191 Location: USA
|
|
|
|
Douglas Wilder wrote: |
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. |
Actually, I've been meaning to share this with the hopes the community would contribute enhancements.
I'm not sure now how my company would feel about that. I could check. While I created this on my own time and computer for the pc a long time ago and I wouldn't share any enhancements I made on my company's dime I'd have to see if there are legal ramifications.
I did get a bonus for this from my current employer. Actually, this is the 3rd company that's given me some kind of award for it
But it really wasn't that hard. Just a little unusual. |
|
Back to top |
|
|
|