|
View previous topic :: View next topic
|
| Author |
Message |
Tanvi Jaiswal
New User
Joined: 04 Apr 2008
Posts: 7
Location: Hyderabad
|
|
|
|
hi,
Atually i am facing a S0C4 abend in prodution run of my job. But when i test run it it doesnt abend with S0C4. I am unable to understand the reason fo it. Here the abend has occured in a called program. And some changes were done in called program. but those changes run fine in test run. Is the abend related to something like where we have to keep the load of both called and calling program? (both loads were kept in same pds)
Production run - I am into support job and we have applications running in batch to incorporate the changes that happened in online. So production run is running batch cycle of our application.
Test run - As the job abened with S0C4 i prepared a test jcl for that code i.e. taking production files but output will not be in production files but test file with same properties. So when i ran the test job it went thru fine. |
|
| Back to top |
|
 |
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Is this a cobol module calling a cobol subroutine? Does the process use the internal sort?
I suspect that "something" is out of alignment or that the code is "walking on storage". Due to differences in the prod/test environment, the problem in the code is not being hit in test.
Often, code will have problems due to unexpected or "that shouldn't happen" data content. |
|
| Back to top |
|
|
Tanvi Jaiswal
New User
Joined: 04 Apr 2008
Posts: 7
Location: Hyderabad
|
|
|
|
hi,
Yes both are cobol code. And the called program is a ynamic program i.e. the decision of picking the load of the called program will happen only during the running of the job. So what i suspect is during test run the load of the called program was picked from some pds and in prod it was picked from some other pds. So the address problem occured as S0C4 is generally related to physical memory issues.
Secondly it is not a data issue. I verified each and every record with condition and for cross checking i also expedited the code. So definitely not a data issue. 
Its still a mystry why test run happened successfully and why prod abended. And dis happened not once or twice but 6 times  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
I believe you may have mentioned the problem.
It may be that the prod and test runs are using different loadlib concatgenations and somewhere an invalid module is being invoked.
Or the concatgenations may be correct in both environments, but there is a load module in some loadlib where it shoould not be and when it is invoked, the 0c4 happens.
You may want to check all of the loadlibs in the prod concatenation and make sure that an "old" version of a module is not in an incorrect library. |
|
| Back to top |
|
|
Tanvi Jaiswal
New User
Joined: 04 Apr 2008
Posts: 7
Location: Hyderabad
|
|
|
|
hi
I even did that........i actually tried running test run and prod run with both the load in test load lib pds and prod load lib pds. But still the same situation. That is why is think some memory problem has occured.
Anyways thanx....... |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| That is why is think some memory problem has occured |
What does this mean? It is almost certain that it is not a hardware memory problem.
| Quote: |
| i actually tried running test run and prod run with both the load in test load lib pds and prod load lib pds. But still the same situation |
Did you make sure that a called module is not in some library where it should not be - this would be some old version that should probably be deleted from that library. |
|
| Back to top |
|
|
Tanvi Jaiswal
New User
Joined: 04 Apr 2008
Posts: 7
Location: Hyderabad
|
|
|
|
hi,
i have made sure that the load of both called and calling program is not in such a pds where it shouldnt be.
Secondly i think it is a memory problem as in abend aid it was stating "accessing beyond a table limit, accessing a linkage area which is exceeding the allocated memory" i.e. all memory related issues. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| "accessing beyond a table limit, accessing a linkage area which is exceeding the allocated memory" |
Yes, i agree.
Now to determine how it happens in one environment and not the other. . .
A couple of common causes are having different modules executed in the different envirnments or having different data to process.
If you are certain that the same module is being invoked in both envirnments, you could put some diagnostic code in the module and move some "eyecatcher" values to working storage as the program runs to determine how far it runs before the abend.
Is there an internal sort in the program? |
|
| Back to top |
|
|
spadma
New User
Joined: 18 Dec 2007
Posts: 9
Location: India
|
|
|
|
Hi,
I am not pretty sure that this could be the reason. But just please check that what ever the values we are passing to the called program are defined in working storage section and the procedure division should contain using clause.
Ex: 01 WS-VARIABLES
05 WS-A PIC X.
.
.
PROCEDURE DIVISION USING WS-VARIABLES.
Else all the values we are passing should be declared in Linkage section and the no USING clause in PROCEDURE DIVISION.
I hope this might helpout  |
|
| Back to top |
|
|
|
|
