I have changed an existing program due to a business requirement, But I am facing a S0C4 issue with it .. It blows up at below Machine Instrunction
at address 00FBD2 .. Can some one please put some more light on this as I dont know assembler langauage
RMP02000 I ATTN9999 06.07.31 02/03/15 STARTED.
RMP02000 MESSAGE:
PROGRAM EXECUTION COMPLETE
*** PROGRAM TERMINATING ***
CEE3204S The system detected a protection exception (System Completion Code=0C4) From compile unit RMP02000 at entry point RMP02000 at compile unit offset +0000FBD2 at entry offset +0000FBD2 at address 4840FBD2.
below is my code in the program
Code:
IF RMPREC-DT-1ST-DELINQ EQUAL SPACES
AND RMPREC-REC-TYPE EQUAL '01'
MOVE 'DOFD IS BLANK' TO REJECT-MSG2
MOVE '10' TO DT-REJECT-CODE-2
MOVE '81' TO DT-REJECT-CODE-2
PERFORM 9200-REJECT-TRAN THRU 9200-EXIT
GO TO 3100-EXIT.
By looking at the compile listing and sysout it looks like it went down on the statement number 06226 which is a write statement like below
Code:
WRITE RPT-SEQ-RECORD FROM DETAIL-TOTRPT.
Below is the definition of RPT-SEQ-RECORD and DETAIL-TOTRPT respectively
Code:
01 RPT-SEQ-RECORD.
05 FILLER PIC X(110)
.
Code:
01 DETAIL-TOTRPT.
05 DT-MIO PIC X(04) VALUE SPACES.
05 DT-REJECT-CODE-1 PIC X(02) VALUE SPACES.
05 DT-REJECT-CODE-2 PIC X(02) VALUE SPACES.
05 DT-APPL-ID PIC X(03) VALUE SPACES.
05 DT-ACCT-NBR PIC X(20) VALUE SPACES.
05 DT-VALUE PIC X(40) VALUE SPACES.
05 DT-AMT-CHAR PIC X(07) VALUE SPACES.
05 DT-VALUE-DLRS REDEFINES DT-AMT-CHAR
PIC S9(11)V99 COMP-3.
05 DT-DESC PIC X(32) VALUE SPACES.
Note:- This program is running fine in production without my change .
Please help to understand this issue and its resolution..
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I assume you are coding in the style of the existing program.
Code:
IF RMPREC-DT-1ST-DELINQ EQUAL SPACES
AND RMPREC-REC-TYPE EQUAL '01'
MOVE 'DOFD IS BLANK' TO REJECT-MSG2
MOVE '10' TO DT-REJECT-CODE-2
MOVE '81' TO DT-REJECT-CODE-2
PERFORM 9200-REJECT-TRAN THRU 9200-EXIT
GO TO 3100-EXIT.
Look at the fourth and fifth lines. Something wrong there, but won't cause S0C4.
88s, END-IF missing, and has the THRU and GO TO. Makes the program more open to failure.
Is the instruction which failed as part of the WRITE in 9200-REJECT-TRAN (THRU 9200-EXIT)? Probably.
Is this perhaps the first time something has been written to that file?
Most likely cause is the file not being open, either at all, or at the time that you use it (may not have been opened, may have been closed).
Confirm that the existing Production program runs with your test data.
Confirm that there are no messages in file three of the sysout (like DD missing).
Confirm that the program uses FILE STATUS fields for each file and checks them after each IO (I bet it doesn't).
The IF condition is ending with a dot(.) after GO TO 3100-EXIT statement in last line, I changed it in the same style this program has written hence didn't use END-IF, However we have so many condition coded in same manner pointing to 3100-EXIT with a GO TO Statement
The instruction which is failing is under the 9200- Para which performs 9120-ERROR - para for each line of report ..
Code:
9200-REJECT-TRAN.
IF RMPREC-REC-TYPE NOT = SPACES
MOVE RMPREC-REC-TYPE TO DT-VALUE
MOVE 'REC TYPE ' TO DT-DESC
PERFORM 9100-PROCESS-ERROR THRU 910
0-EXIT.
Code:
9100-PROCESS-ERROR.
MOVE WS-MIO TO DT-MIO
MOVE DT-REJECT-CODE-1 TO WS-REJ-CODE-1-HOLD
MOVE DT-REJECT-CODE-2 TO WS-REJ-CODE-2-HOLD
IF APPL-CODE-ERROR = 'Y'
MOVE RMPREC-APPLICATION-CODE TO DT-APPL-ID
ELSE
MOVE APPLID-CODE(A-SUB) TO DT-APPL-ID.
MOVE RMPREC-ACCT-NBR TO DT-ACCT-NBR.
[color=red]WRITE RPT-SEQ-RECORD FROM DETAIL-TOTRPT[/color].
The last line I believe is causing the issue
The report/file is written every day this program runs but when it goes inside my code for any record then it blows up
Production program runs well with test/prod data
File status is not coded after each IO .. but it is running fine without my changes
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I agree that is the line causing the problem.
When the implicit MOVE of the WRITE ... FROM ... is being done, one of the items has "lost" addressability. Since your source field is in WORKING-STORAGE (probably, from the name) it is most likely the file area.
The first likely cause is that the file has been CLOSEd already before your code. That's the simple one.
Is your code executing, at any point, after the report file has been closed?
Thank you so much Bill for all your help and time..
The issue was resolved by placing this code in the right paragraph.. you were correct this was not working because we did not have the file open.. Actually this code came from one of my colleague and I was testing it without doubting on code because he also tested it months back(was working fine) and there after he left the organization , So I suspected the data only .. Any way you made me to focus on the code instead of data .. Thanks a lot again !!
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Yes, it should, but it doesn't help in situations like this. Helps in plenty of others.
The S0C4 would come before the WRITE went off to the IO-routines. Access the data under the FD after a file is CLOSEd, or before it is OPENed, and S0C4 will result.
Unless the file is using APPLY WRITE ONLY, or the program has compiler option AWO.
In that case, the S0C4 will be avoided (can never happen) and the FILE STATUS field will save the day for sure. If coded. Only if coded.
Do use APPLY WRITE ONLY for VB output files. Don't use compiler option AWO. Do use FILE STATUS checking after each IO, regardless of file type (do use extended FILE STATUS for VSAM).