I need help with a tedious manual procedure. I need to find out in which of the 25 CICS production regions that...
file XXXX is in.
At times one of the production batch jobs is unable to close and/or open a file. When I check the JCL to see which region the file is in and I log on to that region and enter ' cemt I file (xxxx) ' the file is not there, so I have to start going through each of the regions to find my file. Sometimes I get lucky and find it in one of the first 5 regions that I check, and sometimes not so lucky.
So, Is there a magic command that I can enter that would locate that file no matter in which region it's in instead of me having to change the prefix of my command '??MT I FILE (XXXX) '.
This was a VERY interesting question, and I'm going to go through my thought process for your (no doubt) interest and delectation. My 1st idea was to run some sort of extract against the CSD and get the Connection and File definitions, compile them into a program and manipulate from there. I rejected this idea as it would not give a guarenteed layout of what files were actually where (as you could dynamically install them). A bit of a refinement was to have a PLT program which did the scanning for the files and dumped the info into a shared TSQ from where it could be read. This again falls down on the installation problem, so one would have to use CICS exits to note additions and deletions. This was not an appealing issue. So I came down to a dynamic bit of code which could be executed from within CICS and also from MVS. What you need to do is code up a demon-like utility program and put it in all of your regions. This should perform the following functions LIST -> extract all known files in the region together with open/closed (& the ings) enabled/disabled (& the ings) local/sysid INQ -> return this info for a specific file SET -> set the file status to be open/closed enabled/disabled This program should use the File Control SPI to do the browse (for LIST) or run the specific XC INQUIRE or SET actions verbs as appropiate. The commarea would look something like COMMAND CL8 (LIST,INQ,SET) SYSID CL4 (SYSID of executing region, set by caller and not touched) SPECIFIC FILE CL8 (for INQ/SET) SPECIFIC FILE OPEN/CLOSED AL4 (the CVDA) SPECIFIC FILE ENABLED/DISDABLED AL4 (the CVDA) NUMBER OF RETURNED FILES F (for LIST) Repeating for each file FILE CL8 FILE OPEN/CLOSED AL4 (the CVDA) FILE ENABLED/DISDABLED AL4 (the CVDA) SYSID CL4 (or local if X'00000000') Then write another program which manages things. It initially calls the utility prog in LIST mode for all regions. You end up with a list of files in both the local region and all remote regions. Then do some user interaction to select a file in an interested region, and XC LINK SYSID(x) the utility program with a SET on the file : this gets routed to the relevant region for execution. On return ship an INQ request to see that the status has changed. If you are clever, you can use the returned info from the LIST to construct a sequence of operations which stop access to the file in remote regions before actually closing it in the region where it physically resides. Even better, as all the work is being done by the utility program, you can run this is batch (see one of my SupportPacs which supplies codes to do this in JCL or a MVS Pipe) and stop access to your CICS files if offline operation is required or you have some sort of extermal monitor/operations tool.
Dig Deeper on IBM system z and mainframe systems
Related Q&A from Robert Crawford
For better mainframe capacity planning, how do I convert CPU hours to MIPS? And is there a way to calculate the relationship between MIPS and MSUs? Continue Reading
I have two years of experience in mainframe technology, currently working as a mainframe developer. I want to change to Java technology. Continue Reading
I want to replicate DB2 from the mainframe to an AIX box since it's cheaper and the copy can be used for testing. Is this possible? Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.