View previous topic :: View next topic
|
Author |
Message |
faizm
New User
Joined: 13 Apr 2012 Posts: 59 Location: India
|
|
|
|
I am getting S0C4 Abend sometimes.
My code (basically read a input file and create a new file both of same LRECL, and format) runs fine and gives proper output file when there is less number of records (in 100's) in input file but it got abended when there are records in thousands in i/p file. Also, the same happens when there is an empty input file.
My Job uses two programs. The first one create the sorted output for the next program. The S0C4 abend always occurs in the second program only which uses the sorted input.
I tried reading the dump and there it shows MVCL( Long Move) and also inaccessible storage for large number of records and inaccessible storage for empty file layout.
I have initialized my output file also but still getting the abend. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
When S0C4 Abend occurs
An Invalid address referenced due to subscript error
In a group Move the length of the receiving field was defined incorrectly
Moving variable length record which is larger than the receiving field’s length.
Read/Write a file which has not been opened in the program.
Read/Write a file after EOF.
Invalid parms passed through linkage section.
Used DD dummy with logic that moves high values to FD at end of read.
Tried to use CALL within COBOL SORT Input output procedure
Using GOBACK in COBOL SORT output procedure
do You have any tables in Your program ?
Quote: |
Also, the same happens when there is an empty input file. |
define empty... and check Your end of file processing. |
|
Back to top |
|
|
faizm
New User
Joined: 13 Apr 2012 Posts: 59 Location: India
|
|
|
|
Enrico, empty file layout is same as that of other i/p files. I don't have tables in program. check is already there in place for end of file processing. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
The S0C4 tells you that you were trying to access storage that you were not allowed to, so no surprise to see references to that in the formatted dump.
An MVCL is certainly a possibility for a failing instruction, but tells us nothing in itself.
What language is the second program in your Job written in? Have you located which (presumably) high-level-language instruction caused the abend?
The S0C4 for an "empty" file is possibly the same thing, and possibly not. If, in you end-of-file processing, you access anything from the input record area, you will likely get an S0C4 for an "empty" file.
The "other" S0C4 is down to the processing you do when there is data on the file. You have to tell us more about that, including answering enrico's question, |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
faizm wrote: |
Enrico, empty file layout is same as that of other i/p files. I don't have tables in program. check is already there in place for end of file processing. |
How many files are you reading? The record-layout for a file with no data is largely irrelevant.
No tables? What about called programs? Or is yours a called program? Remember we need to know what language.... |
|
Back to top |
|
|
faizm
New User
Joined: 13 Apr 2012 Posts: 59 Location: India
|
|
|
|
Bill, second program is reading the output file created from pgm 1. my requirement is that if the records are there in the i/p file for 2nd program then it should format that input file and create a new file. If there is no record in the i/p file for 2nd pgm then it should create an empty file. The 2nd pgm is not called by any program nor does it calls other. It uses the output created from previous pgm in the job and then format the files accordingly.
The code is written in cobol. |
|
Back to top |
|
|
faizm
New User
Joined: 13 Apr 2012 Posts: 59 Location: India
|
|
|
|
And, it always fails at the point of first time write i.e WRITE OUTPUT-RECORDS FROM WS-INPUT RECORDS. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
how do You tell the called program that no record is being passed and it has to do nothing?
who is opening and closing the output file ? |
|
Back to top |
|
|
faizm
New User
Joined: 13 Apr 2012 Posts: 59 Location: India
|
|
|
|
I am checking for the low values in the first record ( in case of empty file) before the execution of WRITE statement and if it is low values then exit from this para and close all the files. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
If you open a file, read, get end-of-file and then try to use the record area (check for low-values) you will get S0C4. Once end-of-file is reached, don't ever try to use an input-record area.
Your "empty" file is identified by counting the records as you successfully read them. Once end-of-file is encountered, if you have zero records counted, then you have an empty file.
The "other" S0C4 may well be the same problem, but could be different.
I don't see, without overwriting of code, how write output from ws could give an S0C4 - or is your output file not open at the time? |
|
Back to top |
|
|
faizm
New User
Joined: 13 Apr 2012 Posts: 59 Location: India
|
|
|
|
Bill, I am able to resolve the S0C4 for empty file. However, it remains as such for file with large number of records.
Is that I need to set the region parameter on this step with 0M (if there may be memory issue). The file is open output before writing. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
most of the addressing issues would go away
and you would be left with just the logic to debug
if you were to insure that- all READs use the WORK-AREA OPTION
- all WRITEs use the WORK-AREA OPTION
- and no instruction references a file structure in the FD, and i mean nooooon
also,
the assumption that a record will contain binary zeros at the end of file
is wrong.
use file status to determine if the i/o was successful.
as bill said, after the first read, and end-of-file would indicate empty file.
that you occaisionally receive a data protection leads me to guess,
that you have code that checks the buffer, even after end-of-file.
using the buffer (FD File area) contents is poor programming
as well as error prone.
based on the size of the buffer and the number of records
sometimes the program will run ok and sometimes it will not.
stay out of the FD File area,
only reference the work-area in WORKING-STORAGE,
only use WORK-AREA OPTION for READs and WRITEs. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
I am checking for the low values in the first record ( in case of empty file) before the execution of WRITE statement and if it is low values then exit from this para and close all the files. |
This may or may not be appropriate, depending upon how your site is set up. Sites can choose to initialzie memory (usually to LOW-VALUES or x'00') but this is NOT standard across all sites. You really need to check the FILE STATUS variable after the READ is complete to determine if you got a 10 (end of file). |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Would you like to confirm how you resolved that S0C4, please?
Region=0M? No. It will be nothing to do with that.
OK. If you don't have it already, compile with the generated pseudo-assembler.
Make sure the instruction you see at the offset in the program is the one you see at the offset in the formatted dump, and check that the stuff close to it in the dump looks like your program code. We don't usually check for that specifically, you just notice something "looks" wrong when it is, and confirm with the compile listing.
In the dump, either directly or from your W-S, check that the output file is open. Remember. You have an error in your program (at least one). So even though you think your file is open, it might not be.
What sort of file is it? V/VB, F/FB, VSAM, what?
You say it is an MVCL. You show a WRITE... FROM W-S, so that is consistent with seeing an MVCL. Unless you have trashed something big-time, you haven't lost addressability of your working-storage, so it is the record-area/buffer that does not exist. Quickest way to get that is to fail to open the file successfully or to successfully close it before the write. Those are the most likely scenaria.
If none of that, you'll have to start showing us some snippets of relevant code. OPEN, CLOSE, READ and WRITE, FDs and SELECTS, output messages from the step and the JCL for the step. |
|
Back to top |
|
|
faizm
New User
Joined: 13 Apr 2012 Posts: 59 Location: India
|
|
|
|
well (S0C4 for empty file) that was solved by setting a flag at the end of file and then bypass the write statement when it is true.
I have already FILE STATUS in place and it shows file not open at the time of WRITE. Well my file is in OPEN OUTPUT mode defined in Initialize para. How come the file get closed before the Write statement? I have another question coming in that why it happens when there are huge records in the i/p file and no S0C4 for less number of records. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
If you have opened your output file, yet it is closed by the time you come to a particular WRITE and you weren't expecting that, then you have a logic error in your program. With the smaller number of records (probably the content of the records, rather than the number of records is the problem) then it has just not created the situation where the logic error causes the file to be closed by your program.
Causes of S0C4 Abend
Invalid Addressing: The program attempted to access a storage address that does not exist or is not accessible due to addressing errors.
Protection Violation: The program tried to read from or write to a protected area of memory without the necessary permissions.
Data Alignment Errors: The program accessed data at an address that is not aligned correctly for the data type (e.g., accessing a 4-byte integer at an address that is not a multiple of 4).
Addressing Mode Misalignment: The program is in the wrong addressing mode (24-bit vs. 31-bit vs. 64-bit) and attempts to use an address that is not valid in the current mode.
Common Scenarios Leading to S0C4 Abend
Uninitialized Pointers: Using pointers that have not been properly initialized to valid storage addresses.
Out-of-Bounds Access: Accessing array elements or memory locations outside the allocated bounds.
Program Logic Errors: Bugs in the code logic that lead to illegal memory accesses.
Overlay Problems: One part of the program overwrites memory that is used by another part, leading to invalid addresses.
Diagnosing S0C4 Abend
Dump Analysis: When an S0C4 abend occurs, the system usually generates a dump file. Analyzing this dump file with tools like IPCS (Interactive Problem Control System) can help identify the cause.
Review PSW (Program Status Word): The PSW contains the address of the instruction that caused the abend. This can help pinpoint the location in the code where the problem occurred.
Check Registers: Inspect the values in the general-purpose registers at the time of the abend to understand what addresses were being referenced.
Review Source Code: Identify the instruction or statement in the source code that corresponds to the abending address.
Resolving S0C4 Abend
Initialize Pointers: Ensure all pointers are properly initialized before use.
Bounds Checking: Implement thorough bounds checking for arrays and memory accesses.
Align Data: Ensure data structures are properly aligned to the expected boundaries.
Correct Logic Errors: Fix any logical errors in the code that might lead to invalid memory accesses.
Use Debugging Tools: Employ debugging tools and techniques to trace and monitor memory accesses. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
why it happens when there are huge records in the i/p file and no S0C4 for less number of records. |
Because there is one or more problems with the code.
It sounds like you have possibly "fallen through" and issued the close prematurely.
or
Continued processing after end-of-file.
or
The open was unsuccessful for whatever reason.
or
An internal array/table has been overrun.
or
Many other alternatives. . . |
|
Back to top |
|
|
|