HP OpenVMS Systems Documentation

There are two new item codes for this system service. They are:

JPI$_PARSE_STYLE_PERM
JPI$_PARSE_STYLE_IMAGE

These return the values that were set by $SET_PROCESS_PROPERTIES, that can be either PARSE_STYLE$C_TRADITIONAL or PARSE_STYLE$C_EXTENDED. Return length is one byte for each one.

B.1.4 $CREPRC System Service

PRC$M_PARSE_EXPANDED

This sets the PARSE_STYLE_PERM and the PARSE_STYLE_IMAGE properties for the new process to EXPANDED.

B.1.5 $SETDDIR System Service

The following text has been added to the system service description:

On Alpha systems, the Set Default Directory service attempts to replace the default directory string with a DID if the length of the resulting default directory exceeds 255 bytes. If this happens, then in addition to the normal syntax check, the entire path to that specification, including the device, is verified and must exist for the call to succeed.

B.2 Record Management Services (RMS) Changes

OpenVMS Record Management Services (RMS) has been modified to support Extended File Specifications. The following sections describe syntax and semantics changes and RMS data structure changes.

B.2.1 Overview of Record Management Services Changes

• Support for a wider range of characters in a file name, extension, and directory
• Access to file specifications with extended characters
• Support for directory structures deeper than eight levels
• Access to file specifications longer than 255 bytes through the NAM block with some restrictions in functionality
• Access and complete specification of file specifications longer than 255 bytes by callers who are aware of the new naming characteristics through a new interface (NAML block)

On ODS-5 volumes, RMS can manipulate filenames and subdirectory specifications of up to 255 8-bit or 16-bit characters in length. RMS can handle a total path name 512 8-bit or 16-bit characters in length.

Prior to OpenVMS Alpha Version 7.2, the NAM block interface could pass file specifications of up to 255 bytes each (including the resultant file specification). The following sections describe the changes that allow for passing longer file specifications and that provide compatibility with applications using the NAM block interface prior to this release.

B.2.1.2 Additional Characters

On ODS-5 volumes, RMS supports access to files and directories with names that contain arbitrary 8-bit characters, except for the C0 control set (hexadecimal 00 through 1F) and the following characters:

Double quotation marks (")
Asterisk (*)
Backslash (\)
Colon (:)
Left and right angle brackets (< >)
Slash (/)

Question mark (?)
Vertical bar (|)

Note that this explicitly includes both the C1 character set (hex 80-9F) as well as graphical and other characters between 9F and FF. This allows the entire ISO Latin-1 character set (with the 7-bit character exclusions noted above) and any defined Unicode character.

B.2.1.3 Deeply Nested Directory Support

Under Extended File Specifications on Alpha, RMS supports deep nesting of up to 255 directories, with the restriction that the total directory specification must be no longer than 512 8-bit or 16-bit characters. The deep nesting of directories is also supported on ODS-2 disks.

B.2.2 Syntax and Semantics Changes

The following sections describe new RMS file specification syntax and semantics features. See the Guide to OpenVMS File Applications for more information about using RMS with Extended File Specifications.

B.2.2.1 Use of Hyphen as First File Name Character

Prior to OpenVMS Version 7.2, RMS documentation recommended against creating files with names that begin with a hyphen (minus sign).

On Alpha systems, the Extended File Specifications changes to RMS allow you to use a hyphen anywhere in a file name or a directory name. If a directory name containing a hyphen is ambiguous, that is, if it could be interpreted as referring to a parent directory, you must prefix the hyphen with the escape character (^) to accurately specify the file or directory.

B.2.2.2 Characters Accepted Directly

The set of characters valid through the RMS interface in a file specification (without any special escape character) is extended according to the following list. Note that these characters must not be preceded by the escape character circumflex ( ^ ).

• Upper and lowercase alphanumeric characters:

  A - Z, a - z, 0 - 9

• Special ASCII (7-bit) characters:

  $ - _

• ISO Latin-1 characters in the range (hex) A0 to FF.

• Escape ( ^ ) followed by a hexadecimal digit requires a second hexadecimal digit. The two following characters represent a hexadecimal value for an arbitrary 8-bit character.
  For example, ^20 represents a space.
• Escape followed by underscore (^_) or by a space represents one space.
• Escape followed by uppercase U (^U) indicates that the next four characters represent a hexadecimal value for an arbitrary 16-bit character.
• Each 2-byte Unicode character must be represented as a ^Uxxxx sequence.
• The following characters require an escape character when they are used as part of a file name on input to RMS and DCL. For the period (.)¹ and tilde (~)², the escape character is only required under some circumstances, detailed in their respective footnotes.

  Exclamation point (!) Pound sign (#) Ampersand (&) Apostrophe (') Left parenthesis (() Right parenthesis ()) Plus sign (+) Atsign (@) Left brace ({) Right brace (}) Period (.)1 Comma (,) Grave accent (`) Semicolon (;) Left bracket ([) Right bracket (]) Percent sign (%) Circumflex (^) Equal sign (=) Tilde (~)2

The following characters can be preceded by the escape character (^) on input to RMS or DCL, but need not be. For the period (.)¹ and tilde (~)² the escape character is only required under some circumstances, detailed in their respective footnotes.

Dollar sign ($)
Minus sign (-)
Period (.)1
Tilde (~)2

Sequences consisting of the escape character followed by any character not mentioned previously are reserved.

B.2.2.6 Canonical Form of File Specifications

In some cases, there are multiple ways to write the same characters. For example, ^20, ^ , and ^_ are all equivalent. When RMS outputs a file specification (as a resultant name, for example), it follows these rules to determine which form to use:

• Any character that cannot be represented with eight bits is represented as ^Uxxxx, where xxxx is four hexadecimal digits.
• Space is represented as the escape character followed by an underscore (^_).
• Other ISO Latin-1 8-bit characters that have no graphical representation or which are used for control functions by other OpenVMS software or by terminals is represented by an escape character followed by two hexadecimal digits (^xx). Otherwise, it is represented by its own character. The following 8-bit values are output as an escape character followed by two hexadecimal digits.

  7F (rubout) 80-9F (C1 control characters) A0 (nonbreaking space) FF (Latin small letter y diaeresis)

• If the file specification is longer than 255 bytes and must be output through a NAM block, a DID or FID abbreviation is used.
• The following characters are output preceded by the escape character (^):

  Exclamation point (!) Pound sign (#) Ampersand (&) Apostrophe (') Grave accent (`) Left parenthesis (() Right parenthesis ()) Plus sign (+) Atsign (@) Left brace ({) Right brace (}) Period (.) Comma (,) Semicolon (;) Left bracket ([) Right bracket (]) Percent sign (%) Circumflex (^) Equal sign (=)

With extended file names, some legal names will be too long for unmodified RMS applications or for DCL to handle, either because of many levels of long directory names or because of a long file name with escape characters in it. To maintain compatibility with applications using the traditional (or pre-Version 7.2) interfaces, shorter names that RMS can output to the application and that an application can input to RMS through the traditional interface will be generated.

DID abbreviation is the first step that RMS uses to create a generated name if the file specification is longer than 255 bytes. RMS attempts to generate a short enough name by abbreviating the directory with its directory ID (DID). For example:

        DKA100:[5953,9,0]FOO.TXT;1.

Restrictions on DID Abbreviations

When RMS is processing a file specification that does not fit into a traditional (pre-Version 7.2) short output buffer, RMS can attempt to abbreviate the root or directory component by replacing the component with the directory ID of the lowest-level subdirectory in the component.

There are circumstances in which RMS will not be able to generate a DID-abbreviated root or directory component. For example, if the path to the lowest-level subdirectory includes a wildcard, RMS does not have a particular directory ID to use. (And RMS does not attempt to replace a portion of a root or directory component with a DID.)

When RMS is unable to sufficiently shorten a file specification by generating a DID-abbreviated root or directory, it proceeds to the next step, FID abbreviation.

B.2.2.8 FID Abbreviation

If the file specification is still too long after DID abbreviation, RMS next attempts to generate a short enough name by abbreviating the file with its File ID (a comma-separated sequence of decimal digit strings, surrounded by brackets) in the file name field.

In cases where the extension field is normally presented, a generated name includes the complete extension or drops the extension (including the period (.)), depending on whether there is space.

In cases where the version number is normally presented, a FID abbreviated file name includes the version. As a human-readable aid in recognizing files, when a FID abbreviation is generated, the name field also contains an initial subset of the actual file name. The subset consists of the first 38 characters of the file name (where escape counts as a character) followed by the tilde (~). No attempt is made to resolve ambiguities for files that differ only after the first 38 characters of their names.

Here is an example of a FID abbreviation:

        LookAtWhatWeHave^!ThisIsAVery_long^.fi~[7254,30,0].txt;1

Restrictions on FID Abbreviations and DID Abbreviations

A FID abbreviated file name can be used for input to RMS, but only the FID abbreviation itself is significant to RMS. The subset file name, the type field, and the version are all ignored on input.

A FID cannot be used as input to the CREATE command (or any other file creation command or API) when creating a file. A DID cannot be used to create a directory. When a FID is used in a file specification, the file specification either initially contains a device and directory or it acquires them from defaults processing in RMS. If a file with the specified FID exists on the volume, it must exist within the specified directory; otherwise, RMS acts as though the file were not found.

B.2.3 RMS Data Structure Changes (Alpha Only)

This section lists the changes to the name (NAM) block. It also describes the new name (NAML) block that is used to specify file specifications longer than 255 bytes.

B.2.3.1 NAM Block

The file name block options field, NAM$B_NOP, has a new flag as shown in Table B-3.

The file name status bits field, NAM$L_FNB, has the new flags as described in Table B-4.

The NAM has three new fields: NAM$B_NMC, NAM$W_FIRST_WILD_DIR, and NAM$W_LONG_DIR_LEVELS. The NAM$B_NMC field returns the flags described in Table B-5.

The NAML is a new block that can optionally take the place of a NAM block. The NAML has all the fields of the NAM, and additionally contains new fields to allow filespecs to be specified that are longer than 255 bytes.

Table B-6 describes the new fields for the NAML Block.

RMS reads the following flag from the NAML$L_INPUT_FLAGS field:

RMS writes the following flags to the NAML$L_OUTPUT_FLAGS field: