Ticket #312 ( Closed )

Short Description Trapping TN_REJ_DEVICE-IN-USE
Entered By: JaxAce When: 1999-05-28 11:35:33 Build: 2_0_4G
Categories Type: Problem   Department: Product   Category: TN3270 Connection
A while back, we went through trying to catch when
a connection is attempted to a dedicated LU that is
already in use.

<TECATCH> doesn't catch it, as was suggested in an
earlier email.

<TEIF task.sessionactive = 0>  doesn't get called;
likely because it fails before these routines.

However, the TN_REJ_DEVICE-IN-USE pops up immediately
in the diag window. We need that to be trapped just as
fast in the surfer code - Can that be done?  

Otherwise, the Browser spins its wheels until it blows up, 
and the session state is undetermined ...the diagnostic 
window displays:

(Unable to connect to group LU_GROUP_1:I2287183--(Bad internal Session Number or invalid SessionKey...))

Then it bombs in a place it should not be, perhaps it 
is falling through to the absolute last section:

Error: Script Interpreter (Internal Execution error in 
Template Section "global.footer", OpCode TEPUTSECTION
 due to exception code C0000005 
Append By: WindSurfer  When: 1999-05-28 12:06:56  New Status: Pending Customer
Comment We've reviewed, and will be reproducing both the trap and the situation on Tuesday of next week-- you should be able to expect a fix sometime around mid-day...
Append By: WindSurfer  When: 1999-06-01 17:25:13  New Status: Pending Customer
Comment Fix is available at ftp://ftp.ieinc2.com/pub/surfer/t2_0_4I.zip

The TECATCH will now work-- the following sample catches the error:

<tesection doconnect
  when tranpath_1 is "linkme">
<teaction connect "LU_GROUP_1">
<teif task.SessionActive>
  <teaction return withscan>
  <teputsection badconnect>
<teevent catch>
 <teputsection badconnect>

<tesection badconnect>
  <h1>Sorry-- Could not connect</h1>
<table border>
<tr><td><teshow task.errorcomponent></td></tr>
<tr><td><teshow task.errortext></td></tr>
Append By: JaxAce  When: 1999-06-02 10:31:34  New Status: Closed
Thanks, this seems to work, but raises other, minor
issues, which I'm posting in another ticket.

- H
Append By: JaxAce  When: 1999-06-17 17:15:55  New Status: Pending IE

This doesn't recognize that the
device is in use.

If I alter this line (from code above), to 
get a specific LU, it works fine - as long 
as the LU is not already in use:

   <teaction connect "LU_GROUP_1:"+web.LU>

If it is in use, no error occurs, AND the
connection is made on a _different_ LU taken
from the pool.

- H

Append By: WindSurfer  When: 1999-06-17 17:54:18  New Status: Pending Customer
Comment OK, will figure-out what is going on and get you a fix.
Append By: JaxAce  When: 1999-06-21 16:57:39  New Status: Closed

OOOPS   sorry 

It's not likely you'd ever figure this out!

My code contains a subtle error not in the comment above:

   <teaction connect "LU_GROUP_1:" + web.LU>

but the sample above is:

   <teaction connect "LU_GROUP_1:"+web.LU>

which works.  

I'd like to see a tricks and traps section here on your 
site to better document the parser from hell. (Yes, I 
remember NOW:) that the parms are units that 
should have no white space in them...)

This works too:

      <TESET task.handler = "LU_GROUP_1:" + web.LU>
      <teaction connect task.handler>

Hope some new, user vars that don't need an active session, 
are in the wings - it's tough to cram everything in one

Append By: JaxAce  When: 1999-06-21 17:13:28  New Status: Pending IE

Forgot to mention that there is still a problem with this...

It's hard to reproduce, but the task. vars do not always 
show the error condition - the table in the sample code you 
gave (see comment on 06-01) draws, but .errorcomponent and .errortext are empty. 

The lack of error msg happens maybe once out of every 20 
attempts to connect  to a session (LU) that is already in 
use. (Guess: It could be that I am trying to connect just as the same one is being released by SNA (e.g., I do a stop 
from admin, then do the connect by URL from a second browser.)

- H
Append By: JaxAce  When: 1999-06-22 10:49:05  New Status: Pending IE
Debugged a bit more ... narrowing it down ....

With only one session running in the entire
surfer server (build 2.0.4I ) 

When the LU for that specific session is requested again, 
the CATCH block does consistenly fire, but the
TN_REJ_DEVICE-IN-USE does NOT always display in the DIAG 
window. When it doesn't, it doesn't show up in task.errorcomponent either.

Getting the LU connect error to work correctly is pretty important...


- H
Append By: WindSurfer  When: 1999-06-22 11:45:14  New Status: Pending Customer
Comment If you catch it with logging on, please send the end of the log to us (the surfdiag.log / host protocol log) at surfer@ieinc.com so we can try to reproduce here. There is a very specific message back from the host with the reject in it, and we would like to confirm that when the bug occurs, the reject reason code is there...then we can try to figure-out what timing issue might be "losing" the message.
Append By: JaxAce  When: 1999-06-22 12:48:04  New Status: Pending IE

AH HA ... The sample code puts the same section twice...

By coding the message directly, as follows, it's clear
that when the trap is called, the error message shows 
correctly. When it fails to show, the trap not being 
called when , rather it's the TEELSE clause that's 
triggered, and then component fails -- so the session is not

<teif task.SessionActive>
    <teaction return withscan>

     <!-- previously: teputsection badconnect-->
     <h1>1 Sorry -- Could not connect

         <teshow task.errorcomponent>
         <teshow task.errortext>
Append By: WindSurfer  When: 1999-06-22 13:07:24  New Status: Pending Customer
Comment By the way, just fixed the parser from hell so that in the TEACTION and other tags, the "+" token will act to concatenate across blanks...also, anything inside parenthesis will concatenate across blanks also...
Append By: WindSurfer  When: 1999-09-14 17:08:14  New Status: Pending Customer
Comment Is this working yet, or are you evacuating??