Migration step 18: Start Db2 12

During migration to Db2 12, start the Db2 subsystem after you run job DSNTIJMV and IPL z/OS.

Before you begin

If you have not already done so, convert the BDSD to extended format, as described in Convert the BSDS, Db2 catalog, and directory to 10-byte RBA and LRSN format .

To start Db2, complete the following steps:

1. Start Db2 from the z/OS console with the following command, where -DSN1 is the subsystem command prefix that you defined for Db2, and DSNZPxxx is the name of the Db2 initialization parameter module:

   -DSN1 START DB2 PARM(DSNZPxxx)

   If you omit the PARM parameter, and you specified a value in the PARAMETER MODULE field on installation panel DSNTIPO3, that value is used as the parameter module name. If you did not specify a parameter module on panel DSNTIPO3, Db2 uses the default, which is DSNZPARM. See PARAMETER MODULE field.
   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

   Some Db2 catalog or directory table spaces remain restricted until you migrate the catalog to Db2 12. For more information, see What to do next .

   If Db2 starts successfully, some or all of the following address spaces start, where ssnm is the Db2 subsystem name.

   • The system services address space (ssnmMSTR)
   • The database services address space (ssnmDBM1)
   • The IRLM address space (irlmproc), where irlmproc is the IRLM procedure name
   • Possibly, the DDF address space (ssnmDIST)
   • Possibly, the administrative task scheduler stored procedure address space (ssnmADMT)

   If you have not run job DSNTIJRT, and the administrative task scheduler starts, the administrative task scheduler issues error message DSNA679I to report SQLCODE -805 until you run job DSNTIJRT. The administrative task scheduler starts if you specified an address space procedure name in the ADMIN SCHEDULER field on installation panel DSNTIPX.

   If Db2 does not start successfully, 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 correct job was run for DSNTIJUZ. Also, check that the subsystem parameter member that you specified (or used by default) when you started Db2 is the one that the DSNTIJUZ job built. Check the JCL for the Db2 startup procedure.

2. If you want to use the TSO SUBMIT command to do housekeeping and migration verification, start TSO (if it is not already started).
3. If you did not enable primary user IDs to issue Db2 commands from the z/OS console or TSO SDSF when you first installed the subsystem, take one of the following actions:
   • Grant SYSOPR authority to all primary user IDs that issue Db2 commands from the z/OS console or TSO SDSF. Issue the following command:

     GRANT SYSOPR TO userid

   • Define RACF® classes to authorize Db2 commands. Use the following statements:

     SETR CLASSACT(DSNADM)
     RDEFINE DSNADM DSN1.SYSOPR UACC(NONE)                        
     SETR RACLIST(DSNADM) REFRESH
     PERMIT DSN1.SYSOPR CLASS(DSNADM) ID(userid) ACCESS(READ)    
     SETR RACLIST(DSNADM) REFRESH   
     

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