The following sections contain notes related to system parameters.

4.41.1 New System Parameters

V8.3

To learn about new system parameters, see the HP OpenVMS Version 8.3 New Features and Documentation Overview.

4.41.2 Obsolete System Parameters

V8.3

The following system parameters are marked as obsolete in OpenVMS Version 8.3:

• SMP_CPUS
• SMP_CPUSH
• IO_PREFER_CPU
• IO_PREFER_CPUS
• NPAG_AGGRESSIVE
• NPAG_GENTLE
• SCH_CTLFLAGS
• TTY_SILOTIME
• BALSETCNT
• BREAKPOINTS
• MMG_CTLFLAGS
• NISCS_MAX_PKTSZ
• NISCS_PORT_SERV
• SECURITY POLICY

The following new parameters replace the preceding ones:

• SMP_CPU_BITMAP
• IO_PRCPU_BITMAP

For more information about these new system parameters, see the HP OpenVMS System Management Utilities Reference Manual or online help.

4.41.3 System Parameter Changes

V8.4

The following system parameters are changed in OpenVMS Version 8.4.

• AUTO_DLIGHT_SAV - now dynamic
• MULTITHREAD - now dynamic

V8.3

The following system parameters are changed in OpenVMS Version 8.3.

• BALSETCNT - wording changes
• BREAKPOINTS - now dynamic
• MMG_CTLFLAGS - additional bits defined; wording changes
• NISCS_MAX_PKTSZ - wording changes
• NISCS_PORT_SERV - bit definition changes
• SECURITY_POLICY - Bits 13 and 14 defined
• SHADOW_SYS_DISK - wording changes
• WBM_MSG_UPPER - default changed

For more information, see the HP OpenVMS System Management Utilities Reference Manual or online help.

4.42 Terminal Fallback Facility

V8.2

On OpenVMS Alpha systems, the Terminal Fallback Facility (TFF) includes a fallback driver (SYS$FBDRIVER.EXE), a shareable image (TFFSHR.EXE), a terminal fallback utility (TFU.EXE), and a fallback table library (TFF$MASTER.DAT).

To start TFF, invoke the TFF startup command procedure located in SYS$MANAGER, as follows:

$ @SYS$MANAGER:TFF$SYSTARTUP.COM

To enable fallback or to change fallback characteristics, invoke the Terminal Fallback Utility (TFU), as follows:

$ RUN SYS$SYSTEM:TFU TFU>

To enable default fallback to the terminal, enter the following DCL command:

$ SET TERMINAL/FALLBACK

OpenVMS Alpha TFF differs from OpenVMS VAX TFF in the following ways:

• On Alpha systems, the TFF fallback driver is named SYS$FBDRIVER.EXE. On VAX systems, the TFF fallback driver is named FBDRIVER.EXE.
• On Alpha systems, TFF is capable of handling 16-bit character fallback. The OpenVMS Alpha fallback table library (TFF$MASTER.DAT) contains four more 16-bit character tables than the VAX library. Table 4-4 describes these additional tables.

  Table 4-4 TFF Character Fallback Tables

  Table Name	Base	Description
  BIG5_HANYU	BIG5	BIG5 for CNS 11643 (SICGCC) terminal/printer
  HANYU_BIG5	CNS	CNS 11643 (SICGCC) for BIG5 terminal/printer
  HANYU_TELEX	CNS	CNS 11643 for MITAC TELEX-CODE terminal
  HANGUL_DS	KS	KS for DOOSAN 200 terminal

  
  These tables are used mainly by the Asian region. Also, the table format was changed due to the support of 16-bit character fallback.

• On Alpha systems, the TFU command SHOW STATISTICS does not display the size of the fallback driver (SYS$FBDRIVER.EXE).

RT terminals are not supported by TFF.

For more information about the Terminal Fallback Facility, refer to the now archived OpenVMS Terminal Fallback Utility Manual on the OpenVMS documentation website:

Click on "Archived documents" in the left sidebar to link to this manual.

4.43 User Environment Test Package (Integrity servers Only)

V8.2

The User Environment Test Package (UETP) can be used with the following cautions:

• During the load phase, there are sporadic access violations in UETMEMY01. This does not terminate execution affect the validity of the run. UETP is still useable and produces valid results.
• The device phase currently does not complete execution due to an access violation.
• The DECnet phase runs fine. The cluster phase is still being tested. It appears to execute properly, but there are some concerns, and the output does not show other system names properly.

Permanent Restriction

