BIS Inactivity timeout and Windows 8.1

Rich,

The first thing to do is to enable tracing using the {{TRACE}} tag.  There is usually an informative message in the trace file about what triggered the session timeout.

Also, IIS on my Win8.1 machine is IIS8.

Rich,

[Rich sent a message to me via the message feature with a trace file.  However, the Inbox feature seems to be broken; I have tried with IE and Chrome...]

It appears to me that your SRF file is broken.  We have had some issues with malware/virus trashing the SRF file at some of our customer sites.  But clearly the trace is showing a bunch of nonsense.  So your original symptom makes sense, since the Session timeout is not getting set.  After the default timeout of 10 minutes (600 seconds) your session is timed out and torn down.

Try replacing the SRF file with one that is know good.  On a couple of occasions the viral damage was bad enough that we had to reinstall.  Fortunately, none of the data files were affected.

Please reply in thread (log in, then use the reply box below) because I cannot seem to reply via the message system.

Tom,

We did test on an identical system and with a different SRF file than the one at our client and got the same results.

We set the timeout values in a called program  Here is that code:

000000 PROCEDURE DIVISION.

000000*-----------------------------------------------------------

000000 A100-BEGIN SECTION.

000000*-----------------------------------------------------------

000000 A101.

000000     DISPLAY 'AMI D900 START PROG'.

010408     CALL 'B$SETINACTIVITYTIMEOUT' USING BIS-INACTIVITY-TIMEOUT

010408         GIVING BIS-STATUS.

010408     CALL 'B$SETSERVICETIMEOUT' USING BIS-SERVICE-TIMEOUT

010408         GIVING BIS-STATUS.

000000 A199-EXIT.

000000     DISPLAY 'AMI D900 END PROG'.

000000     EXIT PROGRAM.

And after that call, this is what we get in the trace file normally:

LiantBIS  Processing {{SessionParms(InactivityTimeout=3600)}} tag created by
          B$SetInactivityTimeout, timeout is now 3600 seconds
Service   BISX: HANDLE-REQUESTS
Service   bisx in handle-show-page
Service   next page = c700
Service   next module =
Service   showing C700
Service   bisx in show-page
Service
LiantBIS  Processing {{SessionParms(ServiceTimeout=3600)}} tag created by
          B$SetServiceTimeout, timeout is now 3600 seconds
Service   bisx in error-check
Service   bisx in write-response
Service   BISXUTIL: WRITE-RESPONSE
Service   bisx in error-check
Service   BISX: in GET-REQUEST
Service

Don't know if this helps or not.

Well, the trace file fragment does not contain either AMI D900 START PROG or AMI D900 END PROG.  So, there is no reason to believe, from the trace, that the displayed code is ever executed.  The only lines DISPLAYed from the Service (i.e. the COBOL program) are those of the BIS Express runtime module.

It looks like the service timeout is indeed being set at 60 minutes, not the default 10 minutes, when the SRF's {{SessionParms}} tag is processed.  We don't have a timeout in the trace, so we don't know what circumstances were when the timer expired.

So, nothing very conclusive from this particular trace. 

My apologies, the original trace does include the call to D900, I must not have copied that part.  The trace files are rather large so I didn't copy the whole thing.

I would be suspicious that something might be resetting the timeout later in the session.  Are there any other reports of the inactivity timeout being changed in the session trace file -- something setting it back to the default 600 seconds?  For example, if keep-alive requests are asynchronously sent to the session, and the target .SRF file contains a {{SessionParms}} tag, that would reset the timeout for the session.

When the session times out, a final set of records should be written to the file trace for the session.  From what I remember, those records should indicate why the session ended and how much time was left.  

