Hello,

In the past we stored specific variables in the ISPF pool that we could use during the ISPF session of the user

It would be great to be able to do the same via the VPOOL, this would require a HLLX exit on the primary panel

This would give us the ability to store specific userVariables in the VPOOL and retrieve them from any HLLX we would see fit

Or a way to store VPOOL variables from outside the HLLX (but that I think is less likely to be provided)

Thank you

Johan

Hi Johan 

My company has dealt with a lot of customers moving from ISPF centric to a more generic level of interfaces with ChangeMan.   We have found very few reasons to use the VPOOL over the length of a session. Historically the developer logs on to tso and then ChangeMan and does a number of actions. In the new paradigm they often connect and disconnect multiple times and can come into the process multiple ways with git Zowe eclipse and other tools. 

it would be good to understand what type of information you are storing, and how it is used. we can help you look for alternate ways to achieve the same or better results 

Tom Mavor

CM2 Software 

Hi Tom,

We would like to store the type of user it is during the session, depending on the type fill in certain values at package create time

This info is quit static and would be useful on a series of locations and we don't want to retrieve it all the time, you could compare it with an ISPF environments variable. So this would come in handy to be able to retrieve it from that pool. So even a way to store some static data in that pool would be interesting even via a XML Service or other mean, so when the user connects

Best regards

Johan
PS: We have a solution but we each time retrieve the data when needed, but that is a bit overkill

Hi Johan,

I created a change ticket for something like this some time ago but it has not gained any 'traction'. Your request will help change that.

My description from the original ticket goes like this...

Customers making use of the VPOOL facility (or any other home-grown means of setting session variables) may wish to set these variables during the initialisation of the client session with the ZMF started task.
The exit(s) would be passed as much user/session information as is available at that point.

We should implement at least two initial exit points...

1) One for the ZMF instance as a whole, executed during start up. Customers could assign global variables (e.g. use XML services to obtain global admin settings and write them to VPOOL variables for use by all other exits without having to execute the same XML all over the place).

2) One for client initialization, executed just after the initial connect to ZMF.

This sounds, to me, like what you are looking for ?

Do you have any other comments or suggestions based on the above ?

All the best - Steve