Host Integration Server: The 3270 session is busy.

[Chris Hayes]

I've also posted this in the microsoft.public.biztalk.server MSDN Managed
Newsgroup area.

We are using Host Integration Server 2006 with our BizTalk Server 2006 to do
some screen scraping of an old mainframe application (I know less than ideal
to say the least). But we are encountering a number of errors that read:
"The 3270 session is busy. The Receive () method should be called to
determine when input is allowed and this method can be retried."

Now we know where the offending code is, we just can't figure out why we get
errors intermittently at this point. We are using a SessionDisplay object to
SendKey an Enter key stroke to move to the next screen in the mainframe app.
The line immediately prior to the Enter SendKey command is "[SessionDisplay
object].WaitForSession(SessionDisplayWaitType.NotBusy, 60000);". We would
have thought that WaitForSession(SessionDisplayWaitType.NotBusy, x) would
wait for the session to NOT be busy before trying to send another key. Our
time interval is set to 60 seconds but the WaitForSession seems to ignore
this.

Is the WaitForSession method not working properly and waiting as it is
instructed?

Does anyone have any suggestions for a workaround?

Thanks,

Chris

[Andrew McLaren]

Hi Chris,

Your understanding of the WaitForSession() method is correct. At least, it's
the same as mine - so, um, I hope it's correct :)

This is just a wild stab in the dark, but ... perhaps when you see this, the
session is not actually busy - it's locked. The 3270 state machine is
pretty complex, there are lots of RQD "Request Definite Response" flags, and
similar stuff, flying back and forth. After data has been sent to the host
application with a SendKey, the session could be in a few different states:
- busy
- ready to send more data
- locked.
Maybe the SI client library is throwing up a SessionBusy error message, when
what it really means is SessionLocked.

There are 2 ways to deal with a locked session. You could inspect the OIA
buffer, to find the cause of the lock and then try to deal with it
gracefully. Or, you could just issue a Reset key, same as if you were
sitting at a real 3270 terminal:
[SessionDisplayobject].SendKey("@R") // @R for RESET

If sending a Reset fixes the problem, you'll know it is because the session
was in the Locked state, rather than Busy, per se. From there, you can get
more foresnic if you want - probably an SNA trace of the 3270 data to see
whether the host was locking the keyboard, or similar. You may need your
best 3270 data stream expert, on hand for this.

Other folks may have better ideas (since this is very much a stab in the
dark). Hope it helps a bit anyway ...

Andrew McLaren

[Chris Hayes]

Thanks Andrew,

I'll give this a shot and see what happens.

Chris

Post by Andrew McLaren
Hi Chris,
Your understanding of the WaitForSession() method is correct. At least,
it's the same as mine - so, um, I hope it's correct :)
This is just a wild stab in the dark, but ... perhaps when you see this,
the session is not actually busy - it's locked. The 3270 state machine is
pretty complex, there are lots of RQD "Request Definite Response" flags,
and similar stuff, flying back and forth. After data has been sent to the
host application with a SendKey, the session could be in a few different
- busy
- ready to send more data
- locked.
Maybe the SI client library is throwing up a SessionBusy error message,
when what it really means is SessionLocked.
There are 2 ways to deal with a locked session. You could inspect the OIA
buffer, to find the cause of the lock and then try to deal with it
gracefully. Or, you could just issue a Reset key, same as if you were
If sending a Reset fixes the problem, you'll know it is because the
session was in the Locked state, rather than Busy, per se. From there, you
can get more foresnic if you want - probably an SNA trace of the 3270 data
to see whether the host was locking the keyboard, or similar. You may need
your best 3270 data stream expert, on hand for this.
Other folks may have better ideas (since this is very much a stab in the
dark). Hope it helps a bit anyway ...
Andrew McLaren

[Chris]

Unfortunately that didn't work, I still the 3270 session is busy error
intermittently.

Looks like its time to come up with a plan B.

