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



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

Postby Aki88 » Wed Jan 22, 2020 2:23 pm

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!
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

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

Postby enrico-sorichetti » Wed Jan 22, 2020 3:13 pm

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
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
enrico-sorichetti
Global moderator
 
Posts: 2994
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 164 times

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

Postby Aki88 » Wed Jan 22, 2020 3:20 pm

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.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

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

Postby sergeyken » Wed Jan 22, 2020 6:38 pm

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.
Javas and Pythons come and go, but JCL and SORT stay forever.
User avatar
sergeyken
 
Posts: 408
Joined: Wed Jul 24, 2019 10:12 pm
Has thanked: 6 times
Been thanked: 40 times

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

Postby Aki88 » Wed Jan 22, 2020 8:15 pm

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.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

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

Postby Robert Sample » Wed Jan 22, 2020 9:11 pm

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.
Robert Sample
Global moderator
 
Posts: 3719
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 279 times

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

Postby Aki88 » Wed Jan 22, 2020 9:19 pm

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.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

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

Postby sergeyken » Wed Jan 22, 2020 11:25 pm

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 ***
Javas and Pythons come and go, but JCL and SORT stay forever.
User avatar
sergeyken
 
Posts: 408
Joined: Wed Jul 24, 2019 10:12 pm
Has thanked: 6 times
Been thanked: 40 times


Return to Stupid Questions

 


  • Related topics
    Replies
    Views
    Last post