TSO session holding IMS dynamic allocations

[Ed Goodman]

When we use Xpeditor (BTS mode) or Debug Tool (BTS mode), TSO seems to be holding the dynamic allocations that IMS makes to the databases.

We start BTS, IMS opens the databases as needed, then we end the BTS session. Then, you go and look at ISRDDN, and the DDs are still allocated to the database datasets.

Can cause trouble when someone else needs exclusive access, like for an image copy. Can also cause MAJOR trouble if developer switches environments, like from TEST1 to TEST2. Any of the prior allocations override dynamic allocation, and they get a mix of databases. Then either total chaos or total hilarity ensues, depending on your point of view.

Is there a way to get IMS/TSO to agree to free these allocations in RTM cleanup?

[don.leahy]

Is BTS running as a BMP?

[Ed Goodman]

No...the parm is DLI.

[PascalQ]

Ed, I saw your post on friday and thought to myself "why did he mention IMS in the title... that's gonna scare people off!"


Anyway, for those of us who don't know Xpeditor and Debug Tool... can you clarify? I'm a bit confused because you started talking about dynaloc and then switch to ISRDDN and DD statements.

What's that Xpediter in BTS mode thing? I know BTS a little, but it's usually a "plain" IMS batch job. So why can you see it in ISRDDN?

When I'm in ISRDDN and type "enq" I can see the enqueues to datasets, but no DDs. When in ISRDDN I can see my own DDs only...


Also: is this running under DBRC control? When the job ends (assuming it is a job), can you still see it listed as subsystem in DBRC? (LIST.SUBSYS SSID(jobname))

[yarnseeker]

"TSO seems to be holding the dynamic allocations "

by that i'm assuming that you mean true dynamic allocation. if you are debugging interactively, are they dyncamically allocated to YOUR tso session or are they dyncamically allocated to like a started task that is your debugging tool? it sounds like the former which would be a problem.

potential ugly fix #1 - change jcl to NOT use dynamic allocation and put free=close in jcl?

potential ugly fix #2 - change your script such that it will execute a clist/rexx that will release them

better fix is to have the debug product release any test files allocated. xpediter does this. Maybe there's an option for you somewhere that you just haven't discovered yet. You can only pray

"Can also cause MAJOR trouble if developer switches environments, like from TEST1 to TEST2" ... Been there. Done that. FIXED that.

Luckily we had a 'setup' in our cics environment where you can make it 'know' about the databases so we enforce a rule where only 1 test environment can 'know' about a set of test databases. We got tired of being burned on that one.

2nd issue was somebody running an image copy job WHILE the databases we online in CICS. We fixed that puppy by putting a disp=old on one of the databases in the JCL. we had 1 guy that had done this like 5 or 6 times w/in the last few months. The DAY I put that change in the test jcl, it caught him and prevented it

[Steve Coalbran]

As I understand it... through the grapevine...
The first thing to check is the user guide (sorry toyou!) which describes how to set up DT for IMS programs... and check it's been installed and configured correctly.
If it's an IMSPlex, for example, you may need to alter an LE run-time parameter
For IMS BTS programs - If you want your program and your debugging session to run on a single screen, choose full-screen mode. If you want your BTS data to display on your TSO terminal and your debugging session to display on another terminal, choose full-screen mode using a dedicated terminal. If you want your BTS data to display on your TSO terminal and your debugging session to display on a supported remote debugger, choose remote debug mode.
You will not get any response from (IBM)support until you can prove that it's all been set up and configured correctly.
Steve

[don.leahy]

Originally Posted by Ed Goodman

No...the parm is DLI.

Normally when DLI is used, the startup clist explicitly allocates the IMS data bases (which have to be offline) and explictly FREEs them afterwards.

[Ed Goodman]

First things first: a better explanation of what I'm running.

In my TSO session, I start debug tool. The session is set up for IMS online, full screen mode. So it actually needs to run the BTS program. (same as xpeditor)

BTS starts, I put in the starting transaction, it fires it off. IMS dynamically allocates databases to the proper DDs.

I end the BTS session, get the IMS CLEANUP complete message.

I go to ISRDDN, and the IMS database files are still allocated.

This happened when we used Xpeditor too.

So.... is it because my TSO session hasn't ended?

[PascalQ]

I don't know Ed, but surely something is wrong

Again, not understanding how you exactly invoke the Debug Tool and BTS, but do you at any stage (or in the settings?) have the chance to edit the JCL (there must be a batch job which is started, right? at least in the background...)?

If you have a chance to edit the JCL, as work-around you might want to try hard-coding the DDs and turning dynamic allocation off, by specifying NODYNALLOC in the DFSVSAMP DD. See here

[nadel]

I dont know anything about that environment, but as a short term fix, I'd suggest writing a quick and dirty CLIST or Rexx that frees those data sets after you are done (assuming they are not open). If the ddnames are always the same, you could even just assign a TSO FREE F(f1,f2,f3,...) to a PF key.