[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Intermittent error: I/O: Unknown system state



   Thanks for all the advice.  After digesting it for a couple of days,
   we are planning to get current on our PTFs and hope that solves the
   issue.
   I have 1 more question based on some more digging I did, and I'd like
   your opinion.  I did some reading up on gsk_environment_init() on the
   following link:
   [1]http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/un
   ix9.pdf
   On p35, Usage Note #1, it states that "if gsk_environment_init()
   fails, gsk_environment_close() must be issued to clean up resources."
    I'm not sure I understand things properly, but if the init fails,
   would doing a close and another init perhaps resolve the issue?  I'm
   thinking that if something is damaged and can't initialize, could we
   grab another by doing a close and another init?  If so, can you
   suggest some code for me to try?
   Thanks,
   John Dyar
   Systems Analyst
   Information Technology
   Springs Window Fashions LLC
   Phone: 608-828-4045
   Fax: 608-836-6127
   john.dyar@xxxxxxxxxxxxxxxxxxxxxxxxx

   From:    Scott Klement <sk@xxxxxxxxxxxxxxxx>
   To:      HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
   Date:    02/04/2011 04:50 PM
   Subject: Re: Intermittent error: I/O:  Unknown system state
   Sent by: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
     _________________________________________________________________

   Hi John,
   >     Attached are some debug logs - one from a http_post that worked,
   and
   >     one that has the error.  I scoured the website for clues to why
   the
   >     failure happened but couldn't find any.
   Thanks for the debug logs.  I'm not sure what the cause of this error
   is, but I'll tell you everything I'm able to glean from log, and
   perhaps
   this will give you some clues about what to try next?
   From looking at the logs, it appears the error is being detected in
   the
   following section of code within the COMMSSLR4 module of HTTPAPI:
        C* Initialize the SSL environment.  After this, secure sessions
        C*   can be created!
        c                   eval      rc = gsk_environment_init(wkEnvh)
        c                   if        rc <> GSK_OK
        c                   if        rc = GSK_AS400_ERROR_NOT_REGISTERED
        c                   callp     SetError(HTTP_NOTREG: 'Application
   ' +
        c                             'is not registered with DCM!')
        c                   callp     https_cleanup
        c                   return    -1
        c                   else
        c                   callp     SetError(HTTP_GSKATYP:
   'gsk_env_init: '+
        c                                         ssl_error(rc))
        c                   callp     https_cleanup
        c                   return    -1
        c                   endif
        c                   endif
   NOTE: That's taken from the current beta.  I don't have a copy of the
   older code handy.  I do know that this routine was changed somewhat,
   though, I think the changes were small bug fixes.
   From the debug log, I can see that the API rc=406 (GSK_ERROR_IO) and
   errno=3474 (also known as MSGID(CPE3474) or EUNKNOWN) which is
   "Unknown
   System State."  This, in turn, triggers HTTPAPI's error #24
   (HTTP_GSKATYP), which is what would be returned back to your program
   via
   http_error().
   So we know the exact line of code where it's happening.  It's
   happening
   when I call gsk_environment_init(), which is an IBM-supplied API, and
   it's documented here:
   [2]http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/gs
   k_environment_init.htm
   If you look at the information center page (the link above) you'll see
   the following listed as an error response for the API:
      [GSK_ERROR_IO]
          An error occurred in SSL processing, check errno value.
   So that's what you're getting.  And below that further, it lists a few
   different errno values, but does not list EUNKNOWN (3474).  It does
   say
   "If an errno is returned that is not in this list, look in Errno
   Values
   for UNIX-Type Functions for a description of the errno."
   so, if I look there, I see this:
   EUNKNOWN -- Unknown system state.
      The operation failed because of an unknown system state. See any
      messages in the job log and correct any errors that are indicated,
      then retry the operation.
   So now I go back to the job log you sent on Tuesday, and I see this:
   *NONE Command 01/19/11 22:01:00.030472 QCLCLCPR QSYS 04A4 PPR200P
   MODHPGM *STMT
   To module . . . . . . . . . : PPR200P
   To procedure . . . . . . . : PPR200P
   Statement . . . . . . . . . : 3900
   Message . . . . : 3900 - CALL PGM(PPR200)
   CPF9897 Diagnostic 40 01/19/11 22:01:04.092360 HTTPAPIR4 MODHPGM *STMT
   HTTPAPIR4 MODHPGM *STMT
   From module . . . . . . . . : HTTPUTILR4
   From procedure . . . . . . : UTIL_DIAG
   Statement . . . . . . . . . : 2992
   To module . . . . . . . . . : COMMSSLR4
   To procedure . . . . . . . : SSL_ERROR
   Statement . . . . . . . . . : 5574
   Message . . . . : (GSKit) I/O: Unknown system state.
   Cause . . . . . : No additional online help information is available.
   There's no messages in between the "CALL PGM" and the "Unknown System
   State"...  so there's no errors in the job log for me to correct.
   You'll note that your debug file (as well as your job log) also lists
   a
   bunch of "(GSkit) Handle not valid" errors.  These I've seen before,
   and
   are caused by the first error.  The current beta will eliminate these
   errors (but, AFAIK, won't eliminate the "Unknown system state")
   >     I'm hoping someone has a tip for what I could check or try next.
   Well... if you waded through my long-winded message, above, I hope
   you'll see that HTTPAPI is calling an IBM-supplied API, and the error
   is
   occurring inside that API.
   My next step would be to make sure you have the latest CUME & Group
   PTFs
   installed.   There was a similar error that IBM fixed in 2007 related
   to
   SSL in FTP...   No idea if that's the same thing that's happening
   here,
   but they are both using the same SSL engine, so it could be...
   [3]http://www-01.ibm.com/support/docview.wss?uid=nas21f5728dac1be65a98
   6257331003c69c5
   ----------------------------------------------------------------------
   -
   This is the FTPAPI mailing list.  To unsubscribe, please go to:
   [4]http://www.scottklement.com/mailman/listinfo/ftpapi
   ----------------------------------------------------------------------
   -
   THIS ELECTRONIC MESSAGE AND ANY ATTACHMENTS ARE INTENDED ONLY FOR THE
   USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED, AND MAY
   CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM
   DISCLOSURE UNDER APPLICABLE LAW. DO NOT FORWARD THIS MESSAGE WITHOUT
   EXPRESS CONSENT OF THE SENDER. If you are not the intended recipient,
   you are hereby notified that any review, reliance, dissemination,
   distribution or copying of this communication is strictly prohibited.
   If you have received this communication in error, please immediately
   notify the sender by return email message and delete all copies of the
   original communication. Thank you for your cooperation.

   Message examined by Websense Email Security Service

References

   1. http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/unix9.pdf
   2. http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/gsk_environment_init.htm
   3. http://www-01.ibm.com/support/docview.wss?uid=nas21f5728dac1be65a986257331003c69c5
   4. http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------