Tape Swap contention

[Anon Anon]

Has anyone experienced MICS jobs interfering with Tape Swap maintenance? Our Tape Librarian has noticed the following:
Periodically, maintenance (microcode update, etc) must be performed on our IBM virtual tape libraries. Our configuration allows tape processing to continue during this activity however certain actions need to be taken. UCBs associated with the 'cluster' to be worked on must be freed up. This is accomplished by use of the SWAP command. This swap processing works well for almost all tape allocations. It does not work for a very small subset. The actual maintenance activity cannot begin until all appropriate UCBs are freed up. So if a UCB can't be freed up by use of SWAP, the activity is delayed until the associated job completes. I have been trying to determine what causes this issue. When a SWAP of drives associated with these DD's is attempted, the following message is issued:
IGF512I SWAP FROM xxxx TERMINATED - NO USER FOUND

[Scott Barry]

I personally have not seen this condition in the 4 decades (ouch!) I have been involved with MICS and have been supporting MICS (or other software) clients, however I am unsure which specific type of MICS job you are experiencing this condition (e.g., BACKUP, HISTW/HISTM, AUDIT, TAPEfff in DAILY/INCRUPDT?)

As I see it, this condition is not necessarily MICS-unique and could occur with any batch job that has a DD allocation for a tape resource that is not opened right away at job-step initiation.

These instances with MICS where a UNIT=(<TapeEsoteric>,,DEFER) is used to delay the tape-unit allocation until the last possible point in a long-running job-step are typical with MICS. For jobs like DAILY/INCRUPDT and the TAPEfff outputs, MICS (though more about it being SAS behavior) issues a LIBNAME at the point in the job where the allocation is necessary to continue operation.

So, for consideration, a long-running batch job that uses tape-allocation DEFER processing may be what's conflicting with the TAPE SWAP operation, rather than it being something unique to MICS? You may want to perform a test where the DEFER parameter is not used. Unfortunately, the MICS JCLGEN process does not have a JCLDEFC/JCLDEF option for omitting this parameter.

Regards,

Scott Barry
SBBWorks, Inc.