|
View previous topic :: View next topic
|
| Author |
Message |
shankarm
Active User
Joined: 17 May 2010
Posts: 175
Location: India
|
|
|
|
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. |
|
| Back to top |
|
 |
saiprasadh
Active User
Joined: 20 Sep 2006
Posts: 154
Location: US
|
|
|
|
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 |
|
|
| Back to top |
|
|
shankarm
Active User
Joined: 17 May 2010
Posts: 175
Location: India
|
|
|
|
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? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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? |
|
| Back to top |
|
|
shankarm
Active User
Joined: 17 May 2010
Posts: 175
Location: India
|
|
|
|
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.. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
What is in the binary field after the 7000000000 is placed in the field? Show this value in hex. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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. |
|
| Back to top |
|
|
shankarm
Active User
Joined: 17 May 2010
Posts: 175
Location: India
|
|
|
|
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. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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). |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| 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? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| 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). |
|
| Back to top |
|
|
shankarm
Active User
Joined: 17 May 2010
Posts: 175
Location: India
|
|
|
|
| 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. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Thank you for letting us know it is resolved 
d |
|
| Back to top |
|
|
|
|