Chris

Post by Chris Hayes
Thanks Andrew,
I'll give this a shot and see what happens.
Chris

Post by Andrew McLaren
Hi Chris,
Your understanding of the WaitForSession() method is correct. At least,
it's the same as mine - so, um, I hope it's correct :)
This is just a wild stab in the dark, but ... perhaps when you see this,
the session is not actually busy - it's locked. The 3270 state machine is
pretty complex, there are lots of RQD "Request Definite Response" flags,
and similar stuff, flying back and forth. After data has been sent to the
host application with a SendKey, the session could be in a few different
- busy
- ready to send more data
- locked.
Maybe the SI client library is throwing up a SessionBusy error message,
when what it really means is SessionLocked.
There are 2 ways to deal with a locked session. You could inspect the OIA
buffer, to find the cause of the lock and then try to deal with it
gracefully. Or, you could just issue a Reset key, same as if you were
If sending a Reset fixes the problem, you'll know it is because the
session was in the Locked state, rather than Busy, per se. From there, you
can get more foresnic if you want - probably an SNA trace of the 3270 data
to see whether the host was locking the keyboard, or similar. You may need
your best 3270 data stream expert, on hand for this.
Other folks may have better ideas (since this is very much a stab in the
dark). Hope it helps a bit anyway ...
Andrew McLaren

[Neil Pike]

Chris,

You don't have a multi-threaded app sharing the same scraping code perhaps?
e.g. thread 2 is doing something that mucks up what you're testing/debugging on
thread 1?

Other than that, you should definitely check the OIA status before/when you get
this issue. Which could give a clue.

Other than that, you need to take a look at an SNA/3270 trace to see just what
is going on with the session when this issue occurs.

I have seen weird timing issues like this before, with other API's (non MS
ones). And what those developers sometimes resorted to was hard-coding in a 0.1
second (or whatever) delay before checking the session and sending the next
keystroke. A kludge and not good for throughput, but maybe worth a try, even
just as part of the debugging exercise.

Unfortunately that didn't work, I still the 3270 session is busy error 
intermittently.
Looks like its time to come up with a plan B.

Neil Pike. Protech Computing Ltd
Microsoft SNA/HIS MVP
https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D

[Chris]

Thanks Neil,

The app isn't multi threaded so we can't blame that unfortunately.

I'll do my best to muddle through the OIA data and SNA/3270 trace (I'm a Web
App Developer converting over to BizTalk cause I got bored with web dev).

I'm holding off on the hardcoding of a wait interval before the offending
bits of code but I know that might wind up being the only option in the short
term.

And what's really bad is, this isn't my first problem with Host Integration
Server 2006, I actually found that Session Integrator wouldn't scale earlier
this year and had to get PSS involved, they issued a private hotfix to
address our problem... I'm hoping to avoid another experience like that.

Of course if we could get away from screen scraping altogether that'd fix a
lot of things...

Chris

Post by Andrew McLaren
Chris,
You don't have a multi-threaded app sharing the same scraping code perhaps?
e.g. thread 2 is doing something that mucks up what you're testing/debugging on
thread 1?
Other than that, you should definitely check the OIA status before/when you get
this issue. Which could give a clue.
Other than that, you need to take a look at an SNA/3270 trace to see just what
is going on with the session when this issue occurs.
I have seen weird timing issues like this before, with other API's (non MS
ones). And what those developers sometimes resorted to was hard-coding in a 0.1
second (or whatever) delay before checking the session and sending the next
keystroke. A kludge and not good for throughput, but maybe worth a try, even
just as part of the debugging exercise.

Post by Chris
Unfortunately that didn't work, I still the 3270 session is busy error
intermittently.
Looks like its time to come up with a plan B.

Neil Pike. Protech Computing Ltd
Microsoft SNA/HIS MVP
https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D

[Neil Pike]

Chris,

