| Previous | \Contents | ^Index |
G If you are seeing more files backed up than previously, you are seeing E the result of a change that was made to ensure BACKUP can perform an G incrementation restoration of the files. In particular, if a directory H file modification date changes, all files underneath it are included in @ the BACKUP, in order to permit incremental restoration should a directory file get renamed. ` 5.42.1.1 Why has OpenVMS gone through the agony of this change?
D When a directory is renamed, the modified date is changed. When the E restoration needs to restore the directory and its contents, and the H restoration should not result in the restoration of the older directory @ name when a series of incremental BACKUPs are restored. Thus an A incremental BACKUP operation needs to pick up all of the changes.
H Consider performing an incremental restoration, to test the procedures. E This testing was how OpenVMS Engineering found out about the problem ? that was latent with the old BACKUP selection scheme---the old H incremental BACKUP scheme would have missed restoring any files under a @ renamed directory. Hence the change to the selection mechanisms D mentioned in Section 5.42.1. T 5.42.1.2 Can you get the old BACKUP behaviour back?
A Yes, please see the /NOINCREMENTAL qualifier available on recent F OpenVMS versions (and ECO kits). Use of this qualifier informs BACKUP B that you are aware of the limitations of the old BACKUP behaviour % around incremental disk restorations. T 5.42.2 What can I do to improve BACKUP performance?
E Use the documented commands in the manual for performing incremental E BACKUPs. Use the documented incremental procedures. Don't try to use 2 incremental commands in a non-incremental context.
G Also consider understanding and then using /NOALIAS, which will likely G be a bigger win than will anything to do with the incremental BACKUPs, H particularly on system disks and any other disks with directory aliases.
: See the OpenVMS V6.2 release notes for additional details. K 5.42.3 Why is BACKUP not working as expected?
% First, PLEASE READ THE BACKUP MANUAL.
. Second, PLEASE GET THE CURRENT BACKUP ECO KIT.
; Third, PLEASE SET THE PROCESS QUOTAS PER THE DOCUMENTATION.
D BACKUP has a very complex interface, and there are numerous command H examples and extensive user documentation available. For a simpler user ; interface for BACKUP, please see the documentation for the BACKUP$MANAGER tool.
2 As for recent BACKUP changes, oddities, bugs, etc:
+ When working with BACKUP, you will want to:
* When working with the BACKUP callable API:
D BACKUP savesets can be corrupted by FTP file transfers and by tools G such as zip (particularly when the zip tool has not been asked to save H and restore OpenVMS file attributes or when it does not support OpenVMS < file attributes), as well as via other means of corruptions.
F If you have problems with the BACKUP savesets after unzipping them or B after an FTP file transfer, you can try restoring the appropriate " saveset attributes using the tool:
|
" , $ @RESET_BACKUP_SAVESET_FILE_ATTRIBUTES.COM |
B This tool is available on the OpenVMS Freeware (in the [000TOOLS] A directory). The Freeware is available at various sites---see the D Freeware location listings elsewhere in the FAQ---and other similar . tools are also available from various sources.
E In various cases, a SET FILE/ATTRIBUTES command can also be used. As C the parameters of this command must be varied as the target BACKUP : saveset attributes vary, this approach is not recommended.
A Also see the "SITE VMS", /FDL, and various other file-attributes E options available in various FTP tools. (Not all available FTP tools % support any or all of these options.)
H Browser downloads (via FTP) and incorrect (binary or ascii FTP transfer G modes) are notorious for causing RMS file corruptions and particularly A BACKUP saveset corruptions. You can sometimes help encourage the C browser to select the correct FTP transfer type code (via RFC1738):
F You can also often configure the particular web browser to choose the C appropriate transfer mode by default, based on the particular file G extensions, using a customization menu available in most web browsers. F You can select that the specific file extentions involved use the FTP G binary transfer mode, which will reduce the number of corruptions seen. V 5.42.5 How do I write a BACKUP saveset to a remote tape?
A How to do this correctly was described at DECUS long ago. On the D 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 3 $ mount/nounload/over:id/block=8192/assist tapedev 1 $ convert/fdl=SAVE-SET sys$net tapedev:save-set. $ dismount/unload tapedev $ stop/id=0 |
A On the node where you want to do the backup, use the DCL command:
|
" $ backup - srcfilespec - 9 node"user pwd"::"task=backup_server"/block=8192/save |
G One area which does not function here is the volume switch; multi-reel E or multi-cartridge savesets. Since the tape is being written through F DECnet and RMS and the magtape ACP, BACKUP won't see the media switch H 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 G (directly, not over the net) as the XOR blocks are effectively ignored E until and unless needed for error recovery operations. BACKUP likely A will not be able to perform an XOR-based recovery across reel or cartridge boundaries.
G Unfortunately BACKUP can't read tapes over the network because the RMS D file attributes on a network task access look wrong; the attributes ) reported include variable length records. S 5.42.6 How to perform a DoD security disk erasure?
B Sometimes refered to as disk, tape, or media declassification, as ? formatting, as pattern erasure, or occasionally by the generic G reference of data remanence. Various references to the US Deparment of / Defence (DoD) or NCSC "Rainbow Books" . documentation are also seen in this context.
A While this erasure task might initially appear quite easy, basic F characteristics of the storage media and of the device error recovery G and bad block handling can make this effort far more difficult than it might initially appear.
A Obviously, data security and sensitivity, the costs of exposure, ? applicable legal or administrative requirements (DoD, HIPPA or A otherwise), and the intrinsic value of the data involved are all > central factors in this discussion and in the decision of the @ appropriate resolution, as is the value of the storage hardware involved.
F With data of greater value or with data exposure (sometimes far) more A costly than the residual value of the disk storage involved, the E physical destruction of the platters may well be the most expedient, G economical, and appropriate approach. The unintended exposure of a bad H block containing customer healthcare data or of credit card numbers can F quite be costly, of course, both in terms of the direct loss, and the 1 longer-term and indirect costs of such exposures.
A Other potential options include the Freeware RZDISK package, the F OpenVMS INITIALIZE/ERASE command (and potentially in conjunction with the $erapat system service) A and OpenVMS Ask The Wizard (ATW) topics including (841), (3926), F (4286), (4598), and (7320). For additional information on sys$erapat, @ see the OpenVMS Programming Concepts manual and the OpenVMS VAX G examples module SYS$EXAMPLES:DOD_ERAPAT.MAR. Some disk controllers and H even a few disks contain support for data erasure. Some DSSI Disk ISEs, for instance.
< For the prevention of casual disk data exposures, a generic ? INITIALIZE/ERASE operation is probably sufficient. This is not H completely reliable, particularly if the data is valuable, or if legal, E administrative or contractual restrictions are stringent---there may E well be revectored blocks that are not overwritten or not completely F overwritten by this erasure, as discussed above, and these blocks can H obviously contain at least part of most any data that was stored on the H disk -- but this basic disk overwrite operation is likely sufficient to , prevent the typical information disclosures.
? You will want to consult with your site security officer, your F corporate security or legal office, with HP Services or your prefered D service organization, or with a firm that specializes in erasure or D data declassification tasks. HP Services does traditionally offer a % secure disk declassification service. Q 5.42.7 How to enable telnet virtual terminals?
A To enable virtual terminal support for telnet and rlogin devices, ? add the following logical name definitions into SYLOGICALS.COM:
|
" 0 $ DEFINE/SYSTEM/EXECUTIVE TCPIP$RLOGIN_VTA TRUE 0 $ DEFINE/SYSTEM/EXECUTIVE TCPIP$TELNET_VTA TRUE |
H See SYS$STARTUP:SYLOGICALS.TEMPLATE for details on the typical contents of SYLOGICALS.COM.
H In SYSTARTUP_VMS.COM, ensure that a command similar to the following is invoked:
|
" O $ SYSMAN IO CONNECT VTA0/NOADAPTER/DRIVER=SYS$LOADABLE_IMAGES:SYS$TTDRIVER.EXE |
F In MODPARAMS.DAT, add the following line or (if already present) mask C the specified hexidecimal value into an existing TTY_DEFCHAR2, and 5 perform a subsequent AUTOGEN with an eventual reboot:
|
" TTY_DEFCHAR2 = %X20000 |
This value is TT2$M_DISCONNECT.
E 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 |
A MiniMerge support has been available for many years with OpenVMS F host-based volume shadowing, so long as you had MSCP controllers (eg: G HSC, HSJ, or HSD) which supported the Volume Shadowing Assist known as " "Write History Logging".
E If you are interested in mini-merge and similar technologies, please B see the Fibre Channel webpage and the information available there:
F Mini-Merge support was originally intended to be controller-based and & was expected with HSG80 series storage B controllers and was expected to require ACS 8.7 and OpenVMS Alpha V7.3-1.
Host-based Mini-Merge (HBMM) H is now available for specific OpenVMS releases via a shadowing ECO kit, C and is also present in OpenVMS V8.2 and later. HBMM applies to the D HSG80 series and---like host-based volume shadowing---to most other ' (all other?) supported storage devices.
G The following sections describe both Mini-Copy and Mini-Merge, and can provide a basis for discussions. 6 5.42.7.1.1 Mini-Copy?
@ A Shadowing Full Copy occurs when you add a disk to an existing E shadowset using a MOUNT command; the entire contents of the disk are C effectively copied to the new member (using an algorithm that goes H through in 127-block increments and reads one member, compares with the D target disk, and if the data differs, writes the data to the target G disk and loops back to the read step, until the data is equal for that D 127-block section). (This is one of the reasons why the traditional B recommendation for adding new volumes to a shadowset was to use a E BACKUP/PHYSICAL copy of an existing shadowset volume, simply because F the reads then usually matched and thus shadowing usually avoided the need for the writes.)
A If you warn OpenVMS ahead of time (at dismount time) that you're H planning to remove a disk from a shadowset but re-add it later, OpenVMS F will keep a bitmap tracking what areas of the disk have been modified F while the disk was out of the shadowset, and when you re-add it later A with a MOUNT command OpenVMS only has to update the areas of the F returned disk that the bit-map indicates are now out-of-date. OpenVMS E does this with a read source / write target algorithm, which is much F faster than the shenanigans the Full Copy does, so even if all of the 9 disk has changed, a Mini-Copy is faster than a Full Copy. 7 5.42.7.1.2 Mini-Merge?
C A Shadowing Merge is initiated when an OpenVMS node in the cluster < (which had a shadowset mounted) crashes or otherwise leaves E unexpectedly, without dismounting the shadowset first. In this case, @ OpenVMS must ensure that the data is identical, since Shadowing H guarantees that the data on the disks in a shadowset will be identical. E In a regular Merge operation, Shadowing uses an algorithm similar to A the Full Copy algorithm (except that it can choose either of the H members' contents as the source data, since both are considered equally G valid), and scans the entire disk. Also, to make things worse, for any E read operations in the area ahead of what has been merged, Shadowing H will first merge the area containing the read data, then allow the read to occur.
E A Merge can be very time-consuming and very I/O intensive. If a node H crashes, the surviving nodes can query to determine what exact areas of E the disk the departed node was writing to just before the crash, and G thus Shadowing only needs to merge just those few areas, so this tends E to take seconds, as opposed to potentially requiring many minutes or $ even hours for a regular full Merge. l 5.43 Please explain DELETE/ERASE and File Locks?
E DELETE/ERASE holds the file lock and also holds a lock on the parent F directory for the duration of the erasure. This locking can obviously E cause an access conflict on either the file or on the directory---it C might well pay to rename files into a temporary directory location E before issuing the DELETE/ERASE, particularly for large files and/or C for systems with multiple overwrite erase patterns in use; for any C systems where the DELETE/ERASE erasure operation will take a while.
A if you see the %MAIL-W-NONEWMAIL, no new messages error G reported when MAIL indicates you have messages, then the NEWMAIL count has become skewed from reality.
A The count of new mail messages is kept separately from your mail D folder, and is stored in VMSMAIL_PROFILE.DATA. It sometimes happens D that this count differs from what is stored in your mail folder. If G this arises, invoke MAIL and repeatedly enter the READ/NEW command (or H press the keypad hyphen key on an LK-compatible keyboard) until you see F 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 G inconsistent across cluster members, your customer is likely missing a F definition of the VMSMAIL_PROFILE logical name---and is probably also H missing definitions of other logical names associated with other shared G files---or has one or more inconsistent definitions of this and likely of other logical names.
G For details on the configuration data files that must be shared within H a cluster, please see SYS$STARTUP:SYLOGICALS.TEMPLATE on V7.2 and later. i 6.2 How do I send or read attachments in VMS MAIL?
E Is there any way to send or read mail with files as attachments from VMS?
C Not directly with the OpenVMS MAIL facility, but there are several other options:
G Use the anti-spam capabilities present in the TCP/IP Services V5.1 and later SMTP servers.
Use a firewall.
D On earlier TCP/IP Services releases, some simple DCL can reportedly G prevent relay SMTP spam. Use the UCX command SHOW SERVICE SMTP/FULL to F find the directory containing the UCX$SMTP_RECV_STARTUP.COM file, and insert the following DCL:
|
"
$ ! $ ! Block spam.
$ ! G $ MY_ADDRESS_LONG[0,32]=F$INTEGER(F$TRNLNM("SYS$REM_NODE")-"::") I $ MY_ADDRESS=F$FAO("!UB.!UB.!UB.!UB",F$CVUI(0,8,MY_ADDRESS_LONG),- D F$CVUI(8,8,MY_ADDRESS_LONG),F$CVUI(16,8,MY_ADDRESS_LONG),- ) F$CVUI(24,8,MY_ADDRESS_LONG))'" 5 $ MY_ADDRESS_REVERSE=F$FAO("!UB.!UB.!UB.!UB",- E F$CVUI(24,8,MY_ADDRESS_LONG),F$CVUI(16,8,MY_ADDRESS_LONG),- D F$CVUI(8,8,MY_ADDRESS_LONG),F$CVUI(0,8,MY_ADDRESS_LONG))'" J $ 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 6 $ WRITE SYS$OUTPUT "SPAM from relay rejected" $ EXIT $ ENDIF @ $ UCX SHOW HOST 'MY_ADDRESS_REVERSE'.SPAMSOURCES.ORBS.ORG $ IF $STATUS.EQ.1
$ THEN 8 $ WRITE SYS$OUTPUT "SPAM source relay rejected" $ EXIT $ ENDIF
$ ! $ ! Run receiver.
$ ! - $ run sys$system:ucx$smtp_receiver.exe $ goto exit |
| Previous | YNext | \Contents | ^Index |