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.

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.

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)

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.