[comp.os.vms] DECserver query

BRENT@uwovax.UWO.CDN.UUCP (06/12/87)

   We are thinking about getting DECservers (yes, I've queried
this one before, but not this aspect).  We also have a GANDALF
PACX, so the 200's are needed for modem control.  I've looked at
the User Guide, and frankly, the user can do too much to "his"
port, and leave it around for the next unsuspecting connection.
   I'd like to limit (or inhibit entirely) the following "user"
functionality:  LOCK, SET/DEFINE PORT PARITY/FLOW/CHARACTER,
and perhaps others, since it appears that these could get left
around.
   Am I misreading somethig?  Or are these concerns justified?
Thanks as always.  Brent.
--
Brent Sterner                            ***********************
Lord Protector,  d i g i t a l  Systems  *                     *
Computing & Communications Services      *      b r i n g      *
Natural Sciences Building                *       b a c k       *
The University of Western Ontario        *   the other 4 bits  *
London, Ontario, Canada  N6A 5B7         *                     *
Telephone (519)661-2151 x6036            ***********************
Network     <BRENT@uwovax.UWO.CDN>  ! VAX CLUSTER
            <A105@UWOCC1.BITNET>    ! IBM 4341 (last resort)

SYSMSH@ULKYVX.BITNET (06/14/87)

>   We are thinking about getting DECservers (yes, I've queried
>this one before, but not this aspect).  We also have a GANDALF
>PACX, so the 200's are needed for modem control.  I've looked at
>the User Guide, and frankly, the user can do too much to "his"
>port, and leave it around for the next unsuspecting connection.
>   I'd like to limit (or inhibit entirely) the following "user"
>functionality:  LOCK, SET/DEFINE PORT PARITY/FLOW/CHARACTER,
>and perhaps others, since it appears that these could get left
>around.

We've got several DECserver-200's connected to a terminal switch.  Modem
control is enabled.  I ran into the same problems with the DEFINE and
LOCK commands.  Users were able to alter the permanent characteristics
of any random port.  LOCK would also not clear out if the line was
dropped from the switch.  I was forced to disable LOCK and patch out
the DEFINE command in the PR801ENG.SYS file.  Thats about your only
option other than an SPR.  If you are interested in the technique
drop me a mail msg.  I allow the users to do SET commands because they
do clear out after the line drops.

Someday I'll submit an SPR for making DEFINE PORT an optionally privileged
command and making a LOCKED port unlock upon line drop.

Mark Hittinger/systems programmer iv/ocis south center
University of Louisville, Louisville, Ky 40292
sysmsh@ulkyvx.bitnet
sysmsh%ulkyvx.bitnet@wiscvm.wisc.edu

DHASKIN@CLARKU.BITNET (Denis W. Haskin, Manager, Technical Services) (06/16/87)

> Date:         Fri, 12 Jun 87 09:02:05 EST
> From:         Brent Sterner <BRENT@UWOVAX.UWO.CDN>
> Subject:      DECserver query
>
> We are thinking about getting DECservers (yes, I've queried this one
> before, but not this aspect).  We also have a GANDALF PACX, so the 200's
> are needed for modem control.  I've looked at the User Guide, and frankly,
> the user can do too much to "his" [you mean "his or her", right?] port, and
> leave it around for the next unsuspecting connection.

Well, we have DECserver 100s and 200s but we are not currently using the
200s for modem ports.  As local ports, a LOG command is sufficient to set
the port to wait for the next connection at *default* settings, and (unless
disabled) it will autobaud and stuff like that.  I don't know exactly how
they behave under modem control; when the connection is broken (that is,
carrier is dropped) my assumption would be that a LOGOUT would take
effect and the server would be back in its default state.

> I'd like to limit (or inhibit entirely) the following "user" functionality:
> LOCK, SET/DEFINE PORT PARITY/FLOW/CHARACTER, and perhaps others, since it
> appears that these could get left around.
You can do it;  I think it would DEF BREAK DISABLE (to disallow access
to the Local> prompt) and  DEF AUTOCONNECT or some such thing.  We've
done it here.


% Denis W. Haskin                             Manager, Technical Services %
% ----------------------------------------------------------------------- %
% DHASKIN@CLARKU.BITNET   Office of Information Systems     (617)793-7193 %
% Clark University               950 Main Street      Worcester MA  01610 %
%                                                                         %
% "Anyone who _moves_ before Most Holy comes back out will spend the rest %
%  of eternity sipping lava through an iron straw."        - Cerebus      %

AE@DAL.BITNET (Aidan Evans, Dalhousie University) (06/25/87)

 We have DECserver 200/MC's connected to a Develcon Develswitch.  Some of
the parameters set for each port include:

    Autobaud enabled, Autoconnect enabled, Autoprompt enabled,
    Inactivity logout enabled, Modem control enabled, Security enabled

In order to use the DEFINE command, or to SET a port other than the
one to which you are connected, or to SET certain port characteristics
(e.g., to disable security) you must have first entered a "SET
PRIVILEGE" command, which prompts for a password.  There is a
documented default password given in one of the manuals; that password
has of course been changed with a "SET PASSWORD" command on all the
servers.

 On our servers, a you can change characteristics of the port to which you
are currently connected; these changes disappear when you logout of the
port.  Logout from the port is NOT synonymous with logging out of VMS.
After VMS logout you are still connected through the Develswitch to the
server port.  So that our users don't have to remember to logout of the
server as well as VMS, we have set the server "inactivity timeout" to the
minimum allowed, so that after one minute of no activity at the "Local>"
prompt, and with no active terminal sessions, the server logs out the
port.

 As for the LOCK command, if a port is locked, disconnecting the terminal
from the Develswitch disconnects from the server, and the lock is
released.  This is useful if you have forgotten the lock password you
used.

 Of course nothing is perfect.  I have noticed that the "inactivity
logout" seems to be inconsistent.  Sometimes it takes a full minute, but
it does range downwards to 10 or 20 seconds, or sometimes immediately.
Actually, we would prefer to be able to specify the timeout in seconds; on
our Control Data CYBER you get ten seconds before "inactivity logout".