| Previous | Contents | Index |
Host-based Volume Shadowing (HBVS) is Disk Mirroring is RAID Level 1.
HBVS is capable of shadowing devices of different geometries, of different block counts (with dissimilar device shadowing; allowing for mixtures of hardware) and---with dynamic volume expansion---of growing volumes on the fly, and HBVS is capable of shadowing/mirroring/raid-1 operations across cluster configurations up to the full span---please see the Cluster SPD for the current supported span; the supported span limit is currently multiple hundreds of kilometers---of a cluster. HBVS can be layered onto controller (hardware) RAID, as well.
For information on host-based striping, please see the StorageWorks
RAID product.
5.46 Encryption and Compression?
To increase the difficulty of data decryption by an unintended recipient, the process of encryption seeks to eliminate patterns---such as repeated series of characters---within the input data, while compression is the process of locating and using patterns amd repeated sequences within the data in an attempt to reduce the aggregate volume of data; encryption and compression are typically at odds.
As a rule, encryption is not particularly sensitive to the particular input data (and the process also tends to provide the same or an increased data volume out as the encrypted results), while the efficiency of compression is sensitive to the input data. You have likely already seen that some files compress better than others, and some files and some BACKUP operations that don't compress particularly efficiently with drive-level compression. (Disabling the BACKUP XOR redundancy blocks can sometimes assist with the efficiency of zip compression, too.) Encrypted data is often basically uncompressible; the better the encryption, the worse the achievable compression.
Put another way, always compress before you encrypt. If you are using
encryption with drive-level compression (drive-level compression is
commonly found on magnetic tape devices including DAT/DDS and DLT
devices), do not expect the compression to provide any significant
reduction in the volume of data as the drive-level compression is
obviously further along in the I/O pipe and downstream from the
encryption. Don't expect to achieve a 2:1 compression ratio for an
encrypted file. You may see an increase in output size with compression
enabled, and entirely disabling drive-level compression may be a
reasonable course. This assumes the drive compression logic doesn't
itself notice this and disable its own compression.
5.47 Collecting PC Samples Before Crash?
The following assumes there is an OpenVMS system-level problem, whether a hang or otherwise, and that you are going to generate a crashdump as part of debugging this. To collect PC samples before forcing the system crash, most OpenVMS VAX and OpenVMS Alpha systems can be halted and then continued from the console; basically a [CTRL/P] or [HALT], examine the PC via console-specific command, and a CONTINUE command at the OPA0: console terminal. By recording a series of sample PC values, you can often spot loops and use this data to determine exactly what is active when you are later looking at the crashdump file using the system dump analyzer (SDA, ANALYZE/CRASH).
To force the system crash, the command is usually CRASH. Certain older processors lack a console CRASH command and require a published series of console deposit commands. See the OpenVMS manuals or the manuals for your processor for details on the particular console command sequence.
Alpha systems using USB-based consoles do not reliably permit the CONTINUE, and the Integrity servers and the EFI console do not offer this console command mechanism. Other Alpha systems and the SRM console do permit the CONTINUE, as does the console found on many VAX systems.
Additionally, to ensure that you receive a crashdump during an unintended halt instruction on your VAX or Alpha system, ensure that the console AUTO_ACTION mechanism is set to RESTART,REBOOT, or the console-specific equivalent. A kernel-level halt will then trigger a restart, and the restart will fail, and the failure will trigger a crashdump, and the completion of the crashdump will trigger a reboot.
if you see the %MAIL-W-NONEWMAIL, no new messages error reported when MAIL indicates you have messages, then the NEWMAIL count has become skewed from reality.
The count of new mail messages is kept separately from your mail folder, and is stored in VMSMAIL_PROFILE.DATA. It sometimes happens that this count differs from what is stored in your mail folder. If this arises, invoke MAIL and repeatedly enter the READ/NEW command (or press the keypad hyphen key on an LK-compatible keyboard) until you see no new mail messages. Then enter the command one more time. This will resynchronize the counters.
If you are operating in a cluster and find your mail counts inconsistent across cluster members, your customer is likely missing a definition of the VMSMAIL_PROFILE logical name---and is probably also missing definitions of other logical names associated with other shared files---or has one or more inconsistent definitions of this and likely of other logical names.
For details on the configuration data files that must be shared within
a cluster, please see SYS$STARTUP:SYLOGICALS.TEMPLATE on V7.2 and later.
6.2 How do I send or read attachments in VMS MAIL?
Is there any way to send or read mail with files as attachments from VMS?
Not directly with the OpenVMS MAIL facility, but there are several other options:
Use the anti-spam capabilities present in the TCP/IP Services V5.1 and later SMTP servers.
Use a firewall.
On earlier TCP/IP Services releases, some simple DCL can reportedly prevent relay SMTP spam. Use the UCX command SHOW SERVICE SMTP/FULL to find the directory containing the UCX$SMTP_RECV_STARTUP.COM file, and insert the following DCL:
$ !
$ ! Block spam.
$ !
$ MY_ADDRESS_LONG[0,32]=F$INTEGER(F$TRNLNM("SYS$REM_NODE")-"::")
$ MY_ADDRESS=F$FAO("!UB.!UB.!UB.!UB",F$CVUI(0,8,MY_ADDRESS_LONG),-
F$CVUI(8,8,MY_ADDRESS_LONG),F$CVUI(16,8,MY_ADDRESS_LONG),-
F$CVUI(24,8,MY_ADDRESS_LONG))'"
$ MY_ADDRESS_REVERSE=F$FAO("!UB.!UB.!UB.!UB",-
F$CVUI(24,8,MY_ADDRESS_LONG),F$CVUI(16,8,MY_ADDRESS_LONG),-
F$CVUI(8,8,MY_ADDRESS_LONG),F$CVUI(0,8,MY_ADDRESS_LONG))'"
$ WRITE SYS$OUTPUT F$TIME()+" "+F$TRNLNM("SYS$REM_NODE")+MY_ADDRESS
$ UCX SHOW HOST 'MY_ADDRESS_REVERSE'.INPUTS.ORBS.ORG
$ IF $STATUS.EQ.1
$ THEN
$ WRITE SYS$OUTPUT "SPAM from relay rejected"
$ EXIT
$ ENDIF
$ UCX SHOW HOST 'MY_ADDRESS_REVERSE'.SPAMSOURCES.ORBS.ORG
$ IF $STATUS.EQ.1
$ THEN
$ WRITE SYS$OUTPUT "SPAM source relay rejected"
$ EXIT
$ ENDIF
$ !
$ ! Run receiver.
$ !
$ run sys$system:ucx$smtp_receiver.exe
$ goto exit
|
If you've installed the DECwindows examples, you'll find DECW$CDPLAYER.C, .DAT, .EXE, .UIL, and .UID. Copy the .UID and .DAT files to DECW$USER_DEFAULTS: (typically SYS$LOGIN:), define the logical name DECW$CD_PLAYER to be the device name of your CD-ROM drive (eg. DKA400:), give yourself PHY_IO and DIAGNOSE privileges, and run the .EXE. (These privileges are required, as the access to the CD-related extensions will require the use of the privilege-protected IO$_DIAGNOSE I/O function code.) You can also install the image with these privileges. See the source for additional details - note that the comments regarding the need for SYSGEN CONNECT are no longer applicable (at least as of VMS V5.5-2).
There's also SYS$EXAMPLES:CDROM_AUDIO.C and .EXE, a non-Motif program, available on OpenVMS VAX, and DECW$EXAMPLES:DECW$CDPLAYER.* on OpenVMS VAX and OpenVMS Alpha.
The standard OpenVMS ATA (IDE) SYS$DQDRIVER device driver does not support the necessary does not support the necessary IO$_DIAGNOSE function code that is required for access to audio CD media commands (on OpenVMS versions prior to V7.3), but an updated SYS$DQDRIVER device driver (source code and all) with this capability and with the source code of an updated DECW$CDPLAYER CD audio player is available on the OpenVMS Freeware website (www.hp.com/go/openvms/freeware/, look for the directory /dqdriver/), and these updates are also included on OpenVMS Freeware V5.0, and OpenVMS ECO kits containing newer versions of the driver are available. Freeware V6.0 has a version of DQDRIVER that is newer than that of the OpenVMS Alpha V7.3-2 release, with additional capabilities and with improved error diagnostics.
OpenVMS Alpha V7.3 and later include a version of SYS$DQDRIVER with the
necessary IO$_DIAGNOSE support.
7.2 How do I access a Microsoft Windows floppy disk from OpenVMS?
The HP Advanced Server (formerly known as PATHWORKS) for OpenVMS product includes an unsupported and undocumented utility called PCDISK, and this tool can read and write various Microsoft MS-DOS and Microsoft Windows FAT-format diskettes, and can usually access FAT-format volumes written by other operating systems.
ProGIS in Germany sells a product called VMove which supports DOS files on many different device types. For more information, send mail to info@progis.de.
Engineering Software has a product called VAKSAT which will read, write, and erase files on MS-DOS FAT diskettes. Available for both VAX and Alpha. Contact ed@cityscape.co.uk for more information.
MadGoat PC Exchange (PCX) is a utility for copying files to and from MS-DOS and Microsoft Windows (FAT) format diskettes under OpenVMS, using an RX23 (3.5"), RX26 (3.5"), or RX33 (5.25") diskette drive. For 3.5" diskettes, high-density disks can be read or written; double-density disks are read-only. Only high-density disks are supported on the RX33.
The Freeware package WINFX is available on Freeware V6.0, and can read the FAT volume structure.
Various of the more recent AlphaStation systems use a different sound board (Microsoft Sound System) than the earlier DEC 3000 series systems, and DECsound, as supplied by DECwindows Motif, doesn't support this board nor this interface. HP offers an optional product, Multimedia Services (MMOV) for OpenVMS:
which provides a replacement for DECsound for this card as well as many other features (an AVI and MPEG player, video capture support, etc.)
Ensoniq sound support is also available.
7.4 How do I read IBM EBCDIC tapes on OpenVMS?
Most (all?) IBM EBCDIC-based systems can read and write ANSI-labeled ASCII magtapes. Fixed-length records (MOUNT /FOREIGN /BLOCKSIZE=512 /RECORDSIZE=512, for one-block records) and the DCL COPY command can be used to transfer fixed-record-size text files out onto tape media, or to read from fixed-record tape media. Please consult the IBM documentation for the details and command syntax needed when reading and writing ANSI media using IBM JCL or other applicable IBM command language.
There exists various freeware around (TAPECOPY, ETAPE, TCOPY, MTEXCH) that can read and write EBCDIC tapes. Visit the Encompasserve (DECUS) website software archives search engine and search for "EBCDIC" for details.
OpenVMS does not include an integrated tool for EBCDIC tape processing, but does provide a character conversion API useful within application programs.
One source for ETAPE is:
The OpenVMS Freeware V5.0 distribution included this ETAPE tool, as
well.
7.5 How can I patch an OpenVMS Alpha image?
Using the OpenVMS Freeware tool ZAP:
tell ZAP to read a block (bucket) of information based on the virtual block number (VBN), using X for hexadecimal. Dump yourself into the OpenVMS debugger with R2 pointing into the buffer, EXAMINE/INSTRUCTION as needed, alter the buffer as required, GO to get out of the debugger and back into ZAP, and use the ZAP W command to write the updated block.
DCL symbols are programming-style variables implemented within the DCL command interpreter, and these are used both for programming and to provide command verb synonyms. Symbols are local to the command interpreter operating within a particular process, and are not shared. Lists of symbols can be copied into subprocesses during a subprocess creation operation, but these symbols are neither copied back into the parent process when the subprocess exits, nor are symbols ever shared across processes.
Symbols can be specified in and utilized in basic mathematical operations, and bit-level operations are available with the f$cvsi and f$cvui bit extraction lexical functions, and with the square-brackets notation for bit insertion (see Section 8.13 for an example), and with bitwise operators. Symbols are of two basic types, STRING and INTEGER, and these (or an undefined symbol) can be differentiated with the f$type lexical function. DCL symbols can also be used as a mechanism to abbreviate a DCL command verb, or an easy way to invoke a DCL command procedure.
Symbols can have local or global scope within a process, and scope is affected by nested procedure calls and DCL constructs such as CALL and SET SCOPE, but such discussions are beyond the scope of this section.
OpenVMS Logical names can store device names, device and directory specifications, rooted or searchlist specifications, and full filenames. Logical names can also store arbitrary data, but there are no native mathematical or bitwise operators available. Analogous to DCL symbols, process-local logical names can be copied into subprocesses during a subprocess creation operation, but these process-local logical names are neither copied back into the parent process when the subprocess exits, nor are these logical names ever shared.
Logical names are implemented deep within the OpenVMS executive, and are organized into logical name tables. Logical names can be stored in tables private to a process( LNM$PROCESS, the process-local logical name table) , that can be shared among processes in the same job tree ( LNM$JOB, the job logical name table) or in logical name tables that are shared among larger groups of processes (eg: LNM$GROUP, the UIC group logical name table and LNM$SYSTEM, the system-wide logical name table). Logical names are centrally intended to provide various I/O-related capabilities, including device independence and configuration customization---correctly-written application programs can use logical names to avoid embedding specific device or device and directory specifications, and to allow filename and configuration customizations.
One of the most powerful capabilities of logical names beyond the device independence provided involves the defaulting capabilities; you can use RMS parsing (directly, or with mechanisms such as the f$parse lexical function) to provide a filename and a default filename. To provide the mechanism that allows SYSUAF to be located in an arbitrary position or even an arbitrary filename, a construct similar to the following is used:
$ UAF = F$PARSE("SYSUAF","SYS$SYSTEM:.DAT")
|
This design allows the logical name SYSUAF to be optionally defined, and -- when present---to specify the particular location and name of the file. Portions of the full file specification that are omitted are retrieved using the default translation of SYS$SYSTEM: and the file type of .DAT.
Logical names also have assigned processor modes, as some translations must be trustworthy. In the example above, only trusted and privileged system users should be able to redirect the SYSUAF authorization database, so any definition of the SYSUAF logical name must be made in EXECUTIVE mode in a trusted logical name table.
As for common OpenVMS terminology, logical names are "defined" and the associated processing is refered to as "translation", while symbols are "equated" and the associated processing is refered to as "substitution". "Lexical functions" are processing routines built into DCL, and typically prefixed with f$. Many of the lexical functions are built upon correspondingly-named system services, though not all.
Symbol substitution occurs only when the DCL command interpreter is reading and processing the command input; for information on DCL symbol substitution, see Section 8.10. For program access, see the RTL routines lib$set_symbol and lib$get_symbol.)
For information on logical name translation, please see f$trnlnm lexical function and the DCL commands DEFINE and DEASSIGN, as well as underlying system services such as sys$trnlnm. Logical name translation occurs when requested, or as the file or I/O operation is started.
Please see the OpenVMS User's Guide in the OpenVMS documentation set for a far more detailed description of these constructs.
For related materials, please see Section 8.10 and Section 8.11.
8.2 How do I run a program with arguments?
The RUN command does not accept arguments. To pass arguments to a program, you must use what is called a "foreign command", and either an explicit command as shown here, or an automatic foreign command. For example:
$ unzip :== $disk:[dir]unzip.exe $ unzip -? |
The leading $ in the equivilence name for the symbol definition is what makes the DCL symbol a foreign command. If the device and directory are omitted, SYS$SYSTEM: is assumed.
Under OpenVMS V6.2 and later, DCL supports automatic foreign command definition via the logical name DCL$PATH. An example of a definition of this logical name is:
$ DEFINE DCL$PATH SYS$DISK:[],ddcu:[mytooldir],SYS$SYSTEM: |
DCL will first look for a command in the DCL command table, and if no match is found and if DCL$PATH is defined, it will then look for command procedures and executable images with filenames matching the command specified, in the directories specified via DCL$PATH. The first match found is invoked, and under OpenVMS, the DCL$PATH support will cause a command procedure to be activated in preference to an executable image.
For more information on foreign commands or on automatic foreign command support, see the OpenVMS User's Manual.
See also Section 10.3.
If you want to create a detached process that takes arguments from a command line, it must be run under the control of a command line interpreter (CLI) (typically DCL). This is done by placing the command line in a file, specifying SYS$SYSTEM:LOGINOUT.EXE as the image to run and the command file as the input. For example:
$ OPEN/WRITE CMD TEMP_INPUT.COM $ WRITE CMD "$ MYCOMMAND arguments" $ CLOSE CMD $ RUN/DETACHED SYS$SYSTEM:LOGINOUT /INPUT=TEMP_INPUT.COM |
Various OpenVMS library calls (such as lib$spawn(), cli$dcl_parse(), and the C library system() call) require access to a command line interpreter such as DCL to perform requested actions, and will not operate if a CLI is not available.
When a CLI is not available, these calls typically return the error status SS$_NOCLI. And as mentioned above, invoke the image LOGINOUT to cause a CLI (such as DCL) to be mapped into and made available in the context of the target process.
For examples of how TCP/IP Services sets up its foreign commands (which includes tools such as uuencode and uudecode), please see the DCL command procedure SYS$STARTUP:TCPIP$DEFINE_COMMANDS.COM.
Also see Section 8.12.
| Previous | Next | Contents | Index |