Hi A123I,

What Cobol? What OS? What kind of file? (Line/Binary) Sequential, Indexed, Relative?

I think the only "standard" is for Line Sequential files (plain text). Other cases depend on vendor. Please specify.

Theophilos.

Hi theotyflos,
thanks for that.. I'm working on OS/390, and I am going to handle the Sequential file.

Regards,
A123I

I don't know OS/390 but I think that if you define the file as line sequential it will be able to handle different record legths (delimited by CR and/or LF I suppose) without any other work from you.

A123I,

One of the key things is to specify "RECORD CONTAINS 0 CHARACTERS" in your FD section for the file.  Cobol will then use the lrecl definition specified in your JCL or the actual lrecl the file was created with if not specified in your JCL.  

Next, define your record layout as the largest you expect to receive.  You will have to have some way of knowing exactly how large your record is so once you issue a read you can move the valid portion of the record from your input area into a working storage field with a proper layout.

Example.

FD  INPUTFILE
     ......
     RECORD CONTAINS 0 RECORDS.
01  INPUTAREA                  PIC X(2000).

    READ INPUTFILE .....
    MOVE INPUTAREA(1:LRECL) TO WORKINGSTORAGELAYOUT.

I think this is what you are asking.  

etom

Hi A,

The following link might help. Also try using the "advanced search function here. You might find other threads on the subject.

Regards, Jack.

Thread209-659340

Hi Etom,
This was really close to what I was looking for. I would like to slightly more descriptive on my problem...

I wanted to code a universal program in cobol that could process input file of any record format, record length.

Thanks once again for everbody's help on this...

Regards,
Atul

Hi A,

There's a cobol pgm written by CHARLIE HOTTEL that shows how to get the LRECL for any file used by the pgm. Don't know how to contact him, but I do have the code.

If you want a copy contact me at jacksleight@hotmail.com

If you want to excise the code you need, just do a search
for "LRECL" or "DCB". Also don't forget to OPEN your target file before you begin your search of the TIOT for the DDNAME associated with it.

It's a handy pgm to have. It shows you how to get at most of the system info you might have a need for.

Regards, Jack.

I don't know if this is still supoported but we used to define files as format "U", (undefined), in jcl. you used to be able to bypass dcb processing. (i come from a world where we had 4k machines. we had to write our own iocs, (input output control system), and do necessary label checking and deblocking ourselves to eliminate the high space using ibm software. :)

It has been a long time since I used format "U" however, I do think it is still available in the mainframe compilers. If I remember correctly, this option reads the whole block of records at once and your program must deblock the data to retrieve the actual record.

It does sound like this might do the job however, A123I indicates they want to read any type of input.  Variable and Fixed.  Using this option would make the program somewhat more difficult as you would have to know the format of the file ahead of time and adjust your deblocking for variable block files to deal with the variable record sizes.

etom.

Etom is correct on this... I am still waiting for the response from slade once I get it I'll let you all know about this.

Thanks everybody,
A

Hi Slade, Still waiting for the response from your side. Can u please arrange to send the program?

Regards,
A

Hi A,

I sent you the code the same day that I received your
e-mail. I deleted your e-mail w/your return address, so please resend it.

Thanx, Jack.

A couple of "updates"

1) Regarding using RECORDING MODE IS U

Make certain that you read,

 "Change in file handling for COBOL programs with RECORDING MODE U under OS/390, Version 2 Release 10"

at:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BO...

2)  For what you are doing (and as long as your input is ALWAYS a QSAM file), you can CALL a subroutine passing the FD-name *before* your open, and that subroutine will get the "DCB" as an input field that you can then "modify" as you wish.  Traditionally such subroutines are in Assembler, but if you really like "working with pointers" - you can also process this in COBOL (just get the layout of the DCB macro).

Bill Klein

A star to Slade he had send the code to me and this is going to solve my problem. Thanks a million to everybody for helping me out with this.

Just for your all reference the things are working using pointer which return the details of the files that are being used.

Regards,
A

A nice subject to put in the FAQ's.

[This is my first-ever posting to Tek-Tips]

First, I want to thank Slade for providing the refrenced code -- it will be handy.

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.

Thanks, Craig

Hi,

It doesn't work for the output files. Perhaps you can use a byte-stream output file.

Regards,

   Crox

I don't  think IBM 390 COBOL supports byte-stream files, Crox.

I never used it but what would RECORDING U mean?

RECORDING MODE U - is for "undefined".  See for example,

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BO...

Bill Klein

Would it be usable for CrgJConrad?

It *might* work for creating a "not known at compile time" recrod length.  However, it is certainly NOT supported for that purpose - and therefore, may fail in the future.

The bottom-line is that there is NO truly supported way to do this.

Another (unsupported) solution (for QSAM - nto VSAM) would be to create a "random" record layout in your source fprogram; after you OPEN the file, do a CALL "assembler-program" USING FD-name.

Then the Assembler subprogram will receive addresability to the DCB and could "manually" modify the attributes.

HOWEVER, the bottom-line is that (Standard and/or IBM) COBOL is NOT intended to create "dynamic" files.

Bill Klein

I'm having the same issue when attempting to process multiple input file with varing record length in a single program. I've tried everything listed for this but still have not solved the problem. Slade cau you share a cpy of CHARLIE HOTTEL code?

Hi Big Mike,

Sure. What'a your e-addr?

Regards, Jack.

I want to thank those of you (Slade, Crox, WMK, webRabbit) that took the time to assist me in this.  I was able to use the ideas in the code provided by Slade to determine the LRECL of the input files.  This was a big help.  Next, I wanted to use the input lengths to dynamically determine an output length.  I couldn't find a way to handle that part (see other postings), but I finally settled on using RECFM=V output file (even though all the records are the same length) -- not quite what I wanted, but close.

I wonder what would happen if I used the same code Slade provided to find the LRECL and write a new value to it (after opening it with a very large LRECL, but never yet writing) -- would this work, or would Cobol choke on the first write?

Again, I appreciate all the help.

Craig

Slade, My email address is tf0m860@yahoo.com

Just a reminder to anyone working with an IBM mainframe COBOL compiler - and creating (OPEN OUTPUT) RECFM=V files.

Make certain that you use the AWO compiler option.  To the besto of my knowledge, this compiler option NEVER causes a problem - and is always a "performance" (and space) benefit when writing blocked VB files.

See:
 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BO...

Bill Klein

Could you also send me that code?  Thanks

schristi69@yahoo.com

Slade, any chance I could get a copy of that famous COBOL-program? I have sent you my e-mail address.

I am working with a similar problem trying to write a general program that works on different input and output files - record sizes not known until run time.

Regards
Olav

Olav et al,

If you find a way to dynamically set output record length (new file), PLEASE let me know.

Thanks, Craig