Results 1 to 4 of 4
  1. #1
    Join Date
    Nov 2008
    Posts
    15

    Unanswered: Question about recovering from CAF errors on OPEN

    So, our application uses CAF to communicate with DB2 and we use the DSNALI module.

    We use the DSNALI function 'OPEN' to connect to DB2, using the specified subsystem and plan. If the OPEN fails (like an invalid plan was specified), the TCB created contains information from the failed OPEN and that is causing other problems.

    For example, if the OPEN fails while connecting to subsystem 'A' (which is valid) using plan 'BOGUS' (which is invalid), a return code of '8' is returned by CAF with a reason code of '00F30034'. Cool.

    If we then try to open a NEW connection to DB2 using subsystem 'B' (which is valid but on another system) using plan 'GOOD' (which is a valid plan), a return code of '200' is returned with a reason code of '00C10208'.

    In an attempt to "gracefully" recover from the initial failed OPEN, we have tried to use the 'CLOSE' and 'DISCONNECT' functions but those fail as well. When we use the 'CLOSE' function, a return code of '200' is returned with a reason code of '00C10203'. When we use the 'DISCONNECT' function, a return code of '200' is returned with a reason code of '00C10204'.

    I have found the explanations of the various reason codes we're getting:

    IBM Information Management Software for z/OS Solutions Information Center

    but what I haven't found is how to effectively "reset" CAF when a failed OPEN attempt is encountered.

    We're using DB2 V8.1 on z/OS.

    Any ideas?

    Thanks!

    Peace...

  2. #2
    Join Date
    Dec 2004
    Location
    Italy
    Posts
    32
    Tom, did you issued the close or disconnect instructions in the 'A' or 'B' subsystem?

  3. #3
    Join Date
    Nov 2008
    Posts
    15
    Hi! I issued the 'DISCONNECT' in the 'A' subsystem, right after getting the '00F30034' error. When attempting the DISCONNECT, I got a return code of 200 with a reason code of '00C10204'.

    So, the series of events went like this:

    • Call DSNALI with the 'OPEN' function with subsystem 'A' plan 'BOGUS'
    • Return code '8' with reason code '00F30034' is received.
    • Call DSNALI with the 'DISCONNECT' function.
    • Return code '200' with reason code '00C10204' is received.

    If I then call DSNALI with the 'OPEN' function and a different subsystem and plan, I get a return code '200' with a reason code of '00C10208', and this is the main problem.

    Peace...

  4. #4
    Join Date
    Nov 2008
    Posts
    15
    Ok, this issue has been resolved. The problem was with the use of the 'OPEN' function to do an explicit connection to the specified subsystem and plan.

    If the 'OPEN' function is used and the implicit connection to the specified subsystem and plan works BUT the 'OPEN' can't allocate the resources for the specified plan, the TCB being used CAN NOT be used to connect to a different subsystem. Why not? Because the implicit connection is still open.

    If an explicit 'CONNECT' is used before the 'OPEN', an explicit 'DISCONNECT' can be used in the event the 'OPEN' fails.

    I had to open an ETR with IBM to get this information.

    Peace...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •