MVSFORUMS.com

yadav2005 · Intermediate Joined: 10 Jan 2005 Posts: 348 Topics: 144

Hai,

I am presently undergoing training in Mainframe & i am trying to simulate S0C7 error & this is the pgm which i have coded.I am assuming to get S0C7 error when i am moving data from alphabetic to numeric but when i run my runjcl i do not get S0c7 but the output below.Please help me how do i simulate S0C7 / solve the problem & what should i do if i get S0C7 ?

PGM
IDENTIFICATION DIVISION.
PROGRAM-ID. SAMPLE.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A PIC X(3) VALUE 'GAP'.
01 B PIC 9(3).
PROCEDURE DIVISION.
MOVE A TO B.
DISPLAY 'A IS ' A.
DISPLAY 'B IS ' B.
STOP RUN.

COMPJCL
RC =4

RUNJCL
//TECH22Z JOB ACCT#,'MJ',CLASS=A,NOTIFY=&SYSUID,MSGLEVEL=(1,1),
// TIME=(,2)
//STEP1 EXEC PGM=SAMPLE
//*******************************************************************
//* CHANGE THE PGM NAME ON EXEC AND STEPLIB
//*******************************************************************
//STEPLIB DD DSN=TECH22.COBOL.OBJ,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSIN DD DUMMY
//

SYSOUT
********************************* TOP OF DATA **********************************
A IS GAP
B IS GA7
******************************** BOTTOM OF DATA ********************************

kolusu · Posted: Mon Jan 10, 2005 5:42 am Post subject:

yadav2005,

There are many ways to simulate a S0C7 abend. The simplest way is to Divide the variable by zero or change the definition of B to comp-3 and perform any arthimetic on it.

yadav2005 · Intermediate Joined: 10 Jan 2005 Posts: 348 Topics: 144

Kolusu,

I have tried simulating the code which u have mentioned in two types when i code using the second method i get the output:but i do not get S0C7 anywhere please can u help me out.

PGM
IDENTIFICATION DIVISION.
PROGRAM-ID. SAMPLE.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A PIC X(3) VALUE 'GAP'.
01 B PIC S9(5) COMP-3.
PROCEDURE DIVISION.
MOVE A TO B.
ADD +1 TO B.
DISPLAY 'A IS ' A.
DISPLAY 'B IS ' B.
STOP RUN.

COMPILE JCL
RC=0

RUNJCL
A IS GAP
B IS 00718

--------------------------------------------------------------------------------------------

PGM
IDENTIFICATION DIVISION.
PROGRAM-ID. SAMPLE.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A PIC X(3) VALUE 'GAP'.
01 B PIC 9(3).
PROCEDURE DIVISION.
COMPUTE B = A / 0.
DISPLAY 'A IS ' A.
DISPLAY 'B IS ' B.
STOP RUN.

But,When i code using the first method i get compile time error with RC=12 the reason being

11 IGYPA3074-S "A (ALPHANUMERIC)" was not numeric, but was a sender in a arithmetic expression. The statement was
discarded.

11 IGYPA3150-W A zero constant was used as a divisor.This statement may cause a program exception at execution time.
-Messages Total Informational Warning Error Severe Terminating
0Printed: 2 1 1
-* Statistics for COBOL program SAMPLE:
* Source records = 14
* Data Division statements = 2
* Procedure Division statements = 4
0End of compilation 1, program SAMPLE, highest severity 12.
0Return code 12

kolusu · Posted: Mon Jan 10, 2005 8:44 am Post subject:

yadav2005,

oops here is the correct code. I forgot about the redefines part.

dtf · Posted: Mon Jan 10, 2005 10:45 am Post subject:

yadav2005 · Intermediate Joined: 10 Jan 2005 Posts: 348 Topics: 144

Kolusu,

I have included the code whichu had mentioned & here is the

PGM

IDENTIFICATION DIVISION.
PROGRAM-ID. SAMPLE.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 A PIC X(3) VALUE 'GAP'.
01 B REDEFINES A PIC S9(5) COMP-3.
PROCEDURE DIVISION.
ADD +1 TO B.
DISPLAY 'A IS ' A.
DISPLAY 'B IS ' B.
STOP RUN.

COMPILE JCL
RC=0

