Fallback step 4: Start Db2 11

During fallback, you can start Db2 11 after you re-establish your Db2 11 TSO logon procedures, CICS® connections, and IMS connections.

Procedure

To start Db2 11:

Start the IRLM.
If you have not requested that Db2 automatically start the IRLM, start it before you start Db2. Use the following command, where irlmproc is the name that you assigned to the IRLM startup procedure:
```
START irlmproc
```
This is the value that you specified for the PROC NAME option on installation panel DSNTIPI.
If you specified YES for the AUTO START option on installation panel DSNTIPI, Db2 starts the IRLM automatically.
Start Db2 from the z/OS® console by using the following command:
```
-DSN1 START DB2,PARM(DSNZPxxx)
```
In this command, -DSN1 is the subsystem command prefix that you defined for Db2, and DSNZPxxx is the name of the Db2 11 subsystem parameter module. If you used the default name, DSNZPARM, you can omit the PARM parameter.
If Db2 starts successfully, two to five address spaces also start. These address spaces are ssnmMSTR and ssnmDBM1, and possibly ssnmDIST and irlmproc, where ssnm is the Db2 subsystem name and irlmproc is the IRLM procedure name.
If Db2 starts successfully, the series of restart messages that you receive concludes with these two messages:
```
DSNR002I   RESTART COMPLETED
DSN9022I   DSNYASCP '-DSN1 START DB2' NORMAL COMPLETION
```

Complete one of the following actions:

Option Description

Option	Description
If you have done distributed processing with your Db2 12 subsystem	Check message DSNR005I for the number of indoubt threads after you start Db2. If you find no indoubt threads, continue falling back as if you had not done any distributed processing. If you find indoubt threads, issue the following command: `-DSN1 DISPLAY THREAD(*) TYPE(INDOUBT)` If the number of indoubt threads that are reported in the DSNV408I messages is equal to the number of threads that are reported in the DSNR005I message, continue falling back as if you had not done any distributed processing. If fewer indoubt threads are reported by DSNV408I messages than in message DSNR005I, proceed as follows: Stop Db2 11. Determine which units of work are incomplete by scanning the Db2 recovery log with the Db2 12 DSN1LOGP utility. Use the SUMMARY option of this utility. Examine the DSN1LOGP output to find all the DSN1162I messages that have a COORDINATOR name in a remote location. Each of these messages identify an indoubt DBAT. Record the LUWID that is displayed in each message. Decide whether to commit or abort each indoubt DBAT. One way to do this is by contacting the COORDINATOR location. If it is another Db2 subsystem, use the DISPLAY THREAD command to help you decide. If you have not already done so during migration, apply the fallback PTF that is supplied with Db2 12. Start Db2 11 again. Issue the RECOVER INDOUBT ACTION(`correct decision`) LUWID(`luwid`) command to resolve each indoubt DBAT.
If you have not done distributed processing with your Db2 12 subsystem	Check outstanding restrictions after you start Db2. Identify databases whose uses are restricted by issuing the following command: `-DSN1 DISPLAY DATABASE() SPACENAM() RESTRICT` You can start some of these databases at this time.

If you have done distributed processing with your Db2 12 subsystem

Begin general-use programming interface information.

Check message DSNR005I for the number of indoubt threads after you start Db2. If you find no indoubt threads, continue falling back as if you had not done any distributed processing. If you find indoubt threads, issue the following command:

-DSN1 DISPLAY THREAD(*) TYPE(INDOUBT)

If the number of indoubt threads that are reported in the DSNV408I messages is equal to the number of threads that are reported in the DSNR005I message, continue falling back as if you had not done any distributed processing. If fewer indoubt threads are reported by DSNV408I messages than in message DSNR005I, proceed as follows:

Stop Db2 11.
Determine which units of work are incomplete by scanning the Db2 recovery log with the Db2 12 DSN1LOGP utility. Use the SUMMARY option of this utility.
Examine the DSN1LOGP output to find all the DSN1162I messages that have a COORDINATOR name in a remote location. Each of these messages identify an indoubt DBAT. Record the LUWID that is displayed in each message.
Decide whether to commit or abort each indoubt DBAT. One way to do this is by contacting the COORDINATOR location. If it is another Db2 subsystem, use the DISPLAY THREAD command to help you decide.
If you have not already done so during migration, apply the fallback PTF that is supplied with Db2 12.
Start Db2 11 again.
Issue the RECOVER INDOUBT ACTION(correct decision) LUWID(luwid) command to resolve each indoubt DBAT.

End general-use programming interface information.

If you have not done distributed processing with your Db2 12 subsystem

Check outstanding restrictions after you start Db2. Identify databases whose uses are restricted by issuing the following command:

-DSN1 DISPLAY DATABASE(*) SPACENAM(*) RESTRICT

You can start some of these databases at this time.

If Db2 does not start properly, it usually abends with a reason code that indicates where the error occurred. To find the error, check the set of definitions for the associated resource. A common cause of startup failure is that the BSDS does not match the subsystem parameter values; ensure that the startup procedure is pointing to the correct BSDS and subsystem parameter. Also, check that the subsystem parameter member that you specified (or is used by default) when you started Db2 is the one that job DSNTIJUZ built. Check the JCL for the Db2 startup procedure.
Optional: Start TSO. If you want to use the TSO SUBMIT command to do housekeeping and fallback verification, you must start TSO (if it is not already started).