|
View previous topic :: View next topic
|
| Author |
Message |
sudhakar84
New User
Joined: 20 Jun 2008
Posts: 25
Location: chennai
|
|
|
|
I have to extract the records with a PD field which have value greater the 1.
The file is FB file. When I use the below condition it is extracting the records greater then or equal to 1. Could you please let me know why ?
Include cond=(1,8,pd,gt,1) |
|
| Back to top |
|
 |
Arun Raj
Moderator
Joined: 17 Oct 2006
Posts: 2482
Location: @my desk
|
|
|
|
sudhakar84,
I would try verifying some of the records manually in HEX-mode if those are really 8 byte packed decimal data starting at position-1.
Can you post some sample data here (in HEX mode)? |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2218
Location: USA
|
|
|
|
In your output, print the actually extracted fields both in decimal, and hexadecimal formats. One cannot guess about your data without exact details.
| Code: |
OUTREC FIELDS=(C'DEC=',1,8,PD,TO=ZD,
C' HEX=',1,8,HEX) |
|
|
| Back to top |
|
|
sudhakar84
New User
Joined: 20 Jun 2008
Posts: 25
Location: chennai
|
|
|
|
| The declaration of field in cobol is s9(13)v9(2) comp-3 |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2218
Location: USA
|
|
|
|
| sudhakar84 wrote: |
| The declaration of field in cobol is s9(13)v9(2) comp-3 |
In order to debug or fix your code, you need to check NOT THE FIELD DECLARATION, but THE ACTUAL PHYSICAL VALUE OF THE FIELD to be sorted/selected.
This is classical routine job in programming, known since... 50 years. |
|
| Back to top |
|
|
sudhakar84
New User
Joined: 20 Jun 2008
Posts: 25
Location: chennai
|
|
|
|
| sergeyken wrote: |
| sudhakar84 wrote: |
| The declaration of field in cobol is s9(13)v9(2) comp-3 |
In order to debug or fix your code, you need to check NOT THE FIELD DECLARATION, but THE ACTUAL PHYSICAL VALUE OF THE FIELD to be sorted/selected.
This is classical routine job in programming, known since... 50 years. |
I totally understand your point. The problem is that I cannot post data from my organization. that will result in loosing my job 
Kindly let me know if there is a decimal place of 2, do i need to do any correction in my include condition ?
Include cond=(1,8,pd,gt,1) |
|
| Back to top |
|
|
dneufarth
Active User
Joined: 27 Apr 2005
Posts: 420
Location: Inside the SPEW (Southwest Ohio, USA)
|
|
|
|
| Did you at least view the 8 bytes in HEX and verify they are valid 15 digit numeric values? |
|
| Back to top |
|
|
dneufarth
Active User
Joined: 27 Apr 2005
Posts: 420
Location: Inside the SPEW (Southwest Ohio, USA)
|
|
|
|
| Eliminated dup post. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2218
Location: USA
|
|
|
|
| sudhakar84 wrote: |
The problem is that I cannot post data from my organization. that will result in loosing my job
Kindly let me know if there is a decimal place of 2, do i need to do any correction in my include condition ?
Include cond=(1,8,pd,gt,1) |
1. You can verify the tested value printed in decimal + hexadecimal by yourself only.
2. I doubt if the exposure of a single 8-byte numeric value (without any context) might violate security policy. For instance:
DEC=1234567890 HEX=0000001234567890C
DEC=9876543210 HEX=0000009876543210C
- does this violate any policy?
Only 1, or 2, or 3 of such numeric values should clarify the issue.
Also, it sounds strange that you debug your not working code with real production data???
Anyway, I recommend you to run a standalone test on limited data to fix this issue alone.
3. Your INCLUDE statement looks fine (but it needs to be coded in caps...)
The only thing I suspect so far: in case your input dataset has RECFM=VB then you need to change the offset by 4:
INCLUDE COND=(5,8,PD,GT,1)
or, for more clarity
INCLUDE COND=(5,8,PD,GT,+1)
In the same manner you might miscalculate the original offset of your field within the record. How do you know the offset is 1? There is no sign of this fact taking into account only the presented information... |
|
| Back to top |
|
|
Arun Raj
Moderator
Joined: 17 Oct 2006
Posts: 2482
Location: @my desk
|
|
|
|
| sudhakar84 wrote: |
| The problem is that I cannot post data from my organization. that will result in loosing my job |
The problem you mentioned so far is that you see values = 1 in your output, where you expect values only >1. I don't think posting the value '1' that got INCLUDed into your output (in HEX) is so sensitive that you will lose your job.
sergeyken,
The OP mentioned in his very first post that he is working with an FB input. |
|
| Back to top |
|
|
sudhakar84
New User
Joined: 20 Jun 2008
Posts: 25
Location: chennai
|
|
|
|
| sergeyken wrote: |
| sudhakar84 wrote: |
The problem is that I cannot post data from my organization. that will result in loosing my job
Kindly let me know if there is a decimal place of 2, do i need to do any correction in my include condition ?
Include cond=(1,8,pd,gt,1) |
1. You can verify the tested value printed in decimal + hexadecimal by yourself only.
2. I doubt if the exposure of a single 8-byte numeric value (without any context) might violate security policy. For instance:
DEC=1234567890 HEX=0000001234567890C
DEC=9876543210 HEX=0000009876543210C
- does this violate any policy?
Only 1, or 2, or 3 of such numeric values should clarify the issue.
Also, it sounds strange that you debug your not working code with real production data???
Anyway, I recommend you to run a standalone test on limited data to fix this issue alone.
3. Your INCLUDE statement looks fine (but it needs to be coded in caps...)
The only thing I suspect so far: in case your input dataset has RECFM=VB then you need to change the offset by 4:
INCLUDE COND=(5,8,PD,GT,1)
or, for more clarity
INCLUDE COND=(5,8,PD,GT,+1)
In the same manner you might miscalculate the original offset of your field within the record. How do you know the offset is 1? There is no sign of this fact taking into account only the presented information... |
I found the answer. It should be
INCLUDE COND=(5,8,PD,GT,+100) |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2218
Location: USA
|
|
|
|
| sudhakar84 wrote: |
I found the answer. It should be
INCLUDE COND=(5,8,PD,GT,+100) |
So, there have been two bugs in the original version of your code...
It always makes sense to run a standalone test specifically on the suspicious data, as suggested in previous replies. In that case you'd discover your problem immediately, without long discussion on this forum, while giving us no meaningful info...
Two major issues were not mentioned:
1) you have RECFM=VB (difficult to guess in advance)
2) you did not mention which sort of "decimal 1" do you mean? It actually must be "decimal 1.00". The format PIC '9(13)V9(2)' COMP-3 is visible ONLY WITHIN the corresponding COBOL code; outside of COBOL it is considered as if it was PIC '9(15)' COMP-3 |
|
| Back to top |
|
|
|
|
|
