DISKQUOTA error not allowing login

[Volker Halle]

Hein,

I was going along the same route ;-)

The error message seen does seem to come directly from DCL without an additional image being invoked. Otherwise you would get SYSTEM-F-NOPRIV as a secondary error message preceeded a message from the image or facility (e.g. RMS) itself.

Swain,

please turn on SET VERIFY in SYLOGIN.COM for this user ...

Volker.

[Volker Halle]

Swain,

please also see the following thread for a similar problem and a solution. That problem involved DECW$SM.LOG filling the disk, so you're lucky that you're using disk quotas !

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1351472

Volker.

[Swain]

I added following lines to SYLOGIN.COM

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

When ROLAND loggedin, the login was succesful but thrown following warning.

%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\AMS\

But this warning came for other users also and AMS did not work for anyone.

Since it's a critical application environment, I had to revert the changes in SYLOGIN.COM.

Please let me know of any alternative.

Thanks,
Swain

[Volker Halle]

Swain,

you should NOT have included

$ IF F$MODE() .EQS. "OTHER" THEN EXIT

Depending on the process environment, in which SYLOGIN is being used, this statement would EXIT your SYLOGIN and fail to invoke the necessary procedures for defining your AMS environment.

But what you've learned from this execerise is: the login problem of user ROLAND DOES depend on SYLOGIN.COM AND/OR some procedure it calls !

Please try again with just the line turning on SET VERIFY for user ROLAND.

Volker.

[Zeni B. Schleter]

I did say LOGIN.COM not SYLOGIN.COM just because users can put queries in the LOGIN.COM that are not friendly with detached processes. Your environment may not allow such usage.

[Swain]

Thank you all! It's a privilege being with you.

Looks like it works. I'll check with the user and confirm.

BTW, what about the terminal output that comes because of SET VERIFY. User must be scared of that. :)

Thanks,
Swain

[Volker Halle]

Swain,

are you saying, that by just enabling SET VERIFY for user ROLAND, that user can now login via DECwindows and doesn't get the %SYSTEM-F-NOPRIV message in DECW$SM.LOG anymore ?!

We suggested to enable SET VERIFY to actually find the DCL command, which causes this problem. Once you've found and solved the problem, you would of course turn off verification again.

So what else did you chagne to make it work ?

Volker.

[RBrown_1]

You ask: >>>>
BTW, what about the terminal output that comes because of SET VERIFY. User must be scared of that. :) <<<<

Once you have found and corrected the problem, you can remove SET VERIFY.

[P Muralidhar Kini]

Hi Swain,

>> $ IF F$MODE() .EQS. "OTHER" THEN EXIT
This may be one that is causing the AMS not to work.

The SET VERIFY is only a temporary change that you have to make.
It would remain only until you find out the root cause for the
problem, after that you must remove it from the command procedure.

>> Looks like it works. I'll check with the user and confirm.
Does this means that the problem is solved.
If yes, let us know what was the root cause for the problem.

Regards,
Murali

[Swain]

I am putting here the lines that produced the error.

! SYLOGIN.COM
$!
$ if (mode .eqs. "INTERACTIVE") then set terminal /insert
$ @sys$manager:ams$setup.com

contains
$!
$ ams :== @ams$code:[com]define_logicals.com

contains
$!
$ @ams$code:[sitecom]set_node_defaults.com 'P1' 'P2' 'P3' 'P4'

$!
$ exit

Log File:

$! DECW$SM.LOG
$!
Executing SYS$MANAGER:SYLOGIN
.
.
.
$ if (mode .eqs. "INTERACTIVE") then set terminal /insert
%SET-W-NOTSET, error modifying DKA0:
-SET-E-INVDEV, device is invalid for requested operation
.
.
.
$do_login:
$ write sys$output "Executing DISK$AS:[ROLAND]LOGIN.COM;"
Executing DISK$AS:[ROLAND]LOGIN.COM;
$ write sys$output ""

