🚀 go-pugleaf

In article <9212181659.AA17811@relay1.UU.NET>, raxco!galaxy.dnet!gleeve@uunet.UU.NET 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: CARL@SOL1.GPS.CALTECH.EDU | 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.