Taking my usual "I am a paranoid" approach, this is an S (Serious Error) rather than an E (Error) with an RC=12 because it could indicate that you have gotten maintenance from a "hacked" source. Imagine the chaos that a hacker could do if they could insert some code into TCPIP. And, although I'm anal about always getting an RC=0 (to the extent that I do weird and stupid things at times), many consider RC=4 to be a "don't even bother looking" return code. So RC=12 might be considered a kick in the privates rather than the RC=8's slap in the face.
OT to SMP/E, but an example of why RC=0 is "nirvana", is our attempt to upgrade from Endevor 12 to Endevor 15. The people who wrote the "processors" (rules used to compile and link programs, move source, ...), ignored all messages which did not cause the program to not produce a load module, regardless of the rule's RC. Those same processors in R15 now cause the processing to abort. In the interim, we have greatly downsized. We no longer have any SMEs for Endevor. My manager is doing this himself and is on the phone to CA a lot due to our lack of knowledge and no time to learn. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 • N. Richland Hills • TX 76010 (817) 255-3225 phone • john.mck...@healthmarkets.com • www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Tuesday, September 25, 2012 6:49 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: GIM44336S > > OK. This was entirely a user error. I was pointing at the wrong > archive > in RECEIVE FROMNETWORK. But I got: > > GIM45500S ** VERIFICATION OF HASH VALUE OF FILE > /*****/*****.gimzip/GIMPAF.XML FAILED. SMP/E WILL NOT > RETRY FILE RETRIEVAL. > GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVCMF - > java.security.InvalidParameterException > GIM20501I RECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE > WAS 12. > > Somehow the GIM44336S seems to be a punishment disproportionate > to the offense? "UNUSUAL CONDITION"? "security"? What did I do? > Will I be written up? M&C was little help on this. > > I retried on a system with ICSF available, and got not the GIM44336S > but yet the GIM45500S, which I had assumed was consequential to > the GIM44336S, and this put me correctly on track for my problem. > > I don't consider either of these to merit RC=12. More like RC=8. But, > yes, execution shouldn't continue. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
