| Previous | Contents | Index |
The DCL symbol substitution processing occurs only at the DCL prompt, not within data and not within files. If you wish to perform symbol substitution in this environment, you typically write a small file containing the command(s) and data to be invoked---potentially only the data---and you then invoke the created procedure or reference the specified data.
In this case, use of a file containing nolinemode commands or other techniques might be useful---you will want to ensure that the text editor you use does not attempt to use screen mode or similar, as this is not generally considered adventageous within a command procedure.
Tools such as FTP have alternatives: COPY/FTP.
DCL symbol substitution occurs in two passes, using the ampersand and the apostrophe. In most cases, only the apostrophe is necessary. In a few cases---such as the DCL PIPE command---you will may need to use the ampersand to get the substitution to work. The following example uses ampersand substitution to transfer the contents of the header into a logical name:
$ PIPE CC/VERSION | (READ SYS$PIPE hdr ; DEFINE/JOB/NOLOG hdr &hdr ) |
A logical name (in the job logical name table; shared by all processes
in the current job) was used as DCL symbols cannot be returned back out
from a DCL PIPE or other spawned subprocess.
13.11 Where can I get Perl for OpenVMS?
OpenVMS support is included in the standard distribution of Perl, the popular scripting language created by Larry Wall. In addition to nearly all of the functionality available under Unix, OpenVMS-specific Perl modules provide interfaces to many native features, as well as access to Oracle, Ingres, and Sybase databases via the Perl DBI available on OpenVMS.
A website useful for getting started with Perl on OpenVMS---where you will find such things as download links, instructions, auxiliary tools, and sample scripts---is available at:
If you have a C compiler, the best way to obtain Perl is to download and build it yourself. The latest production quality source kit is available from:
You will need GUNZIP and VMSTAR (both available from the OpenVMS Freeware CD, or from other sites) to unpack the archive; once you've done that, read the instructions in the README.vms file.
Binary distributions for most Alpha and VAX environments are available on the OpenVMS Freeware CD-ROM and from various websites, including the following:
During active Perl development cycles, test kits are sometimes found at: from:
Watch the mailing list (see below) for details on experimental releases.
Charles Lane maintains pages on how to write CGI scripts in Perl for the OSU HTTP server, as well as more general tips, tricks, and patches for building and running Perl on OpenVMS:
There are OpenVMS-specific Perl modules that implement interfaces to a subset of the VMS System Services. With these modules, you can get (and often set) device, job, queue, user, system, and performance information. The lock manager, RMS indexed files, screen management utilities, and Intracluster Communication Services are also accessible via Perl. The relevant modules are all available from:
To subscribe to the OpenVMS Perl mailing list (a discussion forum for both user support and new development), send an email message to vmsperl-subscribe@perl.org
The mailing list archives may be searched at:
The DECmigrate image translation family provides tools that translate OpenVMS VAX images for use on OpenVMS Alpha, and OpenVMS Alpha images for use on OpenVMS I64, Details are available at:
VEST is the name sometimes given to the DECmigrate translation tool for VAX images, AEST is the name given to the Alpha translation tools, and TIE names the DECmigrate run-time environment within OpenVMS. (If you've ever noticed images with filenames ending with _TV and wondered what this meant, these images are part of TIE.) And yes, you can use AEST to re-translate images that were translated using VEST; you can perform a second translation of a VAX image.
Please see Section 7.4 and Section 13.14 for related information.
Please see the website for the most current details on availability and
plans and status of translations for OpenVMS I64 platforms.
13.13 Where can I get Zip, Unzip, self-extracting zip, etc?
Many packages are provided in ZIP, GZIP, or BZIP2 format, which requires you to acquire the associated unzip tool to unpack it. You can get ZIP and UNZIP and related and similar tools from the following areas:
or you can request the FILESERV_TOOLS package from the e-mail server.
Beware: The [000TOOLS...] pre-built versions of ZIP on the OpenVMS Freeware V4 CD-ROM will erroneously return BILF errors on OpenVMS V7.2 and later. Use the source on the Freeware V4 to rebuild the ZIP image(s), or (better) acquire a far newer Zip kit from a more recent Freeware, or elsewhere. The pre-built version of ZIP on the Freeware V4 kit is older than the included ZIP sources, and comparatively buggy.
Directions for creating and using the sfx self-extracting zip file compression mechanism are available in the unzip kit that is available at:
If you want to build the zip images for yourself (eg: for an older OpenVMS version), pull over the entire contents of a recent unzip directory.
HP OpenVMS Engineering uses a tool known as FTSV for creating
self-extracting compressed files using the OpenVMS DCX compression
tools, as seen with various OpenVMS ECO (patch) kits. sfx provides
better compression than does DCX. The FTSV and its related FTSO package
have only limited availability outside HP, and are not standard
products.
13.14 Are VAX Hardware Emulators Available?
Software-based emulators of the VAX architecture and for specific VAX hardware platforms are available from various sources:
VAX emulators that operate on PC systems and/or on OpenVMS Alpha systems are available. For information on an alternative to using a VAX emulator--- on the available DECmigrate VAX executable image translator---please see Section 13.12.
In terms of software, very few. As of OpenVMS V6.1, the VAX and Alpha platforms are very close to "feature parity". OpenVMS on IA-64 is expected to have "feature parity" with OpenVMS Alpha, and is based on the same source pool. Most applications can just be recompiled and run. Some differences to be aware of:
There are also a number of manuals which discuss migration to OpenVMS Alpha available on the documentation CD-ROM media, both in the main documentation and in the archived documentation section.
On more recent OpenVMS Alpha versions, OpenVMS Alpha has begun to add features and support not available on OpenVMS VAX. Salient new areas include the following:
Please see Section 14.4.5 for Intel Itanium terminology.
14.2 Seeking performance information for Alpha (and VAX) systems?
HP makes a wide range of performance documents available through its FTP and WWW Internet servers (see Section 3.2).
The following contain information on current Alpha and VAX products:
The following sites contain information on various retired VAX and Alpha products:
Also see CPU2000:
This section contains information on VAX and Alpha consoles, and
details related to console commands, serial lines, and configuration
settings.
14.3.1 What commands are available in the Alpha SRM console?
In addition to the normal BOOT commands and such (see Section 14.3.5.2 for some details) and the normal contents of the console HELP text, operations such as I/O redirection and floppy disk access are possible at the SRM console prompt:
>>> show * > env.dat >>> show conf > conf.dat >>> cat env.dat > fat:env.dat/dva0 >>> cat conf.dat > fat:conf.dat/dva0 |
>>> ls fat:env.dat/dva0 >>> ls fat:conf.dat/dva0 |
The abbreviation SRM is derived from the Alpha System Reference Manual, the specification of the Alpha architecture and the associated firmware.
PALcode is a name assigned to a particular set of functions provided by
the SRM firmware. PALcode is used to provide low-level functions
required by higher-level operating system or application software,
functions which may not be directly available in Alpha hardware.
PALcode is implemented using available Alpha instructions and using the
Alpha processor, though PALcode operates in a mode which simplifies
programming. PALcode is also permitted access to processor-specific and
otherwise internal features of a particular Alpha microprocessor
implementation; microprocessor-specific features which are not easily
accessable to operating system or application code.
14.3.3 Alpha COM ports and VAX console serial line information?
This section contains information on the Alpha COM communication ports,
and related settings, as well as on the VAX console bulkhead and VAX
console serial line connection.
14.3.3.1 Which terminal device name is assigned to the COM ports?
COM2 is normally TTA0:. COM1 is normally TTB0: if the Alpha workstation is booted with the SRM console environment variable set to graphics, and is OPA0: if the console is set to serial.
On the DEC 2000 series (sometimes incorrectly known by the name of the system as sold for Microsoft Windows NT Alpha; as the DECpc 150 AXP series) on older OpenVMS Alpha releases, COM1 through COM4 are known as OPA0: through OPA3:. On all current OpenVMS releases, these ports are serviced by the terminal driver and not by the console OPDRIVER driver.
Often the easiest way to determine the OpenVMS terminal name assigned to the port is to connect a terminal, log in interactively, and look at the output of SHOW TERMINAL. (Device names can vary by OpenVMS version, as well as by the SRM console environment variable selection.)
For serial console hardware and related information, and for pin-outs
and related information, please see Section 14.3 and Section 14.27.
14.3.3.2 Which serial port is the console on the MicroVAX 3100?
Just to keep life interesting, the MicroVAX 3100 has some
"interesting" console ports behaviours based on the setting
of the BREAK enable switch. When the console is not enabled to respond
to BREAK, MMJ-1 is the console port. MMJ-3 will (confusingly) output
the results of the selftest in parallel with MMJ-1. When the console is
enabled to respond to BREAK, MMJ-3 becomes the console port, and MMJ-1
will (confusingly) output the results of selftest in parallel with
MMJ-3.
14.3.3.3 How can I set up an alternate console on a VAXstation?
Most VAXstation series systems and a few Alpha series systems have a switch -- most often labeled S3, largely for historical reasons---that enables one of the serial lines as the system console device; as OPA0:. This disables console output to the graphics display. (For a related behaviour, please see Section 11.10.)
All VAXstation 3100 series systems provide a S3 slide switch, though the oldest may be missing the cut-out through the enclosure that provides access to the switch. The slide switch is located near the diagnostic LED display. (The slide switch is accessable with the cover removed.)
Various members of the DEC 3000 series Alpha systems also have a similarly-labled S3 switch for selection of the alternate console.
The particular port that becomes the console can vary. The printer MMJ connection is used on all VAXstation 3100 series. On VAXstation II, the console DB9 is used, rather than the graphics display. On most (all?) AlphaStation series systems, typically the COM1 serial port becomes the console.
Also see Section 14.3.6, Section 11.10, and Section 14.19. Beware the two different DB9 pin-outs; see Section 14.28 for related details.
For information on registering software license product authorization
keys (PAKs), please see Section 5.6.2.
14.3.3.4 Please explain the back panel of the MicroVAX II
The MicroVAX-series console bulkhead interface was used with the KA630, as well as with the KA650 and KA655 processors.
There are three controls on the console bulkhead of these systems:
Triangle-in-circle-paddle: halt enable.
dot-in-circle: halt ([break]) is enabled,
and auto-boot is disabled.
dot-not-in-circle: halt ([break]) is disabled,
and auto-boot is enabled.
Three-position-rotary: power-up bootstrap behaviour
arrow: normal operation.
face: language inquiry mode.
t-in-circle: infinite self-test loop.
Eight-position-rotary: console baud rate selection
select the required baud rate; read at power-up.
|
There are several different bulkheads involved, including one for the BA23 and BA123 enclosures, and one for the S-box (BA2xx) series enclosure. The console bulkheads typically used either the MMJ serial line connection, or the MicroVAX DB9 (not the PC DB9 pin-out), please see the descriptions of these in section WIRES1. For available adapters, see Section 14.28.
Also present on the console bulkhead is a self-test indicator: a
single-digit LED display. This matches the final part of the countdown
displayed on the console or workstation, and can be used by a service
organization to determine the nature of a processor problem. The
particular countdown sequence varies by processor type, consult the
hardware or owner's manual for the processor, or contact the local
hardware service organization for information the self-test sequence
for a particular processor module. Note that self-tests 2, 1 and 0 are
associated with the transfer of control from the console program to the
(booting) operating system.
14.3.4 What are Alpha console environment variables?
Alpha systems have a variety of variables with values set up within the SRM system console. These environment variables control the particular behaviour of the console program and the system hardware, the particular console interface presented to the operating system, various default values for the operating system bootstrap, and related control mechanisms---in other words, "the environment variables provide an easily extensible mechanism for managing complex console state."
The specific environment variables differ by platform and by firmware version---the baseline set is established by the Alpha Architecture:
AUTO_ACTION ("BOOT", "HALT", "RESTART", any other value
assumed to be HALT), BOOT_DEV, BOOTDEF_DEV, BOOTED_DEV,
BOOT_FILE, BOOTED_FILE, BOOT_OSFLAGS, BOOTED_OSFLAGS,
BOOT_RESET ("ON", "OFF"), DUMP_DEV, ENABLE_AUDIT ("ON",
"OFF"), LICENSE, CHAR_SET, LANGUAGE, TTY_DEV.
|
OpenVMS Galaxy firmware can add console environment variables beginning with such strings as LP_* and HP_*, and each particular console implementation can (and often does) have various sorts of platform-specific extensions beyond these variables...
The contents of a core set of environment variables are accessible from
OpenVMS using the f$getenv lexical and the sys$getenv system service.
(These calls are first documented in V7.2, but have been around for
quite a while.) Access to arbitary console environment variables is
rather more involved, and not directly available.
14.3.5 What are the boot control flag values?
Both VAX and Alpha primary bootstraps support flag values; a mechanism
which permits the system manager to perform specific customizations or
site-specific debugging of the OpenVMS system bootstrap. While very
similar, there are differences among the boot flag implementations for
the various architectures.
14.3.5.1 What are the I64 IPB boot flag values?
The OpenVMS I64 primary bootstrap flags are processed within the IA-64 primary bootstrap image IPB.EXE; within the SYS$EFI.SYS structures. The primary bootstrap boot flags are largely parallel to those of OpenVMS Alpha (see Section 14.3.5.2, though the console and the console mechanisms used to specify the boot command, the boot flags, and boot command options do differ markedly.
When you register an EFI boot alias (please see Section 14.4.5 for Intel Itanium terminology), you will be asked if you want to enter boot options, and what type. To add boot flags to a boot alias, select Unicode as the boot options type, and enter an SRM-like options string, such as the conversational bootstrap selected by the following example:
-fl 0,1 |
| Previous | Next | Contents | Index |