What can cause S0C4 abends in VISION:Builder/VISION:Two jobs that have not changed?
Article ID: 54291
Updated On:
Products
Issue/Introduction
Description:
S0C4 abends in jobs that have run previously without any changes can be baffling.
Solution:
Normally when a S0C4 occurs there has been some change to the application, but in some cases this is not the situation.
First make sure all current maintenance is applied.
Then check to see if the M4LIB is BDAM. VISION:Builder/VISION:Two tracks everything internally for BDAM M4LIBs, so only the COMLIB utilities may be used to move them. (See Chapter 12 in the Environment Manual). When a BDAM M4LIB it is moved with anything else you risk compromising the dataset's integrity. Even migrating to another DASD of the same type is risky as any bad block in a different location corrupts the dataset. This frequently happens without the user's knowledge as a matter of site housekeeping in archiving unused datasets or migrating DASD.
BDAM is frequently chosen as the M4LIB format because it has somewhat better performance and requires less authorization. VSAM on the other hand, provides device independence as VSAM performs all the housekeeping.
If the M4LIB is BDAM, use MARKUTIL with UCDUMP and UCREST to backup and restore the M4LIB.
If this does not clear up the S0C4, then open an issue with Technical Support.
Environment
Component:
Feedback
