ZMF Explorer: how to change token expiration time

Hi Stefano,

There is no way to change the token expiration time.

ZMF explorer establishes 5 pre-defined 'sessions' with the ZMF REST server. We pull a session from the pool to perform your current set of functions. Once that set is complete the 'session' is returned to the pool. If a session is left inactive (i.e. you leave the current function in-flgiht) it is terminated by the ZMF REST server after a period of time. This should not cause any functional problems, you just click to re-establish the session and then proceed with what you want to do.

Is this causing a problem ?

All the best - Steve

Thank you Steve.

Users just told me that it's annoying having to re-establish session. I was just wondering if there is a parameter for this... So not even at ZMF REST Server I may "add" some time before terminating session? 

I've tried to change SESSION_TIMEOUT in ZMFPARMS member of the z/OS Tomcat installation but nothing happened.

Any advice?

Thank you.

The SESSION_TIMEOUT parameter is the right one. It is specified in minutes and has a default of 30 minutes !   That ought to be enough for anybody, yes ?

Which makes me wonder what else is going on here.

I'll try and do some testing at my end (but that may have to wait till next week). In the meantime, do you have a feel for how long a user leaves an explorer initiated function inactive before they get this "Inactive Toke Expired" message ?

Thanks

The SESSION_TIMEOUT parameter works fine for me - we use a setting of 10 (i.e. 10 minutes). The default setting is 30 (minutes). You can make it longer if you wish but why would you want to do that? The local representation of the tree is a point-in-time snapshot. Something may have changed in the period since you last interacted with ZMF - refreshing the tree is a good idea.

On reflection, I believe that the setting we use (i.e. SESSION_TIMEOUT=10) is a good compromise.

You can make this longer but all you're doing is using up more resources in the ZMF REST server (e.g. if a user doesn't do anything for 30 minutes, surely it's a good idea to release resources ?). And relying on a tree that is 30 (or whatever the SESSION_TIMEOUT value is set to) minutes old is not a good idea anyway ?

All the best - Steve

Hi ​@Stefano Antoniazzi 

I encounter exactly the same issue with my VScode/ZMF installation, I constantly get “inactive Token expired” which forces me to update once more my password profile to be able to continue working with ZMF.

What solution/workaround did you implement to get this token not expiring too quickly?

Thanks a lot for your help,

Christophe

• ​@Steve Downes 
  Hi Steve,​@Christophe is one of our newbee admins. Would you be so kind on elaborating on the first reply :
  - Which 5 pre-defined sessions
  - Current set of functions (which functions)
• This to better understand the relationship with the ZMF Explorer and the Tomcat

Thank you in advance
Best regards
Johan

​@Johan Jacob ​@Christophe 

Hi Johan and Christophe,

My understanding of the internals involved here is limited but I have asked others (who will know more) to contribute. However, today is a company holiday at Rocket (Juneteenth) so it will be next week before anybody else responds.

Here is my understanding (may not be 100% correct, which is why I am looking elsewhere for validation).

Under the covers, the vsCode ZMF explorer establishes 5 open connections with Tomcat/ZMF. These form a pool from which sessions are allocated to service whatever you are currently doing in the extension (i.e. when you request ZMF services). If you do nothing for a period of time these sessions are closed (to save resource). the next time you do anything in the ZMF explorer they are re-established.  

As far as I know, this mechanism should not force you to do anything with the credentials you have already stored ? 

As to the precise parameter (in Tomcat, I guess) which may help with persisting these sessions (if such a parameter exists), I’m afraid this is where my knowledge runs out. Hopefully my colleagues will be able to give better detail on this next week.

All the best - Steve

Hi ​@Steve Downes  and ​@John Skelton 

Thank you both for the reply, we will investigate this next week and will get back to you with our findings

Best regards

Johan

​@Johan Jacob ​@Christophe ​@Steve Downes 

I did some testing in this area and found an error when SESSION_TIMEOUT=0:  You will be timed out immediately.   This is a regression in Rest Services. 

I would think increasing the value for SESSION_TIMEOUT may solve your problem, but it appears you have already tried this approach without success.

Regards,
John