none
Requests getting processed twice RRS feed

  • Question

  • Hi.

    We are using HIS Session Integrator to perform queries in a third party TN3270 application. We are charged for each query, that is, for each time we press "enter/PF24" in the search screen, as far as I can gather. (The third party supplier can't really define it)

    The problem now is, that it seems that we are getting billed twice the amount compared to what our own logs show that we are should be, so it seems that we are doing "double searches".

    I have been through all my code, and compared it to some legacy code (that didn't use HIS), and it seems to be doing the exact same thing, and the old application did not have this issue.

    Then I stumbled across this article:
    "TN3270 Application May Process a Screen of Host Data Twice": http://support.microsoft.com/kb/268171

    Now the question is if this article could in some way be related to HIS 2006, or if we could be dealing with a similar situation (that we might be getting the screen twice, causing double billing).

    The article contains some traces, but I am not sure where to get those traces, or how to read them. 

    I would appreciate any sort of advice on how to track down if this could be the case (or any other ideas on what could be happening).

    Monday, May 17, 2010 2:56 PM

Answers

  • The issue described in KB 268171 was specific to the TN3270 Service included with HIS 2000. Therefore, the same issue would not be presetn in Session Integrator.

    Since you are using Session Integrator to connect to the mainframe via TN3270, the best option for troubleshooting would be to get a network trace (Sniffer, Ethereal, Network Monitor, etc.) of the traffic between the systme running Session Integrator and the IBM Mainframe. In addition, you might want to capture Session Integrator traces by running the SNA Trace Utility (snatrace.exe) per the following:

    1) Run snatrace.exe.

    2) Highlight Session Integrator Client and click Properties.

    4) Click the Set All button on all three tabs (Internal Trace, Message Trace, and

    API Trace).

    5) Click OK.

    6) Highlight Session Integrator Server and click Properties.

    7) Click the Set All button on all three tabs (Internal Trace, Message Trace, and

    API Trace).

    8) Click OK.

    9) Minimize the SNA Trace Utility window.

    10) Repro the problem.

    Once the problem has occurred (or you have captured the flow that exhibits the symptoms), restore the SNA Trace Utility window and click "Clear All Traces" to stop the traces. Typically, Microsoft Product Support analyzes these traces.

    You might be able to follow the flow in the network trace to see what might be happening. If not, you might consider opening a support case so that HIS support can help anaylze the trace data.

    Hope this helps.

    Thanks...

     

     

     


    Stephen Jackson - MSFT
    Monday, May 17, 2010 4:43 PM

All replies

  • The issue described in KB 268171 was specific to the TN3270 Service included with HIS 2000. Therefore, the same issue would not be presetn in Session Integrator.

    Since you are using Session Integrator to connect to the mainframe via TN3270, the best option for troubleshooting would be to get a network trace (Sniffer, Ethereal, Network Monitor, etc.) of the traffic between the systme running Session Integrator and the IBM Mainframe. In addition, you might want to capture Session Integrator traces by running the SNA Trace Utility (snatrace.exe) per the following:

    1) Run snatrace.exe.

    2) Highlight Session Integrator Client and click Properties.

    4) Click the Set All button on all three tabs (Internal Trace, Message Trace, and

    API Trace).

    5) Click OK.

    6) Highlight Session Integrator Server and click Properties.

    7) Click the Set All button on all three tabs (Internal Trace, Message Trace, and

    API Trace).

    8) Click OK.

    9) Minimize the SNA Trace Utility window.

    10) Repro the problem.

    Once the problem has occurred (or you have captured the flow that exhibits the symptoms), restore the SNA Trace Utility window and click "Clear All Traces" to stop the traces. Typically, Microsoft Product Support analyzes these traces.

    You might be able to follow the flow in the network trace to see what might be happening. If not, you might consider opening a support case so that HIS support can help anaylze the trace data.

    Hope this helps.

    Thanks...

     

     

     


    Stephen Jackson - MSFT
    Monday, May 17, 2010 4:43 PM
  • I have captured some tracing, and I am trying to look through it.

    The first one I am looking at is SICAPI1.ATF

    It seems that I can see the "SendKey request" entries, but the actual data is encoded, and I cant quite figure out which encoding is used. It looks like the "7c96" is about the same as enter/PF24, But how would I decode other string that I can find in the trace?

    Any hints on how to read these logs are much appreciated.

    Thursday, May 27, 2010 2:55 PM
  • Let's say that you see something like the following in the SICAPI1.ATF trace:

    SPROX SendKey request
    SPROX USHORT count = 2
    SPROX SAFEARRAY keys
    SPROX Number of bytes per element = 1
    SPROX 7c96
    SPROX SAFEARRAY keys end


    The "7c96" represent the EBCDIC codes for the characters being sent. In this case, they are as follows:

    X'7C' = @
    X'96' = o (lower case)

    This means that the SI application is sending @o, which is defined as PF24 in Session Integrator. As you had surmised, this was the PF24 that you thought it was.

    There are two options to send keys using Session Integrator. The 3270NET example in
    the SDK displays the following within Form1.cs:

    // hit enter
    m_Handler.SendKey("@E");

    However, the following can also perform the same function:

    m_Handler.SendKey(SessionDisplayKeys.Enter);

    In the SI code, "SessionDisplayKeys.Enter" ends up returning "@E". The m_Handler.SendKey(SessionDisplayKeys.Enter) method is a simpler method since the VS intellisense will automatically display a list of available "keys" in a list.

    Hope this helps.

    Thanks...

     

     


    Stephen Jackson - MSFT
    Thursday, May 27, 2010 4:28 PM
  • Thank you. So that log file confirms that I am sending the keys that I want to be sending.

    So the question is if that log file only shows my calls to the API, or if it shows what actually goes on in the underlying session?

    I tried looking at the other trace files, but it is pretty hard to figure out what is going on. Are there any keywords I could search for in the log files to see what gets sent over the line? Or am I better of with a sniffer tool (and what would I be looking for there?)?

    Friday, May 28, 2010 7:39 AM
  • This is where is starts getting deep into the underlying SNA protocol. <g>

    If you look in the SICMSG1.ATF trace file around the same time as the "sendkey request", you should see a message similar to the following:

    FMI   00120200->00110002 FMI DATA 
    FMI                      NO ACK reqd Key:2 Seq:0 BCI ECI BBI CDI
    FMI  
    FMI   ---- Header at address 1B1C6070, 1 elements ----
    FMI   00000002 6A000000 00000000 01008404     <....j.........d.>
    FMI  
    FMI   ---- Element at address 1B214124, start 13, end 18 ----
    FMI   7D4FE211 5CF1                           <}OS.\1          >

    The data that is being sent is the data in the Element part of the message. In this case, the data is as follows:

    7D - ENTER
    4FE2 - 3270 screen buffer address (corresponds to a row and column on the 3270 screen)
    11 - Set Buffer Address (SBA) command
    5CF1 - Buffer Address that the cursor will be placed at.

    In the case of the PF24 key, the data should include a 4C as that is the EBCDIC Hex code for a PF24 AID key.

    HIS traces aren't really intended for customer troubleshooting as there is no documentation that describes how to interpret them. Once you get into the actual SNA data flow, then you need to be able to breakout the SNA data as defined by IBM. It is doable, it can be time intensive.

    The data that you see in the SICMSG1.ATF trace will be the data that ultimately gets sent to and received from the IBM mainframe.


    Stephen Jackson - MSFT
    Friday, May 28, 2010 7:13 PM