- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Error accessing authorization file
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-07-2007 01:30 AM
тАО12-07-2007 01:30 AM
Re: Error accessing authorization file
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.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-07-2007 01:53 AM
тАО12-07-2007 01:53 AM
Re: Error accessing authorization file
That is a problem for SOX. No go.
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-10-2007 04:48 AM
тАО12-10-2007 04:48 AM
Re: Error accessing authorization file
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-10-2007 04:56 AM
тАО12-10-2007 04:56 AM
Re: Error accessing authorization file
check OPERATOR.LOG or the OpenVMS console (OPA0:) for any unusual errors seen at the time of this failure.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-10-2007 05:01 AM
тАО12-10-2007 05:01 AM
Re: Error accessing authorization file
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-10-2007 05:01 AM
тАО12-10-2007 05:01 AM
Re: Error accessing authorization file
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-06-2008 11:08 PM
тАО01-06-2008 11:08 PM
Re: Error accessing authorization file
I will remove the set file/prot.
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-07-2008 05:27 PM
тАО01-07-2008 05:27 PM
Re: Error accessing authorization file
>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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-07-2008 11:14 PM
тАО01-07-2008 11:14 PM
Re: Error accessing authorization file
As soon as I started the set file/prot job, the f$sea job aborted (f$sea returning "").
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2008 04:29 PM
тАО01-09-2008 04:29 PM
Re: Error accessing authorization file
>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.