After an IPL, I discovered that the database listener job QXDAEDRSQL is not active after I started SAP. I was unable to start the job when logon to <SID>ADM using 'startsap db' command. Only when I logon to QSECOFR and use 'strtcpsvr server(EDRSQL)' then I can start the listener job.
May I know why startsap command use to start SAP does not also start up the listener job? And why I can't start the listener when logon to <SID>ADM?
I discovered there were some job queue created for job STRRMTDB under library QGPL/QBATCH. I think this is the job belonging to <SID>ADM when attempting to start the listener. The job definition attributes indicates that the job ended with severity 30. That is the only information I have to work on. There are not spooled filed generated for the job.
Can you suggest how to troubleshoot further? Thanks.
Edited by: limws1 on Nov 23, 2010 4:17 AM
I did a DSPLOG on two SAP systems. One has no issue with the listener starting automatically while the other has an issue. Below are the log entries:
Listener started automatically:
Job 050856/ERPADM/SAPSTRSRV started on 11/21/10 at 19:17:29 in subsystem QUSR
Subsystem R3_02 started.
Job 050857/ERP02/SAPSTART started on 11/21/10 at 19:17:29 in subsystem R3_02
Job 050863/QPGMR/QPMASERV started on 11/21/10 at 19:17:33 in subsystem QSYSWR
Job 050864/QPGMR/QPMACLCT started on 11/21/10 at 19:17:44 in subsystem QSYSWR
Job 050853/ERPADM/DSP01 ended on 11/21/10 at 19:18:13; .164 seconds used; end
Job 050865/ERP02/SAPOSCOL started on 11/21/10 at 19:19:01 in subsystem R3_02
Job 050877/ERP02/PS started on 11/21/10 at 19:20:12 in subsystem R3_02 in R3E
Job 050877/ERP02/PS ended on 11/21/10 at 19:20:12; .022 seconds used; end cod
Job 050913/QUSER/QXDARECVR started on 11/21/10 at 19:21:37 in subsystem QSYSW
Job 050914/QUSER/QXDARECVR started on 11/21/10 at 19:21:49 in subsystem QSYSW
Job 050915/QUSER/QXDARECVR started on 11/21/10 at 19:25:41 in subsystem QSYSW
Device DSP01 no longer communicating.
Job 050916/QUSER/QXDARECVR started on 11/21/10 at 19:31:47 in subsystem QSYSW
Vary on completed for device ERP.
Session to device ERP ended normally.
Listener not started automatically:
Job 054549/QSYS/R3_01 started on 11/21/10 at 19:48:07 in subsystem R3_01 in R
Subsystem R3_01 started.
Job 054551/ERQ01/SAPSTART started on 11/21/10 at 19:48:08 in subsystem R3_01
Job 054556/QPGMR/QPMASERV started on 11/21/10 at 19:48:17 in subsystem QSYSWR
Job 054547/ERQADM/DSP01 ended on 11/21/10 at 19:48:19; .168 seconds used; end
Job 054557/QPGMR/QPMACLCT started on 11/21/10 at 19:48:27 in subsystem QSYSWR
Job 054558/ERQ01/SAPOSCOL started on 11/21/10 at 19:50:01 in subsystem R3_01
Job 054569/ERQ01/PS started on 11/21/10 at 19:51:15 in subsystem R3_01 in R3E
Job 054569/ERQ01/PS ended on 11/21/10 at 19:51:16; .023 seconds used; end cod
Vary off completed for device ERQ.
Description for device ERQ changed.
Vary on completed for device ERQ.
Session to device ERQ ended normally.
I noticed that for the system with listener started automatically, the listener was started when starting up the SAP sytem. However for the system with issue, the listener does not start when starting up the SAP system.
Edited by: limws1 on Nov 23, 2010 4:17 AM
Edited by: limws1 on Nov 23, 2010 4:25 AM
you may want to check the authority of socket /QXDALISTEN (in the root directory) and the authority of the root directory itself: WRKAUT OBJ('/QXDALISTEN') and WRKAUT OBJ('/'). I think, /QXDALISTEN inherits its authority from the root, that's why you need to check root, too.
If *PUBLIC does not have *RWX, this may explain your issue. Usually the system startup program is running under user profile QUSER, i.e. without any special authorities. You can check job description QSYS/QSTRUPJD to find out.
If authority is your problem, you have the following options to solve the problem:
1. Change job description QSYS/QSTRUPJD to run under QSECOFR or a similar user with special authority *ALLOBJ.
2. Grant *RWX authority to the root directory, so that next time the socket gets the same authority.
3. Use API's QSYGETPH and QWTSETP to switch to QSECOFR before executing the command STRTCPSVR SERVER(*EDRSQL).
Note that running the startup program with adopted authority - USRPRF(*OWNER) - will not solve the issue as adopted authority does not work for IFS objects.
I confirmed *PUBLIC has *RWX to both /QXDALISTEN and /.
Job log for QSTRUPJD has the following message:
>> QSYS/CALL QSYS/QWDAJPGM
Subsystem QSERVER in library QSYS being started.
STRTCP started for user QPGMR in job 053986/QPGMR/QSTRUPJD.
Unable to determine if operation completed.
Function check. TCP8A3F unmonitored by QSTRUP at statement 2900,
TCP8A3F received by QSTRUP at 2900. (C D I R)
Could it be that the TCP daemon wasn't started properly by QSTRUP thus causing the listener not to start up?
In my the other SAP server where the listener starts up automatically, I cannot see any message generated for QSTRUPJD.
the second level message text for TCP8A3F explains:
Cause . . . . . : Either TCP/IP is not active, or the job default wait time
was exceeded while waiting for the operation to complete.
Recovery . . . : Use the WRKTCPSTS (NETSTAT) CL command to determine if
TCP/IP is active. Review the QTCPCTL and QTCPWRK system job logs to
determine if the operation completed. Review the QSYSOPR and QTCP message
queues to determine when TCP/IP was ended or if it has not been started. If
the problem is determined to be a timeout problem, then wait for the system
activity to decrease, or increase the default wait time for your job using
the Change Job (CHGJOB) command.
If it was just for the startup program, then I would suggest to add the command DLYJOB DLY(30) between the STRTCP and STRTCPSVR command. However, if STRTCPSVR also fails now (several hours after the STRTCP command) with another user but QSECOFR, then the timing cannot be the issue. Mayby you should perform the actions of the message text to find out if you have any problems with STRTCP.