Virtual I/O Cache (VIOC) --- also known as VAX Cluster Cache (VCC) --- is not available on OpenVMS Integrity servers. On Integrity servers, setting the SYSGEN parameter VCC_FLAGS to 1 is equivalent to setting VCC_FLAGS to 0 or not loading caching at all.

HP recommends Extended File Cache (XFC) as the preferred method for caching on both Alpha and Integrity servers. For more information about XFC, refer to the HP OpenVMS System Manager's Manual.

In a future release of OpenVMS Alpha, support for VIOC will be removed.

4.45 Analyze Utility for OpenVMS

The following sections describe corrected problems in the Analyze Utility for OpenVMS.

4.45.1 Formatted Symbol Vector Correctly Shown in Data Segment

Previously, the symbol vector summary information did not indicate the segment in which the symbol vector resided. The symbol vector was formatted only in the dynamic segment.

This problem is fixed in OpenVMS Version 8.3-1H1. The formatted symbol vector now appears with the data segment in which it is contained. The formatted symbol vector is embedded in data and visible in a dump of the data.

To avoid formatting the same data twice, the symbol vector is no longer shown with the dynamic segment. To make formatting of the symbol vector easy, the SYMBOL_VECTOR keyword is allowed for the /SEGMENT qualifier. When you specify this keyword, the resulting output is only the formatted symbol vector. The surrounding data are not shown. To show and format all of the data, select the segment by number.

To get equivalent output for the former command /SEGMENT=DYNAMIC for symbol vectors, use the /SEGMENT=(DYNAMIC,SYMBOL_VECTOR) qualifier.

The summary information shows the name of the data segment that contains the symbol vector.

4.45.2 Transfer Array Formatted in Data Segment

Previously, if you selected the data segment that contained the transfer array (either by segment number or with the ALL keyword), the transfer array was not formatted. Information about the transfer array was shown only in the summary.

This problem is corrected in OpenVMS Version 8.3-1H1. The formatted tranfer array now appears in the data segment.

4.45.3 System Version Array Formatted in Dynamic Segment

System version data is in the dynamic segment. Previously, if you selected the dynamic segment (either by segment number, or with the ALL or DYNAMIC keyword), the system version array was not shown. Information about the system version array was only shown in the summary.

This problem is corrected in OpenVMS Version 8.3-1H1. The formatted system version array now appears in the dynamic segment.

4.45.4 Enhancements for the /SEGMENT Qualifier

Enhancements have been made to the /SEGMENT qualifier for dynamic segments. The Analyze utility is now been enhanced to accept keywords for the /SEGMENT=DYNAMIC qualifier to provide customized information. The keywords for selectable information are:

• ALL---(Default) Formats all parts of the dynamic segment
• TAGS---Formats the tag array
• IMAGE_STRINGS---Formats strings of the specified image
• RELOCATIONS---Formats the image relocations
• FIXUPS---Formats the image fixups
• SYSTEM_VERSION_ARRAY---Formats the system version array

The default, /SEGMENT=ALL, formats all of the image information.

Note that formatting using the TAGS keyword includes the names of the needed images, so you need not add IMAGE_STRINGS to print the names.

4.45.5 Support for Section Escaping Added

On OpenVMS V8.3, the Analyze utility did not complete when analyzing an object module with more than 65,280 sections. Instead, it looped when attempting to print the section header table.

This problem has been fixed in OpenVMS V8.3-1H1.

4.46 INSTALL Utility for OpenVMS (Installing Resident Images in S2 Space)

The INSTALL utility now supports installing code segments of resident images into 64-bit S2 address space. Not all code can run in a full 64-bit address space (P2 or S2). For example, the code must be prepared for 64-bit PCs when handling exceptions. Also, some compilers require the /POINTER_SIZE=64 command qualifier, when generating code, suitable for a 64-bit address space.

To avoid mapping unprepared code in the S2 space, the INSTALL utility by default will continue to map the code segments in S0/S1 space. The INSTALL utility will map code segments of resident images to S2 if the following conditions are met:

• The developer explicitly confirmed that the code is 64-bit ready by using the /SEGMENT_ATTRIBUTE=CODE=P2 qualifier when linking the image.
• There is sufficient pre-allocated space in the resident code region in the S2 space to map the code segments. The size of the region is determined by the system parameter GH_RES_CODE_S2 (number of pages). The default value is set to 0. That means that by default even 64-bit ready resident images have their code mapped in the S0/S1 space.