IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

COBOL program for unknown Input file length


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
ParagChouguley

Active User


Joined: 03 Feb 2007
Posts: 175
Location: PUNE(INDIA)

PostPosted: Fri Feb 27, 2009 4:04 pm
Reply with quote

Can one write a cobol program which accepts FB input file but length of that file is unknown or varies?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Fri Feb 27, 2009 4:30 pm
Reply with quote

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
View user's profile Send private message
ParagChouguley

Active User


Joined: 03 Feb 2007
Posts: 175
Location: PUNE(INDIA)

PostPosted: Fri Feb 27, 2009 6:18 pm
Reply with quote

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

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Fri Feb 27, 2009 6:20 pm
Reply with quote

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
View user's profile Send private message
PeD

Active User


Joined: 26 Nov 2005
Posts: 459
Location: Belgium

PostPosted: Fri Feb 27, 2009 6:57 pm
Reply with quote

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

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Fri Feb 27, 2009 7:10 pm
Reply with quote

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
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table

PostPosted: Fri Feb 27, 2009 7:33 pm
Reply with quote

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
View user's profile Send private message
Douglas Wilder

Active User


Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL

PostPosted: Fri Feb 27, 2009 9:03 pm
Reply with quote

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
View user's profile Send private message
superk

Global Moderator


Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA

PostPosted: Sat Feb 28, 2009 1:07 am
Reply with quote

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

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Sat Feb 28, 2009 1:38 am
Reply with quote

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
View user's profile Send private message
superk

Global Moderator


Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA

PostPosted: Sat Feb 28, 2009 1:50 am
Reply with quote

Maybe, right below the "reading a file backwards" topic.
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Sat Feb 28, 2009 5:31 am
Reply with quote

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

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Sat Feb 28, 2009 6:23 am
Reply with quote

William -- the original request was for an FB file, which conflicts with the undefined format.
Back to top
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Sat Feb 28, 2009 5:46 pm
Reply with quote

Robert Sample wrote:
William -- the original request was for an FB file, which conflicts with the undefined format.
It is recommended that you not use format U to update or extend a file that was written with a different record format. If you use format U to update a file that was written with a different format, the RECFM value in the data-set label could be changed or the data set could contain records written in different formats.
But reading seems to be ok.......
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA

PostPosted: Sat Feb 28, 2009 6:59 pm
Reply with quote

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
View user's profile Send private message
William Thompson

Global Moderator


Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ

PostPosted: Sat Feb 28, 2009 7:16 pm
Reply with quote

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
View user's profile Send private message
jasorn
Warnings : 1

Active User


Joined: 12 Jul 2006
Posts: 191
Location: USA

PostPosted: Sun Mar 01, 2009 8:59 pm
Reply with quote

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
Code:

RECORD CONTAINS 0

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
View user's profile Send private message
Douglas Wilder

Active User


Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL

PostPosted: Mon Mar 02, 2009 10:16 pm
Reply with quote

Thank you that is very great!
Back to top
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table

PostPosted: Mon Mar 02, 2009 10:53 pm
Reply with quote

jasorn wrote:
It's not only possible in COBOL to FB input file when the lrecl isn't known at compile time, it's pretty easy.
Good call, even easier than I thought.....
The RECORD CONTAINS 0 CHARACTERS clause can be specified for input QSAM files containing fixed-length records; the record size is determined at run time from the DD statement parameters or the data set label. If, at run time, the actual record is larger than the 01 record description, then only the 01 record length is available. If the actual record is shorter, then only the actual record length can be referred to. Otherwise, uninitialized data or an addressing exception can be produced.
Back to top
View user's profile Send private message
jasorn
Warnings : 1

Active User


Joined: 12 Jul 2006
Posts: 191
Location: USA

PostPosted: Tue Mar 03, 2009 4:47 am
Reply with quote

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
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Wed Mar 04, 2009 8:26 am
Reply with quote

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

Jasorn - which language was used to write your copybook parser?
Back to top
View user's profile Send private message
jasorn
Warnings : 1

Active User


Joined: 12 Jul 2006
Posts: 191
Location: USA

PostPosted: Wed Mar 04, 2009 8:48 am
Reply with quote

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

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
View user's profile Send private message
jasorn
Warnings : 1

Active User


Joined: 12 Jul 2006
Posts: 191
Location: USA

PostPosted: Wed Mar 04, 2009 4:40 pm
Reply with quote

dick, actually, it does program does that too icon_smile.gif. 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
View user's profile Send private message
Douglas Wilder

Active User


Joined: 28 Nov 2006
Posts: 305
Location: Deerfield IL

PostPosted: Wed Mar 04, 2009 9:00 pm
Reply with quote

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
View user's profile Send private message
jasorn
Warnings : 1

Active User


Joined: 12 Jul 2006
Posts: 191
Location: USA

PostPosted: Thu Mar 05, 2009 5:02 am
Reply with quote

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

But it really wasn't that hard. Just a little unusual.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Unable to interpret a hex value to De... COBOL Programming 4
No new posts COBOL sorting, with input GDG base COBOL Programming 7
No new posts Need help with ADABAS query (COBOL-AD... All Other Mainframe Topics 0
No new posts Replacing FILLER with FILLER<SeqNu... DFSORT/ICETOOL 2
No new posts Error to invoke MPP program through B... IMS DB/DC 3
Search our Forums:

Back to Top