OpenVMS Version 7.2 Release Notes

Updated: 12 December 1998

OpenVMS Version 7.2 Release Notes

Contents

Index

5.19 Privileged Interfaces and Data Structures (Alpha Only)

This section contains release notes concerning privileged code and data structures.

5.19.1 Changes and Enhancements

The following sections describe changes that affect privileged code.

5.19.1.1 Per-Thread Security and Backward Compatibility

V7.2

The security information previously stored in several data structures has moved to a new Persona Security Block (PSB) data structure, making the relevant fields in those structures obsolete in OpenVMS Version 7.2. The affected structures include the Access Rights Block (ARB), Process Control Block (PCB), Process Header Descriptor (PHD), Job Information Block (JIB), and Process Control (CTL) region fields.

Table 5-1 shows the obsolete data cells and where the information in those cells has moved.

For single persona execution within a process, the obsolete data cells¹ are maintained for backward compatibility. The cells are not maintained while a process is executing with multiple user-level personae (because any code checking the old cells would likely make the wrong security decision).

Note

A process is created with a single user-mode security profile known as the natural persona. Backward compatibility based on the current value of the new SYSGEN parameter ARB_SUPPORT, which defines the level of backward compatibility between the obsolete cells and the new PSB data structure, is maintained while the process remains in this user-mode persona state. (See the OpenVMS System Management Utilities Reference Manual for information about the ARB_SUPPORT parameter.)

Backward compatibility is not supported when multiple user-mode persona exist. Multiple user-mode persona are created using the $PERSONA_CREATE system service.

Backward compatibility of the obsolete data cells might not be maintained in future releases of OpenVMS. Writers of privileged code are encouraged to search for the obsolete symbols in their code and make the necessary modifications to remove the code's dependence on the obsolete cells, and to get the information from the new locations.

Table 5-1 Obsolete Data Cells and New Location of Security Information
Obsolete Data Cell New Location

ARB$L_CLASS PSB$AR_CLASS (Not supported ¹)

ARB$L_RIGHTSLIST PSB$AR_RIGHTS (array of rights chains pointers) --- Persona, image, and system rights chains

ARB$L_UIC PSB$L_UIC