You can always open a case with PSS again if you believe it's a bug in session
integrator. Which it could well be, as it's a v1.0 product effectively. Did you get
a Kb/bug number for your hotfix by the way? (Purely technical interest to see what
it was).

I'd be happy to take a look at a zip with the trace in as and when.

Is there really no other way of getting at the application/database other than a
screen-scrape? Can't the mainframe developers/vendors develop a "new" CICS/IMS
transaction that could be consumed via WIP, or, even better perhaps, via MQ Series?

That said, I've seen/implemented/debugged MANY systems that relied on screen
scraping and got them all to work effectively. Never used Session Integrator though
- just various 3rd party 3270 emulator/
hllapi/jhllapi type layers. Found my fair
share of bugs in them too - so it wouldn't surprise me if MS didn't get SI right
first time...

Post by Chris
The app isn't multi threaded so we can't blame that unfortunately.
I'll do my best to muddle through the OIA data and SNA/3270 trace (I'm a Web 
App Developer converting over to BizTalk cause I got bored with web dev).
I'm holding off on the hardcoding of a wait interval before the offending 
bits of code but I know that might wind up being the only option in the short 
term.
And what's really bad is, this isn't my first problem with Host Integration 
Server 2006, I actually found that Session Integrator wouldn't scale earlier 
this year and had to get PSS involved, they issued a private hotfix to 
address our problem... I'm hoping to avoid another experience like that.
Of course if we could get away from screen scraping altogether that'd fix a 
lot of things...

Neil Pike. Protech Computing Ltd
Microsoft SNA/HIS MVP
https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D

[Chris]

Hi Neil,

Thanks for your help.

There's no chance that they'll rewrite the app to be more friendly to
Session Integrator so I'm stuck using screen scraping.

I did try this though and have had luck with it.
[SessionDisplay].WaitForSession(SessionDisplayWaitType.Active);
[SessionDisplay].SendKey("@E");

I was able to go through 60+ iterations without getting a 3270 is busy
error. Which is better than it was before, hopefully this gets us past the
problem.

If it doesn't work I'll be back,

Again, thanks for your help,

Chris

Post by Andrew McLaren
Chris,
You can always open a case with PSS again if you believe it's a bug in session
integrator. Which it could well be, as it's a v1.0 product effectively. Did you get
a Kb/bug number for your hotfix by the way? (Purely technical interest to see what
it was).
I'd be happy to take a look at a zip with the trace in as and when.
Is there really no other way of getting at the application/database other than a
screen-scrape?

Can't the mainframe developers/vendors develop a "new" CICS/IMS

Post by Andrew McLaren
transaction that could be consumed via WIP, or, even better perhaps, via MQ Series?
That said, I've seen/implemented/debugged MANY systems that relied on screen
scraping and got them all to work effectively. Never used Session Integrator though
- just various 3rd party 3270 emulator/
hllapi/jhllapi type layers.

Found my fair

Post by Andrew McLaren
share of bugs in them too - so it wouldn't surprise me if MS didn't get SI right
first time...

Post by Chris
The app isn't multi threaded so we can't blame that unfortunately.
I'll do my best to muddle through the OIA data and SNA/3270 trace (I'm a Web
App Developer converting over to BizTalk cause I got bored with web dev).
I'm holding off on the hardcoding of a wait interval before the offending
bits of code but I know that might wind up being the only option in the short
term.
And what's really bad is, this isn't my first problem with Host Integration
Server 2006, I actually found that Session Integrator wouldn't scale earlier
this year and had to get PSS involved, they issued a private hotfix to
address our problem... I'm hoping to avoid another experience like that.
Of course if we could get away from screen scraping altogether that'd fix a
lot of things...

Neil Pike. Protech Computing Ltd
Microsoft SNA/HIS MVP
https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D

[Neil Pike]

Chris,

That's odd. I'd have thought that the session would be active ALL the time, unless there
was some sort of comms issue that caused a disconnect. So I can't understand why putting
that in would fix it...