If the final end of session block doesn't appear. it's possible something external is ending the session. A remote possibility is that some IIS application pool setting is affecting this.  The advanced application pool settings do have an ":idle timeout" that defaults to 20 minutes but that will not end a BIS session (it's not considered idle if a session exists).  But there might be other settings that could affect BIS.

As far as I know there have not been other reports of the timeout getting reset to the default 600 seconds.  

I'm sceptical about the SRF files being the problem since we have hundreds of them throught our system. There shouldn't be mulitple requests sent to the session since each workstation has it's own session and in this case, the client only has one workstation.

I'm told we had a similar issue with windows 7.  The idle timeout was set to a large number which resolved the issue but that doesn't seem to be working for windows 8.1.  They are going to see if we have an IIS 8 we can load and test here to see if IIS 7.5 is an issue.

As far as I know there have not been other reports of the timeout getting reset to the default 600 seconds.  

I'm sceptical about the SRF files being the problem since we have hundreds of them throught our system. There shouldn't be mulitple requests sent to the session since each workstation has it's own session and in this case, the client only has one workstation.

I'm told we had a similar issue with windows 7.  The idle timeout was set to a large number which resolved the issue but that doesn't seem to be working for windows 8.1.  They are going to see if we have an IIS 8 we can load and test here to see if IIS 7.5 is an issue.

Rich,

Seeing an entire trace file would go a long way toward solving this.  The trace file that you sent me through the messaging capability of this forum is shown below.  The highlighted trace entries are what led me to believe that something had trashed the SRF file.  Note that the unrecognized parameter messages, when taken together, spell out C:\\Database\\c3007.srf   

If the trace file is extremely big (and some are) then zip it and send it to me.  My email is my first name at my company's domain, which can be guessed or Googled from the company's name.

Service AMI C701 MAIN-LOGIC
Service bisx in show-page
Service
BIS Ignored {{SessionParms(IüÿÎ<!=€\\)}} tag, unrecognized parameter
BIS Ignored {{SessionParms(?=?)}} tag, unrecognized parameter
BIS Ignored {{SessionParms(\\=C)}} tag, unrecognized parameter
BIS Ignored {{SessionParms(:=\\)}} tag, unrecognized parameter
BIS Ignored {{SessionParms(D=a)}} tag, unrecognized parameter
BIS Ignored {{SessionParms(t=a)}} tag, unrecognized parameter
BIS Ignored {{SessionParms(b=a)}} tag, unrecognized parameter
BIS Ignored {{SessionParms(s=e)}} tag, unrecognized parameter
BIS Ignored {{SessionParms(\\=c)}} tag, unrecognized parameter
BIS Ignored {{SessionParms(3=0)}} tag, unrecognized parameter
BIS Ignored {{SessionParms(0=7)}} tag, unrecognized parameter
BIS Ignored {{SessionParms(.=s)}} tag, unrecognized parameter
BIS Ignored {{SessionParms(r=f)}} tag, unrecognized parameter
Service bisx in error-check
Service bisx in write-response
Service BISXUTIL: WRITE-RESPONSE
Service bisx in error-check
Service BISX: in GET-REQUEST
Service XMLExchange Received exchange response from service
BIS Processing {{ContentType(text/html; charset=utf-8)}} tag
XMLExchange No {{FormActionTarget}} in this exchange, sequence checking suppressed
Service BISXUTIL: READ-REQUEST-NO-TIMEOUT
Service BISXUTIL: reading request no time out
Service BIS Page Rendering Complete: service program remains active, session remains active!
------------ SESSION TERMINATING [12/16/14 15:36:06] -----------------------------------------------
Async Session "bisx{1}" expired 601 seconds after last request, requesting service termination (30 second timer started)
Service BISXUTIL: no request pending 0.001 0.001
Service bisx in error-check
Service !!!!!!!!BIS Error Occurred!!!!!!!!
Service BIS Status: 0050 Service error check is terminating 0.001 0.002
Service bisx in shutdown-logic
Service AMI C701 MAIN-LOGIC
Service AMI C701 TERMINATE-PROGRAM
Service bisx in terminate-xml
Service 0.004 0.006
Service BIS Service complete at line 1215 in program BISX(C:\\Database\\bin\\BISX.COB).
Service 0.021 0.027
Service 0.973 1.000
sync Service "bisx{1}" terminated after 1 second (29 seconds left) BIS Service counter decremented: 0 service programs now running 0.001 1.001
Async Unloading session! 0.001 1.002

Best regards,
Tom Morrison
Hill Country Software

Wow -- that is weird.  I wonder if those SessionParms requests could be coming from the service (via a corrupted B$SetInactivityTimeout timeout call) instead of from the .SRF file.  The prefix is missing from the trace above.  In any case, the SESSION TERMINATING trace clearly shows the 600 second timer in action. I wonder if this is the call that is supposed to extend the timeout to something longer than 600 seconds.

Tom: thanks for your help with this -- your real-world BIS Express experience is invaluable.

Thanks for everyones suggestions so far.  The CS Rep working with this client is out of the office, when he returns, I'll get you a complete trace file.

Here is the full trace file from our initial test on 12/16/14. Please find code here.

Hi Tom,

Was wondering if you had a chance to look at this anymore after I uploaded the complete trace file you requested?

Thanks,

Rich Maringer

Hi Rich:

Thanks for submitting the log -- it clearly illustrated the problem, which I was able to reproduce. I confirmed an issue with a change in v12.09 that indirectly affected the ability of the B$SetInactivityTimeout and B$SetServiceTimeout functions to communicate with the BIS request handler.  v12.08 does not have this problem, which may be why Tom didn't see it.

Until we can offer a solution, you can work around this issue by setting the inactivity timeout (and service timeout, if required) using this tag in your .srf file(s):

{{ SessionParms( InactivityTimeout= seconds ) }}

I also suggest that you express your interest in this problem with your support line representative.

Thanks again for your persistence in bringing this to our attention.

Good find, Uwe.  This could be a real problem in certain circumstances using long running processes.

(Rich, sorry I had not come back to this.  I have recently had a small health issue that took me away from the keyboard for a few days.)

Tom: thanks!  Glad to hear that you're on the mend.