Error accessing authorization file

[Willem Grooters]

I agree you should find out why it's needed in the first place. If you need to reset security, it's always too late.

Preventing interactive users to login, set logins to zero. To prevent batch procedures to login, set queues on hold (STOP/NEXT). To prevent network users to login, disable services that can be accessed (thou that may cause severe problems outside).

To prevent login errors, you might think of this method (I _know_ it's not perfect at all and may have caveats, but it'sa way to get around it):

$ BACKUP/IGNORE=INTERLOCK SYSUAF.DAT SYSUAF1.DAT
$ BACKUP/IGNORE=INTERLOCK RIGHTSLIST.DAT RIGHTSLIST11.DAT
$ SET FILE/PROT=(W:RWED) SYSUAF1.DAT
$ OldUAF = F$TRNLNM("SYSUAF","LNM$SYSTEM")
$ OldRL = F$TRNLNM("RIGHTSLIST","LNM$SYSTEM")
$ DEFINE/SYSTEM/EXEC SYSUAF SYSUAF1.DAT

do your job on SYSUAF.DAT and RIGHTSLIST.DAT

$ IF OldUAF .NES. ""
$ THEN
$ DEFINE/SYSTEM/EXEC SYSUAF 'OldUAF'
$ ELSE
$ DEASSIGN/SYSTEM/EXEC SYSUAF
$ ENDIF
$ IF OldRL .NES. ""
$ THEN
$ DEFINE/SYSTEM/EXEC RIGHTSLIST 'OldRL'
$ ELSE
$ DEASSIGN/SYSTEM/EXEC RIGHTSLIST
$ ENDIF
$ DELETE SYSUAF1.DAT;*
$ DELETE RIGHTSLIST1.DAT;*

You will certianly loose information about logins during the transition period, and usage of AUTHORIZE should be prevented (or disabled); you'll have to decide whether that is a problem or not.

[Wim Van den Wyngaert]

Willem,

That is a problem for SOX. No go.

Wim

[An Vercammen]

Strange, today, I have this error for the first time as well! At least 3 batch jobs failed to start this morning, with "LOGIN-F-FILEACC, error accessing system authorization file." , seen in accounting.
As far as I know, we do not change the security on the sysuaf.dat.
The only job that opens the file is QUEUE_MANAGER at the moment.

Other batch jobs ran OK.

What else can cause this confict?

[Volker Halle]

An,

check OPERATOR.LOG or the OpenVMS console (OPA0:) for any unusual errors seen at the time of this failure.

Volker.

[An Vercammen]

No errors at all in the Operator.log.

Some batch jobs still fail to start at the moment, some start OK.
Some failed jobs can be started afterwards, and vice versa, but they all use the same account.

Can I find out who locks the SYSUAF, if it is a lock at all...

[Wim Van den Wyngaert]

And check in accounting if you can the one who did it.

Wim

[Wim Van den Wyngaert]

Analogue problem today. During the set file/prot a f$sea was done on one of the files. As a result the f$sea returned "".

I will remove the set file/prot.

Wim

[John Gillings]

>Analogue problem today. During the set
>file/prot a f$sea was done on one of the
>files. As a result the f$sea returned "".

Huh? This must be something else entirely.

F$SEARCH does NOT require any kind of access to the target file. It can't be blocked by FLK, FILEACC or PRV. The only access that's required is R (or even E) to the containing directory tree. The file itself can be ACCESS=NONE, you can still search for it and determine its name.

Try it yourself...

[Wim Van den Wyngaert]

I tried 2 batch jobs : 1 doing set file/prot/own of the directroy and 1 job doing f$sea of the file (and a reset of the f$sea). Both in a loop.

As soon as I started the set file/prot job, the f$sea job aborted (f$sea returning "").

Wim

[John Gillings]

Wim,

>1 doing set file/prot/own of the
>directroy and 1 job doing f$sea of
>the file

Just to make sure we're 100% clear here...

Can you confirm that SET FILE/PROT and F$SEARCH of THE SAME FILE do NOT clash?

It's only a SET FILE/PROT of the DIRECTORY CONTAINING the target file of the F$SEARCH which causes trouble?

If so, that confirms what I said in my previous post, but it's NOT the same as your claim: "During the set file/prot a f$sea was done on one of the files. As a result the f$sea returned ""."

As I said F$SEARCH does not require any access to the target file, but it does require access to the enclosing directories.