Anyway, whatever works! Thanks for the update.

Maybe Charles will take a look at the source code for SI and then jump in with what might
be going on here...

Post by Chris
Thanks for your help.
There's no chance that they'll rewrite the app to be more friendly to 
Session Integrator so I'm stuck using screen scraping.
I did try this though and have had luck with it.
[SessionDisplay].WaitForSession(SessionDisplayWaitType.Active);
I was able to go through 60+ iterations without getting a 3270 is busy 
error. Which is better than it was before, hopefully this gets us past the 
problem.
If it doesn't work I'll be back,
Again, thanks for your help,

Neil Pike. Protech Computing Ltd
Microsoft SNA/HIS MVP
https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D

[Andrew McLaren]

Hi Chris,

Sorry the RESET didn't help (was worth a shot).

As usual, I agree with all of Neil's coments. Just to add my own 2 cents ...

Inspecting the OIA could give you a clue what's blocking the session.
Basically you call the CopyOIA function, to put the current OIA into a
buffer. The OIA is 103 bytes long. The interesting info is in bytes 2 to 81.
You read off these bytes and compare them to standard byte patterns which
match 3270 indicators. If you find a match, that tells you the current state
of the session. Yes, I know this sounds primitive, but hey ... it's 3270!
Genuine 1974 era technology :). The doco in HIS is very sketchy on this
point, so your best bet would be to Google for "3270 OIA busy" or "3270 OIA
busy HLLAPI". Examining the entrails of the OIA was a standard practice in
the HLLAPI style of programming (3270 screen-scraping on the desktop), so
lots of HLLAPI mauals have info on how to do this. Data Connection's SNAP-IX
is probably Session Integrator's closest spiritual cousin:

http://www.dataconnection.com/sna/sxdocs/hllpg.htm?./hllpg47.htm

Reading the OIA will only help you understand why the session is blocked -
how you then fix it, will depend on what you find about the session state.
Unless of course the OIA reports the session is in the Ready-for-Input
state, but WaitForSession() says the session is still busy. In which case,
it may well be a bug in the SI Client Library, which you'd want to report to
PSS.

If you're relatively new to 3270, a handy summary is the 3270 introduction
in the CICS manuals; for example:
http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/com.ibm.cics.ts31.doc/dfhp3/dfhp3bh.htm

The canonical reference to 3270 is IBM Publication GA23-0059, "3270
Datastream Programmer's Reference". You can buy this from IBM in hard copy,
although there may be soft copies on the web somewhere. After you read this
book, you'll really know - yea, *feel* deep in your heart - why a
programming model based around three verbs GET, PUT and POST, is so
wonderful :-))

Good luck,
Andrew

[Neil Pike]

If you search for the GA number with Google you can http download it from IBM for free.

IBM are great about making their doco freely available these days. (I remember the old days when it was all in
ring binders and took up pretty much a whole room!)

The canonical reference to 3270 is IBM Publication GA23-0059, "3270 
Datastream Programmer's Reference". You can buy this from IBM in hard copy, 
although there may be soft copies on the web somewhere. After you read this 
book, you'll really know - yea, *feel* deep in your heart - why a 
programming model based around three verbs GET, PUT and POST, is so 
wonderful :-))
Good luck,
Andrew

Neil Pike. Protech Computing Ltd
Microsoft SNA/HIS MVP
https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D

[Chris]

Hi Andrew,

I actually wound trying this:
[SessionDisplay].WaitForSession(SessionDisplayWaitType.Active);
[SessionDisplay].SendKey("@E");

And ran through 60+ iterations without getting a 3270 is busy error. So
maybe this solved the problem as we weren't able to get this far with so many
tries before.

Thanks for your help,

Chris

