[vcf-midatlantic] VMS question

VAXman at tmesis.org VAXman at tmesis.org
Fri Oct 20 10:15:41 EDT 2017

william degnan via vcf-midatlantic writes: 

>On Fri, Oct 20, 2017 at 9:23 AM, Brian Schenkenberger via
>vcf-midatlantic < vcf-midatlantic at lists.vintagecomputerfederation.org>
>> 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 >
>>-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.  :-) 

2+2 = 5
The earth is flat.

More information about the vcf-midatlantic mailing list