This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Debugging program called via WINEXEC

We are upgrading from RM/COBOL v10.1 to v12.17 and Windows 7 to 10.  This functionality worked prior to the upgrade.

I have a pair of program that I need to debug.  I've compiled both with debugging on.  

Program A calls program B using WINEXEC:

40920    STRING '"' DELIMITED BY SIZE
40920                    RMCOBOL-PATH(1:PATH-INDEX) DELIMITED BY SIZE
40920                    '\RUNCOBOL.EXE" B A="A' DELIMITED BY SIZE
40920                    PNF-EMPLOYEE-ID DELIMITED BY SIZE
40920                    PNF-FAMILY-MEMBER-ID DELIMITED BY SIZE
40920                    '" L=' DELIMITED BY SIZE
40920                    RUNTIME-PATH DELIMITED BY ' '
40920                    'LCSWIN.LIB, L=' DELIMITED BY SIZE
40920                    RUNTIME-PATH DELIMITED BY ' '
40920                    'LCSIO.LIB, L="' DELIMITED BY SIZE
40920                    RMCOBOL-PATH(1:PATH-INDEX) DELIMITED BY SIZE
40920                    '\WOWRT.DLL"' DELIMITED BY SIZE
40920                    ', L="' DELIMITED BY SIZE
40920                    RMCOBOL-PATH(1:PATH-INDEX) DELIMITED BY SIZE
40920                    '\LISQL.DLL"' DELIMITED BY SIZE
40920                    INTO SYSTEM-COMMAND
40920    END-STRING.
CALL WINEXEC USING WIN-RETURN SYSTEM-COMMAND WIN-TRUE.

I am able to debug program A but I can't get into program B.  Does anyone have a solution?

Thank you

Parents
  • 0

    Hi Linda:

    If I read this right, you're using CALL SYSTEM to launch another COBOL program.  This launches an entire new runtime system in a separate process.  I don't see how the second process could ever be debugged with the command line you provided using CodeWatch. 

    However, you highlighted the B in the created command.  This looks wrong as if the "buffersize" command line option needs a numeric parameter.

    I'm wondering if, instead of B you meant to use D for using the command line debugger.  So maybe this is the source of the problem and you're using the command line debugger to debug the second process.

  • 0 in reply to 

    B was referring to program B

Reply Children
  • 0 in reply to 

    It would be good to see the entire rendered command. 

    You did say this worked before, but without a D on the command line, I can't see what would cause program B to enter debugging mode since CALL SYSTEM would create a new process. 

    How did you debug it prior to Windows 10?