Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Dynamic length file declaration in COBOL in VS Cobol II 5
- Thread starter A123I
- Start date
theotyflos
Programmer
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.
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.
- Thread starter
- #3
theotyflos
Programmer
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.
-
1
- #5
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
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
-
4
- #6
- Thread starter
- #7
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
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.
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.
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.
- Thread starter
- #11
- Thread starter
- #12
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:
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
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:
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
- Thread starter
- #15
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
Just for your all reference the things are working using pointer which return the details of the files that are being used.
Regards,
A
CraigJConrad
IS-IT--Management
[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
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
- Status
