Our vBulletin migration is complete.
Welcome vBulletin users! All content and user information from the Micro Focus Forums (vBulletin) site has been migrated to this site. READ MORE.
rghaile Absent Member.
Absent Member.
1126 views

XBIS "B$SetInactivityTimeout" and "B$SetServiceTimeout"

Jump to solution

Hello RMCobol Community.  Please allow me to ask for help with XBIS, specifically "B$SetInactivityTimeout" and "B$SetServiceTimeout"

 

There are 3 ways to set "SetInactivityTimeout"

  1. Globally, BIS_SESSION_INACTIVITY_TIMEOUT=600
  2. In the .srf “SessionParms(InactivityTimeout=600)
  3. From the service program, Call "B$SetInactivityTimeout" using {600}

 

BIS_SESSION_INACTIVITY_TIMEOUT=600 has lowest priority and can be overwritten by:

  1. SessionParms(InactivityTimeout=600)
  2. Call "B$SetServiceTimeout"

 

When setting “SetInactivityTimeout” from the service program, “Call "B$SetServiceTimeout"” must be done before “Call "B$ReadRequest"” in order for the timeout to become effective.

 

My question:

Is my understanding of “SetInactivityTimeout” correct?

 

 

 

There are 3 ways to set "SetServiceTimeout"

  1. Globally, BIS_SERVICE_TIMEOUT=30
  2. In the .srf “SessionParms(ServiceTimeout=30)”
  3. From the service program, Call "B$SetServiceTimeout" using {30}

 

BIS_SERVICE_TIMEOUT=30 has the lowest priority and can be overridden by:

  1. SessionParms(ServiceTimeout=30)
  2. Call "B$SetServiceTimeout"

 

When setting "SetServiceTimeout" from the service program, the timeout becomes effective when “Call "B$SetServiceTimeout"” is complete.

 

My question:

Is my understanding of "SetServiceTimeout" correct?

0 Likes
1 Solution

Accepted Solutions
Micro Focus Expert
Micro Focus Expert

RE: XBIS "B$SetInactivityTimeout" and "B$SetServiceTimeout"

Jump to solution

You don't have to restart IIS. The InactivityTimeout (which is the session timeout) will take effect the next time the .SRF file is requested, either when a new session is created or if the SRF is requested by an existing stateful session. The service timeout will not change the timeout of an already running service, but will take effect the next service that is started by that SRF file.

You do have to restart IIS if you change the environment variables, but never if you change a .SRF file.

7 Replies
Micro Focus Expert
Micro Focus Expert

RE: XBIS "B$SetInactivityTimeout" and "B$SetServiceTimeout"

Jump to solution

Your understanding is correct.  The B$ functions have the highest precedence, then the {{SessionParms(...)}} tag, and then the environment variable, then the default values.  The main suggested use of the B$ functions is to dynamically request more time if a particular request is going to take a long time to fulfill.

Also, in the first section, you mentioned B$SetServiceTimeout twice when I believe you meant  to write B$SetInactivityTimeout.  

Finally if this is BIS/IIS on Windows, there was a problem in v12.09 on Windows with B$SetInactivityTimeout and B$SetServiceTimeout not taking effect.  This was fixed in v12.10.  

0 Likes
rghaile Absent Member.
Absent Member.

RE: XBIS "B$SetInactivityTimeout" and "B$SetServiceTimeout"

Jump to solution
Uwe,
Thank you for your response. One follow-up question, please.

You stated "The main suggested use of the B$ functions is to dynamically request more time ".

My application is running "RM/COBOL Runtime - Version 12.12 for Linux". There are 15 methods in my web service application, where 14 methods should complete in less than 5-seconds and 1 method can take up to 20-seconds. I believe we can agree this would acceptable, but sometimes any request will time-out after 4-minutes due to the 3rd party web service being unstable.

I'm grasping at straws to determine the best way to work around the problem. In your opinion, which is better:
1. State the timeout values in the SRF
or
2. Use B$ to set the timeout values each time the service program runs
0 Likes
Micro Focus Expert
Micro Focus Expert

RE: XBIS "B$SetInactivityTimeout" and "B$SetServiceTimeout"

Jump to solution

If the processing delay is caused by your COBOL program processing data for a long time, there are two solutions:

  • The best approach: if your COBOL program is processing in a loop under your control, then if you occasionally call B$SetServiceTimeout(0) in the loop, that will reset the service timer.  It's like a "keep alive" that lets BIS know your program is still processing and hasn't gone off the ranch.  As long as you call this at least once every 30 seconds (or whatever interval you have set the service timeout to), your program can take as long as it needs -- assuming your client won't time out waiting for the response.  

    With this approach, you should also call B$SetSessionTimeout(0) to make sure the session doesn't end after the 10 minutes default period, as that would terminate the service.  For stateless services (see last paragraph below), you can also increase the session timeout in the .SRF file to a large value (say, an hour) so it's not a factor.
  • If you don't have control of the delay in your COBOL program -- for example, you're calling another program from COBOL (or maybe consuming a web service as you stated) that might not return control to the COBOL program for some period of time -- then you can preemptively call B$SetServiceTimeout to some large-enough value at the start of your program.  The only risk is that if the called program or web service doesn't ever return, you're tying up server resources for that amount of time, but hopefully it would fail and give you control back.  If the value is really large (it can be up to an hour, and you can restart that as described above), be sure to also increase the session timeout to something bigger.

Also, if your BIS web application is stateless -- that is, it runs a new service program instance for each request, be sure your .SRF file contains a {{SessionComplete}} tag to declare that you will never receive another request for that session.  That's not a big deal (sessions are lightweight) but there isn't any reason to have it wait for another request that will never come.

Hope this helps.

0 Likes
rghaile Absent Member.
Absent Member.

RE: XBIS "B$SetInactivityTimeout" and "B$SetServiceTimeout"

Jump to solution
Uwe,

Thank you. One final question for my clarification.

For a moment, let's assume I have this statement within the SRF:
SessionParms(InactivityTimeout=110,ServiceTimeout=110

My question:
If I change value 110 to 150, do I have to restart XBIS in order for the change to become effective?
0 Likes
Micro Focus Expert
Micro Focus Expert

RE: XBIS "B$SetInactivityTimeout" and "B$SetServiceTimeout"

Jump to solution

You don't have to restart IIS. The InactivityTimeout (which is the session timeout) will take effect the next time the .SRF file is requested, either when a new session is created or if the SRF is requested by an existing stateful session. The service timeout will not change the timeout of an already running service, but will take effect the next service that is started by that SRF file.

You do have to restart IIS if you change the environment variables, but never if you change a .SRF file.

rghaile Absent Member.
Absent Member.

RE: XBIS "B$SetInactivityTimeout" and "B$SetServiceTimeout"

Jump to solution
Uwe,
Thank you so much for your help. I believe I understand what to do and how to do it.
Thank you!
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: XBIS "B$SetInactivityTimeout" and "B$SetServiceTimeout"

Jump to solution
Fantastic! Happy I could help.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.