Merging a family where there were no backup references could cause a bounds error.
A copy of very many long titles in a SAFE mode run of Mergetape could fault with a bounds error. This has been corrected. Processing more than 128 images in one mergetape run will no longer cause a bounds error. Customer PDUMP files can be difficult to analyse if the customer version of mergetape is older than the latest version. Mergetape will now default to 'dump to printer', creating a taskfile.
On systems running a slave tape library a timing error could occur. A 'Cannot MODIFY Tape CSnnnn: Not in METATAPELIB' msg could occur. In this situation Mergetape will now pause for 5 seconds and retry.
Mergetape will now report details of safe mode and advise that MBout MinAvg are ignored.
Setting the MB parameter in a SAFE merge could interfere with performance. This is no longer the case. SAFE merges tend to create images where the original refs are equal to the active refs. Such images would never be merged unti the active refs decreased. Now such images , with 5 or fewer refs will be selected. Mutivolume images are now excluded from merges as these will normally contain a very big file.
Mergetape estimates the size of a non resident file based on the original size of its backup volume and the number of files backed up. In most cases this works quite well but if a backup contains many very small files and a few very big files then the estimate for the big files will be far too small. This can cause mergetape to try to create an image > 4GB. Using the safe option avoids this problem by splitting the copy after each input volume. As every input volume will use one output volume space will be returned but no serial numbers will be gained. It is suggested that the Safe option is used on families where the 4gb exceeded problem is common. The SAFE run should use MBOUT=3500 and should be followd by a normal run.
A very large volume library could cause Mergetape to fault with an invalid index. Some performance improvement changes were made.
The new method of merging CD Images could fault with an invalid index on systems with a large number (>255) volumes.
Version 620.06 avoided the problem of corrupting the stats file but prevented a subsequent mergetape run for fixing the MB totals.
If the first run of version 620.05 was from a FamilyManager run and not an explicit mergetape run, The stats file would be corrupted. Warnings would be reported,like: Unable to calculate Average MB for CS0448 Could not find container name This problem has been corrected.
Changed the restriction on the minimum number of images to be merged from 3 to 1. When merging images there was no benefit in merging less than 3 tapes as a minimum of two tapes would be used. For images there can still be a benefit in merging 1. Removed some debug code.
Mergetape will now recognise multivolume images created by Familymanager. When selecting CDimages to merge Mergetape was still using a method of selection optimised for tapes. Now CDIMAGES to be merged are presented, sorted by the maximum wastage for the image. This results in a more efficient merge. This version also corrects the avaerage size of images which is held in the Stats file.
Version 620.02 introduced a bug which deleted original count values from the catalog statistics file. This invalidated the VSORIGINALREFS attribute.
Version 600.09 had the unintended and unwelcome side effect of applying the MINAVG setting to all old CDIMAGES. This would happend on every run of Mergetape where MIXAVG was specified.
Warnings about timestamp changes will no longer count as bad backups. Bigfile report files will alway have changed timestamps. They will no longer be reported. Warnings about problems with the CHECKFILE will not report its full title.
The improved logging of Mergetape errors allows Mergetape and the job it runs from, only to be DSed in exceptional circumstances.
The Error "was modified after FMGR run and removed" has been changed to "was modified or removed after FMGR run" and will no longer count as a bad backup.
Added new parameter MBOUT to allow control of the size of output volumes. The maximum value allowed is 3500 Mb. Default is 2000; Added a new parameter MINAVG to allow the specification of the minimum estimated size to be used when merging non resident files. Default is .05 (50Kb) Any non resident file to be merged with an estimated size less than MINAVG will have its size recalculated based on the physical size of the CDIMAGE it is being copied from. If the calculated size is less than MINAVG then MINAVH will be used. Some LMD errors did not correctly identify the volume. This change attempts to rectify the problem.
By default CDIMAGES are created with Private security. The copy job will now mark them as PUBLIC IN. This enables non privileged users to load from CDImages.
Verson 600.02 left a debug program dump in the code. This dump was taken whenever warning like: Warning:*SMA/CP/MCS/1 ON TESTDISK has possible BAD BACKUP was generated. If Mergetape was run for a non existant family a warning was issued. Mergetape will now abort in this case.
The version number of Mergetape is now reported in the Flex Log.
Boj, Input parameters and Abort are now recorded in the Flex Log with Type Job. This change also fixes a bug which could add spurious text the front of the "TIMEOUT Input ==> NO" message.
In some cases when reporting errors in the Familymanager generated copy, an extra spurious error was generated. "Error in formal parameters to EVALUATE" This would prevent Mergetape from DSing
Version 600.02 introduced a bug where Mergetape could report that 1 file was not backed up but no other error was reported. This would happen when backing up the family where the rules file was located
Logging and reporting of errors has been improved. In particular serious error when running after a Familymanager generated copy. If a serious error is detected, Mergetape will wait for up to 1 minute asking whether to confinue or not. If not answered, or NO is entered, the program will DS.
Update for MCP 60 Some preparation for 2035 changes to time(6) format
Cosmetic change
Prevent spurious GS ERR 0 message with single file search on the WORKPACK.
DENSITY = SUPER was used to bypass 4.8 WFL syntax restrictions to allow CopyWrite to do an ADD&CATALOG from CD. (See D-Notes 470.52 and 470.19. SUPER was a synonym for BPI1600, however, both have been deimplemented on 5.5. If a CopyWrite destination volume is KIND=PACK,DENSITY=BPI1250 it is changed to KIND=CD.
Mergetape will no longer fail to detect that the WorkPack is the Merge Family when the first given WorkPack was not available.
MERGETAPE can now create a STATISTICS file from any non-live system catalog file. If the logical file CATALOG is file-equated with the name of the alternate Catalog file, then MERGETAPE will ignore any user-provided parameter and regard it as 'RELEASE NONE'.
RUN *METALOGIC/FLEX/MERGETAPE("RELEASE NONE");
FILE CATALOG=(TEST)CATALOG/2107211 ON DEV
Although much of the normal information in the STATISTICS file is not available, the number of backup references (VSBACKUPS) is useful and can be seen by SUPERVISOR's VL context Opal scripts. See SUPERVISOR DNote 541.76 for more information.
If the string parameter passed to MERGETAPE was longer than 300 characters, MERGETAPE would have faulted with a SEG ARRAY error at 11035400 when writing to the FLEX log file. This problem has been fixed.
Version 540.04 introduced a bug which would cause Mergetape to fault if reporting a file with only one backup reference. This has been corrected.
Mergetape will, where possible, avoid copying files from unsafe backups. ie. Volumes marked as having bad references or as having been destroyed.
On MCP 53.1 and later, WFL jobs generated for tape-to-tape merging (signified by the parameter '=' for familyname) would fail with syntax errors. This occurred because of the Unisys deimplementation of COPY&BACKUP for tape-to-tape copying in MCP 53.1. An alternative tape strategy method has now been adopted to detour this problem and several other merging issues have been resolved.
The MERGETAPE utility will now write run-time information into the Flex log file system and includes BOT/EOT, job and volume information, errors and warnings encountered during the run. In particular, information written to the DIAGNOSTICS trace file is also copied into the FLEX log. MERGETAPE entries into the log file have an identity of 'Mrge(12345)' where 12345 is the mixnumber of the MERGETAPE utility.
12:56:47 Job:Mrge(22730):EOJ Flex MERGETAPE run complete 12:56:47 Wrn:Mrge(22730):WARNING:*EDITOR/OPTIONS ON DEV was modified
after FMGR run
Please see FLEX DNote 540.32 for more information.
Internal change only
The report command has been deimplemented. The LISTVL command in FLEX provides more useful information.
Supports the new attributes VSVER,VSORIGINALREFS and ORIGINALREFS.
Passing a bad parameter to the REPORT command would cause Mergetape to loop.
Ex REPORT MYPACK DENSITY= ....
DENSITY is not a valid option for the REPORT command.
Mergetape will now abort with a bad parameter error in these cases.
Merging CDs would fail with a syntax error on the output job and would report erroneous 'NO FILE' errors.
Previously, MERGETAPE could fault with an INVALID INDEX @23376440 when processing the release of FLEX CD images; this would only occur if one or more image volumes had been discarded (such as expired SCRATCH volumes or missing CD images on disk) during MERGETAPE's initialisation phase. This problem has been corrected.
Use INCLUDE/META
Make use of length stored in PD object.
Tapes created by Mergetape currently have prefixes of FLEXCOPY or the name of the family being dumped. A new parameter (PREFIX) is now alowed which will override the default. The specified prefix must be 10 or fewer characters and be valid for tape names. The Prefix parameter is also valid in Familymanager.
Ex.
("MERGE DEV PREFIX REDDEV")
MERGETAPE will now use the replacement TRIM log file implementation for all FLEX-specific tape information. Please see TAPELIBUPDATER Dnote 520.05 for more information.
If the source for a Mergetape load to workpack was a tape used to backup multiple families and the tape also had a valid LibmaintDir then the load job would fail syntax.
This problem has been corrected but in order to simplify the investigation of any subsequent syntax errors the failing job is now saved in the directory MERGETAPE/LOAD/SYNTAX.
MERGETAPE will now automatically perform a CATALOG PURGE for CD image files held on the alternate CDIMAGE family that have been released during a MERGE FARM run. Previously, only the file's catalog entries on the primary CDIMAGE family were purged.
Further, the locking of FLEX volumes by the automatic RELEASE NONE run after FAMILYMANAGER completes will now not be logged in MERGETAPE's dialog print file.
MergeTape now uses the new Directory format and search optimizations.
In FLEX cataloging environments, MERGETAPE will now unconditionally assign all volumes created by MERGETAPE and FAMILYMANAGER as LOCKED in the TRIM Tape Library system, if this is available. A tape that is LOCKED may only be released by MERGETAPE on the SAME HOST that originally created the tape. This can be seen by viewing the HOSTNAME field in a TP <serial> response. If TRIM is not installed, the above does not apply.
When a tape is LOCKED in a FLEX cataloging environment, it cannot be released by MERGETAPE unless all the following are TRUE (note that the local backup ref count must already be zero for MERGETAPE selection):
1. MERGETAPE is running on the host that originally created the tape. 2. If MERGETAPE is running from a TRIM slave and that tape volume exists in the Master's Volume Library, the backup references count is checked on the Master and must be ZERO.
Additional error messages may be generated by MERGETAPE subject to the conditions above:
Vol:123456: Tape has non-zero MASTER backup refs Vol:123456: Volume is LOCKED and not local host
The mechanisms used to calculate average mb/file values for all FLEX media volumes, whether appended or not, were inaccurate. Conventional non-appended volumes were assigned 50% of their actual average megabyte value whereas the calculation for appended volumes did not allow for backup references that had been lost since the previous backup. This problem occurred during both normal merging and the MERGETAPE run that is executed after each FAMILYMANAGER run.
For appended volumes, MERGETAPE will now calculate the average megabyte value directly by reading the tape's associated LIBMAINTDIR file. The FAMILYMANAGER utility now passes appended tape information to MERGETAPE using the CHECKFILE.
The average megabyte value calculated by MERGETAPE for DUPLICATED volumes was incorrectly adjusted by a factor of two, potentially distorting the weighting checks used during the merging process. This problem has been corrected.
Previously, the automatic deletions of expired CD images and Disk Farms did not delete entries in the Tape Library database if the system was running as a TRIM slave system.
CD images with zero-references but unavailable on the image family may now be removed from the Volume Library and the tape Library by a RELEASE CDIMAGE run of MERGETAPE.
The deletion process for cleaning up expired Disk farms will now exclude an errorneous message about image removal failure.
A new option, IGNORE, allows a Disk Farm merge to remove merged or zero-ref disk farms from the Volume Library and TRIM Tape LIbrary even if the FARM removal has previously failed, usually because the farm has been manually deleted. Using IGNORE will allow such volumes to be discarded and the volume serial numbers re-used.
RUN *METALOGIC/FLEX/MERGETAPE("DEV FARM(META1) AUTO IGNORE")
This change also ensures that a MERGETAPE run only releases eligible entries from the appropriate volume subset (i.e. CD, CDIMAGE, TAPE or FARM) dictated by the MERGETAPE parameter. Previously, expired, non-released volumes from other subsets would have been released unconditionally causing these volumes to remain indefinitely in the Volume Library and ignored by future MERGETAPE runs.
For CD image or Disk Farm merging, it was possible for MERGETAPE to generate an output WFL job that could fail:
"Volume Closed due to SYNTAX limi" "SYNTAX ERRORS in output job. Do not rerun until advised to do so."
This might occur if the output job had many thousands of small files with long file titles forcing the WFL job to be closed due to syntax limit. This limit check did not always work correctly in these circumstances causing the generated job to be too long which then subsequently failed. This problem is now resolved.
Previously, MERGETAPE would fault with an INVALID INDEX at 40860015 if a normal tape merge created multiple output volumes (usually because of syntax or tape length limits). This problem is now fixed.
The change applied by DNote 510.02 caused disk farm merging to be disabled, causing every FARM merge to fail to select any eligible volumes for merging. This problem is now fixed.
Setting the COPYREPORT option in a Disk Farm Or CDImage merge would cause the output Job to fail with syntax errors.
The COPYREPORT option is now ignored for Disk Farm or CDImage merges.
This change fixes a 'task attribute access error' which would happen when Mergetape > 500.02 was run from a Familymanager generated Job.
The MB option now accepts values > 255.
A new boolean option COPYREPORT has been added. This option causes all copies to include the &REPORT option which creates a printed report of Copies, instead of logging them.
If the output job has to be split due to MCP limits, the continuation Job(s) will append to the existing tapes if possible.
A problem where the wrong file could be copied when merging from more than 1 locate capable tape has been corrected.
When converting feet to megabytes in the statistics file, values for Cds, CDImages or DiskFarms will no longer be corrupted.
Mergetape now keeps all size info in MegaBytes (MB) instead of feet. The first time an older Statistics file is updated, the average feet will be converted to average MB.
MERGE = will now keep updated average MB values for the tapes it creates or modifies.
SERIALNO OUT tapes will no longer have their average MBs corrupted. Merge = no longer makes an unnecessary message when trying to merge files from an offline family.
Mergetape no longer complains if 2 or more generations of a file are backed up to the same volumes.
A spurious message is no longer sent when using SERIALNO OUT with a workpack merge.
Boolean parameters are now handled more consistently. A boolean parameter appearing in its own is considered to be set to true. All boolean parameters can be followed by =TRUE or =FALSE.
A new parameter of DENSITY has been added. This is used to specify the density mnemonic of the output tapes to be used, overriding the default values. Ex. DENSITY=FMTDDS2.
Using '=' instead of the family name in a MERGE request, enables a new form of merging. Unlike previous MERGEs, this form merges all the files from all families on the input tapes, including files with conflicting names or generations. This also means that the tapes mounted will nearly always be released in the same run. This form of MERGE no longer asks for or needs a WORKPACK, copying directly from the input to the output tapes. However, as the software exists at the moment, LIBRARY/MAINTENANCE will ask for each input tape to be mounted twice, once briefly to get the directory, and once to copy the files off. This extra mount should be painless for sites with tape robots. By doing the copy from tape to tape, this MERGE is practical only for installations with at least 3 tape drives. A number of 2 drives is the lowest accepted, but should be used as a last resort because each input tape must then be mounted 4 times.
MERGE = is valid with all forms of MERGE involving tapes or CDs, but not CDIMAGE or DISKFARM media. It is also disallowed for the OFFLINE option as the OFFLINE list is still family dependent.
In preparation for the introduction of a merge facility where no work pack is needed, this patch allows REPORT =, to report on the status of all the families which have backed up files.
OUT is a new keyword after the SERIALNO clause which can be used in a merge to specify the serial numbers of the 2 output tapes. If the tapes are good backup tapes in the Volume Library, the copy will have a LIBMTAPPEND=TOEND clause. The new syntax is:
SERIALNO OUT <serial> , <serial>
Mergetape may now make LIBMAINTDIR files when copying to tape, if a new Default option is set appropriately. See FLEX/Inquiry Dnote 500.08 for details.
MERGETAPE will now verify that the COPYWRITE library is available and active, before commencing all merge operations to CD, CD image or Disk Farms. The following messages may be seen:
'Missing GETCOPYWRITESTATUS entrypoint in MAGUS' 'COPYWRITE library is inactive or not installed' 'COPYWRITE DSS functionality is DISABLED'
The first message indicates an unlikely incompatibility problem with an older version of MAGUS. If COPYWRITE is already installed, then it may be necessary to re-install using the COPYWRITE utility e.g. from CANDE:
U *METALOGIC/COPYWRITE REINSTALL
Also, MERGETAPE will now verify and, if necessary, update the creation date of CDIMAGE or FARM volumes created during the merging process. Previously, the creation dates of such volumes were zero.
If 2 versions of a file were on a tape that MERGETAPE used for loading it, the wrong version could have been loaded. This could only happen on a non-FLEX tape. This problem has now been avoided where the tape has a LIBMAINTDIR. This change also allows LIBMAINTAPPEND=TOEND tapes to be used, although MERGETAPE will not as yet create them.
MERGETAPE will now ignore any SCRATCHPOOL assignment when creating disk farm volumes. Normally, COPYWRITE checks for specific SCRATCHPOOL values to provide specialised actions so MERGETAPE now disables this by default.
Similar to the implementation described in FAMILYMANAGER DNote 500.07, it is now possible to create CD images on a family other than that assigned to the FLEX_CWIMAGE configuration variable. As with FAMILYMANAGER, this is controlled using the following syntax change to the CDIMAGE modifier:
------- CDIMAGE ----+------------------------+------------------| +-- = <Alt.family> ------+
For example:
RUN *METALOGIC/FLEX/MERGETAPE("DEV CDIMAGE=ALTIMAGE AUTO")
Internal change only.
Fix syntax conflict with Dnote 500.02.
This change eliminates an extraneous message displayed during a RELEASE NONE run that was introduced by 500.09.
Recent changes to support CDIMAGE merging caused a SEG ARRAY error at 62574132 if a volume library had a very large number of entries. This problem, which would occur for a TAPE-only merge, is now fixed.
This change supports that discussed in COPYWRITE DNote 500.07 which protects the RELEASE FARM of files from a Disk Farm that have already been released by an earlier run of MERGETAPE.
The RELEASE command has been extended to permit the keys words CD, CDIMAGE, FARM or TAPE. This permits MERGETAPE to release volumes of the appropriate type that have zero references and are marked as RELEASED or WASBACKUP. The RELEASE FARM variant that was previously used to housekeep Disk Farm files will now only operate if a threshold value is given.
------ RELEASE -----+--- CD -------+-------------------+-------| +--- CDIMAGE --+ | +--- TAPE -----+ | +--- FARM -----+-------------------+ +-- > <integer>-- +
The protection of the COMPARE and VERIFY options for CopyWrite-created volumes discussed in DNote 500.07 did not work correctly in all situations; this has been corrected.
Under certain circumstances, it was possible for MERGETAPE to miss the EOJ during a CopyWrite deletion of a Disk Farm, causing MERGETAPE to stop. This problem is now resolved.
The COMPARE option will now be ignored with any Disk Farm merging operation as it is not supported by COPYWRITE. Also, the release of Tapes,CDs, Disk Farms and CD Images will now no longer give the misleading message 'nnnn cannot be release because WASBACKUP' if the volume was being released on the same day as its creation.
If a very large number of files (>30000) were copied in a familymanager Dump, then the Mergetape run in the Familymanager job could fail with an 'Array to large' error.
Version 500.03 intended that the rules manager accesscode not be required to run Mergetape. It no longer is required.
Previously, MERGETAPE required operator intervention to retry the CD image COPY&CATALOG.. TO NULL procedure (used to update catalog backup references after a merged CD image has been created) if the COPY generated any file errors. MERGETAPE will now display an appropriate error message and continue; this enables unattended AUTO runs for image merges to complete regardless of errors.
MERGETAPE will now CATALOG PURGE any expired LIBMAINDIR for Disk Farm volumes that have been released during a merge run. MERGETAPE will also now attempt to get the PC hostname for a Disk Farm volume from TRIM if the associated LIBMAINTDIR is unavailable or does not have the host name present. Previously, MERGETAPE would have ignored such volumes, discounting them from the merge process, even though they may have been good candidates.
All MERGETAPE runs must now be run under the Rules Manager usercode; previously, MERGETAPE could be run under any PU usercode but this changes aligns MERGETAPE to use the same security restrictions as the FAMILYMANAGER product. It is not necessary to run MERGETAPE with the Rules ACCESSCODE as this restriction has been relaxed (please see FLEX/LIBRARY DNote 500.08).
MERGETAPE now supports the merging of CopyWrite Disk Farms. These changes have been released in conjunction with enhancements to the CopyWrite package (please see COPYWRITE Software Changes 500.02 and 500.03.
MERGETAPE command has been enhanced to enable Disk Farm merging:
---+-----------+--- <Family> ----- FARM ---- ( <Farm Host> ) ------ +-- MERGE --+
The use of <Farm Host> is mandatory since, at this time, it is not possible to merge farms which may be on multiple PC hosts.
MERGETAPE will now automatically correct average MB values for both CD image and Disk Farms if they are found to be incorrect. MERGETAPE requires these values to determine the weighting of eligible volumes to be used in the merging process. Previously, Disk Farms values would always be 0 or 1 which affected volume selection. For Disk Farms, MERGETAPE will automatically search for the volume's LIBMAINTDIR file and calculate the average disk space by extracting the size of each file. If the Disk farm LIBMAINTDIR file is missing, MERGETAPE will determine the hostname of the Disk farm from the TRIM Tape Library subsystem and attempt to re-create the LIBMAINTDIR using a CopyWrite COPY.
MERGETAPE expects to find LIBMAINTDIR files under the RULES Manager usercode on the DL LIBMAINTDIR family.
During the merging process, if MERGETAPE determines that a Disk Farm is eligible for deletion (i.e. the Disk Farm volume has 0 references), an ADD *= FROM NULL request is initiated requesting CopyWrite to purge the farm at the specified host. When the delete is successfully completed, MERGETAPE will automatically delete any associated Tape Library entry, remove the LIBMAINTDIR and delete the Volume Library entry.
All the above activities are logged in MERGETAPE's dialog print file. This is an example of Disk Farm volume DF0020 being deleted from PC host META1:
12:26 ..Volume Library and TRIM entries will be removed
12:26 ..Volume DEV_A [DF0020] will be released
12:26 ..Disk Farm DF0020 will be deleted from META1
12:26 ....Removing old LIBMAINTDIR for DF0020
12:26 ....(FLEX)LIBMAINTDIR/DEV_A/20040512/DF0020 ON DISK
successfully removed
12:26 ....Deleting DF0020 from Volume Library
The WFL deletion of an extinct Disk Farm would typically look like:
#BOT 14081 (IPP)WFLCODE
#BOT 14082 (IPP)FILE/TRANSFER
#BOT 14083 (IPP)FILE/TRANSFER/SERVICES
#14083 CopyWrite:Metalogic CopyWrite Version 50.500.03 was compiled at
16:41:8 on the 18th May 12004 (MCP 49.189.8737)
#13802\14085 BOT (IPP)SESSION/"Mix# 14083"/"10.0.0.2"/
META1/IPP/COPYWRITE
#14083 CopyWrite:Release ALL 4 FILES in SPARE_A
#14083 CopyWrite:File Release Completed. Volume Release Check Pending
#14085 CopyWrite:[META1] Disk Farm C:\ASeriesBackup\DELL8500MCP\
SPARE_A[DF0017] Removed
#14085 CopyWrite:[META1] Deleting 4 Files in C:\ASeriesWaste\
SPARE_A[DF0017]_21_May_2004_155812
#14085 CopyWrite:[META1] Deleted C:\ASeriesWaste\
SPARE_A[DF0017]_21_May_2004_155812\FILE000.dir
#14085 CopyWrite:[META1] C:\ASeriesWaste\
SPARE_A[DF0017]_21_May_2004_155812 Deleted
#13802\14085 EOT (IPP) (IPP)SESSION/Mix# 14083/10.0.0.2/META1/
IPP/COPYWRITE
#EOT 14083 (IPP) (IPP)FILE/TRANSFER/SERVICES
#EOT 14082 (IPP) (IPP)FILE/TRANSFER
#EOT 14081 (IPP) (IPP)WFLCODE
If Disk Farms volumes hold very large files which drop out of the catalog on a regular basis, it is possible that disk space shortages may become an issue on PC hosts. This can occur because such files will never be released until the volume is merged or drops to zero reference by natural means.
To help minimize this problem, a new modifier to the RELEASE command is now available:--- RELEASE ------ FARMs -----+--------------------+--------- +-- <KB Threshold> --+
The RELEASE FARM command will analyze all existing Disk Farms in the Volume Library searching for large files (or older generations of those files) that have dropped out of the catalog. By default, MERGETAPE will use a threshold file size of 5 Megabytes (5000 KB) to select files but this may be raised or lowered by using <KB Threshold> to specify a lower limit in KiloBytes.
For example:
RELEASE FARM 8000
The above command would look for expired files that have now dropped out of the catalog and are larger than 8 Megabytes. MERGETAPE uses each Disk Farm's LIBMAINTDIR file to select eligible files so this must file be resident or the volume will be excluded. Further, the family associated with each eligible file must be online and available or the release will be skipped.
When CopyWrite receives a request to release a file from a Disk Farm, the file is not removed but replaced by a 'RIP' capsule which is essentially a null file, occupying minimal disk space. This means that a reference to the file remains in the Disk Farm but the disk space has been returned.
At this time, neither MERGETAPE nor CopyWrite 'know' that a released file has been processed before so multiple RELEASE FARM runs may re-release the same file. This problem will be fixed in a later version of Copywrite by marking the file as released in the associated LIBMAINTDIR. A RELEASE FARM command is much faster than a Disk Farm merge and can easily return significant disk space.
In practice, a combination of merging and RELEASE is envisaged as the best way to housekeep DIsk Farms. As with CD images, MERGETAPE can be run silently, without operator intervention, to merge Disk Farms by PC host, at scheduled times. For example, to merge family DEV with farms on PC host META1:
RUN *METALOGIC/FLEX/MERGETAPE("DEV FARM (META1) AUTO")
This run uses automatic settings that controls Farm selection, by default, using less than 25 MBytes to a maximum of 10 volumes. These values can be readily overridden by run-time modifiers.
Due to a limitation of the WFL compiler, it was possible for MERGETAPE to cause a WFL FAULT if the size of the generated WFL COPY job was greater than 65535 words. Although this size of WFL job is very unusual, but because of this restriction, MERGETAPE will now automatically split WFL jobs if this is limit is reached. The dialog file will show the reason as 'CLOSED DUE TO ARRAY'.
MERGETAPE will now terminate early if it is determined that the Volume Library has no eligible volumed packs or tapes. This will occur because it is not possible for MERGETAPE to perform any further processing in such circumstances.
MERGETAPE will now remove all files loaded to the work pack after a successful CD-only merge. Only CD-merging was affected by this problem. Also, the internal version of MERGETAPE has been updated to reflect MCP 49.1 compatibility.
Previously, disk files with the LOCKEDFILE attribute set which were loaded to the work pack during a merge, were not successfully removed during the clean up process. This problem is now fixed.
If the name of the family used to hold CDImage files was too long, it was possible for Mergetape to fault with a 'seg array' error. This problem has been corrected.
During large merges, it was possible for MERGETAPE to fault with a SEG ARRAY error at 40450000 when MERGETAPE was closing off the copy job file because of WFL syntax limits. This problem is now fixed.
MERGETAPE will now allow commas again inside the TIMEOUTS section of the parameter passed to the program; the change in 480.14 disabled this feature. Also, the syntax diagram in this previous note should show that multiple keywords can be used i.e.
+<<<<<----------+-------+-----------------+ --- <familyname> -+-+-- AUTO -----------------------------+-+--| +-- CD ------------------------------+ | |Note that the comma is optional.
MERGETAPE will now accept additional keywords to allow unattended operation of any merge . Previously, the TIMEOUTS modifier was used to control such processing but its requirement has now been relaxed. The full semantics of the MERGETAPE parameter are shown below:
--- <familyname> ---+-- AUTO -----------------------------+---| +-- CDIMAGE -------------------------+ +-- OFFSITE --------------------------+ +-- DETAIL ---+---+--------------+---+ +-- SHORTCOPY -+ +-- = -+- YES -+ | | +- NO -+ | +-- DRIVES ----+-- = -- <integer> ----+ +-- FEET ------+ | +-- MB --------+ | +-- LOADS -----+ | +-- SELECT --- <select specs> --------+ +-- WORKPACK --- = -- <familyname> ---+The keywords are documented as follows:
CD : Find eligible CD volumes only; both CD and CD images will be used for merging. A workpack is required.
CDIMAGE : Finds eligible CD images only; only CD images will be merged. No workpack is required.
If neither CD or CDIMAGE is specified, only tape volumes will be merged.
DETAIL : If YES, provides additional file and volume information in MERGETAPE's diagnostics printout.
DRIVES : Specifies the number of tape/CD drives available for loads and merges. Not applicable for CD image.
LOADS : Specifies the number of CD/CD images/Tapes to be merged for this family.
FEET/MB : For tapes, this value specifies the maximum 'Tape feet' currently in use for a volume, to be used to select eligible tapes for merging. For CD and CD image merging, this value is referred to in MegaBytes. Max value=255.
SHORTCOPY : If YES, then MERGETAPE will automatically proceed with merge jobs that create small tape/CD volumes. MERGETAPE will consider a tape as 'short' if only 20% of the volume will be used. Not relevant for CD images.
WORKPACK: For tape and CD merges, WORKPACK allows user selection of a disk family to be used for loading files for merging.
The RETRY keyword has been deimplemented.
Lastly, the AUTO option tells MERGETAPE that this will be an automated batch run and various options will be automatically assigned unless overridden by other keywords. If used, AUTO should be the first keyword after the family to be merged.
AUTO will default the following:
DRIVES is set to 1 NOSHORTCOPY is set to FALSE DETAIL is set to FALSE LOADS is set to 10 volumes LIMIT is set to 25 MB/tape feetDefault operator name is set to OPERATOR
In the case of CD image merging, it is simple to set up a run of MERGETAPE to merge images without operator intervention:
RUN *METALOGIC/FLEX/MERGETAPE("DEV AUTO CDIMAGE MB=20")
Where MB and DRIVES are both set, MERGETAPE will use that setting which releases the minimum volumes.
Lastly, MERGETAPE can now release 'expired' CD image files for all families during a normal merge or a RELEASE WASBACKUP run. Previously, images could only be removed that belonged to the merging family but MERGETAPE will now examine the CD image host family and store the family name associated for every image volume where possible.
If the family name cannot be determined, MERGETAPE will issue warnings and will drop the volume from the release process.
This change contains more support for backup to Copywrite disk farms.
It also support the new serial number allocation mechanism for CDs and cd images which allows old numbers to be reused.
MERGETAPE will now automatically ALTER merged Copywrite disk images to assign the LOCKEDFILE attribute; this change helps to protect the file against accidental removal.
Also, MERGETAPE will now correctly merge CDs when requested; previously only CD image merging would have been processed without problems.
A new timeout option, MB, has been added to assist batch merges of CD and CD images. If specified, MB controls the megabyte threshold value used by MERGETAPE to automatically select those CD/CD images which are eligible for merging. For example, MB=25 will only select tapes with less than 25 megabytes of active files in the CD or image.
Previously, MERGETAPE would attempt to release backup volumes that had no references (marked as WASBACKUP) even though they had been released before. This problem and minor issues with duplicated backup on CD have been resolved.
MERGETAPE was not correctly applying average feet calculations for non-resident files when merging CD images; this meant that it was likely that the merging of very large, non-resident files would compromise limits on Copywrite image sizes. This patch addresses this problem by applying average feet values for non-resident files.
Also, MERGETAPE will not ask for the name of the default image family if the keyword CDIMAGE is used after the family name to be merged e.g.
RUN *METALOGIC/FLEX/MERGETAPE("DEV CDIMAGE")
During the merging of CD images, it was possible for Mergetape to occasionally fail to keep the size of a generated image to under 650Mb, causing a CopyWrite run-time error. This problem, due to the way that Mergetape calculated the image size, has now been detoured by specifying BLOCKSIZE=4000 on the output image, allowing significant overflow if needed.
This change supports the change made in Familymanager Dnote 480.05.
Mergetape will now accept an extra parameter of CDIMAGE.
Ex. Run METALOGIC?FLEX?MERGETAPE("MERGE MYPACK CDIMAGE")
This will cause Mergetape to ask if CDs or CDimages are to be merged.
Merging to/from CDIMAGES requires the additional Metalogic product
This change is to prepare for being able to use Flex to backup to Copywrite Disk Farms.
It also detours a change made in MCP 48 which caused Mergetape to fault when verifying Familymanager dumps to CD.
If the system option 45(UseCatDefault) is set then any non library maintenance tape created gets a backup reference from the pseudo family TAPE. Mergetape keeps track of these references in the Statistics file.
If Tapemanager is used these noted references will prevent these tapes from being purged.
Some time ago a configuration option FLEX_FAMTAPEREL was added to allow Mergetape to release tapes which once had references on Family Tape but now had no references. The meaning of this option has now been extended so that Mergetape will only count references to Family Tape when this option is true. The option can be inspected and changed using U META/INSTALL CONFIG. The option is in the Full Flex section.
The recent changes support CD image merging had the unfortunate side effect of breaking the weighting mechanism used to select tapes for tape merging. This problem caused large merges to be performed with few tapes being released.
The average feet setting for CD images will now be correctly updated in the STATISTICS file after a merged image is created. Previously, this value was always zero.
The RELEASE NONE run of MERGETAPE performed by FAMILYMANAGER was incorrectly handling CD images as if they were CDs. This caused MERGETAPE to invoke a VERIFY process to handle the CD which was not available. This problem is now fixed.
Also, MERGETAPE would always unconditionally add a volume library entry for new output CD images before confirming with the user if an abort might be required if the new image was too small (less 5% of 640MB). The volume library addition has now been moved after this check.
MERGETAPE will now correctly merge families with files backed up on CD and CD image files. The user has the option to only merge from CD images negating the need for CDs to be used for loading or output, otherwise CD media will be used, as required.
Special handling has been implemented for CD images. When a CD image file is released by MERGETAPE, the Volume Library entry is deleted, the image disk file is removed and any Tape Library entry is deleted. Normal CD volumes will remain in both the Volume Library and METATAPELIB after release, as with tapes.
This patch only changes the version to 48. Version 470.06 is still valid for MCP 48.
MERGETAPE will now recognize pack unit numbers greater than 4095 when searching for information about the user provided workpack family. Previously, MERGETAPE would have rejected the family assignment.
MERGETAPE will now correctly merge files with long file names on systems with SYSOPS LONGFILENAMES set. Previously, these files would be ignored.
On 45, 46 and 47 MCPs, MERGETAPE has been known to fault occasionally with a SEG ARRAY error during the generation of the WFL jobs which create the MERGETAPE output tapes. This problem, which would only occur if the dumps were forced to multiple volumes, has been identified as a bug in the Unisys WFLSUPPORT library. This problem will be UCF-ed and has been detoured in MERGETAPE
MERGETAPE will automatically partition copies into multiple volumes according to WFL library maintenance limits or according to the default length assigned to the tape medium used. After the copies are complete, MERGETAPE will automatically update the backup information of the file copied during the merge. If any of these are found to be subsequently non-resident during the alter phase , MERGETAPE will generate a job to copy the files from the work family; these are called "phantom" files.
However, MERGETAPE could fault with a SEG ARRAY ERROR at 50610000 *if* files were found to be missing from two more of the tape volumes to be created during the merge. This problem is now fixed
This change supports Familymanager 470.02. A subsequent release will allow merging to and from CD images.
This version is required in order to run on MCPs 4.7 or later.
A bug where Mergetape would release reel 2 of a multi volume tape when reel one still had backup references, has been corrected. The problem would only happen if the tape family had ever consisted of more than two volumes.
When a file spans two or more tape volumes the subsequent volumes will always be requested by serial number. This did not always happen in the past. The additional serial numbers are not listed in the 'volumes to be merged' listing.
The Question ..Do you wish full details of the merge to be reported? was intended to display more details of files and tapes being merged. If YES is answered this extra information is sent to the Screen or ODTS and written to the printer file Dialogue. If NO is answered it is written only to Dialogue. This information can be useful in diagnosing bugs in Mergetape and in establishing why fewer tapes are released than expected.
After entering the number of volumes to be merged, a list of the serial numbers of the volumes request is now displayed.
A bug where Mergetape would fail with an array bounds error when attempting to recover from an alternate backup which was offsite or had bad references has been corrected.
A bug where Mergetape would incorrectly calculate the Total and FamTotal figures on the printed tape list has been corrected.
The report on potential volumes to be merged now shows the approximate feet of tape used on each tape, rather than the number of files.
If any volumes will not be released because they have references from other families, the number which will not be released is now reported.
Mergetape is run in the job generated by Familymanager. It checks that files were backup up correctly and update the statistics file.
A problem occurred if any files had changed between the time of the Familymanager run and the time of the copy to tape and was then removed before the Mergetape run. Mergetape would display an Accept message saying that some files had bad references and would DS if no accept was entered in 45 seconds. The DS was to draw attention to the fact there were suspect files on the tape, but the title of those files was never displayed. Now such files will be flagged with the error " was modified after FMGR run and removed".
Eliminate a reference to Archive Log for compatibility with GST 460.09
Files on multi-family FLEXCOPY tapes which were not from the family being merge were not taken into account when deciding whether to merge the tape in a classic tape occupancy merge. This meant that effectively these tapes would be selected for merging very quickly, even though they may be nearly fully used. MERGETAPE now counts files not included in the merge as well. MERGETAPE will maintain a small bias for single family tapes (20%), which should reduce unnecessary tape activity. As a result of this the first pass of a merge will typically be slightly slower, and take more CPU time. The older algorithm can be kept by using an AGE selection clause, e.g. AGE < 9999. The REPORT printout will now include the total backups on all families.
A potential problem with intermittent disk errors on the catalog family has been fixed. The total resident entry count in the statistics file will now be accurate.
MERGETAPE will now print a list of serial numbers, when requested, for requested tapes that are second backups. Previously, no serial number information would be given. It should be noted that file and weighting data for these tapes is unavailable in the statistics report in this case.
The maximum unit number that Mergetape would recognise a tape on was previously 1024.
This has now been increased to 65535.
There appears to be a problem with the Unisys RESTORE command on some MCPs where trying to copy from the second or subsequent reel of a multi family multi reel backup. Setting the config variable FLEX_NORESREEL2=TRUE cause COPY to be used instead of RESTORE. This means that if two files with the same title exist on the tape then it is possible that the wrong one will be loaded. This option should only be used until the MCP bug is fixed.
To set the option enter U META/INSTALL FLEX_NORESREEL2=TRUE
To Reset the option enter U META/INSTALL -FLEX_NORESREEL2
U META/INSTALL FLEX_NORESREEL2 is used to check the option.
A problem which happened when running with the TIMEOUTS option, with no Cande Station has been fixed. Previously ACCEPTS to questions which had time out options were no correctly read.
When merging a very large family on systems with high-capacity tapes, it was possible for MERGETAPE to fault with a SEG ARRAY ERROR when constructing the output WFL COPY jobs.
This problem is now fixed.
This change supports the change in FLEX 450.03 which allows zero to be specified as the length of an output tape. If zero is specified an infinite length of tape is assumed.
Extra tapes were sometimes used in output because MERGETAPE did not correctly calculate the maximum length of a COPY statement in MCPs 43.1 and above.
This is now corrected.
