On 1/26/2019 4:37 PM, Charles Mills wrote:
... You would really rather have your customers and support staff deal with an S80A and a dump rather than a nice error message that says "ABC1234E Unable to obtain storage for record work area"?
Most conditional storage obtain/release failures occur in routines that are nested very deep. They return up to their caller, who returns to their caller and so forth. By the time you reach a routine that cares enough -- or has the ability -- to write a message, the actual failing scenario has been totally lost in translation.
Even if a message is issued by the code requesting the storage service, keep in mind that a "Bad return code from FREEMAIN RC=xx" message tells you absolutely nothing about how to SOLVE the problem. You need to get a dump and issue VERBX VSMDATA/RSMDATA or reproduce under a debugger -- and that isn't always possible.
In z/OS V2R4 JES2 is now using EXECUTABLE=NO storage for data areas. Did you know existing FREEMAINs will fail on such storage unless you also code EXECUTABLE=NO? It took quite a while, even with a dump and VSMDATA, to understand why one of our FREEMAINs was abending in that environment. This kind of problem is essentially unsolvable without a dump. Decades of experience won't help you when the rules change out from under you and no dump exists.
The reality of what has happened since we removed our conditional storage requests is that we now detect nearly 100% of storage-related errors in-house through our normal testing and incidental usage of our own products before customers ever see them. Previously, messages might have appeared, but they weren't always seen or acted upon. Nothing gets people to take notice better than a dump! Occasionally, we get abends in the field and NOW -- because of the change from conditional to unconditional -- we have excellent FFDC (First-Failure Data Capture). The SDUMP tells everything anyone ever wanted to know to solve the issue and no recreate is ever needed.
We don't seem to have issues with customers sending dumps. We support both SFTP and HTTPS credentialed/secure file transfers and we have an Information Security Policy (ISP) in place that protects and guarantees proper disposal of customer data when no longer needed.
-- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ -------------------------------------------------------------------------------- This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
