|
View previous topic :: View next topic
|
| Author |
Message |
Jithucse
New User
Joined: 18 Apr 2008
Posts: 11
Location: Coimbatore
|
|
|
|
Hi,
Is it possible to receive a packed decimal field in a file to alphanumeric
layout in cobol?
Suppose my file contains a field like Account which is
Fieldname type length
Account PD 12
FD XXXX
01 INPUT-REC.
05 ACCOUNT-TAB PIC X (12).
Is it possible in COBOL to receive this data by a file section above? |
|
| Back to top |
|
 |
Craq Giegerich
Senior Member
Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA
|
|
|
|
| Yes but cobol won't do any conversion, if you tell cobol that it is an X field that is the way cobol will treat it. Your record layout must match the actual data in the file or you will have problems. |
|
| Back to top |
|
|
Suresh Ponnusamy
Active User
Joined: 22 Feb 2008
Posts: 107
Location: New York
|
|
|
|
No. Direct move won't work.
When you code a MOVE statement of Packed Decimal to an Alphanumeric in COBOL, the code compilation itself will fail (compilation error).
One way I can think of moving Packed Decimal field to a numeric variable and you can redefine that numeric into Alphanumeric.
But we should be very careful in doing this. Sometimes incorrect declaration leads to data exception (S0C7) error. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Suresh: direct move isn't involved. The file will be read and the record moved into the COBOL FD buffer. A packed decimal field can be treated as alphanumeric; as long as Jithucse doesn't expect to use the packed decimal field as a number there's no problem. |
|
| Back to top |
|
|
Suresh Ponnusamy
Active User
Joined: 22 Feb 2008
Posts: 107
Location: New York
|
|
|
|
That is correct Robert. Group MOVE in COBOL will always be considered as Alphanumeric. Getting the value directly in to the Group variable will not cause any error. But it might leads to the loss of data. That data cannot be read inside the program.
Please correct me If I am wrong. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| But it might leads to the loss of data. That data cannot be read inside the program. |
Please clarify your thought on this. . .
If the code is written correctly, there should be no loss of data. When reading "external" data (data not yet validated), it is common to define it as PIC x(..) and ensure it is correct before moving it to some numeric field. |
|
| Back to top |
|
|
Suresh Ponnusamy
Active User
Joined: 22 Feb 2008
Posts: 107
Location: New York
|
|
|
|
Hi Dick,
What I meant here is, normally if we open a file which has Comp-3 variable values, it will not be in a readable format.
So if we want to use the value in the program, it should be moved to a Packed Decimal variable to perform any operation. But we cannot move an alphanumeric variable to a Packed Decimal. Cobol compiler won't allow that.
And also, the above (directly to a FD buffer) will be moved by reference (Address) and not by values. So the Packed Decimal property will be lost. After MOVE the value in the variable will not be consider as an numeric and it is alphanumeric. If we compare the HEX value of the both, it will be different (packed and alphanumeric).
Suggestions are most welcome. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
The language is COBOL. You can open files with COMP-3, COMP, DISPLAY or other fields, read them, move them, and use them as desired.
| Quote: |
| normally if we open a file which has Comp-3 variable values, it will not be in a readable format. |
would only apply if you mean human-readable (and I can read it perfectly fine by turning hex mode on while browsing the file).
| Quote: |
| And also, the above (directly to a FD buffer) will be moved by reference (Address) and not by values. So the Packed Decimal property will be lost. After MOVE the value in the variable will not be consider as an numeric and it is alphanumeric. If we compare the HEX value of the both, it will be different (packed and alphanumeric). |
This makes absolutely no sense. Packed decimal is a type of data, not a property. It cannot be gained or lost by moves. If Jithucse adds a REDEFINES clause to the FD, the packed decimal data can be used as a number by the redefined variable. |
|
| Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA
|
|
|
|
| Reading a file in cobol does no conversion to the data, if the record layout you read into match the actual data in the file then there is no problem, if it doesn't then you may have problems because cobol will try to use the data format you told it to use. |
|
| Back to top |
|
|
Suresh Ponnusamy
Active User
Joined: 22 Feb 2008
Posts: 107
Location: New York
|
|
|
|
Hi Robert,
Yes the readability here I mentioned is manual read only. Sorry for not mentioning the same. I agree with your point of reading Hex values.
Here the property I mentioned is, internal conversion of the data from a Packed decimal to alphanumeric. As Craiq mentioned, if the layout is same then there is no problem. Otherwise DB2 will try to use the given format.
As you said, using Redefine Clause, we can get the actual data.
please let me know your comments on this. |
|
| Back to top |
|
|
keyarika
New User
Joined: 24 May 2008
Posts: 10
Location: bangalore
|
|
|
|
| HI, what sholud be the length of aplhanumeric field for moving a Packed decimal of length 12. Can it be same, i mean X (12) for PD 12. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| what sholud be the length of aplhanumeric field for moving a Packed decimal of length 12 |
Please clarify your question.
It appears that you are confused as to how data is both stored and manipulated.
If you show a few examples of the data you need to work with we should be able to help. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
If your field is defined as PIC S9(12) COMP-3, this is an X(7) field.
If your field is defined as PIC X(12), this is equivalent to PIC S9(23) COMP-3 but will only be allowed by the compiler if ARITH(EXTEND) option is specified; PIC S9(18) is the maximum allowed otherwise. |
|
| Back to top |
|
|
snehal
New User
Joined: 12 Dec 2006
Posts: 14
Location: pune
|
|
|
|
Hello Robert,
Sorry, I am replying a topic almost two years old. But I could not understand how to get the pic clause X(7) for a variable declared as
PIC S9(12).
Can you please explain bit more. It will be very much helpful.
Thanks in Advance.
Regards,
Snehal |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
There is a manuals link at the top of the page. Click on it, find the COBOL manuals, and read up on internal formats for data.
A COMP-3 field stores 2 digits in each byte, plus half a byte for the sign. 12 digits of COMP-3 data can be stored in 6 bytes, but the sign requires another half-byte. Since the system won't work with half-bytes, one full byte is therefore required for the sign. 6 bytes for numbers plus 1 byte for sign is 7 bytes. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| But I could not understand how to get the pic clause X(7) for a variable declared as PIC S9(12). |
The x(7) does not "go with" a variable of s9(12). The pic x(7) is the same size as s9(12) comp-3. |
|
| Back to top |
|
|
|
|
