Attempting to run the MIM CTC path validation utility on FSYS with the name CTCPROC fails with JCL error. Below are the messages from the log.
$HASP100 CTCPROC ON STCINRDR
IEF695I START CTCPROC WITH JOBNAME CTCPROC IS ASSIGNED TO USERMIM
, GROUP G1035STC
$HASP373 CTCPROC STARTED
IEF403I CTCPROC - STARTED - TIME=23.25.09
IEF453I CTCPROC - JOB FAILED - JCL ERROR - TIME=23.25.09
-JOBNAME STEPNAME PROCSTEP STEPNO
-CTCPROC CTCPROC 1
$HASP395 CTCPROC ENDED
IEE132I START COMMAND DEVICE ALLOCATION ERROR
IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=004D.
4 XXIEFPROC EXEC PGM=MIMCTPRF,TIME=1440,REGION=4M
5 XXSTEPLIB DD DISP=SHR,DSN=SYS2.MIM125.FSYS.LINKLIB
6 XXCTC DD DDNAME=IEFRDER
7 XXSYSUDUMP DD SYSOUT=*
8 //IEFPROC.IEFRDER DD UNIT=58A
IEF695I START CTCPROC WITH JOBNAME CTCPROC IS ASSIGNED TO USER MIM , GROUP G1035STC
IEF467I CTCPROC CTCPROC CTC - UNITS REQUIRED NOT CURRENTLY AVAILABLE - WAITING NOT ALLOWED
IEF272I CTCPROC CTCPROC - STEP WAS NOT EXECUTED.
Taking from FSYS:
MIM0067I Command DISPLAY 923
MIM0176 MIM PATH DISPLAY:
LAST RESTART AT 06:12:20 ON 2021.007
DEV SYSTEM STATE IO-STAT READS WRITES ERR TIME/RSV CYCLES
N/A FSYS LOCAL 0 0 0
05A8 DSYS USABLE IDLE 0 0 0
05AA DSYS USABLE IDLE 0 0 0
0598 TSYS USABLE IDLE 0 0 0
059A TSYS USABLE IDLE 0 0 0
>0580 ESYS IN-USE IDLE 672,182 670,152 0.004120 559,771
0581 ESYS USABLE IDLE 0 0 0
0588 ASYS USABLE IDLE 0 0 0
058A ASYS USABLE IDLE 0 0 0
XCF ESYS USABLE 0 0 0
XCF TSYS USABLE 0 0 0
XCF DSYS USABLE 0 0 0
XCF ASYS USABLE 0 0 0
This behavior raises some questions:
Component : MIA, MII, MIM
The IEF467I message indicates that another job is using the unit requested. The system does not allow waiting for the unit to become available. As illustrated below, CTC devices being tested by the MIM PROCCTC utility cannot be defined or in use by any other utility - including MIM.
What does this "D PATHS" output mean in terms of device allocation/reservation and should we expect CTCPROC to work in such a case?
The MIM DISPLAY PATHS output shows device 58A is already allocated to MIM on ASYS, so cannot be accessed by the PROCCTC. If the error is occurring and the device is not allocated by MIM, it may be in use by another task or SMS. Use the sample job below to determine CTC allocation; a failed result confirms the use of the device for another task.
//JOBNAMEG JOB (123100000),'ALLOCATE CTC',
//ALLOC EXEC PGM=IEFBR14
//DD1 DD UNIT=58A
Does MIM check if primary CTC devices are communicating with each other during initialization?
Yes. MIM performs CTC path validation (handshaking) during product initialization under these conditions:
As MIM validates both the primary and alternate CTC paths, any issues identified will mark the path status as "IN ERROR" - making the device unavailable for use. Successfully validated failover devices will show as "USABLE IDLE" on the MIM DISPLAY PATHS command output - but only on the local system. Therefore, it's required to route this command on all systems where the device(s) are in-use versus available
Can we deallocate the secondary CTC devices on both systems and test the PROCCTC while MIM is running on all systems?
Yes, it is possible; however, it's advised users contact MIM product support for assistance in performing this test. The intention of this measure is two-fold:
Is there any other way to validate the CTC devices while MIM is active across the MIMplex?
The answer to this question depends on the scenario:
Sites acquiring new devices for MIM are recommended to use the PROCCTC utility as intended - validating the new CTC device(s) function correctly prior to implementing
Sites, where users want to test the PROCCTC itself but have no unallocated devices, can opt to either use the process above to deallocate secondary CTC devices from MIM usage or to wait until new, unallocated devices become available.