none
APPC LUs not releasing RRS feed

  • Question

  • Happy New Year!

    We are using HIS 2013 to send orders to a 3rd party system using APPC.  

    Our systems process orders 1 at at time, but uses async mode and is loosely based on the sendrec sample program.

    Every transaction goes through these steps:

    TP_STARTED

    MC_ALLOCATE

    MC_SEND_DATA

    MC_RECEIVE_AND_WAIT (1 or more times)

    MC_DEALLOCATE

    MC_TP_ENDED

    A typical conversation is 0.05 seconds.

    When orders come in and out during the day, all seem to work correctly.

    However, if a "batch" of orders comes in (say 20 or more), where we are processing requests rapidly, the sessions do not always release and once all sessions are occupied, our program hangs at the MC_ALLOCATE stage.  When a session fails to release, there is no indication in the response to MC_DEALLOCATE that would indicate it failed.  Here is a conversation from our logs that created a "stuck" session:

    Issue Next VERB = 0 globalTPID=[]
    TP_STARTED
    VERB TRACE: OPCODE=14h OPEXT=0h TP_ID=[xxx] CONV_ID=0h LU_ALIAS=[xxx] TP_NAME=[xxxx] 

    RETURN-EVENT:opcode=14h primary_rc=0h sec_rc=0h
    Return: AP_TP_STARTED - COPY TP_ID to Global
      LOG TPID=[]

    Issue Next VERB = 14 globalTPID=[]
    MC_ALLOCATE
    VERB TRACE: OPCODE=1h OPEXT=1h TP_ID=[] CONV_ID=0h 
    SYNC_LEVEL=0h RTN_CTL=0h PLU_ALIAS=[xxxx] MODE_NAME=[xxxx] TP_NAME=[xxxx] 

    RETURN-EVENT:opcode=1h primary_rc=0h sec_rc=0h
    Return: AP_M_ALLOCATE

    Issue Next VERB = 1 globalTPID=[]
    MC_SEND_DATAVERB TRACE: OPCODE=Fh OPEXT=1h TP_ID=[] CONV_ID=5596FF0h DLEN= EEh TYPE=0h 
    TP_ID_HEX: 0 0 0 0 E8 6E 59 5

    RETURN-EVENT:opcode=Fh primary_rc=0h sec_rc=0h
    Return: AP_M_SEND_DATA

    Issue Next VERB = F globalTPID=[]
     At AP_M_SEND_DATA 
    MC_RECEIVE_AND_WAIT

    VERB TRACE: OPCODE=Bh OPEXT=1h TP_ID=[] CONV_ID=5596FF0h RTN_STATUS= 1 MAX_LEN=960h 

    RETURN-EVENT:opcode=Bh primary_rc=0h sec_rc=0h
    Return: AP_M_RECEIVE_AND_WAIT WHAT_RCVD=201h LEN=14 (decimal)

    Issue Next VERB = B globalTPID=[]
    MC_DEALLOCATE
    VERB TRACE: OPCODE=5h OPEXT=1h TP_ID=[] CONV_ID=5596FF0h 

    RETURN-EVENT:opcode=5h primary_rc=0h sec_rc=0h

    Issue Next VERB = 5 globalTPID=[]
     At AP_M_DEALLOCATE
    MC_TP_ENDED
    VERB TRACE: OPCODE=13h OPEXT=0h TP_ID=[] CONV_ID=0h 
    TP_ID_HEX: 0 0 0 0 E8 6E 59 5

    RETURN-EVENT:opcode=13h primary_rc=0h sec_rc=0h

    Issue Next VERB = 13 globalTPID=[]
    TP Terminated

    We can release the sessions by restarting our program, so that would indicate something on our side is keeping them opened.

    I would note that we have had this running on HIS 2000 for a number of years, without this issue.

    Any insight you can give is greatly appreciated.

    Mark


    mhaddy

    Thursday, January 2, 2014 9:40 PM

Answers

  • Just to follow-up on this: After looking through some traces that captured the problem, it appeared that the problem was occurring because there were times when the APPC application was not issuing a DEALLOCATE verb to end an APPC conversation after the transaction was completed.

    Thanks...


    Stephen Jackson - MSFT

    Thursday, February 13, 2014 3:49 PM

All replies

  • I'd really need to see a set of HIS traces when this occurs to really see what might be happening. The description you provided is very good, but the HIS traces would allow me to see the APPC verbs, the data sent from the HIS "client" side to the SNA Server service and to the host and back. To do this type of trace analysis requires a support case as it is time consuming and there is no way to get trace files via the forum.

    The traces I would want to see would be captured with the histrace.exe tool on HIS 2013 and are as follows:

    On the HIS Server system:

    SnaServer: LU 6.2 Messages and Data Link Control under the Message trace tab.

    On the HIS system where the APPC application is running (if this is on the HIS Server as well, then you would do all the traces on the same system. If the application runs on a HIS Client, then these traces would be run on that client system):

    SNA Application: Click "Set All" on all 3 tracing tabs.

    Once the traces are enabled, reproduce the problem. Once the problem occurs, click the "Clear All Traces" button to stop the tracing.

    You'd then provide the traces files, the application event log, and the HIS configuration file (%SNAROOT%\conficom.cfg) for us to analyze.

    Thanks...


    Stephen Jackson - MSFT

    Friday, January 3, 2014 5:10 PM
  • Ok, I will open a ticket once I am able to create the trace files.

    mhaddy

    Friday, January 3, 2014 5:54 PM
  • Just to follow-up on this: After looking through some traces that captured the problem, it appeared that the problem was occurring because there were times when the APPC application was not issuing a DEALLOCATE verb to end an APPC conversation after the transaction was completed.

    Thanks...


    Stephen Jackson - MSFT

    Thursday, February 13, 2014 3:49 PM