Post by Andrew McLaren
Hi Chris,
Sorry the RESET didn't help (was worth a shot).
As usual, I agree with all of Neil's coments. Just to add my own 2 cents ...
Inspecting the OIA could give you a clue what's blocking the session.
Basically you call the CopyOIA function, to put the current OIA into a
buffer. The OIA is 103 bytes long. The interesting info is in bytes 2 to 81.
You read off these bytes and compare them to standard byte patterns which
match 3270 indicators. If you find a match, that tells you the current state
of the session. Yes, I know this sounds primitive, but hey ... it's 3270!
Genuine 1974 era technology :). The doco in HIS is very sketchy on this
point, so your best bet would be to Google for "3270 OIA busy" or "3270 OIA
busy HLLAPI". Examining the entrails of the OIA was a standard practice in
the HLLAPI style of programming (3270 screen-scraping on the desktop), so
lots of HLLAPI mauals have info on how to do this. Data Connection's SNAP-IX
http://www.dataconnection.com/sna/sxdocs/hllpg.htm?./hllpg47.htm
Reading the OIA will only help you understand why the session is blocked -
how you then fix it, will depend on what you find about the session state.
Unless of course the OIA reports the session is in the Ready-for-Input
state, but WaitForSession() says the session is still busy. In which case,
it may well be a bug in the SI Client Library, which you'd want to report to
PSS.
If you're relatively new to 3270, a handy summary is the 3270 introduction
http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/com.ibm.cics.ts31.doc/dfhp3/dfhp3bh.htm
The canonical reference to 3270 is IBM Publication GA23-0059, "3270
Datastream Programmer's Reference". You can buy this from IBM in hard copy,
although there may be soft copies on the web somewhere. After you read this
book, you'll really know - yea, *feel* deep in your heart - why a
programming model based around three verbs GET, PUT and POST, is so
wonderful :-))
Good luck,
Andrew

[Rob Beardsworth [MSFT]]

Sorry for coming in here SO late, but here are some comments:

The OIA provided by the Session Integrator is NOT 103 bytes long. It
actually starts at the "On-line and Screen ownership (group 1)" byte
(according to an appropriate scheme, this is Byte 82). Thus for example, if
you look at Bit 3 (IBM numbering scheme) of the first byte of the OIA
returned by Session Integrator , you get the indication as to whether you
are in PLU-SLU session (i.e. if oia[0] & 0x10 is 0x10, then the SLU is in
session with the PLU, not with SSCP). This is what is used by Session
Integrator during the WaitForSession (SessionDisplayWaitType.PLUSLU).

There are 4 SessionDisplayWaitTypes:

Active -> means that the SNA Server's connection to the Host is up, an
ACTPU and an ACTLU have been received for the LU you have specified
PLUSLU -> means you are past a (possible) message-10 screen and are now
actually in session with some host entity, like CICS, TSO etc
NotLocked -> the Keyboard is not locked
NotBusy -> the screen is busy (as defined by oai[8] having it's MSB set ->
Input Inhibited (group 8), Byte 2, bit 0)

NotBusy and NotLocked are NOT the same. Normally, I would wait for
NotLocked, before entering any keystrokes.

WaitForSession's timeout is only an UPPER limit on how long we will wait
for something to happen. If the state requested is reached, we return, no
matter how much of the timeout remains.

Rob Beardsworth MSFT

This posting is provided "AS IS" with no warranties, and confers no rights.

[Andrew McLaren]

Post by Rob Beardsworth [MSFT]
The OIA provided by the Session Integrator is NOT 103 bytes long. It
actually starts at the "On-line and Screen ownership (group 1)" byte

Hey Rob,

Thanks for the clarification; and, my apologies for spreading misinformation
about getting the SessionDisplay OIA property.

