DISKQUOTA error not allowing login

[Volker Halle]

Swain,

please have a look at chapter 2.10 in the DECwindows Motif V1.2-5 release notes. There is example code to be put info SYLOGIN to exit in case of DECwindows session manager logins:

http://www.itec.suny.edu/scsys/vms/ovmsdoc073/v73/6537/6537pro_007.html

Do other users log in via a DECwindows terminal as well ? Or do they login via TELNET ?

Volker.

[Volker Halle]

Swain,

also look at the code in SYLOGIN.COM. It seems to incur some kind of loop, as it is printing the same error over and over again.

Maybe some 'ON ERROR THEN...' going back in a loop ?!

Volker.

[Robert Gezelter]

Swain,

Ok. The RMS parameters, cluster size, and extend size are not unusual.

I agree with Hein and Volker. The problem lies in an INQUIRE command that is being executed.

- Bob Gezelter, http://www.rlgsc.com

[Swain]

$ type sys$manager:SYLOGIN.com
$!
$!
$ set noon
$ mode = f$mode()
$ tt_devname = f$trnlnm("TT")
$ session_mgr_login = (mode .eqs. "INTERACTIVE") .and. -
(f$locate("WSA",tt_devname) .ne. f$len(tt_devname))
$ session_detached_process = (mode .eqs. "INTERACTIVE") .and. -
(f$locate("MBA",tt_devname) .ne. f$len(tt_devname))
$ unknown_devtyp = (mode .eqs. "INTERACTIVE") .and. -
(f$getdvi("sys$command","devtype") .eq. 0)
$!
$ if (mode .eqs. "INTERACTIVE") .and. unknown_devtyp .and. .not. -
(session_mgr_login .or. session_detached_process)
$ then
$ SET TERMINAL/INQUIRE
$ endif
$!
$ if (mode .eqs. "INTERACTIVE") .and. .not. -
(session_mgr_login .or. session_detached_process)
$ then
$ SET CONTROL=T
$ endif
$!
$ IF f$getdvi ("sys$output:", "trm")
$ THEN
$ devnam = f$getdvi ("sys$output:", "devnam" ) - "_" - "_"
$ devnam = f$extract (0, 2, devnam)
$ if devnam .eqs. "WT" then goto skip_inquire
$ if devnam .eqs. "TW" then goto skip_inquire
$ if devnam .eqs. "FT" then goto skip_inquire
$ if devnam .eqs. "RT" then goto skip_inquire
$ set terminal/device=VT200/regis/insert
$ skip_inquire:
$ set terminal/insert
$ ENDIF
$!
$ if (mode .eqs. "INTERACTIVE") then set terminal /insert
$!
$ type sys$manager:notice.txt
$ @sys$manager:ams$setup.com
$!---------------------------------------------------------------------------
$! For Tektronix Netstation
$!---------------------------------------------------------------------------
$ @tek$tools:tek_sylogin.com
$!---------------------------------------------------------------------------
$! RS1 Related commands
$!---------------------------------------------------------------------------
$! define rsuserhome rs1home
$ @disk$applications:[rs1r4]rs1log.com
$ rs1ini :== @disk$applications:[rs1r4]rs1ini.com
$!---------------------------------------------------------------------------
$!
$ edt :== edit/edt
$ eve :== edit/tpu
$ home :== set default sys$login
$ login :== @sys$manager:sylogin.com
$
$!---------------------------------------------------------------------------
$! VAXLINK2 is for Reflection 4 connections
$!---------------------------------------------------------------------------
$ vaxlink2 :== $disk$tools:[reflections]vaxlink2
$!---------------------------------------------------------------------------
$ where :== show logical sys$node
$ who :== show user/full
$ wide :== set terminal/width=132
$ world :== set protection=(W:re)
$!
$ define/nolog qca$print1 postscript1
$!
$ exit

Please check.

Thanks,
Swain

[RBrown_1]

The easiest thing to do is turn on verify and see exactly what is causing the log file to fill up and then work backward from there.

At first glance I don't see anyting wrong with your SYLOGIN file, but there things I am not sure about. AND, this file calls other command files --- what do they do? Could they be causing the problem?

Hence my suggestion to enable VERIFY. Have fun.

[John Gillings]

Swain,

As Hein has pointed out, 6007 blocks is 2.9MB, worth about TWO HUNDREDTHS OF A CENT at current storage costs.

Why are you wasting yours and everyone elses time worrying about it?

Increase the quota and be done with it!

[Steven Schweda]

> Why are you wasting yours and everyone
> elses time worrying about it?

An RZ29B is not very large.

> Increase the quota and be done with it!

If one of the *LOGIN.COM procedures is stuck
in a loop, then giving it more space to fill
may not let anyone be done with anything.

> [...] That will eventually fill up any
> quota [...]

He's right, you know.

> [...] [Search for 'INQUIRE' in login.com
> returned no string.] [...]

LOGIN.COM can invoke other procedures. Did
you also search for "@"? Same for
SYLOGIN.COM. (I can see "@" in what you
posted.)

> [...] other command files [...]

He's right, you know.

Do other users have this problem, or only
this user? (All users suggests SYLOGIN.COM,
one user suggests (his) LOGIN.COM.)

[P Muralidhar Kini]

Hi Swain,

Put the "$SET VERIFY" command in the LOGIN procedure. This will log traces
for every command that gets executed in the command procedure. This should
help in debugging to find out the cause for the problem.

Also as already pointed out, the SYLOGIN procedure calls other command
procedure and we dont know what they are doing. You can use trial and error
method by commenting those command procedure one at a time and to check
if the problem occurs or not.
The best way ofcourse is to add a "$SET VERIFY" and check the traces logged.

i guess increasing the quota will only delay the occurrence of the problem
and may not solve the problem.

Is the problem also seen by other users in the system who does a login
in a similar way to ROLAND user?

Regards,
Murali

[Volker Halle]

Swain,

if you carefully look at the error message:

%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
\INQUIRE\

you'll find that this messages does NOT seem to to be issued by using the DCL $ INQUIRE command in non-interactive mode or by using SET TERMINAL/INQUIRE. The former will work and the latter will issue a message like:

...
$ set term/inq
%SET-W-NOTSET, error modifying DSA1:
-SET-E-INVDEV, device is invalid for requested operation

You'll need to find out, exactly WHICH command in which of the command files run during login for this user will cause this error. Include a couple of ' $ WRITE SYS$OUTPUT "now in xyz.COM"' inside those procedures. If you want to make this less irritating for your other users, use:

$ IF F$EDIT(f$getjpi("","USERNAME"),"TRIM") .EQS. "ROLAND" THEN $ WRITE SYS$OUTPUT ...

Volker.

[Robert Gezelter]

Swain,

Note that Volker's comment about tracing in SYLOGIN applies in a more global sense than merely tracing.

Since SYLOGIN is executed by every user, and indeed virtual every process that starts on an OpenVMS system (at least every process that has a CLI context), the correct way to enable VERIFY is to limit VERIFY mode to the individual user, to wit:

$ IF F$EDIT(f$getjpi("","USERNAME"),"TRIM") .EQS. "ROLAND" THEN $ SET VERIFY

Some discussion about modifying SYLOGIN, and the issues involved were the subject of the most recent installment "SYS$MANAGER:SYLOGIN.COM - Flexibility requires prudence" of The OpenVMS Consultant on OpenVMS.org (see http://www.openvms.org/stories.php?story=10/04/22/1564554 ).

- Bob Gezelter, http://www.rlgsc.com