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.
> 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.
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.
I understand your concern. I do not know how D3 does it behind the
scenes but I can tell you that it does work there.
On D3,
My stack looks like this:
014 GET-LIST EP
013 SORT HOWLI BY-EXP PMID BREAK-ON PMID TITLE SOURCE TOTAL 12 DET-
SUPP
012 ED MD OE1000
011 CT MD PUB.BP
010 EX
009 to ep.publish
008 ED DM CREATE.EDI.INVOICE.SUB
007 ED MD CREATE.EDI.INVOICE.SUB
006 LPR
005 off
004 !@
003 TO BMI
002 WHO
001 TO EP.BMI
I suspect that D3 is only writing the stack after a tcl command gets
executed. Also, I think that what it does is to read the stack
record, update it and write it back out. Truly all it is doing is
pushing the stack up one line.
D3 writes one stack always puts the latest tcl command at the bottom
when you do one. I just looked at my tcl ston D3. The most recent
tcl command goes on the bottom of the record.
I would certainly like to hear what others that have used D3 or
perhaps mvBase have experienced.
Eugene
On Jun 8, 11:46 am, "Martin Phillips" <martinphill...@ladybridge.com>
wrote:
> 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.
my experience:
D3/Linux has a stack based on the 'Account Name'
i say this because when i've tried to reference it, over users (on the same account) have processed TCL commands and i see theirs intermixed with mine
mvBASE has a stack per port
i like the mvBASE version because it contains a basic history of 'whatever' the port executed
you can actually execute something from your port that another port has executed
here's an example:
>.L (4
001 OFF
002 @LOST.DTR
003 DISCONNECT 4
004 WHO
005 CLEAR-FILE DATA TEMP
006 LIST-ITEM TEMP
007 ED TEMP TEST
008 TX.SYS (E
009 TX.SYS
010 TM401
011 SP-ASSIGN F7 HS
012 PPQ.SET
013 TX.SYS
014 TM101
015 PROC.PA.PASSWORD
016 SP-ASSIGN F7 HS
017 PPQ.SET
018 TX.SYS
019 PROC.PA.PASSWORD
020 TX.SYS (E
the above says list the stack of port 4
you can set limits for the number of items to be recorded, etc
so if i'm on port 3 i can:
.X14 (4
the above says execute line 14 of the stack of port 4
of course if port 4 is actually busy, etc., line 14 could actually change before you executed it
just my 2 cents
Steve Trimble
Computerized Data Mgmt Inc
PO Box 13403 Maumelle, AR 72113 (501) 803-0974 09:00am - 6:00pm CST
________________________________
From: eppick77 <eppic...@yahoo.com>
To: OpenQM <OpenQM@googlegroups.com>
Sent: Monday, June 8, 2009 12:43:56 PM
Subject: Re: TCL Stacks
Martin,
I understand your concern. I do not know how D3 does it behind the
scenes but I can tell you that it does work there.
On D3,
My stack looks like this:
014 GET-LIST EP
013 SORT HOWLI BY-EXP PMID BREAK-ON PMID TITLE SOURCE TOTAL 12 DET-
SUPP
012 ED MD OE1000
011 CT MD PUB.BP
010 EX
009 to ep.publish
008 ED DM CREATE.EDI.INVOICE.SUB
007 ED MD CREATE.EDI.INVOICE.SUB
006 LPR
005 off
004 !@
003 TO BMI
002 WHO
001 TO EP.BMI
I suspect that D3 is only writing the stack after a tcl command gets
executed. Also, I think that what it does is to read the stack
record, update it and write it back out. Truly all it is doing is
pushing the stack up one line.
D3 writes one stack always puts the latest tcl command at the bottom
when you do one. I just looked at my tcl ston D3. The most recent
tcl command goes on the bottom of the record.
I would certainly like to hear what others that have used D3 or
perhaps mvBase have experienced.
Eugene
On Jun 8, 11:46 am, "Martin Phillips" <martinphill...@ladybridge.com>
wrote:
> 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.
There is a file in D3 called TCL-STACK. I just checked here and it is
by user rather than the account. I wonder if it has to do with a
setting. I know that you can rearrange the order of the who so that
it can be port, user, account or switch it so that it is port,
account , user.
Eugene
On Jun 8, 2:09 pm, CDMI - Steve T <c...@swbell.net> wrote:
> my experience:
> D3/Linux has a stack based on the 'Account Name'
> i say this because when i've tried to reference it, over users (on the same account) have processed TCL commands and i see theirs intermixed with mine
> mvBASE has a stack per port
> i like the mvBASE version because it contains a basic history of 'whatever' the port executed
> you can actually execute something from your port that another port has executed
> the above says list the stack of port 4
> you can set limits for the number of items to be recorded, etc
> so if i'm on port 3 i can:
> .X14 (4
> the above says execute line 14 of the stack of port 4
> of course if port 4 is actually busy, etc., line 14 could actually change before you executed it
> just my 2 cents
> Steve Trimble
> Computerized Data Mgmt Inc
> PO Box 13403
> Maumelle, AR 72113
> (501) 803-0974 09:00am - 6:00pm CST
>
> Home of self defense products:http://www.protecturself.com
> I understand your concern. I do not know how D3 does it behind the
> scenes but I can tell you that it does work there.
> On D3,
> My stack looks like this:
> 014 GET-LIST EP
> 013 SORT HOWLI BY-EXP PMID BREAK-ON PMID TITLE SOURCE TOTAL 12 DET-
> SUPP
> 012 ED MD OE1000
> 011 CT MD PUB.BP
> 010 EX
> 009 to ep.publish
> 008 ED DM CREATE.EDI.INVOICE.SUB
> 007 ED MD CREATE.EDI.INVOICE.SUB
> 006 LPR
> 005 off
> 004 !@
> 003 TO BMI
> 002 WHO
> 001 TO EP.BMI
> I suspect that D3 is only writing the stack after a tcl command gets
> executed. Also, I think that what it does is to read the stack
> record, update it and write it back out. Truly all it is doing is
> pushing the stack up one line.
> D3 writes one stack always puts the latest tcl command at the bottom
> when you do one. I just looked at my tcl ston D3. The most recent
> tcl command goes on the bottom of the record.
> I would certainly like to hear what others that have used D3 or
> perhaps mvBase have experienced.
> Eugene
> On Jun 8, 11:46 am, "Martin Phillips" <martinphill...@ladybridge.com>
> wrote:
> > 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.
> > ----- 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.
I just looked up the docs from D3 - it does appear to be based on the
user rather than the account:
A user's TCL stack is not terminal dependent. It is user-ID dependent.
If a user leaves a terminal unattended, another user can use the
terminal under the previous user's ID. This causes the new user to
step-on the previous user's stack.
Could it be that the user and the account were the same? I have seen
systems where everyone logged in on the same user.
Eugene
On Jun 8, 2:16 pm, eppick77 <eppic...@yahoo.com> wrote:
> There is a file in D3 called TCL-STACK. I just checked here and it is
> by user rather than the account. I wonder if it has to do with a
> setting. I know that you can rearrange the order of the who so that
> it can be port, user, account or switch it so that it is port,
> account , user.
> Eugene
> On Jun 8, 2:09 pm, CDMI - Steve T <c...@swbell.net> wrote:
> > my experience:
> > D3/Linux has a stack based on the 'Account Name'
> > i say this because when i've tried to reference it, over users (on the same account) have processed TCL commands and i see theirs intermixed with mine
> > mvBASE has a stack per port
> > i like the mvBASE version because it contains a basic history of 'whatever' the port executed
> > you can actually execute something from your port that another port has executed
> > the above says list the stack of port 4
> > you can set limits for the number of items to be recorded, etc
> > so if i'm on port 3 i can:
> > .X14 (4
> > the above says execute line 14 of the stack of port 4
> > of course if port 4 is actually busy, etc., line 14 could actually change before you executed it
> > just my 2 cents
> > Steve Trimble
> > Computerized Data Mgmt Inc
> > PO Box 13403
> > Maumelle, AR 72113
> > (501) 803-0974 09:00am - 6:00pm CST
> >
> > Home of self defense products:http://www.protecturself.com
> > I understand your concern. I do not know how D3 does it behind the
> > scenes but I can tell you that it does work there.
> > On D3,
> > My stack looks like this:
> > 014 GET-LIST EP
> > 013 SORT HOWLI BY-EXP PMID BREAK-ON PMID TITLE SOURCE TOTAL 12 DET-
> > SUPP
> > 012 ED MD OE1000
> > 011 CT MD PUB.BP
> > 010 EX
> > 009 to ep.publish
> > 008 ED DM CREATE.EDI.INVOICE.SUB
> > 007 ED MD CREATE.EDI.INVOICE.SUB
> > 006 LPR
> > 005 off
> > 004 !@
> > 003 TO BMI
> > 002 WHO
> > 001 TO EP.BMI
> > I suspect that D3 is only writing the stack after a tcl command gets
> > executed. Also, I think that what it does is to read the stack
> > record, update it and write it back out. Truly all it is doing is
> > pushing the stack up one line.
> > D3 writes one stack always puts the latest tcl command at the bottom
> > when you do one. I just looked at my tcl ston D3. The most recent
> > tcl command goes on the bottom of the record.
> > I would certainly like to hear what others that have used D3 or
> > perhaps mvBase have experienced.
> > Eugene
> > On Jun 8, 11:46 am, "Martin Phillips" <martinphill...@ladybridge.com>
> > wrote:
> > > 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.
> > > > 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.
yep - in my particular case(s), the account-name is a D3 user
(quite useful, huh?)
more than likely my D3 users came from R83, AP/PRO, to D3
thanks for the info,
Steve Trimble
Computerized Data Mgmt Inc
PO Box 13403 Maumelle, AR 72113 (501) 803-0974 09:00am - 6:00pm CST
________________________________
From: eppick77 <eppic...@yahoo.com>
To: OpenQM <OpenQM@googlegroups.com>
Sent: Monday, June 8, 2009 1:31:05 PM
Subject: Re: TCL Stacks
Steve,
I just looked up the docs from D3 - it does appear to be based on the
user rather than the account:
A user's TCL stack is not terminal dependent. It is user-ID dependent.
If a user leaves a terminal unattended, another user can use the
terminal under the previous user's ID. This causes the new user to
step-on the previous user's stack.
Could it be that the user and the account were the same? I have seen
systems where everyone logged in on the same user.
Eugene
On Jun 8, 2:16 pm, eppick77 <eppic...@yahoo.com> wrote:
> There is a file in D3 called TCL-STACK. I just checked here and it is
> by user rather than the account. I wonder if it has to do with a
> setting. I know that you can rearrange the order of the who so that
> it can be port, user, account or switch it so that it is port,
> account , user.
> Eugene
> On Jun 8, 2:09 pm, CDMI - Steve T <c...@swbell.net> wrote:
> > my experience:
> > D3/Linux has a stack based on the 'Account Name'
> > i say this because when i've tried to reference it, over users (on the same account) have processed TCL commands and i see theirs intermixed with mine
> > mvBASE has a stack per port
> > i like the mvBASE version because it contains a basic history of 'whatever' the port executed
> > you can actually execute something from your port that another port has executed
> > the above says list the stack of port 4
> > you can set limits for the number of items to be recorded, etc
> > so if i'm on port 3 i can:
> > .X14 (4
> > the above says execute line 14 of the stack of port 4
> > of course if port 4 is actually busy, etc., line 14 could actually change before you executed it
> > just my 2 cents
> > Steve Trimble
> > Computerized Data Mgmt Inc
> > PO Box 13403
> > Maumelle, AR 72113
> > (501) 803-0974 09:00am - 6:00pm CST
> >
> > Home of self defense products:http://www.protecturself.com
> > I understand your concern. I do not know how D3 does it behind the
> > scenes but I can tell you that it does work there.
> > On D3,
> > My stack looks like this:
> > 014 GET-LIST EP
> > 013 SORT HOWLI BY-EXP PMID BREAK-ON PMID TITLE SOURCE TOTAL 12 DET-
> > SUPP
> > 012 ED MD OE1000
> > 011 CT MD PUB.BP
> > 010 EX
> > 009 to ep.publish
> > 008 ED DM CREATE.EDI.INVOICE.SUB
> > 007 ED MD CREATE.EDI.INVOICE.SUB
> > 006 LPR
> > 005 off
> > 004 !@
> > 003 TO BMI
> > 002 WHO
> > 001 TO EP.BMI
> > I suspect that D3 is only writing the stack after a tcl command gets
> > executed. Also, I think that what it does is to read the stack
> > record, update it and write it back out. Truly all it is doing is
> > pushing the stack up one line.
> > D3 writes one stack always puts the latest tcl command at the bottom
> > when you do one. I just looked at my tcl ston D3. The most recent
> > tcl command goes on the bottom of the record.
> > I would certainly like to hear what others that have used D3 or
> > perhaps mvBase have experienced.
> > Eugene
> > On Jun 8, 11:46 am, "Martin Phillips" <martinphill...@ladybridge.com>
> > wrote:
> > > 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.
> > > > 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.
On Jun 8, 1:43 pm, eppick77 <eppic...@yahoo.com> wrote:
> I do not know how D3 does it behind the
> scenes but I can tell you that it does work there.
The problem with the D3 stack is exactly the scenario that Martin
describes. It is based on the logon id, so if you have more than one
session under the same ID, ".X" will execute the item last placed on
the stack by any of the logged-on sessions.
I've been burned by this in the past, having one window open for
looking at data, another for programming/executing code, and maybe
some other looking at something else. When moving between them all,
you sometimes ".X" on one window expecting the last command displayed
there to execute, but you forgot that you had done something else in
another window, so it's that window's command that ends up being
executed.
You have to be careful, but I guess if you're aware of how it works,
it's not a big deal. Like you, I've lived with this behavior for
years.
In D3 if you put an "i" in atb 9 of the Users item then the tcl-stack file will be updated by port# rather than by the user ID. I think this was added about 15 years ago specifically to accommodate R83 sites that were not yet making use of the User features.
I might be wrong but I believe there was an addition to this about ten years ago, where you can configure (somewhere) the key that would be used in tcl-stack. So you might be able to key off of user*port, or user*account or account*port, etc. If anyone is really curious about this, check the latest D3 reference guide, post a note to the TL forum, or email TL Support.
> From: Kevin Powick > The problem with the D3 stack is exactly the scenario that Martin > describes. It is based on the logon id, so if you have more than one > session under the same ID, ".X" will execute the item last placed on > the stack by any of the logged-on sessions.
> I've been burned by this in the past, having one window open for > looking at data, another for programming/executing code, and maybe > some other looking at something else. When moving between them all, > you sometimes ".X" on one window expecting the last command displayed > there to execute, but you forgot that you had done something else in > another window, so it's that window's command that ends up being > executed.
> You have to be careful, but I guess if you're aware of how it works, > it's not a big deal. Like you, I've lived with this behavior for > years.
I prefer the mvBASE/jBASE concept of linking the stack to the session no (ie
virtual port no). Ok, you lose the stack when you log off (or interestingly
on jBASE pick up somebody elses stack when you log back in!) but I don't
think that that is too much hardship - and you always guarantee that nobody
else can update your stack except you!
-----Original Message-----
From: OpenQM@googlegroups.com [mailto:OpenQM@googlegroups.com] On Behalf Of
Kevin Powick
Sent: 09 June 2009 00:42
To: OpenQM
Subject: Re: TCL Stacks
On Jun 8, 1:43 pm, eppick77 <eppic...@yahoo.com> wrote:
> I do not know how D3 does it behind the
> scenes but I can tell you that it does work there.
The problem with the D3 stack is exactly the scenario that Martin
describes. It is based on the logon id, so if you have more than one
session under the same ID, ".X" will execute the item last placed on
the stack by any of the logged-on sessions.
I've been burned by this in the past, having one window open for
looking at data, another for programming/executing code, and maybe
some other looking at something else. When moving between them all,
you sometimes ".X" on one window expecting the last command displayed
there to execute, but you forgot that you had done something else in
another window, so it's that window's command that ends up being
executed.
You have to be careful, but I guess if you're aware of how it works,
it's not a big deal. Like you, I've lived with this behavior for
years.
No one seems to have picked up my comment that all the tools needed to create a per-session stack already exist so long as you can decide how you want to identify the session.
Personally, I would not want a stack that merges commands from multiple sessions. This is confusing and potentially error prone if I do something like .X3 only to find that some other session under the same user name has just got in my way. We can implement it but it really is (to my mind) an ugly solution.
Because QM has significantly extended the concept of inline prompts from how it works in other products, it is easy to create a personal stack based on all sorts of criteria. Then use SAVE.STACK in the ON.EXIT paragraph and GET.STACK in the LOGIN paragraph.
Perhaps all sessions have unique ip addresses. I could save my stack with SAVE.STACK <<@IP.ADDR>> and restore it with GET.STACK <<@IP.ADDR>>
Or, maybe I use port mapping so that the TCP/IP port number is useful SAVE.STACK <<SYSTEM(1017)>>
Or, with fixed QM user numbers SAVE.STACK <<@USERNO>>
Or, I may have some operating system environment variable that is a useful identifier SAVE.STACK <<$ME>>
Or, perhaps I actually like the horrible system used by UV SAVE.STACK &&S.<<@LOGNAME>>.<<@USERNO>>
Or, maybe I want to save my stack from my development programming session but not from the session in which I am running the test application. I can do this by setting a user defined @-variable in one or other of these sessions IF '@DEV' # '' THEN SAVE.STACK <<@LOGNAME>>
Or,........ The choices are endless.
Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB +44-(0)1604-709200
How about a system() that would return a dynamic array with the stack
in it? If I had the stack record, then I could write a program that
would do what I want with it via the on.exit.
Eugene
On Jun 9, 5:38 am, "Martin Phillips" <martinphill...@ladybridge.com>
wrote:
> No one seems to have picked up my comment that all the tools needed to
> create a per-session stack already exist so long as you can decide how you
> want to identify the session.
> Personally, I would not want a stack that merges commands from multiple
> sessions. This is confusing and potentially error prone if I do something
> like
> .X3
> only to find that some other session under the same user name has just got
> in my way. We can implement it but it really is (to my mind) an ugly
> solution.
> Because QM has significantly extended the concept of inline prompts from how
> it works in other products, it is easy to create a personal stack based on
> all sorts of criteria. Then use SAVE.STACK in the ON.EXIT paragraph and
> GET.STACK in the LOGIN paragraph.
> Perhaps all sessions have unique ip addresses. I could save my stack with
> SAVE.STACK <<@IP.ADDR>>
> and restore it with
> GET.STACK <<@IP.ADDR>>
> Or, maybe I use port mapping so that the TCP/IP port number is useful
> SAVE.STACK <<SYSTEM(1017)>>
> Or, with fixed QM user numbers
> SAVE.STACK <<@USERNO>>
> Or, I may have some operating system environment variable that is a useful
> identifier
> SAVE.STACK <<$ME>>
> Or, perhaps I actually like the horrible system used by UV
> SAVE.STACK &&S.<<@LOGNAME>>.<<@USERNO>>
> Or, maybe I want to save my stack from my development programming session
> but not from the session in which I am running the test application. I can
> do this by setting a user defined @-variable in one or other of these
> sessions
> IF '@DEV' # '' THEN SAVE.STACK <<@LOGNAME>>
> Or,........
> The choices are endless.
> Martin Phillips
> Ladybridge Systems Ltd
> 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
> +44-(0)1604-709200
> How about a system() that would return a dynamic array with the stack
> in it? If I had the stack record, then I could write a program that
> would do what I want with it via the on.exit.
> On Jun 9, 5:38 am, "Martin Phillips" <martinphill...@ladybridge.com>
> wrote:
>> Hi all,
>> No one seems to have picked up my comment that all the tools needed to
>> create a per-session stack already exist so long as you can decide how you
>> want to identify the session.
>> Personally, I would not want a stack that merges commands from multiple
>> sessions. This is confusing and potentially error prone if I do something
>> like
>> .X3
>> only to find that some other session under the same user name has just got
>> in my way. We can implement it but it really is (to my mind) an ugly
>> solution.
>> Because QM has significantly extended the concept of inline prompts from how
>> it works in other products, it is easy to create a personal stack based on
>> all sorts of criteria. Then use SAVE.STACK in the ON.EXIT paragraph and
>> GET.STACK in the LOGIN paragraph.
>> Perhaps all sessions have unique ip addresses. I could save my stack with
>> SAVE.STACK <<@IP.ADDR>>
>> and restore it with
>> GET.STACK <<@IP.ADDR>>
>> Or, maybe I use port mapping so that the TCP/IP port number is useful
>> SAVE.STACK <<SYSTEM(1017)>>
>> Or, with fixed QM user numbers
>> SAVE.STACK <<@USERNO>>
>> Or, I may have some operating system environment variable that is a useful
>> identifier
>> SAVE.STACK <<$ME>>
>> Or, perhaps I actually like the horrible system used by UV
>> SAVE.STACK &&S.<<@LOGNAME>>.<<@USERNO>>
>> Or, maybe I want to save my stack from my development programming session
>> but not from the session in which I am running the test application. I can
>> do this by setting a user defined @-variable in one or other of these
>> sessions
>> IF '@DEV' # '' THEN SAVE.STACK <<@LOGNAME>>
>> Or,........
>> The choices are endless.
>> Martin Phillips
>> Ladybridge Systems Ltd
>> 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
>> +44-(0)1604-709200
> > How about a system() that would return a dynamic array with the stack
> > in it? If I had the stack record, then I could write a program that
> > would do what I want with it via the on.exit.
> @COMMAND.STACK
> > Eugene
> > On Jun 9, 5:38 am, "Martin Phillips" <martinphill...@ladybridge.com>
> > wrote:
> >> Hi all,
> >> No one seems to have picked up my comment that all the tools needed to
> >> create a per-session stack already exist so long as you can decide how you
> >> want to identify the session.
> >> Personally, I would not want a stack that merges commands from multiple
> >> sessions. This is confusing and potentially error prone if I do something
> >> like
> >> .X3
> >> only to find that some other session under the same user name has just got
> >> in my way. We can implement it but it really is (to my mind) an ugly
> >> solution.
> >> Because QM has significantly extended the concept of inline prompts from how
> >> it works in other products, it is easy to create a personal stack based on
> >> all sorts of criteria. Then use SAVE.STACK in the ON.EXIT paragraph and
> >> GET.STACK in the LOGIN paragraph.
> >> Perhaps all sessions have unique ip addresses. I could save my stack with
> >> SAVE.STACK <<@IP.ADDR>>
> >> and restore it with
> >> GET.STACK <<@IP.ADDR>>
> >> Or, maybe I use port mapping so that the TCP/IP port number is useful
> >> SAVE.STACK <<SYSTEM(1017)>>
> >> Or, with fixed QM user numbers
> >> SAVE.STACK <<@USERNO>>
> >> Or, I may have some operating system environment variable that is a useful
> >> identifier
> >> SAVE.STACK <<$ME>>
> >> Or, perhaps I actually like the horrible system used by UV
> >> SAVE.STACK &&S.<<@LOGNAME>>.<<@USERNO>>
> >> Or, maybe I want to save my stack from my development programming session
> >> but not from the session in which I am running the test application. I can
> >> do this by setting a user defined @-variable in one or other of these
> >> sessions
> >> IF '@DEV' # '' THEN SAVE.STACK <<@LOGNAME>>
Thanks to Ashley's comment, I was able to find the @COMMAND.STACK in
the documentation. The docs says that the @COMMAND.STACK contains the
last 99 tcl commands. Does this contain all of the stack or just the
last 99. There is also a way to set the configuration to hold 999
lines instead of 99. If QM was set to hold 999, would the
@COMMAND.STACK contain the 999 or just 99?
Eugene
On Jun 10, 10:13 am, eppick77 <eppic...@yahoo.com> wrote:
> > > How about a system() that would return a dynamic array with the stack
> > > in it? If I had the stack record, then I could write a program that
> > > would do what I want with it via the on.exit.
> > @COMMAND.STACK
> > > Eugene
> > > On Jun 9, 5:38 am, "Martin Phillips" <martinphill...@ladybridge.com>
> > > wrote:
> > >> Hi all,
> > >> No one seems to have picked up my comment that all the tools needed to
> > >> create a per-session stack already exist so long as you can decide how you
> > >> want to identify the session.
> > >> Personally, I would not want a stack that merges commands from multiple
> > >> sessions. This is confusing and potentially error prone if I do something
> > >> like
> > >> .X3
> > >> only to find that some other session under the same user name has just got
> > >> in my way. We can implement it but it really is (to my mind) an ugly
> > >> solution.
> > >> Because QM has significantly extended the concept of inline prompts from how
> > >> it works in other products, it is easy to create a personal stack based on
> > >> all sorts of criteria. Then use SAVE.STACK in the ON.EXIT paragraph and
> > >> GET.STACK in the LOGIN paragraph.
> > >> Perhaps all sessions have unique ip addresses. I could save my stack with
> > >> SAVE.STACK <<@IP.ADDR>>
> > >> and restore it with
> > >> GET.STACK <<@IP.ADDR>>
> > >> Or, maybe I use port mapping so that the TCP/IP port number is useful
> > >> SAVE.STACK <<SYSTEM(1017)>>
> > >> Or, with fixed QM user numbers
> > >> SAVE.STACK <<@USERNO>>
> > >> Or, I may have some operating system environment variable that is a useful
> > >> identifier
> > >> SAVE.STACK <<$ME>>
> > >> Or, perhaps I actually like the horrible system used by UV
> > >> SAVE.STACK &&S.<<@LOGNAME>>.<<@USERNO>>
> > >> Or, maybe I want to save my stack from my development programming session
> > >> but not from the session in which I am running the test application. I can
> > >> do this by setting a user defined @-variable in one or other of these
> > >> sessions
> > >> IF '@DEV' # '' THEN SAVE.STACK <<@LOGNAME>>
> > >> Or,........
> > >> The choices are endless.
Thanks to Ashley's comment, I was able to find the
> @COMMAND.STACK in the documentation. The docs says > that the @COMMAND.STACK contains the last 99 tcl commands. > Does this contain all of the stack or just the last 99.
Looks like we missed this when we made the stack size configurable. It is the entire stack.
Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB +44-(0)1604-709200
> Thanks to Ashley's comment, I was able to find the
> > @COMMAND.STACK in the documentation. The docs says
> > that the @COMMAND.STACK contains the last 99 tcl commands.
> > Does this contain all of the stack or just the last 99.
> Looks like we missed this when we made the stack size configurable. It is
> the entire stack.
> Martin Phillips
> Ladybridge Systems Ltd
> 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
> +44-(0)1604-709200
|
