Creating a file in Enterprise Cobol dynamically, LRECL is known only at run time.

My challenge is that I want my output file's length to be determined at run time (390 Cobol). I want it to be fixed (not variable), but potentially a different fixed length each time it runs. This length could EITHER be taken from the JCL DD statement (new allocated file, complete with DCB information) or calculated in the program -- either approach works for me, although the latter is preferred. From all my reading, it appears that to use the information from the JCL, I *should* be able to code the output file FD with "RECORD CONTAINS 0 CHARACTERS". However, the Cobol compiler gives an error on the OPEN OUTPUT for this FD:
IGYPA3143-E Physical "SEQUENITAL" file "OUT-FILE" specified in an "OPEN OUTPUT" or "OPEN EXTEND" statement was defined with a "RECORD CONTAINS 0 CHARACTERS" clause. The statement was processed as written.
This works fine for the input files, by the way, but I can't figure out how to do so for the output file.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


It's been some 30 years since I worked with mainframe COBOL, so I have no answer. But no one has responded, so maybe I can get a dialog going that helps lead to a solution. If the file object _exists_ when the program is started, I would expect that RECORD CONTAINS 0 CHARACTERS should work.

I'm curious, though, how your record description entries would be expected to change to accommodate different file LRECLs at run-time. Can you show your FD and the buffer record description below it?

No mainframe dialect of COBOL that I have ever worked with over the past 40 years has supported writing to files with recsize/blksize being unknown at compilation time.  However, I have found a couple of ways in the past to accomplish this.

The first way involved discovering the fixed offset between the addresses of the record buffer (the 01 name) and the DCB the compiler builds for the matching FD.  Using that info I added a second record descriptor (another 01) that defined a 1-byte field that occurred some number of times (the number only needed to match the length of the first 01 in order to avoid compiler errors relating to FIXED vs VARIABLE length record declarations).  Then using the offsets of the DCB plus the offsets of the LRECL and BLKSIZE fields within the DCB itself I calculated the appropriate subscript value of the 1-byte field to "poke" the desired LRECL and BLKSIZE values into the DCB before opening the file for output.

This method worked for several years until we upgraded the compiler to a newer product.  I don't remember the rationale now but instead of trying to repeat the above technique I decided to write an assembler routine to use in conjunction with the COBOL apps and avoid all the clever hacking.  The asm module provided several functions that allowed the COBOL app to handle all the setting of the LRECL and BLKSIZE values and to perform the OPEN/CLOSE/WRITE functions as well.  This had two primary benefits:  1.  It was a much more standard technique that shouldn't break the next time the COBOL compiler was upgraded, and 2.  It should be more usable and maintainable by less skilled users.

If you're interested in the second method (using the assembler code) I will see if I can find the code and an example program to demonstrate it.  I no longer have access to any mainframes so I won't be able to test any changes that might be required.  Let me know if you want the code.

Lynn's comment got me thinking how I'd do it in ILE COBOL on System i.

Simply put, I wouldn't be outputting to a physical/database file; I'd output to a streamfile. The lines written to the streamfile would then be copied into the fixed-length database file afterwards.

I can only assume that modern mainframe COBOL has some way to read/write streamfiles and to copy between streamfiles and database files. (If not, bring a System i into the datacenter.)

britindiaAuthor Commented:
Lynn, could you please send me the code, i would try to play around it,

Thank You!
I found the code in my old archives.  I've attached a file that contains both the COBOL demonstration program and the ASSEMBLY source code.  Ignore what the COB program actually does... it probably won't make much sense to you since it was half of a 2-part solution to compress/uncompress very large mainframe data files for remote transfer to a PC based system that I used long ago.  The code dealing with the 3 calls to "WriteRec" and the data structures used in those calls is all that is relevant.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Mainframe Languages

From novice to tech pro — start learning today.