|
View previous topic :: View next topic
|
| Author |
Message |
neopandya
New User
Joined: 02 Mar 2010
Posts: 8
Location: Bangalore
|
|
|
|
I need to perform the below check in my cobol program
COMP3_Variable - S9(12)V99
IF COMP3_Variable NE TO X'000000000000000C'
But since a comp3 variable cannot be compared directly to a HEX value, or LOW-VALUE or HIGH-VALUE (the HEX value mentioned in the above statements seems to be a signed low-value!! - please correct if wrong) could someone please suggest as to how I can accomplish the above comparison?
I tried to perform a NUMVAL for the hex value mentioned above, and moving it to a numeric variable, but that errors as the hex value doesnt really have a numeric value 
Thanks,
Neo |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
why not simply ... compare to 0  |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| (the HEX value mentioned in the above statements seems to be a signed low-value!! - please correct if wrong) |
There is no such thing as a "signed low-value" -- LOW-VALUES means each and every bit is zero. If you have a sign, then it is not LOW-VALUES.
The hex value you are showing is a COMP-3 value of ZERO. You can say in your COBOL program
| Code: |
| IF COMP3_Variable NE ZERO |
which is exactly what you're attempting to accomplish by your posted IF statement. I recommend you click on the manuals link at the top of the page, find the COBOL Language Reference manual, and study up on internal formats of COBOL variables. |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| neopandya wrote: |
| COMP3_Variable - S9(12)V99 |
Is COMP3_Variable actually a comp3 variable?
| Quote: |
| IF COMP3_Variable NE TO X'000000000000000C' |
As ES implied, your 'signed low-value' is actually just a properly signed packed decimal (comp3) zero...
| Quote: |
| But since a comp3 variable cannot be compared directly to a HEX value, or LOW-VALUE or HIGH-VALUE (the HEX value mentioned in the above statements seems to be a signed low-value!! - please correct if wrong) could someone please suggest as to how I can accomplish the above comparison? |
Just what are you trying to compare that field to? Numeric? Zero? High/Low values?
You are testing the comp3 field for something, what do you expect might be there other than a valid comp3 numeric value? |
|
| Back to top |
|
|
neopandya
New User
Joined: 02 Mar 2010
Posts: 8
Location: Bangalore
|
|
|
|
Let me try to elaborate as to how the problem started.
The below sort-sum was being performed earlier through my JCL which has to be taken care through a cobol program henceforth.
| Code: |
SORT FIELDS=(5,38,CH,A,53,2,CH,A,68,4,CH,A)
SUM FIELDS=(103,8,PD)
INCLUDE COND=((5,7,GT,C'1999-06'),AND,
(103,8,NE,X'00000000000C')),FORMAT=CH |
The sum-fields has been taken care of in my cobol code. I am currently working on the INCLUDE-COND.
The variable (103,8) has been defined as PIC S9(12)V99 COMP-3 while the value it is being compared to is a static HEX X'000000000000000C'.
@Enrico & Robert
Thanks for your reply, I have already tried a comparison to ZERO which had given me me lesser number of records than expected (8 million records less!!).
Is there a way to convert my comp3 variable to HEX and then perform the comparison? If so please advice as to how this conversion can be made. Or any other way this comparison can be performed?
Thanks,
Neo |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| I think your problem is something other than what you believe it to be, but you could always redefine your COMP-3 variable as X(14) and compare the redefined variable to the HEX value. Unless there is something you haven't mentioned, however, you should expect the count to be exactly the same as comparing the COMP-3 variable to ZERO. |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| Robert Sample wrote: |
| X(14) |
| neopandya wrote: |
| The variable (103,8) has been defined as PIC S9(12)V99 COMP-3 while the value it is being compared to is a static HEX X'000000000000000C'. |
The real question is:
Was the sort looking for zero in the PD field?
Any zero or only one with a valid sign of "C"?
Would the data ever have a zero with the sign of "F"?
If the sort was just checking pre-validated data for zero, then why not just check the PD field for zero in your program? |
|
| Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009
Posts: 365
Location: Denmark
|
|
|
|
X(14)? If you redefine the field with a field pic X(8) and compare it to a literal with the value x'000000000000000C', you have recreated the same logic as in the sort, and it should give identical results.
But as CICS Guy pointed out, comparing the packed decimal field to 0 would also exclude records with x'000000000000000F' and possibly, x'000000000000000D'. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Sorry about that -- my brain slipped a cog (not enough coffee I suspect). X(08) is the size needed for the alphanumeric field! |
|
| Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
Hi Neo,
You said,
| Quote: |
@Enrico & Robert
Thanks for your reply, I have already tried a comparison to ZERO which had given me me lesser number of records than expected (8 million records less!!). |
and of course, you'll get fewer recs (maybe not 8 Mil fewer) because the control stmt below will ALWAYS be true even if the field at pos 103 contains packed zeros, because you're comparing an 8 byte field to a 6 byte field. And it is a character compare, NOT an arithmetic compare.
| Quote: |
| (103,8,NE,X'00000000000C')),FORMAT=CH |
|
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
| neopandya wrote: |
| The below sort-sum was being performed earlier through my JCL which has to be taken care through a cobol program henceforth. |
You've done the SUM and you want to code the INCLUDE into your cobol program.- What about the SORT itself? I hope you don't need to rewrite it!
- In case you don't need the sort, why not use SORT FIELDS=COPY? That would save some time, if that's what you need.
- I should have asked this first: WHY? Why do you have to do this?
Now, about the 8M records missing... That's easy:
Due to the error in the INCLUDE COND parameters, all records are SUMmed.
(the error being incorrect length of the x'00...0C' paameter)
In your program, when you compared with ZERO, the selection worked and you SUMmed correctly (only 1999-06).
Change your SORT params to:
| Code: |
SUM FIELDS=(103,8,PD)
INCLUDE COND=((5,7,CH,GT,C'1999-06'),AND,
(103,8,PD,NE,0)) |
and you'll get the same 8M difference. |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
Maybe you won't need to write that cobol program after all...  |
|
| Back to top |
|
|
neopandya
New User
Joined: 02 Mar 2010
Posts: 8
Location: Bangalore
|
|
|
|
Sorry for the delay in replying.. The issue was totally different; I was reusing a piece of code from production, which was a lil messed up!! Now basically, along with my new code.., I would be correcting a code, which has been running for the last 10yrs or so, undetected !!!!
Also, as you guys had mentioned, a comparison to just ZERO was the one that finally worked for me..
Thanks for all the help !!  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Good to hear this is now working - thank you for posting the resolution
d |
|
| Back to top |
|
|
|
|
