Mainframe, MVS and zOS Discussion

Hi,

I've been asked that if can we move the alphanumeric value to numeric variable? For example,
If we move WS-ALPHA to WS-NUM - will that be allowed?

My answer was yes we can move.

Then I was asked that will it get S0C7?

I said MOVE will not cause abend. if WS-NUM was comp-3, it could have S0C7 but with the definitions above there will not be any S0C7 by only MOVE. Possibly a COMPUTE might generate a S0C7 but not the MOVE.

Please help me to understand if it's correct.

Thanks,

Well, some of what you have said is correct. Howerver, why don't you try it? With a USAGE DISPLAY numeric and a PACKED-DECIMAL/COMP-3. Then look at the Language Reference and the Programming Guide to see if you can clear it up yourself, and then come back here with any problems you still have.

You are correct when you say that the MOVE will not abend, but not when you think a COMPUTE might, althoug that could be true with other data. Also, with that data, you won't have a problem with PACKED-DECIMAL/COMP-3.

William Collins wrote:Howerver, why don't you try it? With a USAGE DISPLAY numeric and a PACKED-DECIMAL/COMP-3. Then look at the Language Reference and the Programming Guide to see if you can clear it up yourself, and then come back here with any problems you still have.

Thanks for the guidance William, however, unfortunately I don have Mainframe Access these days and can not experiment this... . And that's why appearing in Interviews.

I'm trying to get the Hercules working on my PC but that's a daunting task in itself...

OK. These days it is ulikely that the MOVE itself will have an instruction generated which will cause an abend.

Using the subsequent result for calculation is a different thing.

Here is your number (S9(3)).
The right-most half byte of each byte is the "Numeric" nybble - and should always contain a hexadecimal 0-9. If it does not, any calculation with it will cause an abend (S0C7).

The left-most half-byte of the right-most byte is the "Sign" nybble - and should always contain a hexadecimal A-F. If it does not, any calculation with it will cause an abend (S0C7).

The remaining left-most half-byte are the "Zone" nybbles. As these are simply discarded when a Numeric (PIC 9 field with not COMP*) is "packed" for some calculation, they may contain any value and have no affect at all on the processing.

In your example there can not possibly in any circumstance be a S0C7. You should check, since you have a four-byte alpha-numeric and a three-byte numeric, which byte gets truncated.
You should be able to explain for each X'hhhh' example what the outcome will be - the value, or S0C7, from what I have described and from reading the Language Reference and Programmer's Guide where necessary.

Thanks William.

What is this number referring to? I don't understand it:

William Collins wrote:Here is your number (S9(3)).

Code: Select all

ZNZNSN

Z is for Zone, N is for Numeric. S is for Sign. Your number is PIC S9(3), so it appears as Z-N-Z-N-S-N in half-bytes or ZN-ZN-SN in bytes.

An example. If you have positive 123 in the field, it is stored as F1F2C3, where the Fs are the Zone, the digits are the Numeric, and the C is the Sign.

Just realised this is almost exactly two years later :-)

William Collins wrote:Just realised this is almost exactly two years later :-)

On our client machines Internet is blocked and we don't get to access site like this, so the delay.