S0C4 may be due to:

1.Missing Select statement(during compile)

2.Bad Subscript/index
3.Protection Exception
4.Missing parameters on called subprogram
5.Read/Write to unopened file
6.Move data from/to unopened file
7.Trying to delete a file which is in production (or to be more precise trying to delete a dataset which has
no access by the user to delete that particular dataset)

COBOL Comp-3 Packed fields:

This page discusses how data is stored in COBOL "comp-3", or "packed" fields.

The COBOL "Comp-3" Data Type

(also called "Computational-3", "Packed Decimal", or "Packed")

(See note 1 about terminology)

COBOL Comp-3 is a binary field type that puts ("packs") two digits into each byte, using a notation called Binary Coded Decimal, or BCD. This halves the storage
requirements compared to a character, or COBOL "display", field. Comp-3 is a common data type, even outside of COBOL, and is fairly standard across platforms
-- that is, it is not dependent upon the operating system, language, or CPU, as the COBOL "comp" is. (See COBOL Computational Fields for information on the
comp data type). However, comp-3 is not commonly found in PC languages.

How the data is stored

The Binary Coded Decimal (BCD) data type is just as its name suggests -- it is a value stored in decimal (base ten) notation, and each digit is binary coded. Since
a digit only has ten possible values (0-9), it can be represented in binary form with only 4 bits. Four bits is called a "nybble", and each nybble contains one digit of
the value. Therefore, you can get two digits in each 8 bit byte. (There's an example below). Normal EBCDIC or ASCII character representation (COBOL
"Display") only stores one character (digit) per byte, so packed data only requires half the storage of unpacked (character) data. (See Character, BCD, and Binary
Fields if this description is not clear.)

The value in a comp-3 field is stored high-order to low-order. That is, the upper nybble of the first byte encountered in the file is the most significant digit of the
value, the lower nybble of that byte is the next digit, etc., etc. The last nybble -- the low nybble of the least significant byte -- is used to store the sign for the
number. Unlike IBM Signed fields (see EBCDIC to ASCII Conversion of Signed Fields), this nybble stores only the sign, not a digit. "C" hex is positive, "D" hex is
negative, and "F" hex is unsigned. In COBOL comp-3 fields (and in most other languages) this nybble is reserved for the sign whether or not the field is denoted
as a signed field in the COBOL PIC.

Comp-3 packed fields are aligned on byte boundaries, and the field is always a whole number of bytes. The sign nybble is always the low nybble of the LSD (least
significant digit). Since the sign takes one nybble, and because there are always an even number of nybbles in any number of bytes, an odd number of digits will
fully-fill a comp-3 field. (An odd number of digits plus a sign nybble makes an even number of nybbles, or fully-filled bytes). If the size of the field is specified as an
even number of digits, as in "PIC S9(6) comp-3.", the upper nybble is ignored and is usually, but not always, set to zero.

Comp-3 fields in COBOL

Comp-3 fields are denoted in COBOL with the "usage is" clause after the PIC, like this:

PIC S9(5) usage is computational-3.

However, the "usage is" is not required and seldom used, and "computational-3" is usually abbreviated "comp-3", so you more commonly see:

PIC S9(5) comp-3.

The COBOL PIC, or picture, for a comp-3 packed field specifies the number of digits after unpacking. The actual number of bytes occupied in the file is about half
that. To calculate the number of bytes from the PIC, add 1 (for the sign) to the total number of digits, divide by 2, and round up if necessary. For example:

PIC S9(7) COMP-3. Byte size = (7 + 1) / 2 = 4

 PIC S9(5)V99 COMP-3. Byte size = (5 + 2 + 1) / 2 = 4

PIC S9(6) COMP-3. Byte size = (6 + 1) / 2 = 3.5, rounded to 4

Comp-3 fields reserve a nybble for the sign, even for "unsigned" values, so the following fields are still 4 bytes:

PIC 9(7) COMP-3. Byte size = (7 + 1) / 2 = 4

PIC 9(6) COMP-3. Byte size = (6 + 1) / 2 = 3.5, rounded to 4

Examples

Lets look at some examples of how comp-3 data is stored. The left column in the table below is the decimal value being stored, and the right column is the
hexadecimal value you will see in the file:

Value Comp-3, hex

+0 0C
+1 1C
+12 01 2C
+123 12 3C
+1234 01 23 4C
-1 1D
-1234 01 23 4D

Each underlined value above represents one byte, in hexadecimal (hex) form. We have only used as many bytes as needed to store the value shown on the left.

When you "unpack" a packed, or comp-3, field, the size of the field will double. This will cause all fields following it to shift down. If the field is in a redefined area,
it will likely no longer fit in the allocated space, and the original field it redefined will have to be modified, or filler will have to be added, to accommodate the larger
unpacked field. Just a few comp-3 fields can make for a messy situation, affecting many other fields, and even other records if the file contains multiple record
types.

Consider this situation.

I have a JCL with 10 steps.
For reasons known only to me, I want to execute step 5 only.
How can I do it?

One way to do it is to use RESTART from STEP05, but it will try to execute the
subsequent steps too.
We have to insert null statement after step05 to prevent the execution of
subsequent steps.
But one decent way is there in which we don’t need to touch the job steps
code, but alter only the Jobcard.
And that is....
In the JOBCARD, code COND parameter. Then, when the Job is executed , only
the Step mentioned in the RESTART parameter will get executed.
e.g., RESTART=STEP05,COND=(0,LE)