Posted: Fri Jul 18, 2003 7:12 am Post subject: File with RECFM=VB
Hi,
Please let me know more about Variable Block Files.
Actually, I was taking i/p from Flat files with RECFM=FB and updating the Flat file with RECFM=FB based on some condition(business logic) and it was successful. But the same thing when I changed RECFM=VB(both i/p and o/p) the program was running with RC=0 but not reading the File itself.
Some 4 bytes extra thing is there. I tried to declare first 4 bytes as filler also for VB File, but even then it was not reading the file.
Please can you update me what could be the reason and what needs to be
done to rectify it.
Thanks in advance. _________________ Have a Great Day.
Thanks & Regards,
Jai
Say the FB file length is 100 and now you're converting to VB.Don't change the COBOL copybook layout.Just add 4 to the LRECL i.e 104 in the JCL.don't put anything like 'recording mode' in select clause.It should work
Jai,
The first 4 bytes is transparent to the program. User need not code for it. The extra 4 bytes is codded on the JCL. Treat your file as a normal FB file (but make sure you are differentiating the different record types). There is good documentation in the reference section of the forum).
Thanks a lot! for your quick response. But I have taken care of all the things which you all have mentioned. Even for Fixed Block, while updating, I am getting '{' in the filler place and that too only for the first record. I think only reason for this might be that I am filling the input data manually. I will try to get the input data in the input file through the batch program itself and see if it works.
Please suggest me what could be the reason of not getting the correct result, if it is manually updated i/p file.
I think, even if we update it manually it should come correctly. What could be the reason for this. Please guide me with your valuable suggestions.
I will update you all once I make this input also through the batch itself and if I get the correct result for both FB and VB.
Thanks again.
Have a Great Day. _________________ Have a Great Day.
Thanks & Regards,
Jai
Joined: 07 Feb 2003 Posts: 266 Topics: 1 Location: Edison, NJ USA
Posted: Wed Jul 23, 2003 3:03 pm Post subject:
I've encountered three situations when attempting to process IBM's variable length records. Here's a description of the methods I use in each of those situations. This may also be valid for non-IBM environments.
1) Don't know the lengths of the recs in the file. (Use Method 1 below.)
2) Can identify each variable rec that you read by knowing the rec type field value of each rec. (Use Method 2.)
3) Record description contains a variable table. (Use Method 3.)
Method 1.
In your FD
Code:
RECORD VARYING FROM 1 TO max len expected
DEPENDING ON WS-REC-LEN
If you don't know the max len use 32K.
Define the FD 01 as:
Code:
01 IP-REC.
05 NBR-OF-BYTES PIC X
OCCURS FROM 1 TO nn DEPENDING ON WS-REC-LEN.
where, nn = max len expected used in VARYING,
WS-REC-LEN is an unsigned numeric data item large enough to hold "max len expected".
When you read an IP rec, the length of the rec just read will appear in
WS-REC-LEN.
If you decide to write the rec to an OP file is is your responsibility to populate that field with the appropriate length. If you decide to expand or reduce the size of the rec before you write it, you must first adjust the WS-REC-LEN field accordingly.
Method 2.
In the FD
Code:
RECORD CONTAINS FROM 1 TO max len expected.
If you don't know the max len use 32K.
Define the FD 01 for as many types of recs as you have, e.g.:
(These could also be copybooks.)
READ IP-FILE
IF REC-TYPE-1 = '1'
do stuff only using IP-REC-1 datanames
WRITE IP-REC-1
END-IF
IF REC-TYPE-2 = '2'
do stuff only using IP-REC-2 datanames
WRITE IP-REC-2
END-IF
etc.
Note that you write the record, not the file.
Also, although I chose to make the rec type PIC X, it could be anything, so long as there is agreement that a given value will always reference a rec of a predetermined length and content.
Method 3.
In the FD
Code:
RECORD CONTAINS FROM 1 TO max len expected.
Define the FD 01 which will contain a variable table, e.g.:
(This could also be a copybook.)
Code:
01 IP-REC-1.
05 fixed part of rec PIC X(nnn).
05 MO-NBR PIC 9(002).
05 REC1-TBL.
10 REC1-ENTRY OCCURS 1 TO 12 DEPENDING ON MO-NBR.
15 REC1-MO PIC X(003).
.
.
.
In the PD:
Code:
READ IP-FILE
If you need to update the data in the file and create a new variable OP file from it, create an OP FD similar to that above. You can use the same copybook or you can create another rec description w/a variable table in it.
If the number of entries in the var table changes, be sure to update the "depending on" field before you WRITE the rec. If not you can move the IP "depending on" field to its OP counterpart.
JCL Notes:
Variable recs are built by the access method in 2 parts: control data and user data.
The control data is composed of a 4 byte Block Descriptor Word (BDW) and a 4 byte Record Descriptor Word (RDW). In each the 1st 2 bytes contain a binary representation of the length.
So, when coding the LRECL and BLKSIZE add 4 or 8 bytes respectively to the longest area expected for your data.
Note that in the COBOL pgm you state the data area sizes only. The BDWs & RDWs are not considered in the pgm.
While I'm on the subject of data length, you can always specify a rec or block length LARGER than the ACTUAL largest rec/block in the file. Just make sure that the BLKSIZE is 4 bytes longer than the LRECL. The only downside is that you waste buffer space. This shouldn't present a hardship, but the technique is handy in those situations where you may not know the exact file attributes.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum