NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/vmsnet/internal/1705

Internet Message Format | 1992-12-21 | 3.5 KB

Path: sparky!uunet!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
From: [e-mail] (Carl J Lydick)
Newsgroups: vmsnet.internals
Subject: Re: call for half baked ideas
Date: 19 Dec 1992 11:14:58 GMT
Organization: HST Wide Field/Planetary Camera
Lines: 66
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <[e-mail]>, raxco!galaxy.dnet![e-mail] writes:
>3. Access monitoring needs to be reconsidered. The ACLs we have in
>VMS are very nice, but if you think a bit you conclude that there
>are many more questions you can ask about whether person A should be
>able to access object/file B. For starters consider things like
>login terminal checks in unix,

You CAN do login terminal checks under VMS.  It's not that hard.  Here's one
strategy:
    Have an image invoked by SYS$SYLOGIN: that:
    1)  Checks to see if a certain JOB logical has been defined;  if it
        has, exit;
    2)  Defines the aforementioned logical name;
    3)  Grants identifiers, based on a database.
Now, of course, given the way LOGINOUT currently works, you've got a potential
problem with a user who logs in, DISCONNECTs, and logs in again from elsewhere,
and I'd like to see an option to have LOGINOUT:
    1)  Do a $FORCEX; and
    2)  Run a special procedure (e.g., SYS$CONNECT:)
when a user logs in and connects to a disconnected process.

>or file passwords in MVS as asking

This sort of functionality is sort of available by encrypting files.

>additional questions like "where's this user coming from now?"

See my comments about the enhancements I'd like on LOGINOUT.EXE.

>"Can I be EXTRA sure he is who I think he is?".

Encryption, again, can do this.
>
>4. For sequential file access, users should have something as easy
>to use as the TOPS-10 open/read/write/close services.

Why don't you think RMS is easy to use?  The only time I can think of where I/O
at the $QIO level gets cumbersome is for disk files, and in those cases, I can
almost always use RMS with the FAB$M_UFO bit set to accomplish what I want.
Yes, it takes a bit of practice to learn how to use it, but once you're used to
it, it's really not all that cumbersome.

>I approve of
>having a standard ISAM facility and so on, but would like a
>smaller facility and would prefer to usually have and need no metadata
>in my files, as variable record length has now.

Learn to $CREATE your files as stream files.  It's NOT that difficult.

>(This would also get
>rid of some of the artifacts like 32767-byte maximum record size
>which we now have.)

You think so?  How is RMS (or its equivalent) to know how large a record it
might be dealing with?  For that matter, there's no real reason (except for
overhead) that RMS couldn't be modified to use a longword for record length
instead of a word, when dealing with files that don't have variable-length
records.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: [e-mail] | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.