[vcf-midatlantic] VMS question
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
> 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.
> >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
> 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. :-)
More information about the vcf-midatlantic