inter process communication with SYS$QIOW

[RAVIKANTH_3]

We have two executabels say exe1 and exe2. When we run exe1, it internally calls SYS$QIOW system call to run one .COM file. This .COM file name is passes as parameter to the system call.

Please find the scratch from the code for exe1

vf_l_connect_sts = SYS$QIOW ( ,
1 %VAL(netchn),
2 %VAL(IO$_ACCESS),
3 netiosts,,,,
4 vc_l_ncb(1:vh_l_ncblen),,,,)

here vc_l_ncb contains the .COM file name to be run. for example it will be RUN_SERVER1.COM

When we run exe1, during debug mode we found that it is giving the below error after system call execution.
%SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node

And one more observation we found in the exe1 log is, it is checking for wrong .COM file name and not the .COM file we given in the "vc_l_ncb" variable.

Could you anyone please respond why it is behaving like this?

Please let me know if you need any more information to analyse and provide answer.

[Volker Halle]

RAVIKANTH,

welcome to the OpenVMS ITRC forum.

What you're trying to do is called 'DECnet non-transparent task-to-task communication'.

For an example see SYS$EXAMPLES:DB_REQUESTER.C and DB_SERVER.C

As future reference, consider to read Chapter 8 Performing Network User Operations of the DECnet for OpenVMS Networking Manual:

http://h71000.www7.hp.com/doc/73final/documentation/pdf/decnet_ovms_net_man.pdf

Volker.

[Hoff]

>Please let me know if you need any more information to analyse and provide answer.

You're going to have to debug this. Use the OpenVMS debugger, for instance, and ensure the NCB is set the way you think it is. And use the debugger on the target side, and see if that's configured the way you think it is.

Here are some widely-regarded instructions on asking smarter questions, and knowing how to ask good questions is a skill that can most definitely help you in your career:

http://www.catb.org/~esr/faqs/smart-questions.html

Here is an example of DCL task-to-task application which might help understand how this sequence works without wading through some Fortran code:

http://h71000.www7.hp.com/wizard/wiz_0159.html

And do read the associated manual, as was mentioned in an earlier reply.

Whomever originally coded this application also decided to dynamically start the server using DCL, rather than starting the image directory, or having the system bootstrap declare a task on the fly. There may well be requirements related to this; there are certainly some trade-offs involved here in having the incoming connection start the server.

Here is one approach that can allow you to run the debugger in a detached process:

http://labs.hoffmanlabs.com/node/803

And if you're not familiar with the OpenVMS Debugger, do skim through that manual, too. The Debugger is a central and useful tool for getting to the cause of these sorts of errors.

http://www.hp.com/go/openvms/doc

And welcome to ITRC.