[vcf-midatlantic] VMS question

william degnan billdegnan at gmail.com
Fri Oct 20 09:56:52 EDT 2017


On Fri, Oct 20, 2017 at 9:23 AM, Brian Schenkenberger via vcf-midatlantic <
vcf-midatlantic at lists.vintagecomputerfederation.org> wrote:

> william degnan via vcf-midatlantic writes:
>
> >I noticed when I logged in today a file / info dump printed to the
> >screen but when I logged out and in again it was gone.  Perhaps that's
> >what you're talking about?
> >
> >Understand that I did not write SYSLOGIN.COM or any of this
> >configuration ... I would not have imagined someone would have a messed
> >up SYSLOGIN.COM to cause the issue you described.  There may be another
> >explanation.
>
> No, that's the only explanation.  Poorly written DCL logic and a really
> stupid premise too.  When somebody logs into VMS, they are granted the
> privileges defined in the UAF record.  They then execute ALL subsequent
> DCL with the persona (privileges, rights, UIC, etc.) defined in the UAF
> record.  There's no way to elevate privileges via ANY DCL command!  The
> author of that SYLOGIN seemed to believe otherwise.
>
>
>
OK.


>
> >I am trying to "take over" from where they guy that set this machine up
> >left off  and learn how this particular server was set up and why.  I
> >want to fix, but I also know System administration tends to reflect the
> >personality of the admin, people have reasons for things.  I am making
> >the assumption that given this was a production system there must be
> >some reasons for things.  Eventually I can try to improve.
>
> Never make assumptions!!!  I have seen more systems in production in my
> career that look like they were managed and or configured by brain-dead
> chimps.  I see people that when told "don't do this" will "do this" and
> then, contact me and want their error corrected.  I tell them "you did
> what I told you not to do" and "don't do it again!"  Guess what?  They
> do it again and again and again.
>
>
That I know, but I am learning a whole new OS and even if it's not the best
way it's the way it is now, learning why something is the way it is helps
me to learn.


>
> >When I log in using Evan's account, I can get in but I have a disk quota
> >exceeded error when I try to generate an email message.
> >
> >MAIL> mail To:     SMTP%"evan at snarc.net" Subj:   VAX USERN/PASS
> >%MAIL-E-OPENOUT, error opening
> >COBK$DATA:[COBK.PERSONAL.EKOBLENTZ]MAIL_0128_SEND .TMP; as output
> >-RMS-E-CRE, ACP file create failed -SYSTEM-F-EXDISKQUOTA, disk quota
> >exceeded
>
> The disk that his account has been assign to IS the system disk.  If
> you look, it's very verly low on disk space.  If I were you, I'd move
> his account and any other user accounts (save SYSTEM, FIELD, SYSTEST)
> OFF OF THE SYSTEM volume.
>
>
I have a new disk I am preparing to use, agreed.



>
> Personally, if you really are hell bent on keeping the system as it
> was delivered, I'd suggest you backup all the volumes and then, init
> and start from stratch.  Then, once you know how it all works, you
> can go back and see what a mess the prior system's owner(s) left you.
>


There is a historic angle here, I get your points though.  Logical.

I see now I never set up the disk quota, doing that now.   It's all a
learning process.  One thing about me, I am pretty good to remember once I
make a mistake/crash something is sometimes how I learn.  So I trash an old
VMS box, I can always start from scratch.  It's not a job.

I see now that the operator of this box probably was not fully trained,
makes it less valuable as a learning tool, why learn on a poorly configured
VAX, but I also have nothing to loose.  :-)

Bill



More information about the vcf-midatlantic mailing list