Joined: 14 Jan 2008 Posts: 2504 Location: Atlanta, Georgia, USA
You would probably be better off writing a CICS program, running as a non-terminal background task, which begins with an INQUIRE TSQNAME START command/API, followed by an INQUIRE TSQNAME NEXT command. After sucessfully completing the NEXT (EIBRESP=DFHRESP (NORMAL)), determine whether the TSQ is old enough to delete by comparing the amount of time between the current date/time and the LASTUSEDINT keyword of the INQUIRE command (you'll have to do some calculations as LASTUSEDINT is a fullword value in seconds) or is a candidate for deletion, regardless. If the amount of time exceeds your site's criteria or the TSQ can be deleted, then issue a DELETEQ TS command. Then, containing browsing the NEXT TSQNAME, regardless of the action made on the last TSQNAME, until you've reached the end of the TSQ's (EIBRESP=DFHRESP (END)).
However, you must be very careful not to delete TSQ's which belong to IBM, 3rd-Party vendors, etc or you may be looking for another employer.
Your program would have to be written to bypass all TSQ's that must not be deleted and it would be advisable to contact your CICS Tech Support personnel and/or CICS System Programmer(s) to determine the names of the TSQ's which cannot and the names which can be deleted.
Your program (transid) can be invoked at CICS Startup time during the 3rd-Stage of the PLT-PI and then within the program, it can issue a deferred start of itself, based upon the site requirements, without requiring manual intervention. For example, an INTERVAL of 10 minutes might be a favorable restart interval after reaching the END of the TSQ's.
The INQUIRE command structure (as well as other commands) requires that your program use the "SP" translator option during translation and sometimes, shops don't allow application programs to issue "System Programmer" commands. You need to verify whether you have the ability to use the "SP" option.
Please review the "CICS System Programming Reference" for your particular version/release. The INQUIRE TSQNAME command accompanied with the LASTUSEDINT keyword was introduced with CICS/TS 1.1, when the Hursley folks rewrote the TSQ DOMAIN logic and functionality.
If the LASTUSEDINT keyword is not available in your INQUIRE TSQNAME API, then your CICS version/release doesn't support it.
Joined: 20 Oct 2006 Posts: 6970 Location: porcelain throne
I guess it is easier to write a program to clean up instead of having each program that creates a que also delete when the tran is finshed. I agree this is predicated on using a return tranid in the exit process of a module, but this problem has been around since cics began and most shops have found a way to delete unnecessary tsqs.
I could see this as a repeated process during the day, but why at the end of day? Is CICS 'SHUT DOWN' at the end of day?
if cics is not brought down at the end of day (at our shop most cics regions are 24/7) then either this, as bill said, possibly dangerous methodolgy (run a job) or properly write the programs that create the tsqs to delete them at the appropriate time.
At my current client, we have some 400 TSQ possibilites in one application alone, and unless the user is 'disconnected' and does not re-connect, each program recognizes when transfer is to change (dfhaid = ? or new tranid) and deletes the tsq before exiting. we have some 8000 users (400 x 8000) and this would leave just too many ques to have sitting around until a separate job deletes them.
though it will work (your separate job whether batch or cics) i feel it is a sledgehammer approach to correcting what should be programmatically accomplished by the que creating program.