lunes, 17 de mayo de 2010 14:56
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).
Todas las respuestas
lunes, 17 de mayo de 2010 16:43Propietario
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
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
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.
Stephen Jackson - MSFT
- Marcado como respuesta Stephen_R_JacksonMicrosoft Employee, Owner lunes, 24 de mayo de 2010 15:46
jueves, 27 de mayo de 2010 14:55
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.
jueves, 27 de mayo de 2010 16:28Propietario
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 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
However, the following can also perform the same function:
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.
Stephen Jackson - MSFT
viernes, 28 de mayo de 2010 7:39
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?)?
viernes, 28 de mayo de 2010 19:13Propietario
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 ---- Header at address 1B1C6070, 1 elements ----
FMI 00000002 6A000000 00000000 01008404 <....j.........d.>
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