These questions and answers originally appeared on TechTarget's Expert Answer Center as part of Robert Crawford's two-week tenure as the on-demand expert in January to February 2006. During this time, he was available @18631 to quickly answer questions on CICS application performance and design, as well as to write daily blog entries. Keep an eye on the Expert Answer Center for topics that could help your IT shop.
We are running z/OS V1.4 and have WLM in goal mode. Our DB2 version is 6.1.0. I need to be able to throttle back jobs that interface with DB2. We don't use DDF or stored procedures with DB2. How can I create an enclave with WLM for this? Will I need to know every thread name to do this? Can I mask the thread name? I am new to WLM and have never set up an enclave before. We have set the CICS transactions that go to DB2, so they run slower, but I still need a way to slow down DB2. Any help you can offer will be greatly appreciated.
I'm inexperienced with WLM also, so I can't tell you how to set up enclaves. However, I do know that DB2 threads run at the priority of the original address space. Therefore, my best advice would be to dial down the batch jobs' priority until they can't get any CPU. You may restrict the number of batch jobs connected to a DB2 subsystem through thread parameters in ZPARMS, but I'm not sure what happens to running batch jobs when you run out of threads.
Is it possible to pass parameters and make a "call" to a CICS COBOL module from a batch COBOL program in a batch environment?
The short answer is no. I've done this accidentally and what happens is the CICS program gets a S0C1 abend when it makes its first call.
That being said, there are ways to write programs so they can run in batch and CICS. However, the program does need to be aware of its environment to avoid issuing any CICS commands. Fortunately, LE provides a couple of functions that can tell you where the program is running. I would look through the LE bookshelf to find out more about the available functions.
CICS also provides the External Call Interface (EXCI) through which batch jobs can use to communicate with programs running in CICS. A series of EXCI calls builds a communication "pipe" to a CICS region. Through that pipe you can link to a program that will actually execute in CICS. You pass parameters to the program through a COMMAREA just as if the calling program were in CICS, too. Consult the CICS External Call Interface manual (SC34-6006-10) for more information.
I think my CICS is running short on DFHTEMP storage during peak workload situations. We use VSAM. I can't seem to locate the job that built the temp files so that I could increase the allocation. What should I do next?
If you can't find the original JCL that created the DFHTEMP dataset you're going to have to recreate it. I'd start with an IDCAMS LISTCAT to see how the current dataset is defined. It should give you all the information you need, including the current allocation. The CICS System Definition guide also contains information on allocating a temporary storage dataset.
The IDCAMS define statements themselves are fairly simple because it's an entry sequenced dataset (ESDS). Pasted below is a sample:
DEFINE CLUSTER(NAME(CICS.DFHTEMP)- RECORDSIZE(4089,4089)- CYL(5) - NIXD - CISZ(4096)- VOLUME(xxxxxx) SHR(2 3)) - DATA(NAME(CICS.DFHTEMP.DATA)- UNIQUE)
You can change the cylinder parameter to meet your needs. And I'm sure I don't have to tell you to keep this it in a safe place this time.