Further to my off-list reply, there are various ways this can be handled.
First, let's explain why it works how it does by reference to the way in
which it works wrongly in UV.

In UV, the command stack is saved when you log out, giving it a name
&&S.loginname.userno. So, for example, if I logout, I might get a saved
stack called &&S.MARTIN.123. The theory is that if I now login again it can
reload my stack and I carry on as if I hadn't gone home.

In the days of async comms lines this worked fine because you always got the
same user number. With ethernet connections, I get my stack but not from
three weeks ago instead of yesterday. There is a very big UV site locally
that has 8000 users on the system. Given long enough, each user will work
their way through 8000 different user numbers and they would end up with
64000000 totally useless saved command stacks. Because this doesn't work,
the official IBM recommendation is that this "feature" should be turned off.

In QM, we chose to save the stack based only on the login id to avoid this
problem. This is fine so long as the user only ever has one session. In your
case, where you have multiple sessions, the issue is how to identify which
of your saved stacks you want to restore when you log in again. If, for
example, you have one session for program development and another to run the
application, how are we to identify which is which as you login?

Probably the simplest answer is that you must take control of this because
only you know the answer. To do this, you turn off automatic stack saving
and use the SAVE.STACK command in the ON.EXIT paragraph and the GET.STACK
command in the LOGIN paragraph, providing the relevant stack name by
constructing this in whatever way fits your needs. The inline prompt
mechanism allows you to retrieve useful variable components such as login
name, tcp/ip port number, ip address, etc to use in this command.

Your suggestion of having a common stack for all users logged in with the
same name appeals to me less every time I think about it. Essentially, we
would need to save the command stack everytime you launch a command and
retrieve it again on return to the command processor. This is easy but
because there is no way to control the interactions between the sessions,
even a simple command stack editing sequence to correct an error such as
   .C/ORDRES/ORDERS/
   .X
might end up executing a totally unexpected command.

Ultimately, I think that this is a problem with no easy automatic solution.
Only you know how you want it to work. We cannot predict which of your
sessions is "more important" and hence should be the one that gets saved.
We have, however, provided you with all the tools to create your own stack
save/restore solution to fit your application.

Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200