RE: Problems with the IBM Distributed Debugger -- CODE400-L



It seems to me that the debugger server socket cannot get a socket bind to
a port to listen to incoming requests.  Q5BROUTE is the debugger program
that attempts to set up the debugger back-end (AS/400 code) as a server
when the STRDBGSVR command is issued.    One of the reasons for failure
could be that the port is already being used by another process on that
AS/400.  By default the debugger server attempts to use port 3001. To
verify if this port is already being used,  issue the command NETSTAT on
the system followed by option 3.  Then press F14 to toggle the display to
show port numbers as opposed to port names and check the column entitled
Local Port.  If 3001 shows up and the debugger server is not running  (i.e
PGM-Q5BROUTE does not show up in Work with  Active Jobs display under
subsystem QSYSWRK), then 3001 is being used by another program.


      Remote           Remote  Local
 Opt  Address           Port    Port  Idle Time  State
      *                     *   3001  000:13:58  Listen
      *                     *   4005  043:30:48  Listen
      *                     *   4444  055:39:05  Listen



 To change the debugger server default port,  you will have to do a
WRKSRVTBLE SERVICE(QDBGSVR)and change the assigned port number.  You will
also have to change the default port number the debugger client will
attempt to connect to. You do this by clicking on the Advance button on the
Debugger Client Load Program dialog. Then change the port number in the
Debugger Settings page to match the one you assigned to QDBGSVR.

Hope this helps.


Satish Gungabeesoon
iSeries  AD Tools,  IBM Canada Lab,
416-448-3269   (tl:778-3269)
satish@ca.ibm.com


"Buckingham, Ed" <Buckingham@AE.com>@midrange.com on 01/22/2001 08:07:34 AM

Please respond to CODE400-L@midrange.com

Sent by:  owner-code400-l@midrange.com


To:   "'CODE400-L@midrange.com'" <CODE400-L@midrange.com>
cc:
Subject:  RE: Problems with the IBM Distributed Debugger


Hi John:
           I did try all of the steps that you have outlined here.  I was
able
to kill the Prestarted job with no problem, but when I try to start up the
debug sever I get the same problem again.  The job tries to start and then
looks like it ends with no problem.  I was able to get a joblog of the
STRDBGSVR command when it executes.  Below is what I found happening:

*NONE      Request                       01/22/01   07:57:48   QWTSCSBJ
*N       QCMD         QSYS         015E
                                     Message . . . . :  -CALL
PGM(QSYS/Q5BROUTE)
CPFAC04    Completion              50    01/22/01   07:57:48   Q5BROUTE
QSYS        *STMT    QCMD         QSYS         018C
                                     From module . . . . . . . . :
Q5BROUTE
                                     From procedure  . . . . . . :
GetUnixSocket
                                     Statement . . . . . . . . . :   11

                                     Message . . . . :   An error occurred
using the control socket for the debug
                                       server.

                                     Cause . . . . . :   The control socket
used to communicate with the debug
                                       server router function could not be
used.  The socket function attempted was
                                       'Bind    ' and the error code was
3401. Recovery  . . . :   Using the
                                       WRKOBJLCK command, check to see
which
job is holding a lock on object
                                       QSYS/Q5BROUTE; type *PGM. End all
jobs holding a lock and retry the
                                       ENDDBGSVR command.

CPF1164    Completion              00    01/22/01   07:57:48   QWTMCEOJ
QSYS        00AA     *EXT                      *N
                                     Message . . . . :   Job
417597/BUCKINGHAM/QSYSJOBD ended on 01/22/01 at
                                       07:57:48; 1 seconds used; end code 0
.
                                     Cause . . . . . :   Job
417597/BUCKINGHAM/QSYSJOBD completed on 01/22/01 at
                                       07:57:48 after it used 1 seconds
processing unit time.  The job had ending

I tried doing what was suggested here, but there were no locks that I could
see on the QSYS/Q5BROUTE object.  The one thing that I find odd is that
according to the joblog it appears to think that I issued the ENDDBGSVR
command when actually I issued the STRDBGSVR command.  Could this be
correct?  The command is not calling the correct program?  Thanks in
advance!

Ed B.

