| Previous | Contents | Index |
BACKUP savesets can be corrupted by FTP file transfers and by tools such as zip (particularly when the zip tool has not been asked to save and restore OpenVMS file attributes or when it does not support OpenVMS file attributes), as well as via other means of corruptions.
If you have problems with the BACKUP savesets after unzipping them or after an FTP file transfer, you can try restoring the appropriate saveset attributes using the tool:
$ @RESET_BACKUP_SAVESET_FILE_ATTRIBUTES.COM |
This tool is available on the OpenVMS Freeware (in the [000TOOLS] directory). The Freeware is available at various sites---see the Freeware location listings elsewhere in the FAQ---and other similar tools are also available from various sources.
In various cases, a SET FILE/ATTRIBUTES command can also be used. As the parameters of this command must be varied as the target BACKUP saveset attributes vary, this approach is not recommended.
Also see the "SITE VMS", /FDL, and various other file-attributes options available in various FTP tools. (Not all available FTP tools support any or all of these options.)
Browser downloads (via FTP) and incorrect (binary or ascii FTP transfer modes) are notorious for causing RMS file corruptions and particularly BACKUP saveset corruptions. You can sometimes help encourage the browser to select the correct FTP transfer type code (via RFC1738):
You can also often configure the particular web browser to choose the
appropriate transfer mode by default, based on the particular file
extensions, using a customization menu available in most web browsers.
You can select that the specific file extentions involved use the FTP
binary transfer mode, which will reduce the number of corruptions seen.
5.41.5 How do I write a BACKUP saveset to a remote tape?
How to do this correctly was described at DECUS long ago. On the OpenVMS host with the tape drive, create the following SAVE-SET.FDL file:
RECORD
FORMAT fixed
SIZE 8192
|
Then create BACKUP_SERVER.COM:
$ ! $ ! BACKUP_SERVER.COM - provide remote tape service for BACKUP. $ ! $ set noon $ set rms/network=16 $ allocate mka500 tapedev $ mount/nounload/over:id/block=8192/assist tapedev $ convert/fdl=SAVE-SET sys$net tapedev:save-set. $ dismount/unload tapedev $ stop/id=0 |
On the node where you want to do the backup, use the DCL command:
$ backup -
srcfilespec -
node"user pwd"::"task=backup_server"/block=8192/save
|
One area which does not function here is the volume switch; multi-reel or multi-cartridge savesets. Since the tape is being written through DECnet and RMS and the magtape ACP, BACKUP won't see the media switch and will split an XOR group across the reel boundary. BACKUP might well be willing to read such a multi-reel or multi-cartridge saveset (directly, not over the net) as the XOR blocks are effectively ignored until and unless needed for error recovery operations. BACKUP likely will not be able to perform an XOR-based recovery across reel or cartridge boundaries.
Unfortunately BACKUP can't read tapes over the network because the RMS
file attributes on a network task access look wrong; the attributes
reported include variable length records.
5.41.6 How to perform a security disk erasure?
Sometimes refered to as disk, tape, or media declassification, as formatting, as pattern erasure, or occasionally by the generic reference of data remanence. While initially easy, characteristics of the media and of the device error recovery and bad block handling can make this effort far more difficult than it might initially appear.
Security and sensitivity of the data is central to this discussion, as is the value of the storage hardware involved---with data of greater value than the disks involved, physical destruction of the platters may be the most expedient, economical, and appropriate approach.
Other potential options include the Freeware RZDISK package, the
OpenVMS INITIALIZE/ERASE command (and potentially in conjunction with
the $erapat system service)
and OpenVMS Ask The Wizard topics such as (841), (3926), (4286),
(4598), and (7320).
5.41.7 How to enable telnet virtual terminals?
To enable virtual terminal support for telnet and rlogin devices, add the following logical name definitions into SYLOGICALS.COM:
$ DEFINE/SYSTEM/EXECUTIVE TCPIP$RLOGIN_VTA TRUE $ DEFINE/SYSTEM/EXECUTIVE TCPIP$TELNET_VTA TRUE |
See SYS$STARTUP:SYLOGICALS.TEMPLATE for details on the typical contents of SYLOGICALS.COM.
In SYSTARTUP_VMS.COM, ensure that a command similar to the following is invoked:
$ SYSMAN IO CONNECT VTA0/NOADAPTER/DRIVER=SYS$LOADABLE_IMAGES:SYS$TTDRIVER.EXE |
In MODPARAMS.DAT, add the following line or (if already present) mask the specified hexidecimal value into an existing TTY_DEFCHAR2, and perform a subsequent AUTOGEN with an eventual reboot:
TTY_DEFCHAR2 = %X20000 |
This value is TT2$M_DISCONNECT.
On older TCP/IP Services---versions prior to V5.0---you will have to perform the following UCX command:
$ UCX UCX> SET CONF COMM/REMOTE=VIRTUAL |
MiniMerge support has been available for many years with OpenVMS host-based volume shadowing, so long as you had MSCP controllers (eg: HSC, HSJ, or HSD) which supported the Volume Shadowing Assist known as "Write History Logging".
If you are interested in minimerge and similar technologies, please see the Fibre Channel webpage and the information available there:
Minimerge support was originally expected with HSG80 series storage controllers and was expected to require ACS 8.7 and OpenVMS Alpha V7.3-1. These plans, the original design, and the implementation that was under development have been revisited, and it is expected that a future OpenVMS release will implement minimerge using the existing storage bitmaps technologies; using a different, new and controller-independent design.
Updated information and the current progress of the development work on minimerge is not available as of this writing.
The following sections describe both MiniCopy and MiniMerge, and can
provide a basis for discussions.
5.41.7.1.1 MiniCopy?
A Shadowing Full Copy occurs when you add a disk to an existing shadowset using a MOUNT command; the entire contents of the disk are effectively copied to the new member (using an algorithm that goes through in 127-block increments and reads one member, compares with the target disk, and if the data differs, writes the data to the target disk and loops back to the read step, until the data is equal for that 127-block section). (This is one of the reasons why the traditional recommendation for adding new volumes to a shadowset was to use a BACKUP/PHYSICAL copy of an existing shadowset volume, simply because the reads then usually matched and thus shadowing usually avoided the need for the writes.)
If you warn OpenVMS ahead of time (at dismount time) that you're
planning to remove a disk from a shadowset but re-add it later, OpenVMS
will keep a bitmap tracking what areas of the disk have been modified
while the disk was out of the shadowset, and when you re-add it later
with a MOUNT command OpenVMS only has to update the areas of the
returned disk that the bit-map indicates are now out-of-date. OpenVMS
does this with a read source / write target algorithm, which is much
faster than the shenanigans the Full Copy does, so even if all of the
disk has changed, a MiniCopy is faster than a Full Copy.
5.41.7.1.2 MiniMerge?
A Shadowing Merge is initiated when an OpenVMS node in the cluster (which had a shadowset mounted) crashes or otherwise leaves unexpectedly, without dismounting the shadowset first. In this case, OpenVMS must ensure that the data is identical, since Shadowing guarantees that the data on the disks in a shadowset will be identical. In a regular Merge operation, Shadowing uses an algorithm similar to the Full Copy algorithm (except that it can choose either of the members' contents as the source data, since both are considered equally valid), and scans the entire disk. Also, to make things worse, for any read operations in the area ahead of what has been merged, Shadowing will first merge the area containing the read data, then allow the read to occur.
A Merge can be very time-consuming and very I/O intensive, so some controllers have Shadowing Assists to make it faster. If the controllers support Write History Logging, the controllers record the areas (LBNs) that are the subject of Shadowing writes, and if a node crashes, the surviving nodes can query the controllers to find out what exact areas of the disk the departed node was writing to just before the crash, and thus Shadowing only needs to merge just those few areas, so this tends to take seconds as opposed to hours for a regular Merge.
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.
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.
The new 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. HP offers an optional product, Multimedia Services for OpenVMS:
which provides a replacement 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 Why is DECmigrate not working with Fortran?
%OTS-F-INDATCOR internal data corrupted in Run-time Library |
This error can arise with Fortran programs if you are running a recent version of OpenVMS Alpha, and are using DECmigrate to translate Fortran applications. The DECmigrate Run-Time Library attempts to support mixed translated-native I/O to the same unit by sharing the native Fortran RTL's internal data structures, and in OpenVMS 7.2 these structures changed and the translated RTL was not updated accordingly.
You can copy DEC$FORRTL.EXE from OpenVMS 7.1, copying it to some spare directory, and then defining the logical name DEC$FORRTL to point to it before running your translated application. Or rebuilding the application to use the available native Fortran compiler. Or you can apply the current Fortran RTL kit, which has a fix for this.
See Section 13.11.
7.5 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 (via http://www.decus.org/), 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.6 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.
| Previous | Next | Contents | Index |