Now, after sorting i tried to copy the data into the vsam but it again failed with key out of sequence.
so, i tried the below sort card,
Code:
sort fields=(5,10,ch,a)
sum fields=none
The records were copied without any issues,
Q1) now what i dont understand is, even though the data is in 'PD' when i tried to sort it in PD format, it didn't work. but when i tried to sort 'PD' data in character format it worked, isn't it logically wrong?
Q2) As per my production job which was written in 1970's, they are using a temporary dataset (disp=(new,pass,delete)). when the job failed and when i sorted, i used a dasd file (new,catlg,delete) and repro'd it into the VSAM. my question is does this make a difference? when i use a cataloged dataset, will the (its a VB file)record descriptor in the first 4 bytes be copied into the VSAM?
Note: I am asking Q2 because, my production jobs using the vsam file repro'd and copied in the above step is failing with S0C7.
I am trying to find the solution, i will post what i find in the forum.
@Experts in the forum,
Please help me with this.
If you need more explanation on the above scenario or if you have any questions, please let me know.
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
Q1. No, it is not logically wrong. You do not understand the internal representation of packed decimal. Negative 1234 is stored as 0001234D in a packed decimal 4-byte field. Positive 1234 is stored as 0001234C in a packed decimal 4-byte field. Sorting as packed decimal, naturally the negative number comes before the positive number. VSAM sees your key as characters, so the 0001234D coming before 0001234C is seen as out of sequence.
Q2. Using a temporary versus permanent data set should make no difference to the processing -- the record layouts and how data is stored does not change for temporary to permanent data set. The record descriptor word in the first 4 bytes of a VB record are used to indicate the length. VSAM manages record lengths differently, so the 4-byte RDW is not stored in the VSAM file directly.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
shankarm,
You are dropping duplicate keys in the sort cards you have shown. I'm wondering if that matters to you in any way?
Also, you are not using EQUALS on the sort, so unless it has been set as the default, you cannot guarantee which record makes it through the SUM statement (one will, but maybe not always the first one).
Both CH and BI will do a sort strictly on bit values. Anything else will do a "logical" sort for that field type.
VSAM uses a strictly bit value order, of necessity. As Robert says, you can regard the key as being Character values for collating purposes, nothing to do with any logical value (like -ve numbers or such things).
If you have an existing job, why are you changing the sort parameters? Something you have changed is likely to be the cause of the S0C7, so what else is changed? Or maybe you have it already?
The real problem is that your file contains Variable Length Records. Hence your sort card must add 4 to the offsets for sort fields to account for the 4-byte RDW.
When you sort 5,10,CH,A you are really sorting only the first field (3-bytes), second field (4-bytes), and 3 bytes of the third field.
You should be sorting 8,4,pd,a,12,4,pd,a,16,2,bi,a if you wish to be sorting fields 2,3, and 4.
You "might" want to consider converting the file to Fixed Format during the sort step. Just sayin'.
