|
View previous topic :: View next topic
|
| Author |
Message |
kbmkris
Active User
Joined: 24 Jun 2006
Posts: 101
|
|
|
|
hi,
I have a COBOL output file in which a field is defined as below.
| Code: |
| AFE-ALPHA-NUM PIC S9(16) COMP-5. |
In the JCL, i want to extract the records for which this particular field is not equal to zero. I dont know what data type this COMP-5 belongs to. Can anyone please let me know what will be the X in the below sortcard?
| Code: |
INCLUDE COND=(100,8,X,NE,0)
SORT FIELDS=COPY |
Say, the field starts at 100th position in the file.
Thanks,
Bala |
|
| Back to top |
|
 |
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| Comp-5 is just binary and since your definition is signed, using FI, fixed point, signed (Equivalent to Signed Binary), will do what you want. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
Bala,
For
| Quote: |
| I dont know what data type this COMP-5 belongs to |
following may be helpful:
COMPUTATIONAL-5 or COMP-5 (native binary): These data items are represented in storage as binary data. The data items can contain values up to the capacity of the native binary representation (2, 4 or 8 bytes), rather than being limited to the value implied by the number of nines in the picture for the item (as is the case for USAGE BINARY data). When numeric data is moved or stored into a COMP-5 item, truncation occurs at the binary field size rather than at the COBOL picture size limit. When a COMP-5 item is referenced, the full binary field size is used in the operation.
Further, the TRUNC(BIN) compiler option causes all binary data items(USAGE BINARY, COMP, COMP-4) to be handled as if they were declared USAGE COMP-5.
A variable of COMP-5 nature, between the range S9(10) through S9(18) is Binary doubleword (8 bytes) & it can represent a numeric value
from -9,223,372,036,854,775 through +9,223,372,036,854,775.
Obviously AFE-ALPHA-NUM PIC S9(16) COMP-5, from your post, is a signed binary variable so for SORT, syntax suggested by William should work. |
|
| Back to top |
|
|
kbmkris
Active User
Joined: 24 Jun 2006
Posts: 101
|
|
|
|
Thanks William & anuj, FI is working in the SORTCARD.
Thanks
Bala |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
You are welcome.  |
|
| Back to top |
|
|
dr_te_z
New User
Joined: 08 Jun 2007
Posts: 71
Location: Zoetermeer, the Netherlands
|
|
|
|
| kbmkris wrote: |
I have a COBOL output file in which a field is defined as below.
| Code: |
| AFE-ALPHA-NUM PIC S9(16) COMP-5. |
|
Take the problem 1 step further back. Talk to the guy/girl who designed this file. Ask him/her to limit himself to packed-decimal when it gets to external data. COMP-5 is excellent in your working/local storage doing calculations and stuff. But the contents is dependant on compiler options. You don't want that in files.
This could be solved but next time you ask: I just FTP'd this dataset to box ABC with characterset XYZ: how do I ....?
In that case, use:
| Code: |
| PIC S9(17) usage display sign leading separate |
There's the strenght of COBOL, this format survives any conversion! |
|
| Back to top |
|
|
kbmkris
Active User
Joined: 24 Jun 2006
Posts: 101
|
|
|
|
hi,
Thanks for your suggestion. You are saying that COMP-5 is dependent on compiler options. But what anuj says is, the compiler option TRUNC(BIN) will change comp, comp-4, and binary as COMP-5. Could you clarify me?
As you said, we can't alter the field as that field is in that way for more than 1 and half years. It seems to be the best as it can store values upto 8 bytes instead of the number of 9 in the variable declaration.
Thanks,
Bala |
|
| Back to top |
|
|
dr_te_z
New User
Joined: 08 Jun 2007
Posts: 71
Location: Zoetermeer, the Netherlands
|
|
|
|
OK, compiler options can influence the internal representation of comp-4 fields instead of comp-5. Sorry about that. This means that comp-4 is even worse than comp-5.
But I stick to my point: binary numeric data is hardly human-readable and very hard to convert to other character sets. You'll never know what is going to happen to a dataset in the future, so stick to comp-3 to compress some space or zoned. When you choose zoned, cough up the sign as well to make life even less complicated. |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| dr_te_z wrote: |
| You'll never know what is going to happen to a dataset in the future, so stick to comp-3 to compress some space |
And PD isn't "very hard to convert to other character sets"?
Bala, stick with what you have, comp-5 is probably the best usage for the field....
dr_te_z, good point about the ZD sign.... |
|
| Back to top |
|
|
kbmkris
Active User
Joined: 24 Jun 2006
Posts: 101
|
|
|
|
hey,
| Quote: |
| But I stick to my point: binary numeric data is hardly human-readable and very hard to convert to other character sets |
I don't think so. I can read this field using file-aid. I too not sure, how i am able to, as it is a binary field. Can anyone let us know the reason behind that?
Thanks,
Bala |
|
| Back to top |
|
|
dr_te_z
New User
Joined: 08 Jun 2007
Posts: 71
Location: Zoetermeer, the Netherlands
|
|
|
|
| William Thompson wrote: |
| And PD isn't "very hard to convert to other character sets"? |
Yes, but:
- at least you have a 'predictable' binary pattern
- it is do-able (not easy) to translate ebcdic-PD to ansi-PD.
I'm trying to make this point here because I've seen too many annalists designing files-to-be-send-to-whatever containing all kinds of formats without even thinking about it.
We, mainframe developers, tend to be fairly shortsighted.
b.t.w. why did the-rest-of-the-world invent XML? Is it used a lot in our mainframe world? why not?
N.B. do not feel insulated please, I'm just trying to invoke some self-reflection |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| dr_te_z wrote: |
| it is do-able (not easy) to translate ebcdic-PD to ansi-PD. |
What is ansi-PD?
1234 is X'01234C' would be what in ansi? |
|
| Back to top |
|
|
dr_te_z
New User
Joined: 08 Jun 2007
Posts: 71
Location: Zoetermeer, the Netherlands
|
|
|
|
| William Thompson wrote: |
What is ansi-PD?
1234 is X'01234C' would be what in ansi? |
more or less the same. I've worked with Micro focus and ACU cobol on P.C.'s and unix-es and when you write a record to file containing COMP-3 fields you can browse (remember Norton?) the file hexadecimal and you recognize your data and you can read it.
I'm not sure about the trailing sign-half-bit, but I check if you want to. That will be later, I'm at the office now. |
|
| Back to top |
|
|
|
|
