|
View previous topic :: View next topic
|
| Author |
Message |
Prasun De
New User
Joined: 17 Jan 2008
Posts: 28
Location: Kolkata, INDIA
|
|
|
|
A PIC X(3) VALUE 'AAA'
B PIC 9(3)
MOVE A TO B
Display B
The above code displays AA1 in sysout.
Please help me understand this. This was actually an interview question. I told it will be a SOC7 But when I tried it is going over my head. |
|
| Back to top |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
I believe we would all be better off if it actually did abend. . . 
Unfortunately, what you have observed is the way it is supposed to work (i.e. it is a feature rather than a problem).
The hex for AAA is x'C1C1C1'. When this is moved to an unsigned zoned decimal field, the sign is converted to an "F" sign (assumed positive).
Change B to pic s9(3) and run again. . . |
|
| Back to top |
|
|
Prasun De
New User
Joined: 17 Jan 2008
Posts: 28
Location: Kolkata, INDIA
|
|
|
|
Yes, I tried and got it dispalyed as AAA,
So what I'm getting is, For unsigned zoned decimal the assumed positive sign is inserted into the last byte but for Signed zoned decimal, the Sign is stored separately... |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
Well, not really "separately".
A signed +1 is an x'C1' which is an A when displayed. An unsigned 1 is an x'F1' which is a 1 when displayed. And to complete the set, a signed -1 is an x"D1' which is a J when displayed. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| So what I'm getting is, For unsigned zoned decimal the assumed positive sign is inserted into the last byte but for Signed zoned decimal, the Sign is stored separately... |
No, you need to click on the manuals link at the top of the page, find the COBOL Language Reference manual sections about internal representation of the different formats of variables, and read it thoroughly. Your question indicates you have no understanding of the internal formats of variables and any competent COBOL programmer should have a good understanding of this topic. |
|
| Back to top |
|
|
saurabh39
Warnings : 1
Active User
.jpg)
Joined: 11 Apr 2008
Posts: 144
Location: Jamshedpur
|
|
|
|
@Robert & @Dick - I have a question.
In the above scenario, the sending field is alphanumeric and receiving is Numeric(Usahe Display).
So it should follow the rule stated in elementary move from alphanumeric to numeric.....
Which says, it is possible but and i quote from manual
| Quote: |
| Figurative constants and nonnumeric literals must consist only of numeric characters and X will be treated as numeric integer fields. |
Which means...when the sending field contains numeric values....then only the move is possible.
But the above scenario doesn't conform to the manual.
Am i missing something? |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
you keep using numeric display fields, which are basically alphanumeric,
but allows the CLASS test IF NUMERIC.
otherwise, numeric display fields allow any type of garbage to be moved in.
if the PIC clause has a sign, the sign byte will be moved but ignoring the high-order bits.
if you want to discuss numeric move rules, deal with a numeric field - comp-3. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
saurabh39, you missed this quote from section 6.2.24.1.1 of the COBOL Language Reference manual on elementary move rules, talking about numeric receiving fields:
| Quote: |
| When the category of the sending item is alphanumeric, alphanumeric-edited, national, or national-edited, the data is moved as if the sending item were described as an unsigned integer. |
|
|
| Back to top |
|
|
Kjeld
Active User
Joined: 15 Dec 2009
Posts: 365
Location: Denmark
|
|
|
|
| saurabh39 wrote: |
@Robert & @Dick - I have a question.
In the above scenario, the sending field is alphanumeric and receiving is Numeric(Usahe Display).
So it should follow the rule stated in elementary move from alphanumeric to numeric.....
Which says, it is possible but and i quote from manual
| Quote: |
| Figurative constants and nonnumeric literals must consist only of numeric characters and X will be treated as numeric integer fields. |
Which means...when the sending field contains numeric values....then only the move is possible.
But the above scenario doesn't conform to the manual.
Am i missing something? |
Your excerpt from the manual deals with figurative constants and literals (i.e. hardcoded values), not general move logic. |
|
| Back to top |
|
|
saurabh39
Warnings : 1
Active User
Joined: 11 Apr 2008
Posts: 144
Location: Jamshedpur
|
|
|
|
Thanks Robert & Kjeld for clarification.
Yes my missed the below quote(my mistake)
| Quote: |
When the category of the sending item is alphanumeric, alphanumeric-edited, national, or national-edited, the data is moved as if the sending item were described as an unsigned integer.
|
But now I have another question, if Alphanumeric sending item is treated as unsigned integer, then all the alphanumeric to numeric move should be valid, then in what case will we get SOC7. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| You misunderstand again -- alphanumeric sending items being treated as unsigned integer does not mean any conversion of characters to numbers will occur. If you move an AAA to a PIC S9(03) COMP-3 variable, you'll still get a S0C7 abend. Unsigned integer means the decimal point is aligned after the last character of the sending variable, and no sign conversion will be attempted -- and nothing else is meant or implied by the quoted statement. Invalid data in the sending variable still causes S0C7 abends. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| then all the alphanumeric to numeric move should be valid |
Why do you believe thie?
You need to spend much more time doing research and should probably run 100 or more experiments using all kinds of data definitions and values.
When there was a better method of training, this type of question was for curiosity/learning rather than for implementation. Every numeric "input" field was completely edited before the code moved the field or tried to use it in a numeric comparison or computation. There was a substantial penalty for "being slack" by not incorporating complete validity checking. |
|
| Back to top |
|
|
|
|
