PD down after RCLSTG *DBXREF

AllisonD

Well Known Member
We were getting errors during a package build suddenly. Solution ID 2009044840 fit the symptoms and we checked our iSeries DBXREF and found it damaged. We took the system and did the reclaim storage the solution recommended and IBM concurred. after we did SQLPKG deletes including JDBJ899 in SY812. After the IPL we can no longer log into our fat clients at any workstation. The JDE.log shows;

ODB0000163 - SQLDriverConnect failure. rc=-1

The next error is;

ODB0000164 DBC:01 [28000][8015] [IBM] [iSeries Access ODBC Driver] cmmunication link failure. comm rc=8015 - CWBSY1006 - User ID is invalid, password length = 0, Prompt Mode = Never, System IP Address n.n.n.n

We visited all passthru ID's and all are functional. Need help, last contact with JDE late last night failed because of an error in their support transfer. recording said add a 3 to a number the never shared and all other efforts to get a live body failed. renewing the effort this morning. We're running on about 3 hours sleep so forgive me if I've left anything out. All help gladly and greatfully accepted.
 
Hi Allison,

Would it be possible you erase Q* SQLPKGs by mistake?
That could cause ODBC communication stop working.
If that's the case, you have to restore them from tape.
 
Object Type Library Attribute Text
QSQLPKG2 *SQLPKG QSYS PACKAGE
QSQXDPKG *SQLPKG QSYS
QZDAPKG *SQLPKG QGPL

They are present but is the fact that two don't appear to have an Attribute assigned an issue? I don't think so since I see other *SQLPKG objects that randomly have and don't have attributes.
 
here's a log...Please review.
 

Attachments

  • 130191-jde.txt
    7.1 KB · Views: 528
Does Porttest work? I was thinking of deleting the QZDAPKG file but it looks like the solution id you gave had you do that already.
 
I would agree that if you have not yet deleted QZDAPKG sqlpkg you should try this (wrkobjlck on this to determine which prestart jobs to end before deleting this).

I would setup a client access trace so you can see what information is being sent to the AS/400.

Also, is the client ever getting to the security server job? Check the logs for it. You might want to turn on debug on the server to see the server debug log for the security kernel.
 
Thanks everyone for the replies; here goes the responses.

Porttest did work;
QZDAPKG was deleted;
QSQLPKG2 & QSQXDAPKG were downloaded and replaced on ES;
Here is EDRSQL;
Subsystem/Job User Type CPU % Function Status
QTVDEVICE QTCP BCH .0 PGM-QTVDEVMG TIMW
QTVTELNET QTCP BCH .0 TIMW
QXDAEDRSQL QUSER BCH .0 PGM-QXDALISTEN SELW
QYPSJSVR QYPSJSVR BCH .0 PGM-QYPSJSVR SIGW
QYPSPFRCOL QSYS BCH .0 PGM-QYPSPFRCOL DEQW
QYUSALRMD QSYS BCI .0 PGM-QCSTCTEXEC SELW
QYUSCMCRMD QSYS BCI .0 PGM-QCSTCTEXEC SELW
QZBSEVTM QUSER ASJ .0 PGM-QZBSEVTM EVTW
QZHQSRVD QUSER BCH .0 SELW

Should there be more than just the QXDALISTEN running?

DEBUG on the Server? (Enterprise or Deployment)?

What on the as/400 is security server trying to connect to? When we take away the security server within the INI, we were able to log on. How come? Something is jumping the tracks...Help me kill a few more brain cells please.
 
BTW, Tom Shoemaker says hi, seems you got stuck at the same table with him at the Cheyenne Mountain Resort a few years back.
 
There normally are two different jobs running for EDRSQL, but I think the second might only start if you have a particular type of activity. you might want to open a call with IBM to discuss.

Debug would be on the AS/400 OW services. When a user signs into OW, if the Security Server is turned off in the workstation jde.ini, then the user id/password that is entered into OW is used to authenticate against the AS/400 directly. The security server on the Enterprise Server is not used. However, when Security Server is turned on in the workstation jde.ini, the the user id/password is used to attach to the AS/400 OW Security Server job. THat job would give you information if it was debugged.
 
Hello,
I have lost QSQLPKG2 and QSQXDPKG how do you get those files? I have V5R1
Thanks
 
I had to get them from IBM Service. The bottom line was I had a corrupted DB Cross Reference. I ended up doing a scratch install and restoring from backups. I would start with the Q SQL packages with IBM's assistance and see if that fixes your issues. If you still have problems, IBM should be able to tell if your cross reference is whacked. I hope your problem ends better than mine did... Good Luck.
 
Back
Top