Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

System services in an UWSS

Go to solution
Oscar van Eijk
Occasional Advisor

System services in an UWSS

Hi All,

A while ago I asked how I could dynamically change identifiers (granted with ATTRIB=DYNAMIC) in a program written in C (thread: http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1193355).

I decided to create an UWSS for it, with a different solution for on VAX (simply no disabling at login time; on VAX it's used only very incidentally :)

Now my problem is, in this UWSS I make several system service calls (SYS$GETJPIW, SYS$FIND_HOLDER, SYS$ASCTOID, SYS$GRANTID and SYS$REVOKID), but this results in:

%DCL-W-ACTIMAGE, error activating image SECURESHRP
-SYSTEM-F-NOSHRIMG, privileged shareable image cannot have outbound calls

I can do without the SYS$ASCTOID, but the others happen to provide the main functionality of my service :-S

Is my approach an option at all, or am I doing something really stupid? Perhaps something in between....

Thnx in advance,
Jur van der Burg
Respected Contributor

Re: System services in an UWSS

A UWSS is, like its name says, a system service and thus it runs in kernel mode. So there are restrictions, like calling an external image like secureshrp that contains some services like the ones you are calling.

Why a UWSS? This is something I would use from a sharable image instead.

Richard J Maher
Trusted Contributor

Re: System services in an UWSS

Personally, I don't see and [K]ernel in U.W.S.S.

If you're creating an Exec mode UWSS then it executes in Exec mode.

"Simply" drop the /protect on the link and you're away. Obviously you can't create a Kernel mode UWSS and ask it to use RMS, and for definitions of "simply" you should search this (sadly edited) forum and comp.os.vms. Here's one example: -


Cheers Richard Maher
Honored Contributor

Re: System services in an UWSS

The UWSS privileged shareable image construct is fairly weak as OpenVMS programming mechanisms go and something that probably didn't work out nearly as well as its designers had intended, and it can have its own specific risks. I prefer to avoid it.

There are a few folks around that find the UWSS interface valuable and that do use it, and find it valuable. I've encountered far too much pain with it to use it (lightly), though I have used it on a very few occasions. There are often better solutions.

The easiest here is probably to install the main image with the requisite privileges.

Somewhat different, but entirely functional, is to implement and use a subsystem identifier. This allows the application to grant an identifier, which can then be used to control access (directly, or possibly paired with another identifier) using an ACL on the target file(s) or other of the target objects.

Or launch an installed image as a subprocess and pass over or command. Or use DECnet task-to-task to launch a server process... In either case, the installed (executable) can call

If you do want to use the UWSS construction, absolutely everything involved in the outbound call must be installed protected or you'll get the NOSHRIMG message. And what you're calling needs to work correctly from inner-mode environments.

Part of the inherent "fun" of creating and maintaining and securing a UWSS is that a UWSS is privileged-mode code; the code is fully privileged because it is executing in an executive or kernel-mode environment, not because the code has privileges. And inner-mode code has its coding requirements, lest a security hole be created. It's this that is at the core of the NOSHRIMG check.

Poke around on the 'net NOSHRIMG topics and you should easily find some of my previous postings on this topic. Caution: you will encounter various (and potentially NSFW) responses to some my previous postings on this topic.

Stephen Hoffman
HoffmanLabs LLC.
John Gillings
Honored Contributor

Re: System services in an UWSS


You can call system services from a UWSS. The trouble here is some of the routines you're trying to call aren't "real" system services! SECURESHRP is effectively another UWSS containing routines:


So, it's $FIND_HOLDER that's causing you trouble.

If you want to persue the UWSS path, try hard coding a test case for whatever $FIND_HOLDER is doing for you and see if everything else works. Maybe you can make assumptions to skip that step? Otherwise, get hold of the sources and see what it's doing to see if you can reimplement it (more than likely it has to do with privileged access to SYSUAF).
A crucible of informative mistakes
Oscar van Eijk
Occasional Advisor

Re: System services in an UWSS

Thanks for your answers!
Some of the suggestions where also given in the thread I referred to; for now I don't see an other practical solution.

But in the service I wrote was simply too much code (I tried it all in one module); moving everything (but the $GRANTID an $REVOKID) to a seperate module which is part of the main program, seems to do the trick!