|
HP OpenVMS Systems Documentation |
|
HP OpenVMS Version 8.3 Release Notes
4.19 System Parameters
The following sections contain notes related to system parameters.
V8.3
To learn about new system parameters, see the HP OpenVMS Version 8.3 New Features and Documentation Overview.
V8.3 The following system parameters are marked as obsolete in OpenVMS Version 8.3:
The following new parameters replace the preceding ones:
For more information about these new system parameters, see the
HP OpenVMS System Management Utilities Reference Manual or online help.
The following system parameters are changed in OpenVMS Version 8.3. For more information, see the HP OpenVMS System Management Utilities Reference Manual.
For detailed descriptions of these parameters see the online help or
the HP OpenVMS System Management Utilities Reference Manual.
V8.3
The OpenVMS Performance Management manual contains several references to the system
parameter LCKMGR_CPUID as LOCKMGR_CPU. This latter reference is
incorrect and will be corrected the next time the manual is updated.
V8.2 There is an error in the description of Bit 1 of the MMG_CTLFLAGS system parameter in the OpenVMS Performance Management manual. That description should be corrected to read as follows: "Reclamation enabled by outswapping processes that have been idle for longer than LONGWAIT seconds. This occurs when the size of the free list drops below the value of FREEGOAL." 4.20 Terminal Fallback Facility (TFF)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:
To enable fallback or to change fallback characteristics, invoke the Terminal Fallback Utility (TFU), as follows:
To enable default fallback to the terminal, enter the following DCL command:
OpenVMS Alpha TFF differs from OpenVMS VAX TFF in the following ways:
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.
V8.2 The User Environment Test Package (UETP) can be used with the following cautions:
4.22 Recommended Caching MethodsPermanent Restriction Virtual I/O Cache (VIOC) --- also known as VAX Cluster Cache (VCC) --- is not available on OpenVMS I64. On I64 systems, 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 I64 systems. 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.
The following release notes pertain to HP Volume Shadowing for OpenVMS,
also known as host-based volume shadowing (HBVS).
V7.3-2 Volume Shadowing for OpenVMS supports device names whose ddc portion of the full device name of $alloclass$ddcu: is three characters. Prior to this release, it was possible to create device names whose ddc portion of the full device name was longer, such as $1$DECRAM10:, and these devices mounted successfully. However, mounting such devices as part of a shadow set caused operational problems, such as %MOUNT-F-XSMBRS errors when other disks were added to the shadow set. Starting with OpenVMS Alpha Version 7.3-2, the Mount utility enforces this three-character requirement for the ddc portion of the full device name during the initial attempt to mount the device. If you attempt to mount a device whose name does not conform to this requirement, the following error message is displayed:
4.23.2 Warning About Using SET SHADOW and SHOW SHADOW in DCL Command ProceduresV7.3-2 The new DCL commands SET SHADOW and SHOW SHADOW will continue to evolve. In a future release, the default display and implementation of a SHOW SHADOW/FULL display will change the current formatting. Therefore, HP advises customers not to rely on parsing the current format of output in DCL command procedures to obtain information about the shadow set. Instead, consider using the F$GETDVI lexical function to obtain many of the items displayed by the SHOW SHADOW command. Furthermore, the behavior of the SET SHADOW command will also change. In addition to other new qualifiers, a new /ALL qualifier will be required if SET SHADOW is used to set characteristics in all shadow sets on a system at the same time.
Please keep these changes in mind if you are writing DCL command
procedures that use these new commands.
V7.3-2 An interaction occurs between write bitmaps and dissimilar device shadowing (DDS) when Volume Shadowing for OpenVMS is used. DDS, a new feature in OpenVMS Version 7.3-2, allows you to construct shadow sets of disk devices that are of dissimilar sizes. (For details about DDS, refer to the HP OpenVMS Alpha Version 7.3--2 New Features and Documentation Overview manual and HP Volume Shadowing for OpenVMS.) Write bitmaps keep track of application writes made to a shadow set virtual unit so that a member can be returned to that virtual unit without the overhead of a full copy. A write bitmap is created when the user issues a DISMOUNT/POLICY=MINICOPY command for a shadow set member or mounts a shadow set using the MOUNT/POLICY=MINICOPY command. When this bitmap is created, its size depends on the current size of the volume. When a shadow set is mounted, the logical size of the shadow set virtual unit is set to the size of the smallest member unit. When a member of the shadow set is removed, the logical size of the virtual unit is recomputed based on the sizes of the remaining members of the set. Consequently, the logical size of the virtual unit may increase. When a write bitmap is created for a shadow set, its size is determined by the current size of the shadow set virtual unit. If the virtual unit's size subsequently increases, the bitmap will not cover the entire virtual unit. If the bitmap is then used to bring back a shadow set member with a minicopy operation, the portion of the virtual unit that is not covered by the bitmap will be copied with a full copy operation. The following example illustrates this problem:
If the removal of a smaller shadow set member is planned, removing it
before removing a larger member with a minicopy bitmap will cause a
larger bitmap to be created and will avoid the performance impact of a
short bitmap. (In the preceding example, you would remove $1$DGA20:
before removing $1$DGA22:.)
Permanent Restriction Volume Shadowing for OpenVMS can be used with the KZPDC controller (Smart Array 5300) subject to the restriction that all shadow set members are formed using devices composed of fault-tolerant devices, such as the following:
A fault-tolerant device on the KZPDC (Smart Array 5300) controller is one that can repair data errors when the media yields errors on one of the underlying LUNs. OpenVMS Alpha Version 7.3-2 and higher supports shadow sets with members whose total block count varies. This new feature is known as dissimilar device shadowing (DDS). DDS allows a KZPDC device to be shadowed with a device from any supported controller. For all prior OpenVMS versions, all devices must report the same number of total blocks for HBVS to create a multiple-member shadow set. The configuration utility sets the total number of blocks on a KZPDC or MSA1000 device to the closest match that it can make to the requested size. Because the KZPDC and the MSA1000 use the same calculation, a device created on both with the same requested size will be set to the same size. This allows HBVS to create multiple-member shadow sets.
4.23.5 Changes in Shadow Set Merge Delay ComputationDuring an unassisted shadow set merge operation, read I/O performance available to applications is reduced by two factors:
The shadow set merge operation employs a throttling mechanism to limit
the impact of merge I/O on applications. The merge process is throttled
by introducing a delay between merge I/Os when system load is detected.
The logic for computing this delay has been redesigned for OpenVMS
Alpha Version 7.3-2. With the new merge delay computation, the default
parameter settings will result in faster merge rates for some I/O
controllers, such as the HSG-80. For more information, refer to the
HP Volume Shadowing for OpenVMS manual.
V7.3 In a single site or in a multiple-site OpenVMS Cluster configuration, if you issue a DISMOUNT command with the /MINICOPY qualifier from a client system to dismount a shadow set member, the command might fail. If the first DISMOUNT command fails, repeat the command, as shown in the following example:
This problem will be corrected in a future release.
V8.3 Following are new and changed features in Version 8.3.
4.25 Default Startup Order Required for OpenVMS and Kerberos ACME AgentsV8.3 The default settings for starting the OpenVMS ACME agents allow logins to function normally. If the default order of startup for the OpenVMS and Kerberos ACME agents is changed so that the Kerberos ACME is started first, accounts that are not in the Kerberos realm might not be able to log in. Changing the default order of startup is not supported in this release of OpenVMS. If the startup order is changed, you can change it back to the default order by performing the following procedure. Edit SYS$MANAGER:ACME$START.COM to search for the section (near the end of the command procedure) where you can specify the desired agent ordering. Change the last line (beginning with AGENT_LIST) so that it appears in the procedure.
4.26 Traceback API Problem Fixed
In OpenVMS I64 Version 8.2, an error occurred when the pc_rel
(relative PC value) or image_desc (image name string
descriptor) arguments were specified as zero. The Traceback facility
now correctly ignores these arguments and continues Traceback
processing.
The following release notes address late-breaking information about
Version 2.0 of WBEM Services for OpenVMS.
WBEM Services for OpenVMS Version 2.0 is based on the OpenPegasus 2.5
code stream of the The Open Group's Pegasus open source project.
Version 2.0 supports local nPartitions and iCAP providers. Only the
functions and capabilities needed by these providers are supported.
Pegasus, a UNIX-based product, is not designed for homogeneous
clusters. To have the cimserver run on more than one node on a cluster
common system disk, install the product on separate roots so that the
repository, trace, and log file directories do not conflict.
After entering the cimprovider -r command, you must stop and
restart the cimserver to complete the process of replacing a provider.
(OpenVMS does not support unloading a dynamically loaded image.)
Be sure to use quotes around a command line option to preserve its
case. For example,
The DCL command PRODUCT REMOVE WBEMCIM does not remove the repository directory tree that WBEM_SERVICES$SETUP.EXE creates after installation. You need to delete SYS$COMMON:[WBEM_SERVICES.VAR...]*.*;* by hand.
If you do not delete the directory tree, when you upgrade or reinstall
WBEM, multiple "File already exists" errors are reported when you run
WBEM_SERVICES$SETUP.EXE.
V8.3 The system service $SIGNAL_ARRAY_64 is missing on I64. Whe you call this service on I64, you receive a return status of SS$_NOT_LOADED (4026 decimal) . This service will be added in a future release of OpenVMS on I64. To work around this problem, you can find the address of the 64-bit signal array in the mechanism array at offset chf$ph_mch_sig64_addr . For example, in C, you can replace the following statement:
with the following statement:
4.29 HP OpenVMS System Analysis Tools ManualV8.3
The following corrections pertain to the HP OpenVMS System Analysis Tools Manual. This manual was
not updated for OpenVMS Version 8.3, but the corrections noted here and
the additions described in the HP OpenVMS Version 8.3 New Features and Documentation Overview are included in online
help for the SDA utility and in related commands for ANALYZE and System
Services logging:
When a dump is being analyzed, it is useful to have data available that cannot be written to the dump file at the time of the system crash. This data includes the full file specification associated with a file identification and, on I64 systems, the unwind data for images activated in processes. If the dump is being analyzed on the system where it was originally written, this data can be collected for use in the current SDA session using the COLLECT command. If the dump is being copied for analysis elsewhere, the COPY/COLLECT command may be used to collect the data and append it to the copy being written. If the COPY/COLLECT command is used after a COLLECT command, the data already collected is appended to the dump copy. By default, a copy of the original dump, as written at the time of the system crash, includes collection. You can use COPY/NOCOLLECT to override this. Conversely, a copy of a dump previously copied by SDA without collection (COPY/NOCOLLECT) does not include collection. You can use COPY/COLLECT to override this. Copying a dump that already contains an appended collection always includes that collection. For all file and unwind data to be collected successfully, all disks that were mounted at the time of the system crash should be remounted and accessible to the process running SDA. If SDA is started early during startup to save the contents of the dump (for example, using CLUE$SITE_PROC; see Section 2.2.3), but disks are not mounted until a batch job is run, then the COPY/NOCOLLECT command should be used in the CLUE$SITE_PROC command procedure. Once all disks are mounted, a COPY/COLLECT can be used to save file and/or unwind data.
If the COPY and the COLLECT operations cannot be done as a single step,
entering the COLLECT/SAVE command writes the collection to a separate
file that can be used later in conjunction with the dump file. A later
copy combines the two files.
You might need to include the
/NOCOLLECT
qualifier to the
COPY
command. For more information, see the preceding section for details.
In Section 2.5, in the first list of the SET PROCESS and SHOW PROCESS commands, the SHOW PROCESS/SYSTEM and SHOW PROCESS/NEXT lines should be juxtaposed, and the following lines should be added to the list:
At the end of the section, the following lines should be added to the bottom of the list of SET PROCESS and SHOW PROCESS commands:
4.29.5 SDA Symbol InitiationIn Section 2.6.1.4, the following line should immediately precede the Section 4.29.5 heading:
Symbols can include lowercase letters. Commands that manipulate symbols
(such as
DEFINE
,
SHOW SYMBOL
, and
UNDEFINE
) require such symbols to be within quotes.
In the Parameters section, Chapter 3, the of the file specifcation description should be as follows: Name of file that contains the dump you want to analyze. If no file specification is given with an ANALYZE/CRASH_DUMP command, the default is the highest version of SYS$SYSTEM:SYSDUMP.DMP . If this file does not exist, SDA prompts you for a file name. If any field of file specification is given, the remaining fields default to the highest version of SYSDUMP.DMP in your default directory. The following should be added to the Parameters section: Collection-file-name
Name of the file to be used by SDA that contains the file ID
translation data and/or unwind data.
In Chapter 3, in the Format section,
filespec
should be
[ filespec ]
(that is, the filespec parameter is now optional).
In the the Introduction to Chapter 4, FLT should be removed and the following commands added:
COLLECT
In Chapter 4, the following content should be appended to the COPY command description: When a dump is being analyzed, it is useful to have data available that cannot be written to the dump file at the time of the system crash. This data includes the full file specification associated with a file identification, and, on OpenVMS I64, the unwind data for images activated in processes. If the dump is being analyzed on the system where it was originally written, this data can be collected for use in the current SDA session using the COLLECT command. If the dump is being copied for analysis elsewhere, the COPY/COLLECT command can be used to collect the data and append it to the copy being written. If the COPY/COLLECT command is used after a COLLECT command, the data already collected is appended to the dump copy. By default, a copy of the original dump, as written at the time of the system crash, will include collection. You can use COPY/NOCOLLECT to override this. Conversely, a copy of a dump previously copied by SDA without collection (COPY/NOCOLLECT) does not include collection. You can use COPY/COLLECT to override this. Copying a dump that already contains an appended collection always includes that collection. For all file and unwind data to be collected successfully, all disks that were mounted at the time of the system crash should be remounted and accessible to the process running SDA. If SDA is invoked early on during startup to save the contents of the dump, for example, using CLUE$SITE_PROC (see Section 2.2.3), but disks are not mounted until a batch job is run, then the COPY/NOCOLLECT command should be used in the CLUE$SITE_PROC command procedure. Once all disks are mounted, a COPY/COLLECT can be used to save file and unwind data.
If the
COPY
and the
COLLECT
commands cannot be issued as a single step, a
COLLECT/SAVE
command writes the collection to a separate file that can be used later
with the dump file. A later
COPY
command combines the two files.
In Chapter 4, the following changes should be made to the DUMP command description:
4.29.11 EVALUATE CommandIn Chapter 4, the following changes should be made to the EVALUATE command description:
4.29.12 MAP CommandIn Chapter 4, the following text should be appended to the end of the description section: On OpenVMS for Integrity servers, the MAP command can also provide additional data for addresses in system space. If the address is determined to be in a code section of an executive loaded image or a resident shareable image, and if the image file is accessible and was linked /TRACEBACK , then the traceback data is used to obtain and display module name and routine name information. In Chapter 4, the following example should be added to the MAP command description:
This example shows the use of the symbol filter. Only symbols whose
value is 2F0 and whose names begin with PCB are displayed.
In Chapter 4, the following lines should be appended to the list of SET PROCESS and SHOW PROCESS commands:
VALIDATE PROCESS/POOL process-name
In Chapter 4, the following lines should be appended to the list of SET PROCESS and SHOW PROCESS commands:
VALIDATE PROCESS/POOL process-name
In Chapter 4, the following text should be appended to the end of the description section: In the description of the directory-spec parameter, SYS$LOADABLE_IMAGES and SYS$LIBRARY should be changed to SYS$LOADABLE_IMAGES , SYS$LIBRARY , and SYS$SYSTEM . In Table 4-1, footnote 3, the following sentence should be removed:
These are found in
SYS$SYSTEM
, and are not automatically read in when you issue a
READ/EXEC
command.
The following changes should be made to the SEARCH command description in Chapter 4:
4.29.17 SHOW_CALL_FRAME CommandIn Chapter 4, the following text should replace the description of the starting-address parameter: On Alpha: An expression representing the starting address of the procedure call frame to be displayed. If no value for starting-address is given, the default starting address is the contents of the frame pointer (FP) register of the SDA current process. For a process that uses pthreads, the following SDA command can be used to display the starting addresses for all pthreads:
On OpenVMS for Integrity servers: An expression representing one of the following:
4.29.18 SHOW CLUSTER CommandIn Chapter 4, the following changes should be made to the SHOW CLUSTER command description: In the Format section, "/CIRCUIT=pb-addr |" should be placed before "/CSID." In the qualifier description for /ADDRESS, "/CSID=csid and /NODE=name" should be replaced with "/CIRCUIT=pb-addr, /CSID=csid, and /NODE=name". In the qualifier descriptions for /CSID and /NODE, "/CIRCUIT=pb-addr," should be added after "/ADDRESS=n". The following text should be appended to the Description:
If the qualifier /CIRCUIT=pb-addr is specified, then the SHOW
CLUSTER command displays only the information from the specified path
block.
The following changes should be made to the SHOW CRASH command description in Chapter 4: The Format section should read, "SHOW CRASH [ /ALL | /CPU = n]". In the Description section the following should be appended to the second-to-last paragraph: Unless /ALL is specified, the registers (on Alpha) or exception frame contents (on I64) are omitted from the display for any CPUs with CPUEXIT or DBGCPUEXIT bugchecks. In the Description section, the phrase "and additionally displays all CPU database addresses in system dumps" should be removed from the final paragraph. The command in example 3 should be changed to the following:
4.29.20 SHOW DUMP CommandIn Chapter 4, the following changes should be made to the SHOW DUMP command description: The Format section should be replaced with the following:
In the Description section, the phrase "the memory map, and the file identification, and/or unwind data collection" should replace the phrase "and the memory map". The following example should be appended to the SHOW DUMP command:
This example of the SHOW DUMP/COLLECTION command shows the contents of
the file identification and/or unwind data collection appended to a
system dump when it was copied with the SDA command COPY/COLLECT. Note
that unwind data segments are found only in system dumps from OpenVMS
I64 systems.
In Chapter4, the following changes should be made to the SHOW PROCESS command description: In the Format section:
In the description of qualifier /ALL, "/STATISTICS" should be added to the line "/POOL/HEADER/RING_BUFFER". The heading and the first paragraph in the description for the /POOL qualifier should read: /POOL [ = { P0 | P1 | IMGACT | ALL (D) } ] Displays the dynamic storage pool in the process’s P0 (process) region and/or the P1 (control) region and/or the image activator’s reserved pages, or optionally, a range of addresses. The default action is to display all dynamic storage pools. The following should replace the description for the /UNWIND_TABLE qualifier: /UNWIND_TABLE [ = { ALL | name } ] (I64 only) If specified without a keyword, displays the master unwind table for the process. SHOW PROCESS/UNWIND=ALL displays the details of every process unwind descriptor. SHOW PROCESS/UNWIND=name displays the details of every unwind descriptor for the named image(s) (wildcards allowed). To look at unwind data for a specific PC in process space, use SHOW UNWIND address. If some or all unwind data for an image was not included in the system dump (for example, it was not in the working set of the process at the time of the system crash), a SHOW PROCESS/UNWIND command may fail with a %SDA-W-NOREAD error because the unwind data is inaccessible. Collecting unwind data (see Commands COLLECT and COPY/COLLECT) will not correct this, as the collected unwind data is only used by SHOW UNWIND address and SHOW CALL. The second bullet under "For I64" should read as follows: Special purpose registers (PC, PSR, ISR). Note that the PC is the combination of the IP and the slot number from the PSR.
The following keywords should be added to the /STATUS qualifier:
4.29.23 SHOW SPINLOCKS CommandThe following changes should be made to the SHOW SPINLOCKS command description in Chapter 4: The Format section should read as follows:
In the description of the name parameter, the phrase "PCB, or cached PCB" should be changed to "PCB, cached PCB, or process-shared." In the description of the /ADDRESS qualifier, the phrase "PCB, or cached PCB" should be changed to "PCB, cached PCB, or process-shared." In the description of the /DYNAMIC qualifier, the phrase "PCB, or cached PCB" should be changed to "PCB, cached PCB, or process-shared." The following new qualifier should be added after the /PORT qualifier: /PSHARED Displays all process-shared (Pthreads) spinlocks.
In the third paragraph of the description section, the phrase "PCB and
cached PCB" should be changed to "PCB, cached PCB, and process-shared."
In Chapter 4,the following changes should be made to the SHOW MEMORY command description:
In the /SLOTS qualifier description, the word "partition" should be
"process."
The following changes should be made to the SHOW GCT command description in Chapter 4: In the Format section, "[ CHILDREN ] |" should be "[ /CHILDREN ] |," and should be followed by "[ /FULL ] |". In the Qualifiers section, the /FULL qualifier description should be added after /CHILDREN: /FULL When used with /CHILDREN, /OWNER=n, or /TYPE=type, the /FULL qualifier causes SDA to provide a detailed display of each node. In the /OWNER and /TYPE descriptions, "Provides a detailed display of all nodes" should be replaced by "Displays all nodes".
In the /TYPE description, "CORE," "SOCKET," and "THREAD" should be
added (in alphabetical order) to the list of valid types.
The following should be appended to the SHOW CPU command description in Chapter 4:
4.29.27 SHOW SYMBOL CommandThe following text should be appended to the symbol-name parameter description:
Symbols that include lowercase letters must be enclosed in quotes.
The Format section should read as follows: /IMAGE
SHOW UNWIND [address|/ALL|/IMAGE=name]
The following changes should be made to the SHOW SWIS command description in Chapter 4:
4.29.30 CLUE CONFIG CommandThe following qualifiers to the CLUE CONFIG command description in Chapter 5: /CPU Displays only the part of the system configuration that contains information about the system, memory and CPUs. /ADAPTER Displays only the part of the system configuration that contains information about the adapters and devices on the system. The following sentence should be appended to the Description section:
If no qualifier is specified, the entire system configuration is
displayed.
In Chapter 5, the following changes apply to the CLUE REGISTER command description: The Format section should read as follows:
The parameters and qualifiers are the same as those used for the CLUE_CALL_FRAME command. The following sentence should be appended to the Description section:
If neither /CPU nor /PROCESS is specified, the parameter
(CPU-id or process-name) is ignored and the registers
for the SDA current process are displayed.
The following table replaces the I64 ISD_Labels Index Table in Chapter 10:
In the example in Section 10.3, both instances of "alpha$library"
should be changed to "sys$library."
In Section 10.4, "SDA$NEWPAGE" should be changed to "SDA$NEW_PAGE." The following routines should be added alphabetically to the existing list:
SDA$CBB_BOOLEAN_OPER
The final paragraph of the section that begins with "So, for example," should be part of the final bullet that begins with, "Some routines expect..." The following new bullet should be added to the end of the section:
4.29.36 Setting Up the Target System for ConnectionsIn Section 11.3, in the Boot Command description, the phrase "with boot command" should be changed to "with the boot command." In the paragraph before the SCD Configuration File description, the final sentence should read, "See the Boot Option Maintenance Menu, as described in the HP OpenVMS System Manager's Manual, Volume 1: Essentials. In Section 11.3, the first bullet in the XDELTA Commands Description should read:
The System Parameters description in Section 11.3 should have the following two bullets appended:
At the end of Section 11.3.2, the following should be added: The equivalent technique on I64 is as follows: Boot the system with only the SCD flag set (bit 15). When you see that the error has occurred, press Ctrl/P at the console. This action gives control to XDELTA (even though the XDELTA boot flag is not set), and you can now type 1;R. The target kernel will get control and wait for a connection for SCD. Also, the following new Section 11.3.3 should be added: The target kernel must have exclusive use of its ethernet device. Some system components, such as DECnet, will not start if the System Code Debugger is loaded. If there are multiple Ethernet devices, and the system is configured to give exclusive access of the SCD Ethernet device to the target kernel, the logical name DBGTK$OVERRIDE should be defined, indicating that the affected system components should start up as normal. The logical name can either be defined systemwide, or in the process where the startup command for the system component will be executed. In Section 11.11.1, the final sentence of the second paragraph ("To remove symbols...") should be removed. In Section 11.11.3, the second and third bullets should be removed, and the first bullet ("Access to All Executive Image Symbols") should not be a bullet. In Section 11.12, the following new paragraph should appear immediately before Example 11-1: Note that the example displays from Example 11-5 onwards are all taken from an OpenVMS I64 system. On an OpenVMS Alpha system, some of the output is different, but the commands entered are the same on both platforms, with one exception as noted in the accompanying text. Also in Section 11.12, the references to "V8.2-014" should be changed to "V8.3-003." Example 11-5 should be replaced with the following:
In Example 11-8, the final line should be replaced with the following:
Example 11-9 should be replaced with the following:
In the paragraph immediately preceding Example 11-10, the reference to line 46 should be replaced with line 93. Example 11-10 should be replaced with the following:
Example 11-11 should be replaced with the following:
In the paragraph immediately preceding Example 11-12, the reference to line 147 should be replaced with line 94, and the reference to line 146 with line 93. Example 11-12 should be replaced with the following:
In the paragraph immediately preceding Example 11-13, the following statement should be added before the closing parenthesis: The suffix _CODE0 is appended if the executive image is sliced. Example 11-13 should be replaced with the following:
In the paragraph immediately preceding Example 11-14, the reference to line 147 should be replaced with line 94, and the reference to line 146 with line 93. Example 11-14 should be replaced with the following:
In the STEP/RETURN paragraph preceding Example 11-15, the phrase "on Alpha, or the R8 register on I64" should follow "R0 register". Example 11-15 should be replaced with the following:
In the first paragraph preceding Example 11-16, the phrase "for address 80002010" should be removed, and the phrase "this image or module" replaced with "INI$BRK." The current Example 11-16 should be removed; the current Example 11-17 now becomes Example 11-16 and is replaced by the following:
The first paragraph in Section 12.4 should be replaced with the following: If SDD cannot find one of the images through this search path, a warning message is displayed. SDD will continue initialization as long as it finds at least two images. If SDD cannot find the SYS$BASE_IMAGE and SYS$PUBLIC_VECTORS files, which are the OpenVMS operating system's main image files, an error message is displayed and the debugger exits. In Section 12.10, Steps 1 and 2 should be replaced with the following:
Note that the example displays from Example 12-1 onwards are all taken from an OpenVMS I64 system. On an OpenVMS Alpha system, some of the output is different, but the commands entered are the same on both platforms. In Example 12-1, the reference to "Alpha" should change to "I64," and "V7.2-019" to "V8.3-003". Example 12-3 should be replaced with the following:
Example 12-4 should be replaced with the following:
4.29.38 OpenVMS Alpha Watchpoint UtilityOn the Part III page, the content in the "Alpha Only" note should be replaced with the following: This utility runs on OpenVMS Alpha systems only. On the first page of Chapter 13, the content in the "Alpha Only" note should be replaced with the following:
This utility runs on OpenVMS Alpha systems only.
In the format section, ARGS should be replaced with ARGUMENTS. In description of parameter FLAGS, ARGS should be replaced with ARGUMENTS. Note that these changes also affect the HP OpenVMS DCL Dictionary: N--Z.
|