OpenVMS Install Utility (INSTALL)

[Eric_369]

Greetings,
I am using the INSTALL command to create known file entries for my executables; however, I am not familiar with all the switches associated with the ADD/CREATE option. The switches in question are '/EXECUTE_ONLY', '/HEADER_RESIDENT',
'/OPEN', '/PROTECTED', '/SHARED', '/WRITABLE',
and others that I am hoping to get further explanation regarding. I am reading the OpenVMS System Management Utilities Reference Manual and don't understand what the terminology means. For example, the documentation defines using the '/OPEN' switch as, "Installs the file as a permenantly open know image." So, if I used the command, '$INSTALL CREATE/OPEN XXX.EXE,' what does it mean that the file 'XXX.EXE' is installed: 1)Permenantly, 2)Open, and 3)Known. Any help would be greatly appreciated. Also, is there any OpenVMS documentation that further explains the Install Utility (INSTALL)
Eric

[Ian McKerracher_1 · Accepted solution]

Hello Eric,

An excellent description of the INSTALL utility and its qualifiers can be found in the OpenVMS System Manager's Manual Volume 2. Have a look at the section in chapter 3 called "Using INSTALL to Install Known Images" (I'm using the v7.3-2 documentation set). You can also find interesting information dotted around the OpenVMS Linker Utility Manual.

Regards,

Ian

[Himanshu_3]

Hi Eric,

Explanation of all the switched goes as below

Header resident
The header of the image file (native images only) remains permanently resident, saving one disk I/O operation per file access. For images with single-block file headers, the cost is less than 512 bytes of paged dynamic memory per file; for images with multiblock headers, the cost varies according to the header block count. Images installed header resident are implicitly installed permanently open.

/[NO]HEADER_RESIDENT
Permanently open

The image file remains open, so access to the image does not require a call to the file system.

/OPEN
Privileged

Amplified privileges are temporarily assigned to any process running the image, permitting the process to exceed its user authorization file (UAF) privilege restrictions during execution of the image. In this way, users with normal privileges can run programs that require higher-than-normal privileges. This attribute (and the
/PRIVILEGED qualifier that creates it) applies only to executable images. /PRIVILEGED[=(priv-name[,...])]

Protected

When the image is activated, the address space for the image is protected against modification by user-mode code. This is critical for shareable code that runs in kernel or executive mode.
/PROTECTED

++ Resident

On Alpha systems, code or read-only data for an image is made permanently resident in a system region of memory. This improves performance by using a special page mapping to reduce translation buffer (TB) miss rates. The resident attribute applies to shareable or executable images that have been linked with the qualifier

/SECTION_BINDING=(CODE,DATA).

Shared More than one user can access the read-only and non-copy-on-reference read/write sections of the image concurrently, so that only one copy of those sections needs to be in physical memory. (Copy-on-reference sections always require a separate copy for each process.) The image is implicitly declared permanently open.

/SHARED

Writable

When a shareable non-copy-on-reference writable section is removed from physical memory (for paging reasons or because no processes are referencing it), it is written back to the image file. Any updates made by processes mapped to the section, therefore, are preserved (while the initial values are lost). The image must also be declared shareable.

/WRITABLE

Hoipe it helps.

Regards,
Himanshu

[Ian Miller.]

http://h71000.www7.hp.com/doc/82FINAL/aa-pv5nj-tk/00/00/49-con.html

[John Gillings]

Eric,

INSTALL can do many things. Which qualifiers you use depends on your objectives. Think of INSTALL as being like adding your own software to the operating system. This is a very powerful function, but it can also be dangerous. Think about what you're really trying to do.

1) (simplest) INSTALL a shareable image so it's "trusted". No qualifiers are necessary, but /OPEN/HEADER/SHARED probably won't hurt and may help.

why? /OPEN means OpenVMS has opened the file, so your processes don't need to. /HEADER means the contents of the header are read into physical memory, so you don't need a disk I/O to read them. /SHARED means any shareable, readable image sections will be placed into a global section, so they are physically shared by all processes accessing the image. Add /EXECUTE_ONLY to prevent processes from being able to read the code. This blocks debugging and reverse engineering.

2) INSTALL an exeecutable or shareable image for performance - use /OPEN/HEADER/SHARED.

why? this will reduce processing to open the file and, because the memory is physically shared, you can save memory. You can go a further step and add /RESIDENT to move the entire image into non-paged memory. This will eliminate all disk I/O associated with this image, but the program needs to be linked specially, and you may need to adjust some SYSGEN parameters.

3) INSTALL an image to physically share read/write memory. Use /OPEN/HEAD/SHARE/WRIT

why - this makes global shareable writeable image sections physically shared. You need to have written and linked the program specifically to do this.

4) INSTALL an executable image so that it has privilege when it runs, use /PRIV or /AUTHPRIV.

why? - to grant privilege to an executable image when it runs, so that unprivileged users can have privileges under controlled conditions. Be very careful - this can create security holes! Note that you CANNOT install a shareable image with privilege.

5) INSTALL your own inner mode system services, use /PROTECTED

why? this needs to be a very special image with a "protection change" vector.


General rule when installing images - always refer to the image by /SYSTEM/EXEC logical name. Define the logical name first:

$ DEFINE/SYSTEM/EXEC MYIMAGE disk:[dir]MYIMAGE
$ INSTALL ADD MYIMAGE/OPEN/HEAD/SHARE
$ RUN MYIMAGE

why? known file activation is "paranoid". If there are any discrepancies between the name used to install the image, and the one used to activate it, known file activation is bypassed. Using logical names as above ensures the activation name is the same as the installation name.

There are other things you can do with INSTALL, see the manual for all the gory details.

[Willem Grooters]

One additionto John Gillings remark:
[quote]
General rule when installing images - always refer to the image by /SYSTEM/EXEC logical name. Define the logical name first:

$ DEFINE/SYSTEM/EXEC MYIMAGE disk:[dir]MYIMAGE
$ INSTALL ADD MYIMAGE/OPEN/HEAD/SHARE
$ RUN MYIMAGE
[/quote]

The very same rule should apply for linking an image. LINK will store the NAME that is used in the LINK command (or option file, most likely) on which the image activator will have to decide what actual image is meant. The logical name tables are examined first and the first hit - in any table - will be used. If no hit is found, the name is expanded to .EXE to reside in SYS$SHARE.

For development of generic routines - typically the ones stored in a shared image - this is extremely powerfull, given that certain dicipline is exercised and basic rules are followed: No change in order (that is: no deletion of old entries and adding new ones only at the end), and defining the logical in the proces or job table referring to the local verion of the executable.
When found fit for production, the only actions required are INSTALL REPLACE of the file and stop and start of the executables using it (and perhaps not even that)

(Used extensively years ago on VAX, but I cannot image things have drastically changed on Alpha)

Willem