Why soc7 in jcl

It occurs because of the following reasons. S0C7 A numeric field contained non-numeric data. Numeric data was not initialized. A subscript or index contained an invalid value.

A comp-3 field had an invalid sign. A group move overlaid a numeric field with non-numeric data. Posted: Tue Nov 22, am. Hi jajularamesh, I suggest you to go for a search wherein you can get many more information on SOC7 abend plus articles realted to it. Please use the "search" option before posting any query. Posted: Tue Nov 22, pm. Basically you need to correcting the offending data. Many times the reason for SOC7 is an un-initialized numeric item. Examine that possibility first. Many installations provide you a dump for run time abend?

These dumps provide the offset of the last instruction at which the abend occurred. Examine the compilation output XREF listing to get the verb and the line number of the source code at this offset.

Then you can look at the source code to find the bug. Some installation might have batch program debugging tools. Use them. Best thing is For resloving this type of error is to find the offset address using the expeditor or anyother tools and check the corresponding moves whether a numeric field has been moved to an alphabetic field Ex- if a dataname is coded to hold an integer value and if you try to insert any other value to that say string etc Post by Anuj Dhawan » Sat Nov 22, am Hi, The idea is to add the given displacement to the address given by the base register.

And it is hexadecimal addition, so don't forget your base 16 math. Then you scan down your dump to the given address and read the instruction, checking the contents of the fields. It really helps when you have a yellow IBM instruction card which shows the hexadecimal equivalents of the commands. And unless your compile is done with the Assembler listing, that won't help much, because then you have to take the Assembler instruction back to your COBOL code to figure out what fields are being referenced by the abending command.

Last edited by Anuj Dhawan on Thu Nov 03, am, edited 1 time in total. So how do you do this quickly and easily? You have to know what causes what errors - basically, you have to understand your data. S0C7 is a data exception. This most commonly means that a numeric value has had something done to it that results in it being placed in an alphanumeric field. So start with your numeric fields.

Because you got a S0C7, I can safely assume this is a batch job and you are dealing with standard input files. That record causing the SOC7 Abend. Yes , the disp can be new,catlg,keep or new,keep,keep However its a very uncoventional method to look at the input file and determine which record is causing it. You may have to again goto the debugger xpeditor to see what happens during that record. Pick up the offset address from the executed JCL.

Go to the compiler cross reference listing. Find the offset address in the XREF. This would give the line number in which the abend has occured. To identify the record which caused abend get into the sysout where the abended record information would be displayed depending on the installation.

Through this when we map it to the record structure we will come to know which field is caused the abend. From this we can fix the SOC7 abend. There you can find the last record and last executed statement. These two information is enough to solve S0C7. Post New Answer. We know that size of redefine and redefining need not to be same..

Then does the below case true 01 ws-date pic 9 6. If there are no compilation errors and if such files are not coded in the JCL, will the OPEN statement run fine when these files are opened? Can we dynamically increase the size of occurs clause? If yes , how?