ARB$Q_PRIV (Working privileges logically OR'd with image privileges) PSB$Q_WORKPRIV, PSB$Q_IMAGE_WORKPRIV

CTL$GQ_PROCPRIV PSB$Q_PERMPRIV

CTL$T_ACCOUNT PSB$T_ACCOUNT

CTL$T_USERNAME PSB$T_USERNAME

EXE$GL_RIGHTSLIST EXE$AR_SYSTEM_RIGHTS (Rights chain pointer)

JIB$T_ACCOUNT ² PSB$T_ACCOUNT

JIB$T_USERNAME PSB$T_USERNAME

PCB$L_NOAUDIT PSB$L_NOAUDIT

PCB$V_SECAUDIT PSB$L_SECAUDIT

PHD$Q_AUTHPRIV PSB$Q_AUTHPRIV

PHD$Q_IMAGPRIV PSB$Q_IMAGE_WORKPRIV

PHD$Q_PRIVMSK PSB$Q_WORKPRIV, PSB$Q_IMAGE_WORKPRIV --- Working privileges logically OR'd with image privileges (PSB)

PHD$R_MAX_CLASS PSB$AR_CLASS (Not supported ¹)

PHD$R_MIN_CLASS PSB$AR_CLASS (Not supported ¹)

**Table 5-1 Obsolete Data Cells and New Location of Security Information**
Obsolete Data Cell	New Location
ARB$L_CLASS	PSB$AR_CLASS (Not supported ¹)
ARB$L_RIGHTSLIST	PSB$AR_RIGHTS (array of rights chains pointers) --- Persona, image, and system rights chains
ARB$L_UIC	PSB$L_UIC
ARB$Q_PRIV (Working privileges logically OR'd with image privileges)	PSB$Q_WORKPRIV, PSB$Q_IMAGE_WORKPRIV
CTL$GQ_PROCPRIV	PSB$Q_PERMPRIV
CTL$T_ACCOUNT	PSB$T_ACCOUNT
CTL$T_USERNAME	PSB$T_USERNAME
EXE$GL_RIGHTSLIST	EXE$AR_SYSTEM_RIGHTS (Rights chain pointer)
JIB$T_ACCOUNT ²	PSB$T_ACCOUNT
JIB$T_USERNAME	PSB$T_USERNAME
PCB$L_NOAUDIT	PSB$L_NOAUDIT
PCB$V_SECAUDIT	PSB$L_SECAUDIT
PHD$Q_AUTHPRIV	PSB$Q_AUTHPRIV
PHD$Q_IMAGPRIV	PSB$Q_IMAGE_WORKPRIV
PHD$Q_PRIVMSK	PSB$Q_WORKPRIV, PSB$Q_IMAGE_WORKPRIV --- Working privileges logically OR'd with image privileges (PSB)
PHD$R_MAX_CLASS	PSB$AR_CLASS (Not supported ¹)
PHD$R_MIN_CLASS	PSB$AR_CLASS (Not supported ¹)

¹OpenVMS Version 7.2 does not maintain the structures to support MAC (mandatory access checking) in a level B1 security environment.
²Security information within this cell is not backward compatible because the JIB is shared among all processes in a job tree.

5.19.1.2 Privileged Code Changes at Version 7.0

V7.0

Privileged-code applications that were recompiled and relinked to run on OpenVMS Alpha Version 7.0 do not require source-code changes and do not have to be recompiled and relinked to run on OpenVMS Alpha Version 7.1 and later.

Privileged-code applications from releases prior to OpenVMS Alpha Version 7.0 that were not recompiled and relinked for OpenVMS Alpha Version 7.0 must be recompiled and relinked to run on OpenVMS Alpha Version 7.1 and later.

OpenVMS Alpha Version 7.0 included significant changes to OpenVMS Alpha privileged interfaces and data structures. As a result of these changes, privileged-code applications from releases prior to OpenVMS Alpha Version 7.0 might require source-code changes to run correctly on OpenVMS Alpha Version 7.0 and later. For more details about OpenVMS Alpha Version 7.0 changes that may require source changes to privileged-code applications, refer to the OpenVMS Alpha Guide to Upgrading Privileged-Code Applications.

For information about recompiling and relinking device drivers, see Chapter 6.

5.19.2 Problems and Restrictions

The following release note describes how per-thread security impacts privileged code and device drivers.

5.19.2.1 Per-Thread Security Impacts Privileged Code and Device Drivers

V7.2

The method used for attaching a security profile to the I/O Request Packet (IRP) has changed.

In previous versions of OpenVMS, the address of the processwide Access Rights Block (ARB) security structure was copied directly into the IRP. Beginning with OpenVMS Alpha Version 7.2, the address of the new security profile structure (Persona Security Block, or PSB) of the thread making the I/O request is moved into the IRP.

The I/O subsystem maintains its access to the PSB through a reference counter. The I/O subsystem increments this reference counter at IRP creation and decrements the counter at I/O completion. When the counter reaches zero, the PSB is deleted from the system.

Device drivers that created copies of IRPs to facilitate multiple I/O operations per request, and subsequently pass the copied IRPs to the I/O subsystem for postprocessing, must make code changes to account for the extra dereferences to the PSB that result. This is done by calling NSA_STD$REFERENCE_PSB and passing the PSB address located in the copied IRP before I/O postprocessing of the IRP copy. The include file and routine call for NSA_STD$REFERENCE_PSB is as follows:

#include <security-macros.h> /* Increment REFCNT of PSB that is now shared by both IRPs */ nsa_std$reference_psb( irp->irp$ar_psb );

Device drivers need to make this change under the following conditions:

If a device driver:
1. Creates a new IRP by duplicating an existing IRP, and
2. Will submit both the original and the duplicate IRPs for I/O postprocessing by calling IOC_STD$SIMREQCOM or IOC_STD$DIRPOST1.
Then the device driver must call NSA_STD$REFERENCE_PSB sometime after duplicating the IRP, but before submitting it for I/O postprocessing.
If a device driver:
1. Creates a new IRP by duplicating an existing IRP, and
2. Does not put the address of some procedure descriptor into the IRP$L_PID cell in either the copy or the original IRP, and
3. Will submit both the original and the duplicate IRPs for I/O postprocessing by calling IOC_STD$REQCOM, COM_STD$POST, COM_STD$POST_NOCNT, or IOC_STD$POST_IRP.
Then the device driver must call NSA_STD$REFERENCE_PSB sometime after duplicating the IRP, but before submitting it for I/O postprocessing.
Device drivers that perform steps 1 and 3 are also likely to put the address of some procedure descriptor into IRP$L_PID. Therefore, most device drivers that duplicate IRPs should be able to function correctly on OpenVMS 7.2 without making source changes, relinking, or recompiling.

Failure to call NSA_STD$REFERENCE_PSB in these circumstances will result in corrupt tracking information within the PSB, which can result in system crashes.

If you make code changes in a device driver to call NSA_STD$REFERENCE_PSB, you must recompile and relink the driver to run on OpenVMS Version 7.2.

Note

¹ Security information within the JIB (JIB$T_ACCOUNT, the account cell) is not backward compatible because the JIB is shared among all processes in a job tree. Modifying the JIB user-name cell (JIB$T_USERNAME) in a multiprocess job tree can adversely affect other processes in that job tree.

5.20 Record Management Services (RMS)

This section contains release notes pertaining to RMS.

5.20.1 Changes and Enhancements

The following notes describe enhancements to RMS.

5.20.1.1 Ellipsis Processing of [000000...] Now Finds All Files

V7.2

Prior to OpenVMS Version 7.2, an ellipsis search specification starting with the master file directory (MFD) (that is, [000000...]) would cause RMS, after returning all files in the MFD, to begin ellipsis processing with the first subdirectory whose name sorts alphanumerically after 000000.DIR. Subdirectory trees beginning with directories whose names sort before 000000.DIR would be skipped.

With the introduction of support for Extended File Specifications, which makes the creation of such directory names a more common event, RMS now begins its ellipsis processing of [000000...] with the first directory found, not the first directory that sorts before the MFD itself. Therefore, this search specification can now be used to return all files located on the specified device.

5.20.1.2 Circular Directory Path Detection (Alpha Only)

V7.2

Circular directory paths result when a SET FILE/ENTER command enters the directory name of a higher-level directory into a lower directory in its subdirectory tree. Prior to Version 7.2, such a directory tree appeared circular to RMS during ellipsis processing (for example, when processing a specification such as [A...]) because RMS did not detect that a directory's directory ID (DID) resulting from a SET FILE/ENTER command had already been encountered higher up in the path.

In earlier releases, an 8-deep directory limit inhibited RMS from looping while following a potentially infinite circle of DIDs. With the introduction of deep directories in OpenVMS Version 7.2, the 8-deep directory limit has been removed. In this release, RMS has been enhanced to detect when a node in the path initiates a circle. Instead of looping, RMS now treats such a node as if it were the lowest element in the current branch of the path.

5.20.1.3 Directory Cache Limits Removed

V7.2

During most wildcard searches, RMS caches the target directory file in memory to optimize calls to the file system. Prior to this release, the maximum size of a directory file that RMS would cache was 127 blocks; wildcard lookups to larger directories would go directly to the file system.

Beginning with Version 7.2, RMS attempts to cache directories of any size. If memory or other resources are not available to cache the file, wildcard lookups are then directed to the file system.

5.21 Run-Time Library (LIB$)

This section contains release notes pertaining to the Run-Time Library (LIB$).

5.21.1 Problems and Restrictions

This section describes known LIB$ RTL problems and restrictions.

5.21.1.1 LIB$FIND_IMAGE_SYMBOL Signals Warning for Modules with Compilation Errors

V7.1

LIB$FIND_IMAGE_SYMBOL may signal a warning (LIB$_EOMWARN) to indicate that the image being activated contains modules that had compilation warnings. A condition handler used with LIB$FIND_IMAGE_SYMBOL should probably handle this as a special case.

To allow LIB$FIND_IMAGE_SYMBOL to continue execution after signaling LIB$_EOMWARN, the condition handler should exit with SS$_CONTINUE. For this reason, you may choose not to use LIB$SIG_TO_RET as a condition handler for LIB$FIND_IMAGE_SYMBOL.

5.21.2 Documentation Changes and Corrections

This section describes minor corrections to the LIB$ Run-Time Library documentation.

5.21.2.1 OpenVMS RTL Library (LIB$) Manual

V7.2

The OpenVMS RTL Library (LIB$) Manual requires the following corrections:

In the description of the LIB$GETJPI routine, the description of the resultant-string argument should read:
String representation of the information you requested. The resultant-string argument is the address of the descriptor for a character string into which LIB$GETJPI writes the string representation.
In the description of the LIB$GETQUI routine, the description of the resultant-string argument should read:
String representation of the information you requested. The resultant-string argument is the address of the descriptor for a character string into which LIB$GETQUI writes the string representation.

5.22 Screen Management (SMG$) Facility

The following sections contain release notes pertaining to the Screen Management (SMG$) Facility.

5.22.1 Documentation Changes and Corrections

This section describes minor corrections to the SMG$ Run-Time Library documentation.

5.22.1.1 OpenVMS RTL Screen Management (SMG$) Manual

Note the following information that should be added to topics in the reference section at the end of the OpenVMS RTL Screen Management (SMG$) Manual:

V7.2

The following statement should be added to the Condition Values Returned section of routine SMG$DELETE_VIRTUAL_DISPLAY:
"Any condition value returned by the $DELPRC system service."
The description of routine SMG$GET_TERM_DATA contains an error in the Arguments section for the capability-data argument. The correction is as follows:

access: write-only

mechanism: by reference, array reference
The description of routine SMG$READ_LOCATOR contains an error in the Arguments section for both the row-number and the column-number arguments. The "access:" for both arguments is write only.

The description of routine SMG$SET_OUT_OF_BAND_ASTS contains an error in the Arguments section for the AST-argument argument. The symbolic names in the Data Structure diagram are incorrect. The symbolic names in the paragraph under this diagram are correct. The correct and incorrect symbolic names are as follows:

Incorrect	Correct
SMG$L_PASTEBOARD_ID	SMG$L_PBD_ID
SMG$L_ARG	SMG$L_USER_ARG
SMG$B_CHARACTER	SMG$B_CHAR

V7.1

In the documentation for the SMG$READ_COMPOSED_LINE routine, the following text should be appended to the description of the flags argument:
"The terminal characteristic /LINE_EDITING should be set for your terminal for these flags to work as expected. /LINE_EDITING is the default."

The description of routine SMG$SET_KEYPAD_MODE should contain this note:

Note

Changing the keypad mode changes the physical terminal setting. This is a global change for all virtual keyboards, not just the virtual keyboard specified by the keyboard-id argument.

5.23 String Manipulation (STR$) Facility

The following sections contain release notes pertaining to the Screen Management (STR$) facility.

5.23.1 Documentation Changes and Corrections

This section describes minor corrections to the STR$ Run-Time Library documentation.

5.23.1.1 OpenVMS RTL String Manipulation (STR$) Manual

V7.2

The following errors will be corrected in the OpenVMS RTL String Manipulation (STR$) Manual the next time this manual is updated.

The description of routine STR$FIND_FIRST_IN_SET contains an error in the Arguments section for the set-of-characters argument. The correct description of the set-of-characters argument follows:
"Set of characters that STR$FIND_FIRST_IN_SET is searching for in the string. The set-of-characters argument is the address of a descriptor pointing to the set of characters."
The description of routine STR$FREE1_DX has an error and an omission in the Condition Values Returned section.
- Delete error STR$_FATINTERR.
- Add error STR$_ERRFREDYN, with the following description:
  "Error freeing dynamic descriptor. LIB$FREE_VM or LIB$FREE_VM_64 failed to free the descriptor."

5.24 System Services

The following sections contain release notes pertaining to system services.

All system services are documented in the OpenVMS System Services Reference Manual.

5.24.1 Changes and Enhancements

The following section describes a change related to system services.

5.24.1.1 $PERSONA System Services: Flags Ignored (Alpha Only)

V7.2

The $PERSONA_ASSUME and $PERSONA_CREATE system services were provided in previous versions of OpenVMS. These services contained a flags argument that specified which persona services options were employed when the persona was assumed or created.

In OpenVMS Version 7.2, these flags are ignored.

The flags are ignored in this version of OpenVMS because with per-thread security, the process of impersonation has changed from modifying processwide security structures to modifying individual security profiles within a process. As a result, all the security information within a profile can be modified without affecting jobwide security structures. This eliminates the need for the persona flags to specify selective modification of security structures.

Table 5-2 and Table 5-3 show the values for the flags argument that are ignored in OpenVMS Version 7.2.

Table 5-2 Ignored$PERSONA_ASSUME Flags
Flags Description

IMP$M_ASSUME_SECURITY Assume access rights, UIC, authorized privileges, user name, and security audit flag.

IMP$M_ASSUME_ACCOUNT Assume OpenVMS account.

IMP$M_ASSUME_JOB_WIDE Assume the new persona, even in a multiprocess job.

**Table 5-2 Ignored$PERSONA_ASSUME Flags**
Flags	Description
IMP$M_ASSUME_SECURITY	Assume access rights, UIC, authorized privileges, user name, and security audit flag.
IMP$M_ASSUME_ACCOUNT	Assume OpenVMS account.
IMP$M_ASSUME_JOB_WIDE	Assume the new persona, even in a multiprocess job.

Table 5-3 Ignored$PERSONA_CREATE Flags
Flags Description

IMP$M_ASSUME_DEFCLASS Create a persona with default classification.

**Table 5-3 Ignored$PERSONA_CREATE Flags**
Flags	Description
IMP$M_ASSUME_DEFCLASS	Create a persona with default classification.

For more information about the $PERSONA system services, refer to the OpenVMS System Services Reference Manual: GETQUI--Z.

5.24.1.2 $PERSONA System Services: Default Privilege Change (Alpha Only)

V7.2

The default behavior in assigning persona privileges has changed in OpenVMS Alpha Version 7.2. Prior to this release, a persona was created with the authorized privileges from the specified user's UAF record as the default privileges. The user's default privileges would be used only if the IMP$V_ASSUME_DEFPRIV flag was set in the call to $PERSONA_CREATE.

This default behavour is inconsistent with OpenVMS security policy and has been changed for OpenVMS Alpha Version 7.2. The new default behavior builds the persona with privileges as specified in the user's UAF record.

For existing programs to run correctly on OpenVMS Alpha Version 7.2, you may need to modify the user's UAF records so that the default privileges specified are equivilent to authorized privileges.

Two new flags have been added to the $PERSONA_CREATE system service. ISS$V_CREATE_DEFPRIV is equivalent to the IMP$V_ASSUME_DEFPRIV flag of earlier releases and is provided solely for backward compatibility. ISS$V_CREATE_AUTHPRIV is provided to allow the caller to implement the default behavior of earlier versions of OpenVMS; that is, to use the user's authorized privileges as default privileges.

The behavior for $PERSONA_CREATE on OpenVMS VAX Version 7.2 remains unchanged.

5.24.1.3 $PERSONA System Services: Audit Record Change (Alpha Only)

V7.2

The audit record for persona creation has changed from type Server Login to type Persona Created. A persona is created by calling the $PERSONA_CREATE system service.

5.24.2 Problems and Restrictions

This section describes problems and restrictions related to system services.

5.24.2.1 Linking SECURESHR Images to Run on Older Versions

V7.0

Some additional entry points have been added to the shareable image dispatch vector. Because of this change, any applications linked against Version 7.0 or later of SECURESHR will not run on a pre-Version 7.0 system. System services that use SECURESHR are the following:

$FORMAT_ACL
$PARSE_ACL
$FORMAT_AUDIT
$DELETE_INTRUSION
$SCAN_INTRUSION
$SHOW_INTRUSION
$ADD_PROXY
$DELETE_PROXY
$DISPLAY_PROXY
$VERIFY_PROXY

If your program uses any of these system services and you want to create a version that runs on systems prior to Version 7.0, you must link your program on a system running a version of OpenVMS prior to Version 7.0.

5.24.2.2 $SUSPND Behaves Incorrectly in a Cluster Environment

VAX V6.0
Alpha V1.5

When the $SUSPND system service is called and the target process is on a different cluster node than that of the process calling the $SUSPND service, the kernel mode suspend flag (bit 0) is ignored. As a result, any suspend is treated as a supervisor-mode suspend.

5.24.3 Corrections

The following section describes a correction to several system services.

5.24.3.1 $PERSONA Restrictions Removed (Alpha Only)

V7.2

Previous versions of OpenVMS contained restrictions on the use of the $PERSONA system services ($PERSONA_ASSUME, $PERSONA_CREATE, and $PERSONA_DELETE). With OpenVMS Version 7.2, these restrictions have been removed.

I/O can now be in progress when you switch personae (using $PERSONA_ASSUME).
You can now safely use personae in a multiprocess job tree. Previously the $PERSONA services modified the Job Information Block (JIB), which is shared by all processes in the job tree. In OpenVMS Version 7.2, the user name and account cells are moved from the JIB to the Persona Block (PSB).
Interaction between a thread manager (for example, the thread manager incorporated within DECthreads) and the security subsystem enables the automatic switching of profiles as threads are scheduled for execution.

For more information about per-thread security, see the OpenVMS Guide to System Security; for details on the $PERSONA system services, refer to the OpenVMS System Services Reference Manual.

5.25 X/Open Transport Interface (XTI)

The notes in this section describe the X/Open Transport Interface (XTI).

5.25.1 Changes and Enhancements

OpenVMS Version 6.2 and later supports the X/Open Transport Interface (XTI) programming interface. The implementation conforms with the XPG4 X/Open CAE XO/CAE/91/600 (ISBN 1 872630 29 4) X/Open Transport Interface (XTI) specification.

Supported Transports

OpenVMS Version 7.1 and later supports the DECnet for OpenVMS (Phase IV), DECnet-Plus for OpenVMS (Phase V), and TCP/IP Services transports. See Section 5.25.2 for support restrictions.

The transport names used in the t_open routine are 'dnet' for DECnet and either 'ip/udp' or 'ip/tcp' for TCP/IP.

Other transports are available with other networking layered products. Consult individual layered product documentation for information about OpenVMS XTI support.

Architecture

XTI is supported by frontend and backend code. Frontend code provides access to the standard interface routines. Backend code provides the interface from the frontend code to the selected networking transport.

The supporting image files are as follows:

XTI frontend code SYS$SHARE:XTI$XTILIB.EXE

TCP/IP XTI backend code SYS$SHARE:XTI$IPSHR.EXE

DECnet XTI backend code SYS$SHARE:XTI$DNETSHR.EXE

XTI C programming include file SYS$LIBRARY:XTI.H

Linking Requirements

After compiling an XTI program, no additional qualifiers are required for linking with XTI.

Documentation

Documentation about XTI is not included in the OpenVMS documentation set. You can order documentation directly from X/Open Company Limited.

You can also contact X/Open Company Limited at the following locations:

USA: East Coast
X/Open Company Limited
3141 Fairview Park Drive
Falls Church
VA 22042-4501
U.S.A.
Tel: +1 (703) 876 0044
Fax: +1 (703) 876 0050
USA: West Coast
X/Open Company Limited
1010 El Camino Real
Suite 380
Menlo Park, CA 94025
U.S.A.
Tel: +1 (415) 323 7992
Fax: +1 (415) 323 8204
United Kingdom:
X/Open Company Limited
Apex Plaza
Forbury Road
Reading
Berks RG1 1AX
U.K.
Tel: +44 1734 508311
Fax: +44 1734 500110
Japan:
X/Open Company Limited
Karufuru-Kanda Bldg, 9F
1-2-1 Kanda Suda-cho
Chiyoda-Ku
Tokyo 101
Japan
Tel: +81 3 3251 8321
Fax: +81 3 3251 8376

5.25.2 Problems and Restrictions

V6.2

The following restrictions apply to XTI on OpenVMS systems:

Nonblocking I/O is unsupported for DECnet for OpenVMS.
DECnet for OpenVMS (Phase IV) does not fit the model for nonblocking I/O. Attempts to open or switch an XTI file descriptor to nonblocking I/O (O_NONBLOCK) will fail.
Connectionless I/O is unsupported for DECnet for OpenVMS.
DECnet for OpenVMS (Phase IV) does not fit the model of connectionless I/O. Therefore, only connection-oriented connections are supported.
Disabled ASTs cause problems.
The XTI backend code uses ASTs for asynchronous delivery of events from the transports. If ASTs are disabled (sys$setast(0)), the XTI backend code will not operate correctly until the ASTs are enabled again.
XTI file descriptors are not compatible with C Run-Time Library file descriptors.

In addition, the 't_info' structure returned from the t_open function reports any additional implementation-specific restrictions for the given transport. (See the XTI documentation for information about the t_open command.)

Contents

Index

Legal

 
6534PRO_014.HTML

	XTI frontend code	SYS$SHARE:XTI$XTILIB.EXE
	TCP/IP XTI backend code	SYS$SHARE:XTI$IPSHR.EXE
	DECnet XTI backend code	SYS$SHARE:XTI$DNETSHR.EXE
	XTI C programming include file	SYS$LIBRARY:XTI.H

access:	write-only
mechanism:	by reference, array reference

OpenVMS Version 7.2 Release Notes

5.19 Privileged Interfaces and Data Structures (Alpha Only)

5.19.1.2 Privileged Code Changes at Version 7.0

1 Security information within the JIB (JIB$T_ACCOUNT, the account cell) is not backward compatible because the JIB is shared among all processes in a job tree. Modifying the JIB user-name cell (JIB$T_USERNAME) in a multiprocess job tree can adversely affect other processes in that job tree.

5.22 Screen Management (SMG$) Facility

5.23 String Manipulation (STR$) Facility

5.24 System Services

5.25.2 Problems and Restrictions

¹ Security information within the JIB (JIB$T_ACCOUNT, the account cell) is not backward compatible because the JIB is shared among all processes in a job tree. Modifying the JIB user-name cell (JIB$T_USERNAME) in a multiprocess job tree can adversely affect other processes in that job tree.