SET UIC

[Manny DeAssis]

The SET UIC command has been undocumented/unsupported for a few versions now. It still works however. We have a procedure that changes UIC and group logical name table (matching). Anyone know of another way to accomplish the same thing?

-md

[Arch_Muthiah]

Manny,

set uic wasn't documented in 6.2 online help. The doc says it is obsolete V7.1 onwards, but it works on my 7.1.

We can use ACL to do most of access and security related work inplace of SET UIC.

Archunan

[Arch_Muthiah]

Manny,

There would a program called JUMP in our freeware CDs, can be used to change UIC.

see this "Ask the wizard" tells about SET UIC.
http://h71000.www7.hp.com/wizard/wiz_2508.html


Archunan

[John Gillings]

Manny,

Well, I guess that depends on your definition of "works".

The trouble with SET UIC is it doesn't do what you think it does (and that's pretty much independent of what you think it does!). I would strongly discourage you from using SET UIC at all.

The software context of a process is a very complex collection of data structures. SET UIC changes a tiny part of it. The group table is another small part, but getting it all right is very tricky and highly version dependent (many system crashes from programs that attempt to implement it).

If you want to change usernames the safest way is to login a whole new process. SET HOST 0 is by far the simplest. From a privileged process there are numerous other ways to do this without necessarily having to enter a password. Exactly how depends on what you're trying to achieve.

[Jess Goodman]

Sorry to disagree, but I use SET UIC all the time interactively and it does exactly what I think it does.

When I need to look at (SHOW PROCESS), modify (SET PROCESS), or STOP [/IMAGE] some process I find it is easier to first do SET UIC [target process group] so I can then just use the process name with the DCL command.

I find the alternative (first doing SHOW SYSTEM/PROCESS=name, and then using the PID displayed with the /ID=pid qualifier) is clumsy, espescially if I'm using a dumb terminal as a console and can't cut and paste.

I do try to always remember to SET UIC back to my [group,member] but even when I forget to do this I haven't caused any problems.

[Jan van den Ende]

John,

I am all with Jess on this.

We are running a vital app, third-party written using Progress stuff (you know, one of those Database + utilities providers that left VMS due to lack of marketing).
The database of course uses (U*x style) ONE single process to communicate with the database, all user processes communicate with this process.
Making things more complex, the app communicates with several external databases, yes, also via a communication server process (one per external db).

And now for the big fun: setting up external communication control is by locking.
- communication startup is by requesting an EXCLUSIVE lock; using default parameters, ie: Clusterwide, grouplevel.
- User processes start by requesting this lock.
- If it is granted, there in no communication server, so an error message is issued and the program stops.
- If the lock is refused, the comm proc is running, so the process can continue.
Trying to start on another node in the cluster, the process continues, then hangs in waiting for the communication to answer (which is never).
BTW: the max number of channels (per node) is less than required at our site. Yes, limited by the Progress supplied code.

So: ALL users running this app MUST be members of the same UIC group to "see" the lock! But: max number of chanels? Solution: run the app on more nodes. Yeah, but the locks are cluster-wide, so each node must use a different UIC group.
How about a cluster-common authorisation file? How about node-tranparncy across the cluster? How about putting 8000+ users all in one UIC group?

The way around this for us was....
SET UIC
combined with
- logical names define WHICH UIC group on WHICH node.
- keep MEMBER UICs unique
make a little command procedure (ACL protected) that does consistency checks, and then SET PROC/PRIV=CMK & SET UIC
- make a small image that translates the EXECmode LNM of said procedure, and spawns the result of the tranlation
- install that image with CMKRNL.

Took more than it looks from this description to find out the details (WITHOUT documentation!) and cook up all this, but all in all, it has served us rather well for years now, and I have not yet been able to find security holes that compare to the also-used practise of just (from the app startup script) SET HOST 0 using a per-node use-by-all, no-password account!

In short: I would not like to see SET UIC go as long as this app is used!

fwiw,

Proost.

Have one on me (maybe in May in Nashua?)

jpe

[Ian Miller.]

What are you doing that uses SET UIC ?

To create a group logical name I usually use

$ RUN/DET/UIC=[g,0] SYS$SYSTEM:LOGINOUT.EXE

to create the group table then

$ DEFINE/TABLE=LNM$GROUP_nnnnnn name value

where nnnnnn is the group number (must be 6 digits) to add logical names.

Sometimes I just submit a batch job using a username in the correct group.

The persona system services are worth investigating also.

[Jan van den Ende]

Ian,


What are you doing that uses SET UIC ?


Read above.


-- RUN /DETACH/ UIC requires mighty privs, requiring at least something like the trick above

-- switching GROUP logical name table does NOT do the trick ( but A common table is required, which might as well be the group table)
-- PERSONA is only available from WITHIN an image, and (by design) becomes void upon image exit. Pretty much useless if there is NO WAY of access to, let alone modifiying, the source code.

I (as in: we) will stick to the scheme above until demonstrated a superior mechanism.
Much more likely: until replaced by a replacement app under U*X. (scheduled for mid-1998, then summer 2000, spring 2001, end-year 2001... under Tru64. Latest schedule I know of: autumn 2006 under Solaris.
(and YES, that implies another customer intending to leave HP as soon as feasable. Loss of trust and such...)

Proost.

Have one on me (perhaps in May in Nashua?)

jpe

[Richard J Maher]

Hi,

I think the short answer to this is if $SET UIC made it to itanium then the best opportunity to get rid of it has come and gone. So if it works for you then IMHO just keep using it.

Having said that, the talk of personae got me interested, but I just haven't been able to find the time to properly investigate a couple of options: -

1) Rundown looks like it assumes the natural persona before calling your kernel mode rundown routines so, presumably, you could set it back again?

Highly unlikely to be supported even if it did work 'cos VMS expects the natural persona to be in force from then on. (Accounting etc)

2) Why not just $persona_modify the natural persona? Doesn't seen to be permanent all though I haven't given up all hope.

I've looked up the code for exe$persona_modify and nsa$modify_persona but can't find the processing for items like iss$_username. If the person's permanent how does one make the changes permanent iss$_flags? psb$m_permanent?

I can't see where rundown resets it either. Needs more than just a quick look.

3) In my travels through the source code I came across an alluring little minx of a routine called nsa$set_natural_persona that does exactly what you want (and the comments just make you want it even more :-)

But you'd have to do some sort of auditing and what about accounting and ownership of the job logical name table and what are you actually trying to achieve in the first place?

4) Maybe an across the board DCL qualifier interface to iss$c_id_image_persona is what you're looking for? Create "n" number of DCL personae and be able to evoke them for any command?

Anyway stick with SET UIC for whatever you're using it for. (But! If they ever do get rid of it :-)

Regards Richard Maher

[Joseph Huber_1]

Apropos PERSONA services:
have a look at Lyle Wests persona programs (at http://www.process.com/openvms , search for PERSONA).