IBM Mainframe Forum

PACKED-DECIMAL is identical to and interchangeable with COMP-3.

The reason for your S0C7 is that your source field does not contain valid packed-decimal data.

The three most likely causes are:

1. You have multiple record-types on the file, and the current record is not the one for the layout you are using
2. You are accessing an OCCURS which is not used on that record (you have a count, what is the value of that?)
3. The data on the file is plain incorrect

I've listed those in order of likeliness, given that you get the abend with entry ( 1 ).

A packed-decimal field does not need to be an odd-number of digits. When it is an even-number of digits, the compiler generates code to ensure that the left-most half-byte is always zero.

Often you will find packed-decimal fields which logically should contain an even-number of digits having an odd-number of digits, to avoid the generation of that extra code.

To add to what others have said, and which I stated in my earlier post, the value you posted for :RTR:-MARKET-TYPE is NOT the value getting the S0C7 abend as the value you posted is not going to cause any S0C7.

One possibility not yet explored: if your code uses PERFORM statements, and one is mis-coded or otherwise allows you to fall through code, it is possible that you hit the end of the file or read another record, dropped into the MOVE statement when your code was not handling the data for that record, and hence causing the S0C7.

We know, beyond any possibility of doubt, that the value you displayed did not cause the S0C7. Therefore, either you are not showing the right value in your post, or the system is handling a different value (from a different record or wherever) than you think it is. Does your site run ABEND AID or similar run-time debugging tool that can show you the exact data vlaue getting the S0C7 ABEND?

One of the ongoing big problems on this forum is attitude. If you think, for whatever reason, that the computer is wrong and you are right about the data -- you are starting with a HUGE handicap in attempting to resolve the problem. Computers never lie and rarely mislead; only programmer attitudes keep them from recognizing where they made their error. Example: I had a programmer one time swear (for 3 months) that CICS was losing COMMAREA because his program kept getting occasional storage violations. With the help of IBM level 2 support, I finally got a good trace of the problem and we tracked down the exact cause of the issue. The first problem was that the programmer "knew" the problem occurred in line so-and-so of his code; the actual abend was more than 400 lines later and I proved this to him by showing the CICS trace entries. The second problem turned out to be a copy book change had been made and a program had not been recompiled to use the new variable length. Hence, his program when it called the other program was overlaying part of the system trailer block on the COMMAREA memory location. Since he "knew" the problem was in the system, he never checked to see that the other program had been recompiled.