IBM suggested I check my audit journal, might tell which PTF deleted the object.
I checked the QAUDITDO.

SELECT * FROM QGPL.QAUDITDO WHERE DOOLIB = QUSRDIRDB and DOONAM = QAGLDCNV52

DO 2017-04-15-23.18.57.150176
DO 2017-04-15-23.18.57.173056

Found 2 entries matching the date/timestamp, but those entries did not include the PTF detail.
Any thoughts from the group?

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob Berendt
Sent: Monday, April 17, 2017 2:47 PM
To: Midrange Systems Technical Discussion
Subject: RE: V7R1 - LDAP server failed to start with GLD040B, causing SSO via Kerberos to fail, folloiwng IPL with PTF apply

wrkobj QUSRDIRDB/QAGLDCNV52
ENDTCPSVR SERVER(*DIRSRV)
RNMOBJ OBJ(QUSRDIRDB/QAGLDCNV52) OBJTYPE(*FILE) NEWOBJ(QAGLDCNV5X) strTCPSVR SERVER(*DIRSRV) ... Job 084335/QDIRSRV/QUSRDIR submitted to job queue QSYSNOMAX DSPJOBLOG 084335/QDIRSRV/QUSRDIR
...
IBM Tivoli Directory Server instance QUSRDIR started successfully.
...
Messages basically match previous QUSRDIR job.

DLTF QUSRDIRDB/QAGLDCNV5X




Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 04/17/2017 02:38 PM
Subject: RE: V7R1 - LDAP server failed to start with GLD040B,
causing SSO via Kerberos to fail, folloiwng IPL with PTF apply
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Rob,

As a test, rename it, recycle LDAP, see if it starts.

If not, rename if back.

Thanks
Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Monday, April 17, 2017 2:36 PM
To: Midrange Systems Technical Discussion
Subject: RE: V7R1 - LDAP server failed to start with GLD040B, causing SSO
via Kerberos to fail, folloiwng IPL with PTF apply

I think "removed" was probably overkill. I think it's more like "it
doesn't build it, nor need it, anymore starting at 7.3" might be more
applicable.
I may start deleting it on some lpars which started out on levels prior to
7.1 and see if adverse reactions are experienced.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 04/17/2017 01:32 PM
Subject: RE: V7R1 - LDAP server failed to start with GLD040B,
causing SSO via Kerberos to fail, folloiwng IPL with PTF apply
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Rob,

According to IBM support, this table, QUSRDIRDB/QAGLDCNV52, was removed
at V7R3.
The details from development were "sketchy".

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob

Berendt
Sent: Monday, April 17, 2017 12:08 PM
To: Midrange Systems Technical Discussion
Subject: Re: V7R1 - LDAP server failed to start with GLD040B, causing SSO
via Kerberos to fail, folloiwng IPL with PTF apply

When are they plan on phasing that out?

I have this table on an lpar upgraded to 7.3 but maybe nothing deletes it?

Object . . . . . . . : QAGLDCNV52
Library . . . . . : QUSRDIRDB
Library ASP device . : *SYSBAS
Type . . . . . . . . : *FILE
Creation information:
Creation date/time . . . . . . . . . : 05/19/10 10:53:32

The change date/time matches our last unload/reload (P6-P8) from almost 3
years ago.

On an lpar which started out at 7.3 it does not exist. WRKJOB QUSRDIR
looks fat, dumb and happy.


Rob Berendt

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.