Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I asked for the information assuming that it would be of help, yes.
For the unsuccessful step, you've shown the joblog only. However, this is the problem:
Code:
CASD203E WRONG LENGTH RECORD 03597
Hit your CA-SORT manual for this message. I don't know whether it is showing the length or the record-number, but it looks like you have a record which is longer than 200 bytes of data.
You specify TYPE = V but state that the records are fixed-length. Decide on one or the other. If fixed, use TYPE=F and drop the extra four bytes from the output blocksize.
The two things are probably connected. If the data is fixed-lenght, but you are telling CA-SORT it is variable, CA-SORT will attempt to use the first four bytes of the data as the RDW, which is hardly likely to be a good thing.
CA-SORT and VSE in one post. May be unique on this forum :-)
In the present state, the file is created as Fixed length by the COBOL program and used as Fixed length.
In the new state, we want the Fixed Length output from the COBOL program to be fed into another COBOL program which requires it to be a Variable length file.
Therefore, I am trying to introduce a SORT step between the two COBOL programs, to convert this Fixed length file into Variable length file.
We are using CA SORT in the VSE environment.
As you suggested, I will try to see the manual for CA SORT and get back.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Just curious . . .
If the file is created as FB why not simply use it as FB?
There should be no need to change it to VB. If there is a generic program that reads several formats of data, this can be accomplished with FB data as well. Long ago i wrote a generic file compare (that does i bit more than the standard compare) and i set it up to handle FB data up to 8k in length.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Quote:
I am interested to know how this can be handled with the FB file itself.
There is not much to it. It is neither fancy nor tricky.
Code:
SELECT FLATFLA ASSIGN TO UT-S-FLATFLA.
SELECT FLATFLB ASSIGN TO UT-S-FLATFLB.
FD FLATFLA
LABEL RECORDS ARE STANDARD
RECORDING MODE IS F
BLOCK CONTAINS 0
RECORD CONTAINS 0 CHARACTERS
DATA RECORD IS FLAT-FILE-A-REC.
01 FLAT-FILE-A-REC PIC X(32000).
FD FLATFLB
LABEL RECORDS ARE STANDARD
RECORDING MODE IS F
BLOCK CONTAINS 0
RECORD CONTAINS 0 CHARACTERS
DATA RECORD IS FLAT-FILE-B-REC.
01 FLAT-FILE-B-REC PIC X(32000).
OPEN INPUT FLATFLA.
OPEN INPUT FLATFLB.
The READS are just a READ INTO.
Actually i lied earlier - the code has been expanded to handle up to 32k rather than only 8k . . .
Joined: 07 May 2010 Posts: 2 Location: Philadelphia, PA
Each RECORD in a variable file has a 4-byte binary RDW. The RDW value includes the length of the RDW. (so a variable record with 200 bytes of data is 204 bytes long)
The first two bytes of the RDW are the binary length of the record (including the RDW) followed by two bytes of binary zeros. (almost always, but lets not go there; its irrelevant) The RDW value for a 204 byte record (RDW + 200 bytes of data) is therefore x'00CC0000'.
When blocked, each block has one 4-byte BDW (first 4 bytes of the block); followed by as many records fit in the block. Records may be different sizes, but must fit in the block. (BDW must be at least 4 bytes larger than your maximum RDW)
The BLKSIZ of four 200-byte fixed records in a variable block is:
((Data length + RDW length) * blocking factor) + BDW length)
((200+4)*4)+4 = 820 NOT 804
1. VSAM is always variable length internally, so variable to variable is not a problem.
2. I believe you will find that your fixed file contains x'0E0D' where CA-SORT expects your RDW to be. (first two bytes) (decimal 3597)
3. I don't currently have access to a CA-SORT manual, but I have previously used INREC to build variable records from fixed records in SYNCSORT and DFSORT. You should be able to create an RDW for your file using either INREC or OUTREC to insert the RDW into the beginning of the record.
Something like the following should work:
INREC FIELDS=(X'00CC0000',1,200)
Note: Dick's example above is coded for MVS/OS390/zOS. LRECL and BLKSIZ are obtained from JCL or the catalog. (not the program) I don't remember being able to do this in VSE.
I hope this helps.
P.S. I hope you are not in the practice of using such small block sizes. It's VERY inefficient. While this has recently become less of an issue with "virtual" hardware, your blocks should be sized to use the device efficiently (emulated/virtual or not) There are many calculators out there on the 'net, so find out what devices you have and use one. Your jobs will run MUCH faster. (wall time)
Short explanation:
When your job gets its' next time slice, you will run out of data before you run out of time. You get swapped out until your next turn. Default of 5 buffers(blocks of data) * records/block gets you swapped out every (blocking factor * 5 records). Better to use your entire time slice, and not process all of your data than the other way around. Overall, this also reduces the overhead of all of that (unnecessary) swapping that the O/S is doing.