> -----Original Message-----
> From:         jstein@ca.ibm.com [SMTP:jstein@ca.ibm.com]
> Sent:         Friday, January 19, 2001 11:17 AM
> To:           CODE400-L@midrange.com
> Subject:           RE: Problems with the IBM Distributed Debugger
>
> Hi Ed,
>
> One of the debugger gang suggested that the cause may be that there are
> prestarted jobs Q5BWHSRV still hanging around when you issued the
> STRDBGSVR
> command.
>
> Try the following steps:
> 1. Use command
>
>    to kill the prestarted job.
> 2. Then use command
>      WRKACTJOB
>      Shift F2
>    to make sure there is no job Q5BWHSRV in subsystem QSYSWRK.
> 3. Now use command STRDBGSVR to start the debug server.
>
> Let us know if this solves the trouble.  Thanks.
> ____________________________________________________
> John Steinbacher, PhD.                   IBM Toronto Lab
> Manager, iSeries AD Tools & Strategy      jstein@ca.ibm.com
> 1150 Eglinton Avenue East, Toronto Ontario, Canada, M3C 1H7
>
> ---------------------- Forwarded by John Steinbacher/Toronto/IBM on
> 01/19/2001 10:50 AM ---------------------------
>
> "Barry W. Hoffman" <bwhoffman@natsem.com>@midrange.com on 01/19/2001
> 08:22:27 AM
>
> Please respond to CODE400-L@midrange.com
>
> Sent by:  owner-code400-l@midrange.com
>
>
> To:   "'CODE400-L@midrange.com'" <CODE400-L@midrange.com>
> cc:
> Subject:  RE: Problems with the IBM Distributed Debugger
>
>
> Hi Ed,
> I know how you feel.  I haven't had a working debugger ever since they
> switched from the Code400 Debugger (v3.2.1?) to the IBM Distributed
> Debugger (v3.2.2?) (at least a year and a half) until just last week
after
> applying SP1 to wdt400 v4.5.1 it magically started working!  We are on
> v4r4
> of OS400, too.  So my suggestion would be to upgrade to wdt400 v4.5.1 and
> apply SP1.  That's the only thing that's worked for me.
>
>
> Note: There are some PTFs for v4r4 listed on
> http://www-4.ibm.com/software/ad/varpg/support/code400.htm
> that should be applied if you haven't done so.
>
>
> Barry Hoffman
>
>
>
>
>
>  -----Original Message-----
> From:   Buckingham, Ed [mailto:Buckingham@AE.com]
> Sent:   Thursday, January 18, 2001 8:44 AM
> To:     'CODE400'
> Subject:        Problems with the IBM Distributed Debugger
>
>
> The copmany I work for has recently upgraded to v4r4 of the OS on the
> AS400.
> Since that time we have not been able to start the debug server using the
> STRDBGSVR command.  When I enter the command, I immediately get a
> completion
> message that my job completed normally.  If I look at my job log for the
> command it shows me the following message, "Start Prestart Jobs command
is
> not allowed now."
>
>
>
>  Cause . . . . . :   The Start Prestart Jobs (STRPJ) command is not valid
> at
>
>
>    this time for reason 1.  See reason 1 shown below:
>
>
>      1 - The prestart jobs for program Q5BWHSRV in library QSYS in
> subsystem
>
>
>    QSYSWRK are already active.
>
>
>
>
>
>  When I try to start a debugger session I still get the standard message
> that my connection was refused and that I need to run the STRDBGSVR
> command.
> Has anyone had any problems with V4R4 related to the debugger?  Is there
a
> PTF that needs to be applied?  Any suggestions would be helpful.  Thanks!
>
>
> Ed Buckingham
> IS Help Desk Consultant
> Phone (724) 779-5683
> buckingham@ae.com
>
>
> +---
> | This is the CODE/400 Mailing List!
> | To submit a new message, send your mail to CODE400-L@midrange.com.
> | To subscribe to this list send email to CODE400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> CODE400-L-UNSUB@midrange.com.
>
> | Questions should be directed to the list owner/operator:
larry@paque.net
> +---
>
>
>
> +---
> | This is the CODE/400 Mailing List!
> | To submit a new message, send your mail to CODE400-L@midrange.com.
> | To subscribe to this list send email to CODE400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> CODE400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
larry@paque.net
> +---
+---
| This is the CODE/400 Mailing List!
| To submit a new message, send your mail to CODE400-L@midrange.com.
| To subscribe to this list send email to CODE400-L-SUB@midrange.com.
| To unsubscribe from this list send email to CODE400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: larry@paque.net
+---




+---
| This is the CODE/400 Mailing List!
| To submit a new message, send your mail to CODE400-L@midrange.com.
| To subscribe to this list send email to CODE400-L-SUB@midrange.com.
| To unsubscribe from this list send email to CODE400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: larry@paque.net
+---