- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: OpenVMS: UIC changes producing unexpected resu...
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
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
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
02-17-2017 11:03 AM
02-17-2017 11:03 AM
I'm a new poster here and have run into an quandry I've not been able to track down. We're doing a lot of tests on UIC to make sure certain COM's are run by a specific user. For years (litterally) it's been expecting [ORACLE] from this lexical statement: if f$getjpi ("","uic") .nes. "[ORACLE]" then it will resubmit the job through a batch queue under the Oracle user. Recently a change was made to the Oracle user that when this test occurs now, it fails even under the ORACLE account because the same test is returning [<name>,ORACLE]. Other than the UIC line in the account looking like this: [700,100] ([<name>,ORACLE]), when it should just be: [700,100] ([ORACLE]).
I've looked at several modifications that I thought may return the account to it's previous appearance, but to no avail. Any ideas on where I should look would be greatly appreciated.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-17-2017 11:34 AM
02-17-2017 11:34 AM
Re: OpenVMS: UIC changes producing unexpected results
I always found this confusing, so I know nothing, but my Web search
for:
openvms uic
did lead to this:
http://h41379.www4.hpe.com/doc/84final/ba554_90015/ch04s01.html
which my provide an explanation. To be sure, you might need to
investigate other members of group 700, and/or other [*,ORACLE] users.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-17-2017 11:57 AM
02-17-2017 11:57 AM
SolutionHi,
It seems if there is a rights identifier that names the UIC group, then it will display the [group,member] as a name, if there is only a rights id for the member then it shows it as [member]. If neither rights id is present, it will show the numbers.
For example, here:
UAF> SHOW ORACLE
Username: ORACLE Owner: ORACLE DB TEST
Account: ORACLE UIC: [277,100] ([ORA,ORACLE])
[...]
UAF> show/id ora
Name Value Attributes
ORA [000277,177777]
Note the 177777 as the member number, this means the entire group or "*".
UAF> show/id oracle
Name Value Attributes
ORACLE [000277,000100]
So to get back your old behavior, simply remove the group rights id, in my case ORA by saying:
UAF> REMOVE/ID ORA
It can always be re-created with:
UAF> ADD/ID/VALUE=UIC:[277,*] ORA
Regards,
Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-17-2017 01:37 PM
02-17-2017 01:37 PM
Re: OpenVMS: UIC changes producing unexpected results
Dave,
Thanks for the expanation and resolution! It has returned the behavior back to what was expected. We'll be watching the jobs for a few days to make sure they will resume properly.
And thanks to you Steven, that link is a wealth of information and to be honest was hard to keep my eyes open reading it. I'll have to space it out over a few days to absorb what I can.
Regards,
Patrick