TCL Stacks - OpenQM | Google Groups

Message from discussion TCL Stacks
Received-SPF: pass (google.com: domain of martinphill...@ladybridge.com designates 81.31.99.7 as permitted sender) client-ip=81.31.99.7;
Message-ID: <41E7C7AFCE924437BB002CB8E665559F@LBS8>
From: "Martin Phillips" <martinphill...@ladybridge.com>
To: <OpenQM@googlegroups.com>
References: <de34fe36-2cdc-48c1-b4cb-9dd437d86199@l28g2000vba.googlegroups.com>
Subject: Re: TCL Stacks
Date: Mon, 8 Jun 2009 16:46:54 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1

Hi Eugene,

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



----- Original Message ----- 
From: "eppick77" <eppic...@yahoo.com>
To: "OpenQM" <OpenQM@googlegroups.com>
Sent: Monday, June 08, 2009 3:12 PM
Subject: TCL Stacks


>
> I am interested in tcl stacks.  Ideally, what I would like is that if
> i am in 2 sessions, the stack would be a combined stack from both
> sessions (assuming that I am in the same account).
>
> I noticed that there is a directory called stacks at the linux level.
> I also notice that if I do save.stack or get.stack, that works on an
> item in the $SAVEDLISTS file.
>
> I am doing a get.stack when I logon and a save.stack when I exit.  The
> problem is that the last session that logs off is the one that really
> gets saved as they all write to the same item.
>
> Eugene
> >