(I know SI isn't HLLAPI, but I'm really surprised that SI behaves so
differently to HLLAPI's CopyOIA(), on this point).

None of this could be discerned from the SI documentation ... although I'm
also aware I'm personally, partly to blame for the state of SI
documentation!

Tschuess,
Andrew

[Andrew McLaren]

An follow-up to my own post, in case anyone is still listening or
interested. I thought I should add some extra context -

HLLAPI is a slightly obsolete API for 3270 screen-scrapping on desktop
machines. It was a multi-vendor specification, supported by IBM, Microsoft,
Attachmate, WallData, etc. For many years, it was the lingua-franca for 3270
screen scraping.

In the HLLAPI specification, function 13 - "Copy OIA" - returns a 103 byte
array of bytes. The 80 bytes from positions 2 to 81 (counting from origin
1), are a copy of the literal, on-screen OIA, which you would see across the
bottom of a 3270 terminal, with symbols indicating Locked, Busy, Comm error,
etc.

Bytes 82 to 103 of the HLLAPI OIA buffer are called "Group Indicator
meanings". These are a set of bit fields, which provide information about
the state of the session. They are basically the same information as the OIA
image; but in a format independent of character sets. The literal bytes in
the OIA image could vary if a different code page (eg Japanese) is used;
whereas the bit fields in the group indicators are always the same.

The OIA Groups defined by HLLAPI are:
1: Online and screen ownsership
2: Character selection
3: Shift state
4: PSS group 1 ("programmed symbol support", not Product Support Services!
:-)
5: Highlight
6: Color group 1
7: Inert
8: Input Inhibited
9: PSS group 2
10: Highlight group 2
11: Color Group 2
12: Comunications Error
13: Printer status
14: Graphics
15: (not used)
16: Autokey play/recoird status
17: Autokey abort/pause status
18: Enlarge state

Note that these "group indicators" were invented by, and for, HLLAPI - they
don't exist in any of the IBM 3270 specs (except to the extent they mention
HLLAPI).

What Rob is saying, is that in Session Integrator, the OIA Property of the
SessionDisplay object only contains the 22 byte, bit-field Group Indicators
portion of the OIA. It does *not* return the OIA format indicator (1 byte)
or OIA image (80 bytes) which are returned by the HLLAPI CopyOAI() function.
Well, that's fair enough: Session Integrator is not a clone of HLLAPI (it's
much better); and the group indicator bit fields provide a more accurate way
of assessing session state. But the behaviour may be surprising for any old
HLLAPI programmers out there ...

Getting the OIA Property of a SessionDisplay object boils down to a call to
Icom3270.getOIA(), under the covers. As far as I can tell, the OIA group
indicators returned by Icom3270.getOIA() are the same as those defined by
HLLAPI.

Inspecting a bitmap of the Group One byte (the 0th byte of the array) will
show whether the session is in the LU-LU state, eg:

// look at bit 3 of group one (one byte)
if ((oiaBuffer[0] & 0x10) != 0) writeline "LU-LU is Active";


Likewise, inspecting Group 8 of the OIA Group Indicators, will show whether
input is inhibited because the session is locked, eg:

// look at bit 0 of 2nd byte, group eight (5 bytes)
if ((oiaBuffer[8] & 0x80) != 0) writeline "Session is busy";

But for the application programer working in SI, *by far* the best way to
determine session state is to use the four SessionDisplayWaitTypes, rather
than trying low-level grovelling of the OIA. As per Rob's advice (if I
interpret him correctly), Chris's problem would be solved by using:

"[SessionDisplayobject].WaitForSession(SessionDisplayWaitType.NotLocked,
60000);"

.. rather than:

"[SessionDisplayobject].WaitForSession(SessionDisplayWaitType.NotBusy,
60000);"

The method will return as soon as the session is no longer in the locked
state (and hence, not busy, either).

There, I hope I got it right, this time! :-) Apologies again, for
broadcasting duff advice before.

Andrew

[Neil Pike]

Thanks Rob. Useful info.

