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.

B was referring to program B

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?  

AJCLAIM CALL TO ELMAIN in order to view Patient Notes

85488 135468 1 40920 STRING '"' DELIMITED BY SIZE
85489 1 40920 RMCOBOL-PATH(1:PATH-INDEX) DELIMITED BY SIZE
85490 1 40920 '\RUNCOBOL.EXE" ELMAIN A="A' DELIMITED BY SIZE
85491 1 40920 PNF-EMPLOYEE-ID DELIMITED BY SIZE
85492 1 40920 PNF-FAMILY-MEMBER-ID DELIMITED BY SIZE
85493 1 40920 '" L=' DELIMITED BY SIZE
85494 1 40920 RUNTIME-PATH DELIMITED BY ' '
85495 1 40920 'LCSWIN.LIB, L=' DELIMITED BY SIZE
85496 1 40920 RUNTIME-PATH DELIMITED BY ' '
85497 1 40920 'LCSIO.LIB, L="' DELIMITED BY SIZE
85498 1 40920 RMCOBOL-PATH(1:PATH-INDEX) DELIMITED BY SIZE
85499 1 40920 '\WOWRT.DLL"' DELIMITED BY SIZE
85500 1 40920 ', L="' DELIMITED BY SIZE
85501 1 40920 RMCOBOL-PATH(1:PATH-INDEX) DELIMITED BY SIZE
85502 1 40920 '\LISQL.DLL"' DELIMITED BY SIZE
85503 1 40920 INTO SYSTEM-COMMAND
85504 1 40920 END-STRING.
85505 135611 1 CALL WINEXEC USING WIN-RETURN SYSTEM-COMMAND WIN-TRUE.

How did you debug it prior to Windows 10?     We were using RM/COBOL v10.01 & Windows 7.  We would compile AJCLAIM & ELMAIN using the Y=3 in the command tail.  In the debug session of AJCLAIM, we set a break on the string command, hit go and then step through the STRING and the CALL.  We would then get into ELMAIN.

I added the 'D' to the command line and tried again.  I received some debugging information but it's not as helpful as a normal debug session. ( I think my terminology may be a bit of a problem.  When I say 'debug' I mean 'CodeWatch' session.)  Is there a way, in this scenario, that I can step through ELMAIN in CodeWatch?

A quick comment - at another company, we were able to type a command - COBTRACE ON/OFF - and displays of the paragraph name were inserted/deleted at the beginning of each paragraph.  This functionality would be very useful in a situation like this. 

Going to summarize a bit here.

You didn't give the actual command in SYSTEM-COMMAND (that is, the contents of the data item), so I tried to put it together myself. I gather it looks something like the bold string below. with $(..) being replaced by the contents of the various data items:

"$(RMCOBOL-PATH)\RUNCOBOL.EXE" $(ELMAIN) A="A$(PNF-EMPLOYEE-ID) $(PNF-FAMILY-MEMBER-ID)" L=$(RUNTIME-PATH)LCSWIN.LIB, L=$(RUNTIME-PATH)LCSIO.LIB, L=$(RMCOBOL-PATH)\WOWRT.DLL, L=$(RMCOBOL-PATH)\LISQL.DLL

In this case, $(RUNTIME_PATH) must end in a backslash while $(RMCOBOL_PATH) apparently doesn't.

It looks like SYSTEM-COMMAND is used like this:

CALL WINEXEC USING WIN-RETURN SYSTEM-COMMAND WIN-TRUE

If we assume the program that's issuing this command has a similar command line, unless LCSWIN.LIB or LCSIO.LIB implement WINEXEC with different semantics, it would be using the WINEXEC in WOWRT.DLL.

I checked and the WOW WINEXEC always creates a new process. I don't see any way that any version CodeWatch would ever step into a new process or automatically attach to such a process -- not in v10 or v12. There must be something else missing here.

CodeWatch does understand RM/COBOL command lines. Is it possible that you replaced "RUNCOBOL.EXE" with "RMCW.EXE" in the above command? I'm not certain CodeWatch processes all runtime commands but this might be worth a try. 

In this case, you could try:

"$(RMCOBOL-PATH)\RMCW.EXE" $(ELMAIN) A="A$(PNF-EMPLOYEE-ID) $(PNF-FAMILY-MEMBER-ID)" L=$(RUNTIME-PATH)LCSWIN.LIB, L=$(RUNTIME-PATH)LCSIO.LIB, L=$(RMCOBOL-PATH)\WOWRT.DLL, L=$(RMCOBOL-PATH)\LISQL.DLL

Again, replacing the $(...) parts with the actual variables on the command line.

If there is something on this command line that CodeWatch doesn't understand, you could certainly create a CodeWatch workspace with the above settings and debug it that way. Since it's a separate process, it shouldn't inherit anything from the main program, although it would inherit environment variables.

This all assumes that the WOW WINEXEC is being used rather than another WINEXEC with different behavior.

I'll give it a try