IBM Mainframe Forum

Hi everyone,

I have been trying to look for a solution to allow me to append/concatenate the characters "XX" at the end of each record within my VSAM file.

Basically, what I wanted to appear in my output is like this:

INPUT (length 1704, fmt VB):


OUTPUT (length 1704, fmt VB):



I tried the OPTION VLSHRT but even with that, I still get the error "ICE218A 3 192 BYTE VARIABLE RECORD IS SHORTER THAN 1702 BYTE MINIMUM FOR SORTOF01 FIELDS"

This is how my SORT step looks like:


As much as possible, we wanted to avoid creating a COBOL program only to accomplish the output i described previously. So, I want to know if it is possible to do using only a SORT step in JCL. I hope you could all help me find the easier and less costly solution

Which SORT product, and which version, are you using?

Why would you want to stick two bytes at the end of the data on each record (as your example shows)? Or at the end of each record (as you seem to be attempting with your SORT cards)? How would you reference those bytes?

These users thanked the author BillyBoyo for the post:

msdiosa (Wed Jul 15, 2015 2:18 pm)

Thanks for the reply.

As per your questions, re: sort product and version - i have to get back to you on that, i don't have connection to host as of this moment.

You're right, the characters 'XX' are required by my client so it will serve a signal for their process that the end of the DATA of each record is reached. I don't exactly know the process that will access these records, I assume it will be a program on their system to which I don't have access to, so as far as I am concerned, I just have to format the records within my VSAM file as they have required.

Please let me know if this is even possible to do thru JCL. If not, I will have no other choice but to create a program just to append the said characters

In DFSORT 2.1 you can do it by built-in function. Otherwise it is more tricky. Do you have any binary or packed-decimal fields on any of the records?

If anyone is reading a VSAM dataset with "variable-length" records, they can get at a record-length to tell how long the data is. It seems an absolutely crazy-dumb idea, and you can tell them I said so, please.

These users thanked the author BillyBoyo for the post:

msdiosa (Wed Jul 15, 2015 2:18 pm)

I think my version of DFSORT is "Z/OS DFSORT V1R12", so I guess it won't be possible to do so by JCL.

The record does have numeric packed decimals so the only way to read and modify the records must be via a COBOL program using STRING/UNSTRING. I would have to agree with you, this is just crazy.

Anyway, thank you so much for responding to my question. I really appreciate it

There is a way then.

If you extend a record with BUILD or OVERLAY, it is always padded with space. To make use of this, you can first use INREC to change all spaces to a value which can't exist in your data. Like X'FE'. So FINDREP. You have to then extend your record one beyond the maximum length possible (LRECL+1) with a space. Intervening bytes between last of actual data and LRECL+1 will be filled with blanks.

You then use FINDREP with DO=2 to change C' ' to C'X'.

You then use FINDREP a third time, to change X'FE' back to space.

On OUTFIL, you use VLTRIM=C' ' to drop off the remaining trailing spaces you created.

You have a problem if the actual data already extends into LRECL-1 or LRECL because the length of the new record will be greater (in the first case) and the record will only contain one trailing X (in the second). Presumably someone already thought of that, and the actual LRECL is original LRECL+2 already.

You can use FINDREP to change two blanks to two Xs, with DO=1. May be clearer.

These users thanked the author BillyBoyo for the post:

msdiosa (Wed Jul 15, 2015 3:40 pm)

Hmm, that's an interesting work-around. I will try doing that and will let you know what happens.

Thanks again.

Finally, we convinced the client team to adapt the changes in the existing program that generates our input file.

We found it near to impossible to do via JCL what they are requiring, due to the structure of the record -- there are optional fields within the record that are empty (or populated with spaces). This makes searching for the last logical data within the record difficult.

Example of the structure (it has 10 occurrences):


The numeric fields are populated by zeros by default, while the alfanumeric fields by spaces. It is difficult to find by JCL the exact end of logical data because although an occurrence may be empty, some of its fields may contain zeros. Also, FLD 6 and 7 are optional, so we can't also assume that the rest of the record is empty just because these two fields contain only spaces.

I know, this requirement is so "weird" it kinda pisses me off but anyway, anything for our dear clients