|
View previous topic :: View next topic
|
| Author |
Message |
baljinders
New User
Joined: 21 Aug 2006
Posts: 72
|
|
|
|
Hi,
I am getting SOC7 Error on the below move.
| Code: |
01 IN-REC.
05 AMOUNT PIC S9(15)V9(02) COMP-3.
01 OUT-REC.
05 AMOUNT1 PIC S9(15)V9(02) COMP-3. |
Move IN-REC to OUT-REC.
is this move possible ?? |
|
| Back to top |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Moving alphanumeric data (the posted level 01s are group fields and so are alphanumeric) should not cause a s0c7. . .
Your problem is probably trying to use the numeric AMOUNT1 field after the move. What value is in AMOUNT and AMOUNT1 at the time of the abend? |
|
| Back to top |
|
|
baljinders
New User
Joined: 21 Aug 2006
Posts: 72
|
|
|
|
Sorry for the incorrect information in the earlier post.
Amount1 is a 05 level copybook field where as amount2 is a level 10 working storage field.
05 Amount1 PIC S9(15)V99 COMP-3.
10 Amount2 PIC S9(15)V99 COMP-3 VALUE 0.
The Amount1 field has zero in it. |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
Are you still moving IN-REC to OUT-REC?
Are you moving Amount1 to Amount2? |
|
| Back to top |
|
|
baljinders
New User
Joined: 21 Aug 2006
Posts: 72
|
|
|
|
| Amount 1 to amount 2 |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
Packed decimal to packed decimal results in the assembler ZAP (zero and add packed) instruction which can generate a data exception, an S0C7.
Amount1 has non-numeric data in it. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Your code should be something along the lines of
| Code: |
IF AMOUNT1 NUMERIC
MOVE AMOUNT1 TO AMOUNT2
ELSE
MOVE ZERO TO AMOUNT2
END-IF. |
The level numbers for AMOUNT1 and AMOUNT2 do not matter.
The location (WORKING-STORAGE or FD) do not matter.
The value of AMOUNT2 before the MOVE statement does not matter.
The number of digits in AMOUNT1 and AMOUNT2 do not have to be the same -- their size doesn't matter.
The value of AMOUNT1 is the only thing that matters. If it is not a number AS COBOL DEFINES NUMBERS, your move may happen but using AMOUNT2 can cause a S0C7 abend. What things would not be considered numbers by COBOL? Plus sign, minus sign, decimal point, comma, spaces instead of zeroes -- basically anything except 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9 (except for the last half byte where the sign is stored) will be invalid. |
|
| Back to top |
|
|
baljinders
New User
Joined: 21 Aug 2006
Posts: 72
|
|
|
|
Thanks Everyone,
I'll make the necessary changes and will get back with the results. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Check your compile options and ensure NUMPROC(NOPFD) is set as opposed to NUMPROC(PFD).
PFD can cause great harm because, instead of a ZAP, an MVC is issued, because the field lengths are the same. You never get a S0C7 with an MVC.
Another little "nasty" is if AMOUNT2 were packed-neutral sign PIC 9 instead of packed-signed PIC S9, because unlike moving a signed-field to signed-field, where the compiler generates a ZAP (as Bill has said above), the compiler will generate an MVC followed by an "OI" of the last byte, to ensure an "F" sign-nibble. This is how a neutral signed AMOUNT2 could end up with a value of X'40404040404040404F', when AMOUNT1 contained all SPACES.
It's best to get the S0C7, because then you can find the bad data earlier than waiting until the excrement hits the fan.
Without the S0C7, you could move the bad data to a file and/or a DB and then, you've compounded the problem significantly.
Don't get me wrong, NUMPROC(PFD) does save cycles, but at what cost? All you need is one packed-field with bad data being propagated throughout the company enterprise and you'll be in more trouble than a squirrel on a six-lane highway. You'll spend much more time tracking down and fixing the problem, than the cost of the saved cycles.
Unless you're guaranteed (with 100% accuracy) that your packed-data will always pass the "smell" test, then I would stick with NUMPROC(NOPFD).
You'll be glad you did.... 
Bill |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| Bill O'Boyle wrote: |
| PFD can cause great harm because, instead of a ZAP, an MVC is issued, because the field lengths are the same. You never get a S0C7 with an MVC. |
Thanks Bill, I'll try to remember that....grin.... |
|
| Back to top |
|
|
|
|
