Converting existing archive tapes from one TAPE/VTS media to a new TAPE/VTS media
Article ID: 30397
Updated On:
Products
Issue/Introduction
CONVERTING DISPATCH ARCHIVE TO NEW MEDIA
Here is what clients converting archive to a new media need to know and understand...
We do not use the MVS or the TLMS catalog when reprinting archived reports. We use our own CA-Dispatch archive database file (.AR).
When Dispatch archives a report, it stores many pieces of information about that report in it's database. Among the things stored are:
A. The DATASET NAME the report was archived with.
B. The VOLSER that the report was archived to.
C. The UNIT that the volser was mounted on when the report was archived.
D. The FILE SEQUENCE NUMBER that the report was archived as.
E. The segment number/BLOCK-ID relative to the location of the report on the tape (BLOCK-ID is used for "fast positioning").
All of the above information (stored on the Dispatch database) is part of the dynamic allocation request that is issued by Dispatch when you REPRINT or extract an archived report from Dispatch.
It is because of the above that you can NOT just copy Dispatch tapes to a NEW MEDIA "OUTSIDE" of CA-Dispatch. If you do this, The Dispatch database NEVER gets updated with the new VOLSER or UNIT information.
Typically, for clients who want to convert their existing Dispatch archives to a new media, the process will be a daunting and time consuming process. There is no "EASY" way to accomplish this task.
- To determine how many archive tapes Dispatch recognizes and see how many reports Dispatch thinks are archive to each tape, you can run the CADSJCL library job DSEXCULP with the MEMBER symbolic set to MEMBER=DSCULP21. This will produce the archive volser report which shows you this information.
If you are going to be converting or moving your Dispatch archived data to a new media, you basically have 3 options which we will outline below:
Environment
Dispatch, 11.6, 11.7, convert, archive, media, move, copy, utility
Resolution
--------------------------------------------------------------------------
OPTION 1 - Execute archive condense/consolidation utility
--------------------------------------------------------------------------
We really don't have a utility "designed to convert" your archive tapes from one media to another. However, the ARCHIVE CONDENSE utility CAN be used to accomplish this. You can find details on the archive condense utility in the following areas of documentation for 11.7:
A. In the 11.7 System Programmers Guide, Chapter 13, starting on or about page 405 through page 409 where we document the DSEXARC(L) — Archive Tape CONDENSE Utility.
B. In the 11.7 User Guide for the Report Administrator manual, Chapter 17, starting on or about page 251 where we document the section entitled "Condensing Existing Archive Tapes"
** Verify APARS RO47524 and RO56358 are applied before condensing **
** Note that successful execution of a given condense process will only "flag" the reports on the original volsers for deletion. These original entries will not actually be deleted from the database until such time as your regular batch archive cleanup job (DSEXTMIG or DSEXPSAR) are executed.
!!! IMPORTANT - PLEASE BE ADVISED !!!
While this utility will accomplish your goal (converting to new media), that is not what it was designed to do. IT IS A VERY SLOW UTILITY! It was designed to "consolidate" a few reports from many tapes onto the same tape.
When you run it, set the #LINES and #REPORTS parameters to a 1 so they are not a factor in the selection criteria. Update the CADSOPTN control member DSARCN01 with the desired INVOL=nnnnnn statements for the volsers you want to condense. On your OUTVOL parameter, you will point to the new media unit.
You will probably want to break up the conversion into many executions of the condense using the INVOL parameter, specifying a limited number of tapes depending on your window for running the condense. We would suggest that you do some testing to get a feel for the timing. Perhaps 5 tapes or so for starters, adding more depending on your processing window.
We provide a version of the utility that runs with Dispatch down (DSEXARCL) and a version that runs with Dispatch active but REQUIRES that the archive and extract subtasks be down (DSEXARC). The DSEXARCL job will run up to 4 times faster that DSEXARC because it does not journal all of the changes.
------------------------------------------------------------------------------------------------
ALTERNATIVE OPTION 2: Copy outside of Dispatch then update Dispatch database
------------------------------------------------------------------------------------------------
One other "possibility" might be to copy the tapes OUTSIDE of Dispatch to the new media, then run the DSEXAUPT utility to update the Dispatch database with the new VOLSER and UNIT information. If possible, this would be the preferred method because it would likely be faster than running the archive condense utility.
Details regarding the DSEXAUPT utility can be found in the 11.7 System Programmers Guide, Chapter 13, starting on or about page 417 where we document the DSEXAUPT — Modify the Archived Reports Volsers utility.
* NOTE that the term "The Batch Extract Request Utility" (The first sentence under the BASIC UTILITY SETUP section) is a TYPO.
!!! IMPORTANT - PLEASE BE ADVISED !!!
The COPY utility you use MUST create an "EXACT IMAGE, FILE BY FILE" COPY of the Dispatch tape. The only difference between the tapes being the VOLSER number and the UNIT type. CA-1 provides a COPYCAT utility which has been successfully used in the past to copy TAPES to new TAPES. We would URGE you to do some testing and, if using CA-1's COPYCAT utility, contact CA-1 Support directly for any details you need on executing their utility to create an EXACT IMAGE tape copy. Your testing should include successfully EXTRACTING a report from the new tape after both the COPYCAT and DSEXAUPT utilities have been run.
- When using a COPY function outside of Dispatch, the INPUT and OUTPUT devices/media must be IDENTICAL or a mismatch on the BLOCK-Id's being stored on the Dispatch database for "fast positioning" and the actual location of the data on the new device/media may occur. (This mismatch results in a S613-04 when trying to reprint a report from the new media).
For more information on using COPYCAT, please refer to CA 1 Knowledge Article Id:30177 - Title: Copy the 3480/3490 to 3590 DISPATCH tapes.
---------------------------------------------------------------------------------
ALTERNATIVE OPTION 3: Rearchive all archived data to the new media
---------------------------------------------------------------------------------
Another "possibility" might be to use the BATCH EXTRACT REQUEST utility. This utility is documented in the Dispatch 11.7 System Programmers Guide, chapter 13, in the section entitled DSEXBDE(L) - Batch Extract Request Utility starting on or around page 422.
We give you a version that runs with Dispatch active (DSEXBDE) and a version that runs with Dispatch down (DSEXBDEL). The JCL setup is pretty straight forward, you will need to satisfy the DSHLQ and LOADLIB symbolics and point them to the Dispatch high level qualifier (DSHLQ) and to the correct Dispatch load library.
The JCL will be looking for a CADSBDE or CADSBDEL proc. which can be found in the CADSPROC library. Use a JOBLIB card or move the appropriate proc to a system proclib if necessary. When you run it, you will need to specify the desired date range via the FROMDATE and TODATE symbolics.
For the purpose of getting the reports rearchived with their original dates and times, you will set the TYPE symbolic as TYPE=C. There is also an UPDATE symbolic you may find very useful. If the UPDATE symbolic is set to 'N', the utility will not actually build any extract requests. It will only produce a report which will show you what VOLSERS will be selected based on the date range you have specified. This will allow you locate the tapes and have them ready and loaded prior to actually building and processing the extract requests. When you are ready to actually build and process the extract requests, simply change the UPDATE symbolic to a 'Y' and rerun the job.
When you run it, the utility automatically builds the extract requests for you just like if you were to do a manual reprint of a report from archive. You will want to have CADDSPL, CADZSAP, DISPATCH, the RPI, ARCHIVE and EXTRACT tasks all active so that the requests will be processed. The EXTRACT task will pull the reports off the tape and throw them out to JES. From there, they will be pulled back into the LDS and processed by the RPI subtask. The RPI subtask will build entries for these reports in the ARCHIVE queue and the ARCHIVE task will write them to the new tape.
!!! IMPORTANT - PLEASE BE ADVISED !!!
* We would URGE you to run MANY SEPARATE executions of the utility and only process 1 days worth or reports at a time. (Unless you archive a very high volume of reports in a single day, then we would recommend including the TIME field in the control card and only do 6 or 12 hours at a time). If you try and re-archive too many reports in one run, you will fill the ARM file used to store the reprint requests until they can actually be processed by the EXTRACT task. Recovering from the ARM file filling up will be very difficult because there is really no easy way of telling what reports were processed successfully and which were not.
When the ARM file DOES fill up, the output from the DSEXBDE will start issuing 1225 error status codes on the entries it is building that won't fit into the ARM file (The job still ends with RC=00 so you have to look at the O/P for the following messages):
Error Status ------ 1225
Error Record ------ AR-PRINT
Error Set --------- AR-EXTR-PRINT
Error Area -------- AR-MISC-AREA
Last Good Record--- AR-REPORT
Last Good Area ---- AR-AREA
DML Sequence ------ 00000022
The above indicate that the ARM file is full!!
* You should run a DSEXSTAT and check the percentage of utilization on your AR-AREA and make sure you have enough room to accommodate the duplicate archive entries that will temporarily be created until you can delete the references to the old volsers.
* Once the reports have been re-archived, you must clean up the old pointers to the old TAPE/VTS entries by executing the DSEXARD utility with the PARM set as PARM=VOLSER=DELETE,nnnnnn where 'nnnnnn' is the actual OLD volser number. You can run DSEXARD up to against 3 volsers at one time separating each volser with a comma. Example:
PARM=VOLSER=DELETE,DISP01,DISP02,DISP03
Execution of the DSEXARD job will be the last thing you do (Recommended after each run of the DSEXBDE(L) process). You have to make sure all of the reports on these TAPE/VTS volumes get rearchived before you can delete the original entries.
We would also recommend testing first with a MANUAL rearchive (orig date/time) And, whether or not a MANUAL rearchive to the new media and a successful extract of the rearchived TAPE version of the report is successful.
Feedback
