Can you help us as we have changed the client's tape unit while using DFHSM to point to the New VTS and it rejects the tapes from the TLMS NSM/SCR pool.
Release : 14.0
Component : CA TLMS Tape Management
1). Tape Allocation. TLMS does not request or is a part of the allocation. Our hooks jump in after the tape is actually mounted. All tape mounts are determined by your IBM ACS rules and the VTS.
2). The TLMS NSM/SCR table. This came from the ole 3420/3480’s days when we had tape operators.
TLMS would intercept the mount message and re-issue with a mount message with the pool name(HSMSCR,etc,etc). We would check the volser to let the mount take place or reject.
3). Along came IBM VTS. The IBM VTS really doesn’t believe in a SCRATCH POOL concept. What was a PAYROLL.MASTER on Monday could be scratched and reused as a DFHSM.BACKUP the following day.
4). Can the TLMS SCR/POOL tables still be used with an IBM VTS? You will notice that when a mount is issued for your older volumes, that the mount message is prefixed with CTS001/ CTS002/CTS009:
CTS001 IEF233A M 3B3C,PRIVAT,SL,………..
This is from the mount message intercepts from TLMS. Let’s take a look at the mount from your DFHSM task last week:
IEC501A M 291F,PRIVAT,SL,COMP,DFHSM,DFHSM
Notice that the mount has a IEC501A prefix. Basically, we can not intercept the IBM mount messages for the VTS, thus we can’t modify the mount message. It is basically suppressed.
5). How do we ensure that the correct volume is being allocated? Again, IBM’s OAM/SMS/ACS routines are determining where the output is going. Assuming you will turn off the ability to write to the ATL and redirect all new DFHSM scratch mounts to the VTS. Guessing you will recycle the old DFHSM volumes to the new VTS. We need to phase out the old TLMS NSM/SCR pools for the new VTS.