What it doesn't explain is why when Chris waits on Active his code seems to
work, but when he waits on NotBusy then it doesn't. If reproducible every time
and not just a timing co-incidence, then that doesn't make sense (to me)
Chris - can you change your code to Notlocked and let us know how that works
compared to the other options tried?

The OIA provided by the Session Integrator is NOT 103 bytes long. It 
actually starts at the "On-line and Screen ownership (group 1)" byte 
(according to an appropriate scheme, this is Byte 82). Thus for example, if 
you look at Bit 3 (IBM numbering scheme) of the first byte of the OIA 
returned by Session Integrator , you get the indication as to whether you 
are in PLU-SLU session (i.e. if oia[0] & 0x10 is 0x10, then the SLU is in 
session with the PLU, not with SSCP). This is what is used by Session 
Integrator during the WaitForSession (SessionDisplayWaitType.PLUSLU).
Active -> means that the SNA Server's connection to the Host is up, an 
ACTPU and an ACTLU have been received for the LU you have specified
PLUSLU -> means you are past a (possible) message-10 screen and are now 
actually in session with some host entity, like CICS, TSO etc
NotLocked -> the Keyboard is not locked
NotBusy -> the screen is busy (as defined by oai[8] having it's MSB set -> 
Input Inhibited (group 8), Byte 2, bit 0)
NotBusy and NotLocked are NOT the same. Normally, I would wait for 
NotLocked, before entering any keystrokes.
WaitForSession's timeout is only an UPPER limit on how long we will wait 
for something to happen. If the state requested is reached, we return, no 
matter how much of the timeout remains.

Neil Pike. Protech Computing Ltd
Microsoft SNA/HIS MVP
https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D

[Chris Hayes]

Hi Neil,

I'll try it when I get back from vacation next week. Sorry for the delay,
but I've actually been vacationing and staying away from work related
things. I'll give this try later next week when I get back work.

Chris

Post by Neil Pike
Thanks Rob. Useful info.
What it doesn't explain is why when Chris waits on Active his code seems to
work, but when he waits on NotBusy then it doesn't. If reproducible every time
and not just a timing co-incidence, then that doesn't make sense (to me)
Chris - can you change your code to Notlocked and let us know how that works
compared to the other options tried?

Post by Rob Beardsworth [MSFT]
The OIA provided by the Session Integrator is NOT 103 bytes long. It
actually starts at the "On-line and Screen ownership (group 1)" byte
(according to an appropriate scheme, this is Byte 82). Thus for example, if
you look at Bit 3 (IBM numbering scheme) of the first byte of the OIA
returned by Session Integrator , you get the indication as to whether you
are in PLU-SLU session (i.e. if oia[0] & 0x10 is 0x10, then the SLU is in
session with the PLU, not with SSCP). This is what is used by Session
Integrator during the WaitForSession (SessionDisplayWaitType.PLUSLU).
Active -> means that the SNA Server's connection to the Host is up, an
ACTPU and an ACTLU have been received for the LU you have specified
PLUSLU -> means you are past a (possible) message-10 screen and are now
actually in session with some host entity, like CICS, TSO etc
NotLocked -> the Keyboard is not locked
NotBusy -> the screen is busy (as defined by oai[8] having it's MSB set ->
Input Inhibited (group 8), Byte 2, bit 0)
NotBusy and NotLocked are NOT the same. Normally, I would wait for
NotLocked, before entering any keystrokes.
WaitForSession's timeout is only an UPPER limit on how long we will wait
for something to happen. If the state requested is reached, we return, no
matter how much of the timeout remains.

Neil Pike. Protech Computing Ltd
Microsoft SNA/HIS MVP
https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D

[Neil Pike]

No worries - enjoy the break!

I'll try it when I get back from vacation next week. Sorry for the delay, 
but I've actually been vacationing and staying away from work related 
things. I'll give this try later next week when I get back work.

Neil Pike. Protech Computing Ltd
Microsoft SNA/HIS MVP
https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D
http://www.linkedin.com/in/neilpike