A very long time ago at $previousjob-1 we used an MPF exit for messages such as TMS001, IEC101A, IEC501A, IEC501E, IEF233A and IEF233D. This exit looked at the tape UCBs for the job name of the newly allocated drive and if the job exceeded a defined limit the exit canceled the job.
I do have the source code available if someone wants to read some real ugly code. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&[email protected] ------- Original Message ------- On Monday, November 7th, 2022 at 6:06 PM, Glenn Miller <[email protected]> wrote: > We encountered the exact same problem recently. In our situation, a batch job > using the IBM DB2 DSNUTILB attempting to perform a DB2 Reorg of a partitioned > DB2 Table with 500 partitions. The batch job was submitted by a TSO User, not > our TWS job scheduler. The job slowly allocated about 470 virtual tape drives > in about 90 minutes until it received IEF877E followed by IEF238D. > Unfortunately, our automation replied WAIT to the IEF238D and replied NOHOLD > to the subsequent IDF433D. That caused Operations to be unaware of the > 'problem' until nearly an hour later when HSM need a virtual tape drive. > A cancel of that 'mis behaving' batch job cleared up the problem, however we > have be struggling with finding a way to prevent the problem or alerting our > Operations folks in real time that a 'not good' situation may be occurring. > As of today, we don't have a good answer for either part. > Glenn Miller > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
