book
Article ID: 131087
calendar_today
Updated On:
Issue/Introduction
After a migration, the client found they had a few View tapes, at the new site, that received the following messages:
. IOS000I ...
. SARTPI43 I/O error positioning tape
What would be the means to fix the tapes?
Resolution
After running the below CA View utility jobs, the client was able to determine that their tapes were, in fact, good:
- First, run the following SARPAC REPORT JCL:
//XXXXXXXX JOB ...
//SARPAC01 EXEC PGM=SARPAC,PARM='view_hlq,REPORT' <=== Modify DB name
//STEPLIB DD DISP=SHR,DSN=VIEW.CVDELOAD <=== Modify, if used
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN DD DUMMY
//
. . Note: The above will provide a list of tapes that View believes it to own.
- Then, run the following SARTSLST JCL, for each tape in question:
//XXXXXXXX JOB ...
//SARTSLST EXEC PGM=SARTSLST,PARM='view_hlq,nnnnn' <=== Modify DB name and Tapeseq #
//STEPLIB DD DISP=SHR,DSN=VIEW.CVDELOAD <=== Modify, if used
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//
. . Note: nnnnn above is the Tape Sequence number, as found in the leftmost column on the SARPAC report, as the T00nnnnn may or may not match the noted sequence number.
- Then, run the following SARTCP tapemap (//TAPEIN ... only), for each tape in question:
//XXXXXXXX JOB ...
//SARTCPMP EXEC PGM=SARTCP
//STEPLIB DD DISP=SHR,DSN=VIEW.CVDELOAD <=== Modify, if used
//SYSPRINT DD SYSOUT=*
//TAPEIN DD DISP=OLD,DSN=view_hlq.SARTAPE.T00nnnnn <=== Modify DSN
//SYSIN DD DUMMY
//
. . Note: nnnnn is the 5-digit sequence number of the tape, as kept within View.
- Compare the reports, to see what reports View considers active and to be on the tape, to what is actually on the tape.