RUNJCL
SOC7 ABEND

OK in the spool ,i have the listing for

JESMSGLG JES2
JESJCL JES2
JESYSMSG JES2
SYSOUT STEP1
CEEDUMP STEP1

When i give a "s" command in SYSOUT, i get the description for the abend S0C7 with the offset +0000025E at address 0000818E.When i give a "s" command in CEEDUMP & made a find for the offset +0000025E ,i got the display.Now i do not know to proceed further .My question is how do i proceed to solve S0C7.

After finding for the offset what should i do & what more i have to find.Can u please guide me in the process.
My concern is to solve S0c7 now.

dtf · Posted: Tue Jan 11, 2005 10:43 am Post subject:

In your run JCL you should also include a

kolusu · Posted: Tue Jan 11, 2005 8:15 pm Post subject:

vini · Posted: Wed Jan 12, 2005 2:19 pm Post subject:

I too recently faced a strange SOC7 problem. Even though the return code in Cntl-M is S04C (not S0C4) the sysout refers to a SOC7.

I used the method Kolusu has explained in one of the posts to get to the statement in error using the offset method .
compile unit offset +0000C9CC
The hexlocs closest to this are 00C9C8 & 00C99E. Since 00C9C8 is closer
I am looking at line # it points to and its a MOVE statement which apparently looks innocent as the data types match and a constant is being moved to a linkage variable and is a standard part of almost every program which prints notices/reports here.
MOVE WSV-RPT-OVER-PAYMENT-STMT
TO WLP-I720-RPT-ID
Even the statement pointed by 00C99E doesnt look like a potential cause
PERFORM 30710-INIT-AJI720-VAR
THRU 30710-EXIT (comprises of an initialise statement for every linkage parameter in the stored procedure which is called thereafter)

My concern is :
Why are the results so unpredictable ? The first time I ran a test using production data I did encounter a similar SOC7 abend and no S04C. However subsequent runs in test did not result in abend despite the data being reverted to its original production like state before each run.

I will be increasing the Region in JCL to 0M as I read someplace that it can help with S04C abends which are unpredictable. Rolling Eyes

I am keeping my fingers crossed as I re-schedule its run in production and which is with minimal change , as I could not trace any real SOC7 like issues.

Any pointers or suggestions would be appreciated.

vini · Posted: Wed Jan 12, 2005 5:14 pm Post subject: Problem located

What is strange is that the SOC7 offset did not point to the problem statement though. Exclamation

Theres a table which had been defined as OCCURS 50 TIMES. This had exceeded like upto 70+ the point at which it abend. However, I was under impression that subscript errors/abends would occur as soon as the maximum limit is surpassed ..i,e in this case at the 51st occurence . So it means that the abend may or may not happen and all depends on howmuch and what is available in memory Rolling Eyes

kolusu · Posted: Thu Jan 13, 2005 6:46 am Post subject:

vini,

A internal table overflow can cause a S0C7 as the overflow might have corrupted the fields declared below the internal table. Now when you try to access the corrupted field via move you will encounter a S0C7.

In your case you just got lucky that 51st occurance did not corrupt a Comp-3 field or you are not referring those fields after the overflow.

Just an example , declare a internal table of 5 occurs and load it with 6 occurances. Also declare a comp-3 field immediately after the internal table declaration.

Now check the contents of the comp-3 field after the load.

Hope this helps...

Cheers

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu

vini · Posted: Thu Jan 13, 2005 1:25 pm Post subject:

Yes Kolusu, It all makes sense now !!! The variable in the statement indicated by offset is a PIC S9(15)V USAGE COMP-3.

aquarian · Posted: Wed Dec 21, 2005 5:17 am Post subject:

Hi all,
Recently i got the same abend ..but when i changed some attributes it has been resolved ...
I can surely say that SOC7 is the most happening and unpredictable abend that occurs in mainframes
what do u guys say??????????????? 8) :
_________________
cheers,
Aquarian

kolusu · Posted: Wed Dec 21, 2005 2:05 pm Post subject:

aquarian · Posted: Thu Dec 22, 2005 10:20 am Post subject:

Yes kolusu,
I understand the abend ..but what i mean to say is that we cannot predict the occurance of S0C7 right Confused

_________________
cheers,
Aquarian