8 Replies Latest reply: Nov 23, 2010 2:07 PM by William Leonardo Neira RSS

QXDAEDRSQL is not active after IPL

Wee Seng Lim
Currently Being Moderated

Hi All,


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?






  • Re: QXDAEDRSQL is not active after IPL
    William Leonardo Neira
    Currently Being Moderated



    check spool files with the command WRKSPLF for user <SID>OFR or <SID>ADM.

    The issue should been becouse the user hasn't permissions.





    William Neira

    • Re: QXDAEDRSQL is not active after IPL
      Wee Seng Lim
      Currently Being Moderated



      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

    • Re: QXDAEDRSQL is not active after IPL
      Wee Seng Lim
      Currently Being Moderated

      Hi William,


      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

  • Re: QXDAEDRSQL is not active after IPL
    Christian Bartels
    Currently Being Moderated

    Hi Lim,


    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.


    Kind regards,

    Christian Bartels.

    • Re: QXDAEDRSQL is not active after IPL
      Wee Seng Lim
      Currently Being Moderated

      Hi Christian,


      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, 

             instruction X'0016'.                                           

           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.




      • Re: QXDAEDRSQL is not active after IPL
        Christian Bartels
        Currently Being Moderated

        Hi Lim,


        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.


        Kind regards,

        Christian Bartels.