[Webinar] Streamline your web hosting managementRegister Today


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

Posted on 2008-02-10
Medium Priority
Last Modified: 2013-11-25
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.
Question by:britindia
  • 2
  • 2
LVL 27

Expert Comment

ID: 20877679

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?

LVL 22

Expert Comment

ID: 21237604
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.

LVL 27

Expert Comment

ID: 21248969
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.)


Author Comment

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

Thank You!
LVL 22

Accepted Solution

JesterToo earned 1000 total points
ID: 21259783
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.

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The following article sheds light on easy-to-use steps to recover non-responding hard drives without data loss. Count on these approaches to fix undetectable, not responding, or non-working hard drives.
The onset of year 2018 has been a usual business for IT teams still struggling to find their way out in terms of strengthening their cloud security.
How to fix display issue, screen flickering issue when I plug in power cord to the machine. Before I start explaining the solution lets check out once the issue how it looks like after I connect the power cord. most of you also have faced this…
Stellar Phoenix SQL Database Repair software easily fixes the suspect mode issue of SQL Server database. It is a simple process to bring the database from suspect mode to normal mode. Check out the video and fix the SQL database suspect mode problem.
Suggested Courses
Course of the Month9 days, 21 hours left to enroll

591 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question