This is a IBM COLBL for OS/390 question. I need a simple pgm to check the first record in several files for a code. The record has the same format in all the files, but the files have differing record sizes (lrecl). The OPEN failes unless the record size of the file exactly matches the longest record in the FD. Any way around this in COBOL?
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 Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Reading / writing Variable Blocked QSAM files 7
- Thread starter 50five
- Start date
-
2
- #2
-
2
- #3
Have you tried overriding the file specs by using a DCB=(lrecl=xxx) in your JCL. Not sure if it will let you do that or not.
I believe I have also seen people get around this problem in the following manner.
FD FILENAME ----
01 RECORD-NAME.
03 RECORD-CHARACTER PIC X
OCCURS 1 TO 10000 TIMES
DEPENDING ON WS-FIELD.
They would then load the WS-FIELD with the lrecl prior to opening the file. This assumes you can feed the program the lrecl from a control record or something like that.
Good luck. I will check around and see if I can find an example of the above code and make sure I did it right. It has been a long time since I have seen this.
etom
I believe I have also seen people get around this problem in the following manner.
FD FILENAME ----
01 RECORD-NAME.
03 RECORD-CHARACTER PIC X
OCCURS 1 TO 10000 TIMES
DEPENDING ON WS-FIELD.
They would then load the WS-FIELD with the lrecl prior to opening the file. This assumes you can feed the program the lrecl from a control record or something like that.
Good luck. I will check around and see if I can find an example of the above code and make sure I did it right. It has been a long time since I have seen this.
etom
-
1
- #4
Hi 55,
Try using "undefined" and blksize=32K. Define your FD rec as 32K too.
Your read will read in as many recs as the blk contains. Since your interested only in the 1st bytes of the block, you shoyld have no problem accessing the field you're looking for. I assume the field is in the same relative position in each file.
Regards, Jack.
Try using "undefined" and blksize=32K. Define your FD rec as 32K too.
Your read will read in as many recs as the blk contains. Since your interested only in the 1st bytes of the block, you shoyld have no problem accessing the field you're looking for. I assume the field is in the same relative position in each file.
Regards, Jack.
-
1
- #5
Hi,
it depends on which version of COBOL you use but the recent versions of IBM's 390 COBOL allow you to define:
RECORD CONTAINS 0
From the manual:
For fixed-length QSAM files, when you code RECORD CONTAINS 0 in the FD, the record size attributes are not in conflict. The record size is taken from the DD statement or the data set label, and the OPEN statement is successful.
Regards,
Crox
it depends on which version of COBOL you use but the recent versions of IBM's 390 COBOL allow you to define:
RECORD CONTAINS 0
From the manual:
For fixed-length QSAM files, when you code RECORD CONTAINS 0 in the FD, the record size attributes are not in conflict. The record size is taken from the DD statement or the data set label, and the OPEN statement is successful.
Regards,
Crox
Hi,
some ways to deal with different record types are:
1) use a record identifier
2) use the parm field to tell what kind of file you are going to process.
3) use READ ... INTO some WORKING-STORAGE identifier and determine the recordtype by testing for space on at the end of the shorter records.
There are utilities to get file-information. Their output can be input to your COBOL program. You can even call TSO.
....
....
Regards,
Crox
some ways to deal with different record types are:
1) use a record identifier
2) use the parm field to tell what kind of file you are going to process.
3) use READ ... INTO some WORKING-STORAGE identifier and determine the recordtype by testing for space on at the end of the shorter records.
There are utilities to get file-information. Their output can be input to your COBOL program. You can even call TSO.
....
....
Regards,
Crox
Crox,
Yeah, there are "workarounds", but the problem is:
1) There may be no useable rec type available.
2) The parm may not match reality, e.g. was used for last run and not changed.
3) There may be legitimate spaces in the record.
In some cases, these workarounds may work, but they can be somewhat risky and are situation specific. At best they're kludgey. My point is that with very little effort IBM (or the compiler provider) can offer a solid solution to the problem.
Regards, Jack.
Yeah, there are "workarounds", but the problem is:
1) There may be no useable rec type available.
2) The parm may not match reality, e.g. was used for last run and not changed.
3) There may be legitimate spaces in the record.
In some cases, these workarounds may work, but they can be somewhat risky and are situation specific. At best they're kludgey. My point is that with very little effort IBM (or the compiler provider) can offer a solid solution to the problem.
Regards, Jack.
I've seen discussion in this forum before about retrieving the allocated DSN name for a file by a Cobol pgm in IBM environments.
If the file name is retrieved, perhaps it can be used to identify the record "type" to be examined.
Sorry, don't have any references for the discussions about retrieving the dataset names.![[sad]](/data/assets/smilies/sad.gif "[sad] [sad]")
Maybe this weekend I'll try searching for that, or hopefully someone else will beat me to it!![[wink]](/data/assets/smilies/wink.gif "[wink] [wink]")
"Code what you mean,
and mean what you code!
But by all means post your code!"
Razalas
If the file name is retrieved, perhaps it can be used to identify the record "type" to be examined.
Sorry, don't have any references for the discussions about retrieving the dataset names.
Maybe this weekend I'll try searching for that, or hopefully someone else will beat me to it!
"Code what you mean,
and mean what you code!
But by all means post your code!"
Razalas
Hi Dimandja,
I'm not sure what you say is not a problem. Do other compilers provide the rec length when RECORD CONTAINS 0 is used?
How do they accomplish that?
Or do you mean that the rec length of the file is not verified against the rec length specified in the pgm, therefore any rec length can be used for the file.
Or something else?
Regards, Jack.
I'm not sure what you say is not a problem. Do other compilers provide the rec length when RECORD CONTAINS 0 is used?
How do they accomplish that?
Or do you mean that the rec length of the file is not verified against the rec length specified in the pgm, therefore any rec length can be used for the file.
Or something else?
Regards, Jack.
Hi Jack,
(I responded to this, but my response seems to have been lost in the net).
The problem I am referring to has to do with IBM JCL rigidity - hardly a COBOL-centric aspect. You see, on many other platforms, programs are intimately interacting with the OS: you can interrogate a file about its structure and attributes before opening it with COBOL, and then using etom's suggestion of "OCCURS DEPENDING ON". The use of JCL to accomplish the same effect is more convoluted (see the thread I suggested above).
That's why I said: "COBOL allows you to define "variable length records" - look into the File Section for the syntax. But, then again the 390 may be different."
That is also why I said: "I think this is an IBM mainframe specific issue, that has nothing to do with COBOL as such."
50five's problem ("The OPEN failes unless the record size of the file exactly matches the longest record in the FD"
can only exist in an environment where JCL is involved as described. I have never had that kind of problem on non-JCL bound environments, for example.
Dimandja
(I responded to this, but my response seems to have been lost in the net).
The problem I am referring to has to do with IBM JCL rigidity - hardly a COBOL-centric aspect. You see, on many other platforms, programs are intimately interacting with the OS: you can interrogate a file about its structure and attributes before opening it with COBOL, and then using etom's suggestion of "OCCURS DEPENDING ON". The use of JCL to accomplish the same effect is more convoluted (see the thread I suggested above).
That's why I said: "COBOL allows you to define "variable length records" - look into the File Section for the syntax. But, then again the 390 may be different."
That is also why I said: "I think this is an IBM mainframe specific issue, that has nothing to do with COBOL as such."
50five's problem ("The OPEN failes unless the record size of the file exactly matches the longest record in the FD"
can only exist in an environment where JCL is involved as described. I have never had that kind of problem on non-JCL bound environments, for example.Dimandja
I reread my post and realized I didn't really spell out the obvious: IBM JCL is an archaic (oops!) technique designed decades ago to deal with batch jobs - and to its credit(?) still in use. Programming has come a long way since then: system (COBOL callable) routines should be there to help out with file structures - COBOL is well equipped to handle record length squabbles: see etom's post.
Dimandja
Dimandja
Hi Dimandja,
You said: ...you can interrogate a file about its structure and attributes before opening it with COBOL...
If it’s not too much trouble can you give a few examples? I assume this can be done from within the pgm.
You said: COBOL allows you to define "variable length records...But, then again the 390 may be different.
You’re right, in IBM mainframe COBOL variable length records are expected to contain BDW/RDWs and because of this, the “variable” designation cannot be used to define fixed length recs even if the lengths of the individual recs differ.
BTW, I empathize with your losing a post to the web. I’ve begun using Note Pad to construct the msg and cut&past it into the reply box. When I’m satisfied that it got to the destination, I delete the Note Pad file.
Regards, Jack.
You said: ...you can interrogate a file about its structure and attributes before opening it with COBOL...
If it’s not too much trouble can you give a few examples? I assume this can be done from within the pgm.
You said: COBOL allows you to define "variable length records...But, then again the 390 may be different.
You’re right, in IBM mainframe COBOL variable length records are expected to contain BDW/RDWs and because of this, the “variable” designation cannot be used to define fixed length recs even if the lengths of the individual recs differ.
BTW, I empathize with your losing a post to the web. I’ve begun using Note Pad to construct the msg and cut&past it into the reply box. When I’m satisfied that it got to the destination, I delete the Note Pad file.
Regards, Jack.
Hi Jack,
A platform I have extensively worked on (Tandem NonStop Servers) has a COBOL85 compiler. This compiler is comparable to COBOL II for IBM. I have coded both batch and online programs with COBOL85.
When dealing with "unpredictable" files, I either use COBOL's own file definitions and handling, or I make system (or API) calls from COBOL to the OS (Guardian) to deal with such situations. These methods offer more flexibility and sophistication to COBOL, that you will have to labor to find by using techniques that rely on batch oriented parameters passing strategies such as offered by JCL.
In order to deal with variable length and variable name files on Tandem, all one has to do is use the following coding strategies - no "JCL".
COBOL only solution:
SELECT OPTIONAL input-file
ASSIGN TO #DYNAMIC
This will reserve a file handle. You can assign any file to it, open it, close it, and re-assign another file. The COBOL_ASSIGN_ routine, will be called to assign file names to the handle when needed.
FD input-file
RECORD IS VARYING IN SIZE FROM 10 TO 2400 CHARACTERS DEPENDING ON num-bytes.
This will accommodate any record size you wish (from 10 to 2400 bytes, in this example). When the file is opened (yes, it will be opened without specifying num-bytes beforehand) and read, num-bytes will contain the current file record size (if you need it).
COBOL and OS solution:
The other technique for dealing with these pesky files is to use system (API) calls to open and read the files. In this strategy, you will not need the COBOL Environment Division at all, and you will only use the Working-Storage in the Data Division.
The following code snippets come from a fully functional program (I wrote years ago) that does what the utility GREP does on Unix systems. The program (written in COBOL) looks to match a search string by opening and reading any file type (and any record size) on any disk on the system.
All the information is of course processed in COBOL. As you can see, there was absolutely no JCL needed to accomplish any of the above. Your OS already has any information you need about any file on your system, and COBOL can get it.
Dimandja
A platform I have extensively worked on (Tandem NonStop Servers) has a COBOL85 compiler. This compiler is comparable to COBOL II for IBM. I have coded both batch and online programs with COBOL85.
When dealing with "unpredictable" files, I either use COBOL's own file definitions and handling, or I make system (or API) calls from COBOL to the OS (Guardian) to deal with such situations. These methods offer more flexibility and sophistication to COBOL, that you will have to labor to find by using techniques that rely on batch oriented parameters passing strategies such as offered by JCL.
In order to deal with variable length and variable name files on Tandem, all one has to do is use the following coding strategies - no "JCL".
COBOL only solution:
SELECT OPTIONAL input-file
ASSIGN TO #DYNAMIC
This will reserve a file handle. You can assign any file to it, open it, close it, and re-assign another file. The COBOL_ASSIGN_ routine, will be called to assign file names to the handle when needed.
FD input-file
RECORD IS VARYING IN SIZE FROM 10 TO 2400 CHARACTERS DEPENDING ON num-bytes.
This will accommodate any record size you wish (from 10 to 2400 bytes, in this example). When the file is opened (yes, it will be opened without specifying num-bytes beforehand) and read, num-bytes will contain the current file record size (if you need it).
COBOL and OS solution:
The other technique for dealing with these pesky files is to use system (API) calls to open and read the files. In this strategy, you will not need the COBOL Environment Division at all, and you will only use the Working-Storage in the Data Division.
The following code snippets come from a fully functional program (I wrote years ago) that does what the utility GREP does on Unix systems. The program (written in COBOL) looks to match a search string by opening and reading any file type (and any record size) on any disk on the system.
Code:
This call returns the next file on disk, including various characteristics about the file structure and type:
ENTER TAL "filename_findnext_"
USING search-id
file-name (1:36)
file-name-len
entity-info-grp
GIVING result
This call will open any file on Tandem:
ENTER TAL "file_open_"
USING file-name (1:file-name-len)
file-name-number
GIVING result
While this call will read any given file returning the number of bytes (record size) read:
ENTER TAL "readx"
USING file-name-number
edit-buffer
edit-buffer-len
count-readDimandja
Hi Jack,
To answer your specific question about: "...you can interrogate a file about its structure and attributes before opening it with COBOL..."
Dimandja
To answer your specific question about: "...you can interrogate a file about its structure and attributes before opening it with COBOL..."
Code:
The following COBOL call will get information about any file (on Tandem Nonstop Servers) without even opening it. The results can be used by the COBOL program for any purpose.
ENTER TAL "File_GetInfoListByName_"
USING filename (1:filenamelen)
item-list
number-of-items
result
result-max
result-length
error-item
GIVING errorHi Dimandja,
Thanx for taking the time to reply. One further ques: I take it that these "TAL" routines are provided by the vendor. True?
Your point that IBM's JCL is responsible for the lack of info, I think, is misplaced. Their lack of commitment is the more likely reason. Maybe they may expand their CEExxx subroutine scheme to provide these services.
Thanx again, Jack.
Thanx for taking the time to reply. One further ques: I take it that these "TAL" routines are provided by the vendor. True?
Your point that IBM's JCL is responsible for the lack of info, I think, is misplaced. Their lack of commitment is the more likely reason. Maybe they may expand their CEExxx subroutine scheme to provide these services.
Thanx again, Jack.
- Status
Similar threads
- Locked
- Question