Troubleshooting
Problem
When running EDIFFUT utility for the first time, WebSphere® Data Interchange 3.3 for z/OS issues the following error to the joblog: +Program failed attempting to initialize the Service Director. Job terminated. Return code = 4. Extended return code = 12.
Symptom
EDIFFUT batch utility encounters, "Program failed attempting to initialize the Service Director. Return code = 4. Extended return code = 12."
WDI 3.3 Client error: "12008 WDI system is at V2.1 and needs to be upgraded to V3.3"
Cause
There are various causes for the above generic errors. The following documentation is strictly for when there is no SQL code in an accompanying error. If an SQL code is provided, instead follow DB2® documentation for the particular SQL code and reason code.
Diagnosing The Problem
If no SQL code is provided in the joblog, then check DSNTRACE for any non-zero reason codes that may have been encountered by DB2. To obtain a DSNTRACE, simply add the following dd statement to your JCL and run the failing job again:
//DSNTRACE DD SYSOUT=*
Search for "RC1" and "RC2" in this trace. All values should be zero. Example of a non-zero entry:
DSNA814I DSNACA70 TCB=009FF310 RC1=0008 RC2=00F30034 ...
If a non-zero code is reported, follow DB2 documentation for the particular Reason code provided in RC2. In the case above, reason code 00F30034 indicates that the authorization ID associated with this connection is not authorized to use the specified plan name or the specified plan name does not exist.
If no SQL code or reason code is being reported as described above, then the cause is likely from certain WDI DB2 tables missing default data loaded during installation.
Note1: This initialization problem is likely to appear during WDI for z/OS installation while running job EDIJDAT1 because this is the first step of the installation process that invokes the Utility.
Note2: If this problem is occurring and you are not currently in the process of installing WDI, then the likely cause is from losing data in one of the WDI tables.
Resolving The Problem
Verify that the following tables are not empty:
Loaded during installation job EDIJRDLD:
EDIPSTD
EDIPSTT
EDIPSTV
EDIMSGS
Loaded during table and object creation using SPUFI member EDISDB2:
EDIPSDI
EDIPSEI
EDIOWNR
EDIPSAP
EDIPSLP
In this particular case, EDIJDAT1 was failing because EDIPSDI was empty due to a failure on "INSERT INTO EDIENU3.EDIPSDI..." when running EDISDB2 via SPUFI.
Another likely cause would be if EDIPSTV were empty. In this case, and to prevent referential integrity errors, ensure table EDIPSTD is successfully loaded first. The initial load for EDIPSTD and EDIPSTV is done via job EDIJRDLD. You may need to delete all rows from both EDIPSTD and EDIPSTV, then re-run the associated job steps in EDIJRDLD pertaining to the two tables.
Note1: This same symptom could occur for any number of tables above. If unsure which failed, drop/redefine the WDI DB2 database verifying that all INSERT statements in EDISDB2 were successfully executed, and then resume WDI installation steps from where job EDIJRDLD was run and continue on.
Note2: If this problem is occurring and you are not currently in the process of installing WDI, then the likely cause is from losing data in one of the above tables. In which case, you should check each table above for data and restore from backup any that are empty. Do not drop your database or reload data via EDIJRDLD as described above as this loads only default data, not user data.
Was this topic helpful?
Document Information
Modified date:
01 August 2018
UID
swg21385010