Verified Answers


If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it!  Learn more

  • State Verified Answer
  • Replies replies
    9
  • Subscribers subscribers
    5
  • Views views
    1576
  • Users 0 members are here
  • Locked Locked
Related
Options
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

LindaPraed_img

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

  • Verified Answer

    0

    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.

Reply

  • Verified Answer

    0

    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.

Children

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.