Debugging DEC C program started from MS Window application

[Arch_Muthiah]

Hi,

Env: OpenVMS 8.2/HP Alpha DS10 Server with DEC programs and MS Windows with VB.

VB screens gets user input and creates datafile; sends the datafile as input to DEC C image thru TCPIP V5.4 and DEC C image starts run, and the results sent back to windows.

Could you please help on how can I run the DEC C image in debug mode? to see step by step execution of C source?

Note: I am going thru VMS debugger manual, but unbale to get good idea out of it.


Archunan

[Jefferson Humber]

Archunan,

You need to compile and link the DEC C .EXE with the /DEBUG switch.

When you run the .EXE then it will be obvious.

Jeff

[Arch_Muthiah]

Jefferson,

I do compile/link using /DEBUG qualifier only. the question is that I don't give $RUN/debug CProg.exe command, this CProg image is triggered by windows' VB program thru TCPIP. I can not $RUN/deb CProg.EXE from VMS as it needs so many records of data from VB screens.

I will appreciate any further suggestions on this.


Archunan

[Ian McKerracher_1]

Hello Archunan,

How is your DEC C image actually initiated? Is the VB program using an Active X control to start a terminal emulator (e.g Reflection) or TCP/IP session which in turn starts the C image on OpenVMS? If so, the VB program probably contains the command to run the C image and it is this command which can be changed. But I'm not sure whether you would have interactive access to the C image.

Is the datafile which is sent from the VB program actually stored on the OpenVMS system?


Regards,

Ian

[Arch_Muthiah]

Ian,

>How is your DEC C image actually >initiated? Is the VB program using an >Active X control to start a terminal >emulator (e.g Reflection) or TCP/IP >session which in turn starts the C image >on OpenVMS?

The windows side GUI, looks like VB or VC++, this actually initiates TCPIP (socket) programming; sends datafile and along with startup information to DEC C programs. Once the input data entered into the GUI screen (not emulator) from MS windows, it inturn communicates with VMS and starts DEC C image. So we can not see anything visually in the OpenVMS side. Windows sends data records only one time; DEC C does processing in VMS side and returns the result back to windows. As windows waits for the result, if there is any delay in VMS side, windows will give timeout error.

****Note:*****
My question is how to debug this DEC C program to see step by step processing?

Archunan

[John Gillings · Accepted solution]

Archunan,

It depends on what you have available and what you're used to.

Probably the best way - Assuming you have access to the LOGIN procedure of the process that runs the program, and you have an X server. Either the Alpha system itself, or a PC running eXcursion or similar. Modify the LOGIN, adding a line like:

$ SET DISPLAY/CREATE/NODE=x-server/TRANSPORT=TCPIP

Now RUN the program with /DEBUG.

An X DEBUG window will appear on the X Server when the program is started. You can now single step etc...

If you don't have an X environment, and you can grant the process SHARE privilege, then login at some terminal and detmine the terminal device name from SHOW TERM (say it's TNA124). Modify LOGIN, redirecting DEBUG input and output to your terminal:

$ DEFINE DBG$INPUT TNA124:
$ DEFINE DBG$OUTPUT TNA124:

Then RUN/DEBUG the program.

From your terminal, issue a WAIT command to quiet your interactive process for a while:

$ WAIT 5:00:00 ! Wait 5 hours

When the program runs, you'll get all DEBUG input and output at your terminal.

If you don't have access to the LOGIN procedure of the process running the program, you can DEFINE DBG$INPUT and DBG$OUTPUT in (say) the GROUP table. Beware that any other process that runs a DEBUG image under that group will also try to start DEBUG at your terminal!

There are plenty of other tricks for running DEBUG sessions, but see how you go with the above first.

[Arch_Muthiah]

Thanks John,

Looks like I can debug the program. I will try this from my standalone OpenVMS 7.3-2/ AlphaPWS 600au, on which I have DEC Windowns Motif.

I will follow you suggestion ($ SET DISPLAY/CREATE/NODE=x-server/TRANSPORT=TCPIP
) tomorrow and I will get back to you.

Please stay with me.

Thanks
Archunan

[Arch_Muthiah]

John,

I tried all your suggestions, it did not bring up the DEBUG screens. When try this from SYSTEM account.

Today I found in VMS side, there is a daemon process (dxx) which always in 'LISTEN' status on 5601 port. This daemon process is initiated by one DEC C program from SYSTEM account. When this 'dxx' daemon process receives any request from MS-windows, it starts the DEC C main program, which in turn starts running series of other DEC C programs.

So I included $ SET DISPLAY/CREATE/Node= DECWIND_node/transport=tcpip cmd in the SYSTEM's login file. Is it OK?. Then I started the WINDOW program, but I did not see any DEBUG screens. Also when try to reboot (entered SYSTEM/password in DEC Window screen), DEC wind was hanging.

Also I found one of the *.LOG file has the following define statements....
$ define sys$input xxx.log
$ define sys$output yyy.log
$ define sys$error zzz.log

May these be the reason for unable to see the DEBUG window? or Is there any other way to debug?

Currently, I am trying to see this dxx daemon process source code, how does it get started, how it calls other DEC C programs, what it does before/after receiving request from MS Windows (via 5601 port).

Please suggest your suspections about this
daemon process and its possible involvement in DEBUG.

Thanks
Archunan

[John Gillings]

Archunan,

Are the target programs compiled and linked with /DEBUG?

I'd suggest you start with a very simple program you've compiled and linked with /DEBUG. Put it in a batch procedure and see if you can get remote debugging working, either using DECwindows or DEFINE DBG$INPUT and DBG$OUTPUT to a terminal. Once you've got that working, see how it might be adapted to work with your daemon process.

>Also I found one of the *.LOG file has
>the following define statements....
>$ define sys$input xxx.log
>$ define sys$output yyy.log
>$ define sys$error zzz.log

SYS$OUTPUT and SYS$ERROR are fine, but SYS$INPUT pointing to a log file?? That seems odd. Not a big deal though.

You can redirect DBG$INPUT and DBG$OUTPUT if you want, but it only makes sense if you're not using the DECwindows interface.

[Arch_Muthiah]

Thanks John for your response. I keep refreshing ITRC to see your response.

By mistake I wrongly mentioned sys$input has been defined, it is not. Only sys$output and sys$err.

I don't access vms machines from home, I will try your sugesstions tomorrow from the office and get back tomorrow.

Archunan

[Arch_Muthiah]

John,

I have struggled last couple of days to understand few of the command procedure involved in this job initialization.

It works fine both the as way you suggested.
1. define DBG$input and DBG$output
and
2. directly from DEC Windows.

Till today noon, I tried all the way you suggested including remote submission. Finally after removing $SET DISPLAY xxxx cmd, it worked.

Thanks so much John.
Archunan

[Arch_Muthiah]

John and Jeff,

Thanks for both of your suggestion, it works fine as per Mr.John's suggestions.


Archunan