$ @DISK$AS:[ROLAND]LOGIN.COM;
$!
.
.
.
$!
$ AMS DEPOSIT
$ @ams$code:[sitecom]set_node_defaults.com DEPOSIT
$!
$!
$ if (f$search("sys$login:ams$define_logicals.com") .nes. "") then -
@sys$login:ams$define_logicals.com DEPOSIT
$!
$ if (P1 .eqs. "") then P1 := WATER
$get1: if (P1 .eqs. "COU") then P1 = "COUPONS"
$ if (P1 .eqs. "DEP") then P1 = "DEPOSITS"
$! if (P1 .eqs. "LEG") then P1 = "LEGIONELLA"
$ if (P1 .eqs. "RES") then P1 = "RESINS"
$ if (P1 .eqs. "WAT") then P1 = "WATER"
$!
$!
$!
$ if (P1 .nes. "COUPONS") .and. (P1 .nes. "DEPOSITS") .and. -
(P1 .nes. "OIL") .and. (P1 .nes. "RESINS") .and. -
(P1 .nes. "WATER")
$ then
$ if (P1 .eqs. "?")
$ endif
$!
$ inquire P1 "Enter application name (? for help)"
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
\INQUIRE\
$ goto get1


This loop keeps on repeating.

I think the line $ AMS DEPOSIT must be changed to
$ AMS DEP or $ AMS DEPOSITS

Is that correct?

Thanks,
Swain

P.S. User is still not able to login through exceed. It sticks on the starting blue screen.

[Volker Halle]

Swain,

noone said this is a trivial problem ;-)

You get into this endless loop, because INQUIRE fails with a NOPRIV error in this context (we still don't know why !) and this causes the procedure to loop back to label get1:

If parameter P1 would have been "DEP" or "DEPOSITS", you would not have got to that INQUIRE command, which fails. This should allow the procedure to continue.

If user ROLAND logs in via TELNET, will he be asked that question: "Enter application name (? for help)" ? If so, this procedure is just not written correctly for a DECwindows session manager login context ! Consider to add the commands to check for DECwindows context (referenced earlier) into this procedure.

And the LOGIN.COM for user ROLAND probably contains the wrong command: $ AMS DEPOSIT instead of $ AMS DEP or $ AMS DEPOSITS.

So this is a good example: you really need at least two errors for an easy problem to become a 'real problem'...

Volker.

[Robert Gezelter]

Swain,

I concur with Volker, with one reservation. Changing the parameter will certainly eliminate the INQUIRE, but a thorough understanding of the applications environment is needed to understand whether this is indeed the correct path.

Secondly, the IF MODE.eqs. "INTERACTIVE" that is failing in SYLOGIN should be corrected also. At a minimum, it should probably read as F$MODE() .EQS. "INTERACTIVE".

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

[P Muralidhar Kini]

Hi Swain,

>> $ if (mode .eqs. "INTERACTIVE") then set terminal /insert
>> %SET-W-NOTSET, error modifying DKA0:
>> -SET-E-INVDEV, device is invalid for requested operation
The above error message is generally issued when you execute the
"$SET TERM" command from a non interactive mode.

To solve this
Either
you should have
$mode = F$MODE()
before the above IF statement
or
use the F$MODE itself in the IF statement

>> I think the line $ AMS DEPOSIT must be changed to
>> $ AMS DEP or $ AMS DEPOSITS
Yes thats right.
But as Robert has mentioned, you should throughly analyze the environment
before you make the changes.

How about for other users, what are they passing in as P1 parameter.
They should be passing P1 value that falls in the set of expected values
and hence the problem is not seen for them i guess.

Is P1 value taken from the user in any scenario?
If yes then, if the P1 value given by user does not match any of the
expected value then the com procedure should handle this error
appropriately in case of non interactive mode
(i.e. using means other than INQUIRE command for non interactive mode)

Regards,
Murali

[Swain]

Adding a $ VERIFY = 'F$VERIFY(0) to ROLAND's login.com helped for DEcwindows terminal.

Thank you all for the great help!

Thanks,
Swain

[Swain]

Closing this thread.

Swain