| The most basic problem is that in a DECwindows environment, you are not logging
into a command line environment; there is no character cell terminal.
However, for various reasons, there is a DCL CLI loaded in the initial process
created, and for some of the same reasons, the login command file is invoked
while logging in. Basically DCL is useful because it is readily tailored to
the needs of the moment whether they be debugging, or special case code. So,
the login command file provides the user with the ability to be involved in
the startup of the windowing environment.
What this processing would be, and for what purpose it would be used, wasn't
clear. It was especially unclear what it meant to login to a captive windowing
environment. Over time it has become more clear and in the next major
DECwindows release, some specific hooks will be provided to help create
the kind of environment that this customer has created on a character cell
terminal using a captive DCL proceedure.
Now, the specific problem is this. Since there is no character cell terminal,
the login command file is running without a `sys$command'; the read/prompt
command is attempting to read from an output file. This fails and the command
procedure exits. Since the account is captive, as soon as the login command
procedure terminates, the process is logged out.
What to do for you customer is not clear, and then, how to do it is murkier.
What does the customer expect to happen. Is the VT1200 being used merely as
a more expensive and slower VT320? Is all that is expected is for a terminal
window to be created and then the menu to come up? Or is there an expectation
that somehow the user will see a `wimp' interface to their specific procedures?
(wimp -> window, icon, mouse, pointer).
|
| Thanks for your explanation as to why our login doesn't work.
The most important thing to the customer is that all of these users
are kept in a captive environment. They should never see the $ prompt.
The VT1000's will be used by several hundred users who will want to have
an ALL-IN-1 session (window) up, along with 3-4 other applications in
different windows. So they do want a "wimp" interface.
We're in a real bind, because the first shipment of VT1000's has
arrived and they are refusing to accept delivery until this problem is
resolved.
I have never used DECwindows, but I'm getting a VT1000 today so I can
start understanding how it all works. Couldn't we add MAIN MENU as an
option under session or terminal manager -- and have that execute their
main menu dcl program that brings up the options for applications? If
we did this, could we take away any othr access to DCL they may have
from session or terminal manager?
I need some help here -- it's becoming a major sales issue and I'm not
knowledgeable enough on the product to know what our options are.
When will the next release be out with the "hooks" you spoke of?
Thanks for any futher help.
Linda
|
| Re: 3649.0
Linda and I think we have come up with a solution for our problem
with the READ/PROMPT problem. It turns out that this is another
variation on the captive account theme, discussed at length in
various notes.
The customer has a DCL command procedure that gets run for every
user on the cluster. This displays a menu containing all the commands
that the user is allowed to enter. Example commands are All-In-1,
the Phone utility, and some customer written programs. The purpose
for buying the VT1000 series terminals was to allow the user to select
All-In-1 and have it come up in a separate window, then to select
Phone and have it come up in a separate window, etc. Then the user
could use the wimp interface (defined .1) to manage the windows on
the screen.
The solution that we have come up with is this. The user connects
to the cluster using a LAT Terminal Window (Not the LAT X session),
which will log into his captive account and run the DCL command
procedure as expected. We modified the command procedure at the
point where it tries to run All-In-1 as follows:
$ LAT_ADDRESS == F$GETDVI("TT","TT_ACCPORNAM")
$ IF F$EXTRACT(0,10,LAT_ADDRESS) .EQS. "LAT_08002B"
$ THEN
$ SET DISPLAY/CREATE/NODE='LAT_ADDRESS'/TRANS=LAT
$ CREATE/TERM/NOWAIT @COMMON_USER:START_ALLIN1.COM
$ ELSE
$ @COMMON_USER:START_ALLIN1.COM
$ ENDIF
For a VT1000 series terminal, f$getdvi("TT","TT_ACCPORNAM") returns
the LAT host name, ie "LAT_08002Bnnnnnn". We then use this to set
up the DECwindows display, and then create a DECterm to run the
program. This has worked fine in all of our tests so far...
A couple of questions though... The LAT X option still exists on
the create menu for the terminal manager. Is it possible to keep
users from using this to get into the system?
Second, there are workstation users who would also like to use the
above solution when accessing the cluster. In other words, set host
to the cluster and have it set display back to the workstation for
the CREATE/TERM command. Are there lexicals similar to the above
that would allow me to set up the workstation the same way as the
VT1000?
If we could get these two questions answered, I think we could put
this one to bed.
Thanks in advance,
Tim Kaschinske
|