Replies

I’m so old I dealt with this: A SOC7 abend, or data exception, usually indicates an issue with numeric data, particularly in COBOL or other mainframe programming contexts. It occurs when a field intended for numeric values contains non-numeric data or is used in a calculation before being initialized. Common causes include uninitialized indexes, incorrect field overlaps in packed decimal arithmetic, or using a packed decimal field that doesn’t contain a valid value.

Early in my career with my current employed, I attended UseNIX and happened upon a software vendor with a product called Purify. I made arrangements to try it at the office. I was probably the 10th customer they had since deciding to market the product. It found all manner of defects. Array bounds read/write errors, using uninitialized variable in a boolean comparison, freeing free'ed memory, using free'ed memory. Our application was using X-Windows in SunOS at the time and it was a total bugfest. Inside of the week, the complaints about core dumps from all of the mentioned items were erased. Subsequently, I insisted on using coverage analysis tools and enhanced unit testing because Purify can only detect a defect in code that actually executes. It was a real step forward in software qualify for that project.

At PacBell, we had a problem with the mainframe coming down daily around 5 PM. I did dumps of the damage common bank in the UNISYS environment. From that, I found the exact terminal that triggered the problem. We sent two people to guard the terminal. Sure enough, around 5 PM a young lady steps up to the terminal and enters a transaction. She was instructed not to transmit it. We captured the screen contents and shipped them off to Bellcore. The next day, we were informed that a COBOL library had a defect triggered by that input the corrupted a common bank library. The library was corrected and a patch sent to our Sperry system support staff. After correction, the transaction ran without a problem. Timeframe was Fall 1983.