IBM Mainframe Forum

Hello again! Sorry for the 1st thread I created yesterday, you see I am on a rush since this language was our training. We're always on pressure, that's why given with a chance to post here anyone can pass by can help me if they can. And I already solved my first program. Now comes the second one.

This time it was a soc4 error. If you can scan my codes, please tell why did I ended up in soc4. Help is very appreciated! And sorry if I break any rules.
Sorry if I'm asking too much. I already bookmarked the links that you gave guys. I'm very thankful.

Please help me if you can.
Edited

At what point did it fail? I am not walking through someone else's code when they have the information to hand.

The system is normally pretty good at providing data about the abend -- such as the offset in the program. If you compile your program with OFFSET or LIST (you can specify one or the other), you will get the necessary data to identify the very line of the program where the abend occurred.

Of course, a S0C4 could also be caused by your compile and linkage edit / binder process not matching, or a table overflow, or many other reasons. When you didn't provide any of the data the system provides to help figure out the problem, why do you expect us to come up with this data?

Hello,

Suggest you add some diagnostic code to determine where the problem happens.

Keep in mind that you cannot refer to a field in a record that has not successfully been read. . .

Is there some reason you did not use the "file status" to determine if an action was successful? There are many more "things" than can happen beyond an eof. . .

Hello again! I already figured it out. I suppose to declare PIC X (alphanumeric) on SAVE-AGNCY-CODE instead of PIC 9. Moving Alphanumeric is not applicable to Numeric.. Another lessoned learn. Now the only thing I need to think of is the logical error of my program.

Rayster wrote:I suppose to declare PIC X (alphanumeric) on SAVE-AGNCY-CODE instead of PIC 9. Moving Alphanumeric is not applicable to Numeric.

That would cause a S0C7, not a S0C4. You may still have other errors.

Yeap at first I encountered SOC7, but then SOC4. Not sure what happened why it became 4.

An S0C4 is a storage protection error. In other words, your program attempted to read or write to storage it is not allowed to use.

An S0C7 is a packed data exception error; in other words, a data area that is supposed to contain packed decimal data does not contain packed decimal data. Often (but not always) an S0C7 error is really a reflection of an S0C4 error, except by chance, a bad address (in terms of the program) happens to point to a storage address it is allowed to read rather than a storage address it is not allowed to read.

Error analysis programs like the Abend-Aid product that is installed on quite a few z/OS systems will attempt to locate and display the data areas associated with an S0C7 error; that can be quite convenient in program analysis. Even with this analysis it is up to the programmer to determine the point in their program where the error occurred; as Rayster has discovered this can be difficult. Analysis of an S0C7 error must follow two major paths; determine if there is a bad address, or determine how data in a presumably valid data area got bad

Hello,

Please re-read my earlier reply. . .

Also consider that fields in an FD should not be referenced before the file is opened or after it is closed.

Not sure what happened why it became 4.

It did not "become a 4". . . All this says is that there was/is more than one error.