A few updates on this issue.
1) IBM confirmed that QAGLDCNV52 is no longer used at V7R2 and V7R3. IBM development stated " considering there is a work around, there is no plan to have the fix ported back to v7r1."
2) There are other old LDAP migration files that will be phased out.
QAGLDCNV51 *FILE QUSRDIRDB PF
QAGLDCNV52 *FILE QUSRDIRDB PF
QAGLDCNV53 *FILE QUSRDIRDB PF
QAGLDCNV54 *FILE QUSRDIRDB PF
3) By using the QAUDITDO log, and matching timestamps, confirmed that QUSRDIRDB/QAGLDCNV52 was NOT deleted by a PTF, but by QSQSRVR job # 947684, one of the many SQL jobs spawned by the QDIRSRV LDAP job.
This occurred a minute after the PTF apply, during the IPL process.
4) IBM is relooking at this as an SQL error, possible X-REF issue. They've seen this before where LDAP fails to start. Its still a mystery why SQL process may deleted QAGLDCNV52.
From the QAUDITDO log.
04/18/17 13:25:36 PAGE 1
Library Object Timestamp Job User Job Program User
name name name name number name profile
QUSRDIRDB QAGLDCNV52 2017-03-30-16.36.03.405520 PALPR5580M PAULS 773,457 QCMD PAULS
QUSRDIRDB QAGLDCNV52 2017-03-30-20.51.47.762848 PALPR5580M PAULS 776,902 QCMD PAULS
QUSRDIRDB QAGLDCNV52 2017-04-03-00.01.04.967296 PALPR5580M PAULS 806,487 QCMD PAULS
QUSRDIRDB QAGLDCNV52 2017-04-15-23.18.57.150176 QSQSRVR QUSER 947,684 QSQSRVR QDIRSRV
QUSRDIRDB QAGLDCNV52 2017-04-15-23.18.57.173056 QSQSRVR QUSER 947,684 QSQSRVR QDIRSRV
* * * E N D O F R E P O R T * * *
From the QDIRSRV LDAP joblog,
SQL7908 Completion 00 04/15/17 23:18:55.153211 QSQROUTS QSYS *STMT QSQCLI QSYS *STMT
From module . . . . . . . . : QSQSRVRC
From procedure . . . . . . : SQSERVER
Statement . . . . . . . . . : 8224
To module . . . . . . . . . : SQLCON
To procedure . . . . . . . : SQLConnect
Statement . . . . . . . . . : 13407
Thread . . . . : 00000001
Message . . . . : Job 947684/QUSER/QSQSRVR used for SQL server mode
processing.
Cause . . . . . : A Structured Query Language (SQL) statement was executed
while running in SQL server mode. SQL statements for this connection or
thread will be processed in job 947684/QUSER/QSQSRVR. Technical description
. . . . . . . . : SQL server mode was requested by either setting the SQL
server mode job attribute, or by setting the server mode environment
attribute via the SQL Call Level Interface. When running in this mode, SQL
statements are processed by a separate job, which runs under the user
profile specified for the connection. The thread identifier is 6 and the
connection is to Relational Database PENCOR05. If the Relational Database
name is *N, this means that all connections for the thread will use the same
job.
GLD040B Diagnostic 40 04/15/17 23:18:57.129104 QGLDLIBMSG QSYS *STMT QGLDRDBM QSYS *STMT
From module . . . . . . . . : GLDM400
From procedure . . . . . . : OS400_send_table_message__FiT1PPc
Statement . . . . . . . . . : 244
To module . . . . . . . . . : GLDRDBX
To procedure . . . . . . . : map_rc_fnc__FilN22PCcT5
Statement . . . . . . . . . : 80
Thread . . . . : 00000001
Message . . . . : SQL error -204 occurred.
Cause . . . . . : The directory server could not perform the requested
operation because an SQL error occurred. The SQL error information is as
follows: Return code = -204 SQL state = 42704 SQL message =
SYSINDEXES in QSYS2 type *FILE not found. Recovery . . . : The requested
operation failed. SQL errors are logged in SQL server jobs. Message SQL7908
in this job log indicates what SQL server jobs were used. Refer to the SQL
server job logs for the SQL errors that may have contributed to this error.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, April 18, 2017 12:04 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: V7R1 - LDAP server failed to start with GLD040B, causing SSO via Kerberos to fail, folloiwng IPL with PTF apply
On 18-Apr-2017 09:04 -0500, Steinmetz, Paul wrote:
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?
Look at more revealing details available as fields in that output file, such as the name of the user, job, and program [e.g. DOJOB, DOUSER, DONBR, DOPGM, DOPGMLIB] identified as responsible for generating those two Delete Object (DO) entries; then refer to the spooled joblog for the job.
midrange.com
