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

Aki88
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Skillset: COBOL, JCL, DFSORT, VSAM
Referer: Google

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

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

Hello,

The below SORT:

Code: Select all


//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:

Code: Select all


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

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

Code: Select all


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!

enrico-sorichetti
Global moderator
Posts: 3006
Joined: Fri Apr 18, 2008 11:25 pm
Skillset: tso,rexx,assembler,pl/i,storage,mvs,os/390,z/os,
Referer: www.ibmmainframes.com

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

Aki88
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Skillset: COBOL, JCL, DFSORT, VSAM
Referer: Google

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.

User avatar
sergeyken
Posts: 458
Joined: Wed Jul 24, 2019 10:12 pm
Skillset: Assembler, JCL, Utilities, PL/I, C/C++, DB2, SQL, REXX, COBOL, etc. etc. etc.
Referer: Internet search

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.

Aki88
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Skillset: COBOL, JCL, DFSORT, VSAM
Referer: Google

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.

Robert Sample
Global moderator
Posts: 3720
Joined: Sat Dec 19, 2009 8:32 pm
Skillset: Systems programming, SAS, COBOL, CICS, JCL, SMS, VSAM, etc.
Referer: other forum
Location: Dubuque, Iowa, USA

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.

Aki88
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Skillset: COBOL, JCL, DFSORT, VSAM
Referer: Google

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.

User avatar
sergeyken
Posts: 458
Joined: Wed Jul 24, 2019 10:12 pm
Skillset: Assembler, JCL, Utilities, PL/I, C/C++, DB2, SQL, REXX, COBOL, etc. etc. etc.
Referer: Internet search

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: :?:

Code: Select all

//*======================================================
//* 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                                                    
//*                                                      

Code: Select all

********************************* 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.