Page 1 of 1

DF/SYNC-SORT: Handling of PD and ZD data formats

PostPosted: Wed Jan 22, 2020 2:23 pm
by Aki88
Hello,

The below SORT:


//STEP001  EXEC PGM=SORT      
//SYSOUT   DD  SYSOUT=*        
//SORTMSG  DD  SYSOUT=*        
//SORTIN   DD  *              
     éýÐ                         --> Record 1
2200058A00444444444444444444444
002C11DC0B000000000000000000000
-------------------------------
   ð ç %                         --> Record 2
2208044601444444444444444444444
000C180C12000000000000000000000
-------------------------------
/*                            
//SORTOUT  DD  SYSOUT=*        
//*                            
//SYSIN    DD *                
 OPTION COPY                  
  INCLUDE COND=(1,3,ZD,NE,000)
/*                            
 

yields:


:::::éýÐ :
2200058A00
002C11DC0B
 ---------
 

Whereas, when 'ZD' is changed to 'PD', it returns:

SYSIN:
INCLUDE COND=(1,3,PD,NE,000)

SORTOUT:

:::::éýÐ :
2200058A00
002C11DC0B
 ---------
:: ð:ç %::
2208044601
000C180C12
 ---------
 


Query: What is causing the difference in behaviour (the dropping of second record) when 'ZD' is coded?
I am fairly confident that I am misunderstanding how packed-decimal-data and zoned-decimal-data is read byte-per-byte, when the input format itself is PD.

It will be very helpful if one can guide on this.

Thank you!

Re: DF/SYNC-SORT: Handling of PD and ZD data formats

PostPosted: Wed Jan 22, 2020 3:13 pm
by enrico-sorichetti
You are using the wrong format ZD
and the wrong length for PD

the first three chars are NOT ZD/PD numbers

for the PD format the length should be 4

reread the principle of operations to get a grasp of number representations

Re: DF/SYNC-SORT: Handling of PD and ZD data formats

PostPosted: Wed Jan 22, 2020 3:20 pm
by Aki88
Thank you for the inputs Enrico; indeed you're right on the PD length for 4 bytes, and data-wise it is '2020008C' (for example).
But my query was when this same data is tested with '1,3,ZD' format, what are the actual data-bytes out of '2020008C' being checked.

I will revisit the POP manual for details around PD/ZD data bits.

Re: DF/SYNC-SORT: Handling of PD and ZD data formats

PostPosted: Wed Jan 22, 2020 6:38 pm
by sergeyken
The data values in first 3 bytes - X'202002', and X'202000' - are neither ZD, nor PD data.

There is nothing to talk about. The example is just wrong from the very beginning.

Period.

Re: DF/SYNC-SORT: Handling of PD and ZD data formats

PostPosted: Wed Jan 22, 2020 8:15 pm
by Aki88
Hello Sergey,

As stated in my response to Enrico, I am aware that the data format for initial 3 bytes doesn't correspond to PD or ZD data types.
This is an example of badly written code from a live environment, which has now been rectified; so while the example is questionable - it is a replica of a live ecosystem.

My query was when coded in the manner it is coded currently, how does *SORT process these 3 bytes, which makes it drop 1 record or select it when coded differently; because either way *SORT doesn't return a warning, it processes these basis its interpretation of data types.

Since this is a very trivial question (thus the forum-section where this query was logged), but it has got me stumped on how *SORT treats such data for processing.

I have been away from mainframes for a few years hence my basics are rusty, and I am going through POP to get my head around this, but any guidance/pointers to the aforementioned crux-of-the-query are deeply appreciated.

Re: DF/SYNC-SORT: Handling of PD and ZD data formats

PostPosted: Wed Jan 22, 2020 9:11 pm
by Robert Sample
I suspect that SORT is packing the ZD data for the comparison to zero -- in which case X'2020008C' would pack into X'000' since the zones would be discarded when packed, and X'2020020C' would pack into X'002' and thus the difference in behavior.

Re: DF/SYNC-SORT: Handling of PD and ZD data formats

PostPosted: Wed Jan 22, 2020 9:19 pm
by Aki88
Greetings and wishes for the new year Mr. Sample.
You're spot on; I wasn't sure, but reading your reply it does make sense; as always thanks a ton. :)

ZD in INCLUDE COND instructs *SORT to process the data as zoned-decimal, since an identifier for the same is not found in the data being processed, it will be packed to nearest translated value, hence the actual data being compared would be '000' or '002'. In case of PD the zones will be picked as-is, hence the different results.

Re: DF/SYNC-SORT: Handling of PD and ZD data formats

PostPosted: Wed Jan 22, 2020 11:25 pm
by sergeyken
Why not just to run a primitive test, to get all answers immediately???!!! :twisted: :?:

//*======================================================
//* CONVERSION OF BAD NUMERICS                          
//*======================================================
//BADNUMS  EXEC PGM=SORT                                
//*                                                      
//SYSOUT   DD  SYSOUT=*                                  
//*                                                      
//SORTIN   DD  *                                        
        '2020020C'                                      
  ð     '2020008C'                                      
//*                                                      
//SORTOUT  DD  SYSOUT=*                                  
//*                                                      
//SYSIN    DD  *                                        
 SORT FIELDS=COPY                                        
*                                                        
 OUTFIL FNAMES=SORTOUT,                                  
        BUILD=(1,3,HEX,                                  
      X,C'PD=',1,3,PD,EDIT=(STTTTTT),SIGNS=(+,-),        
      X,C'ZD=',1,3,ZD,EDIT=(STTTTTT),SIGNS=(+,-))        
*                                                        
 END                                                    
//*                                                      

********************************* TOP OF DATA *****
202002 PD=+020200 ZD=+000002                      
202000 PD=+020200 ZD=+000000                      
******************************** BOTTOM OF DATA ***