syncsort outrec and numeric to comp.

Author Message
shankarm

Active User

Joined: 17 May 2010
Posts: 175
Location: India

 Posted: Mon Apr 09, 2012 9:27 pm Hi, I have a variable with pic s9(9) comp. example, 01 var1 pic s9(9) comp. can we store a 10 digit numeric number in var1? if yes, how? Let us say i have a number 1234567890. how do i copy it using syncsort? from what i know, i have to user outrec. but am not able to find the exact sort card. Outrec=(1:1,10,??) Please let me know if the explanatin is not clear.

Active User

Joined: 20 Sep 2006
Posts: 154
Location: US

Posted: Mon Apr 09, 2012 9:48 pm

Hi Shan,

Integer value will be stored in hexa decimal format in the file.
 Code: //STEP01  EXEC PGM=SORT                                              //SYSPRINT  DD SYSOUT=*                                              //SYSOUT    DD SYSOUT=*                                              //SORTIN    DD *                                                    1234567890                                                          /*                                                                  //SORTOUT   DD SYSOUT=*                                              //SYSIN  DD  *                                                       SORT FIELDS=COPY                                                     OUTREC FIELDS=(1:1,10,11:1,10,ZD,TO=BI,LENGTH=4,80:X)              /*

Position 1 to 10 will have zoned decimal value and position 11 to 14 will have integer value

Output:

 Code: ----+----1---- 1234567890ño K FFFFFFFFFF490D 12345678909622
shankarm

Active User

Joined: 17 May 2010
Posts: 175
Location: India

 Posted: Mon Apr 09, 2012 11:35 pm Thanks a lot for the response saiprasadh. This allows a maximum of 4294967295 only correct instead of 1234567890 if i give 9087654321 as input the job will fail correct? Do you know of any other way to store this?
Bill Woodger

Moderator Emeritus

Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

 Posted: Mon Apr 09, 2012 11:40 pm You are correct in the maximum value for 10 is as you state, for unsigned. This is represented by X'FFFFFFFF'. So, no, without more space, you can't store more. You are "maxed out" for four bytes. What is your actual problem? What are the upper and lower limits of your range? Why can't you use more space?
shankarm

Active User

Joined: 17 May 2010
Posts: 175
Location: India

 Posted: Mon Apr 09, 2012 11:46 pm Bill, A very big process in production seem to use s9(9) comp and it writes a value 7000000000, i knew this is not technically possible but still the process is giving this value. am analyzing the process to resolve an issue, so i wanted to know if there is some other way to store 10 digits..
dick scherrer

Moderator Emeritus

Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

 Posted: Mon Apr 09, 2012 11:54 pm Hello, What is in the binary field after the 7000000000 is placed in the field? Show this value in hex.
Bill Woodger

Moderator Emeritus

Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

 Posted: Mon Apr 09, 2012 11:54 pm OK. That's why I asked about the range. What is the smallest value that actually exists in the data at the moment? As a short-term, if the minimum is large enough, you can adjust by subtracting it from everything. Otherwise, if the minimum is not big enough, you are into byte/bit-stealing as a short-term work-around.
shankarm

Active User

Joined: 17 May 2010
Posts: 175
Location: India

 Posted: Tue Apr 10, 2012 12:04 am the next field is another s9(9) comp followed by filler(just spaces). The value of both the fields are mentioned below, 7787017030 7246579018 The above mentioned values are DBKEYS in an IDMS databbase. The range can be anything starting from 1900000000 to 8999999999.
Bill Woodger

Moderator Emeritus

Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

 Posted: Tue Apr 10, 2012 12:25 am OK, the range is too big to get into four bytes. Your best bet might be the filler. If you have filler, you don't have to scrimp on bits, you can go for a whole byte or two bytes for Cobol convenience. Basically you'd use the new as an "overflow" area. I'd do a module, called by anything which needs to access the field, all access to the field through the module. Called with original, new from filler, and the value which is intended for the original field (or whatever function is required).
Akatsukami

Global Moderator

Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

Posted: Tue Apr 10, 2012 12:39 am

 shankarm wrote: the next field is another s9(9) comp followed by filler(just spaces). The value of both the fields are mentioned below, 7787017030 7246579018 The above mentioned values are DBKEYS in an IDMS databbase. The range can be anything starting from 1900000000 to 8999999999.

Whilst I do not know IDMS, does this not imply that the keys are stored somewhere, in the main data base or a secondary index? If so, in what form are they stored -- doubleword binary, packed decimal, zoned decimal?
Bill Woodger

Moderator Emeritus

Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

Posted: Tue Apr 10, 2012 1:50 am

 Quote: A very big process in production seem to use s9(9) comp and it writes a value 7000000000, i knew this is not technically possible but still the process is giving this value.

Sorry, I didn't read the second part of the sentence.

If you have something that is showing you 10 digits already, then the comp pic s9(9) is not the source of the number. At least not directly.

Either the "fix" is already in in some way, or the source is the database internals, as has been suggested now.

Noticing now, you even have a signed field (in your post at least). That halves the maximum value. Even then you have to have the right compile option.

The field you are looking at is not the source of a 10-digit number > 2-whatever (half the 4-whatever from above).
shankarm

Active User

Joined: 17 May 2010
Posts: 175
Location: India

 Posted: Wed Apr 11, 2012 7:28 am sorry everone for wasting your time. as we discussed, s9(9) cannot store 7000000000 and more, we have an program that handles it. takes the dbkeys and multiply it with 256. and there is a calculation logic for DBKEY.
dick scherrer

Moderator Emeritus

Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

 Posted: Wed Apr 11, 2012 7:38 pm Thank you for letting us know it is resolved d
 View Bookmarks All times are GMT + 6 Hours

 Topic Forum Replies Similar Topics COBOL - Move S9(11)v9(7) COMP-3 to -(... COBOL Programming 5 Convert HEX to Numeric DB2 3 Converting ASCII values to COMP-3 (ZD... JCL & VSAM 2 Find a record count/numeric is multip... COBOL Programming 1 Count Records with a crietaria in a f... DFSORT/ICETOOL 5
Search our Forums:

 IBMMainframes.com is not an official and/or affiliated with IBM® in anyway Board Rules | FAQ | Downloads | Wiki | SiteMap | Contact Us