sys$sndjbc

[Claus Olesen]

The DCL command SUBMIT supports remote invocation in a non-clustered environment using the REMOTE qualifier
$ submit/remote node::dev:[dir]file.type

The system service SYS$SNDJBC does not appear to support remote invocation in a non-clustered environment. I tried

#include
#include
int main()
{
//char *DclFile="NODE01::DKA100:[MYDIR]MYDCL.COM";
char *DclFile="DKA100:[MYDIR]MYDCL.COM";
struct itmblk {
short buflen;
short code;
char *bufadr;
int retbuflen;
} items[] = { { 9, SJC$_QUEUE, "SYS$BATCH", 0},
{ strlen(DclFile), SJC$_FILE_SPECIFICATION, DclFile, 0 },
{ 0 } };
unsigned short iosb[4];
sys$sndjbcw( 0, SJC$_ENTER_FILE, 0, items, iosb, 0, 0 );
}

with no luck whereas without the "NODE01" specification it works fine.

Can anyone confirm? If true then I guess "submit/remote" is not implemented only using sys$sndjbc.

Or am I doing something wrong?

[Arch_Muthiah]

As there is no info about what status code returned by the service, this may be because of the access permission of the disk directory filespec(DKA100:[MYDIR]MYDCL.COM) for the system running the queue, or the valid node name you specified may not be reachable.

Archunan

[Hoff]

SUBMIT /REMOTE and PRINT /REMOTE (and the reason that it works rather differently than the typical command) is based on DECnet DAP protocol. The command also works across operating systems with DECnet stacks.

DECnet Phase IV architecture specs:

http://ftp.digital.com/pub/DEC/DECnet/PhaseIV/
http://ftp.digital.com/pub/DEC/DECnet/PhaseIV/dap_v5_6_0.txt

There may well be an API around for the DEC Distributed Queuing Service (DQS) package, and task-to-task DECnet is certainly feasible. There's an example of task-to-task DCL over at the old Ask The Wizard area.

[John Gillings · Accepted solution]

Claus,

Note that SUBMIT/REMOTE is incompatible with most (all?) other SUBMIT qualifiers. You can't specify queues, parameters, or other variations. It's done with a single bit in the FAB when the file is closed. It's exactly equivalent to the DCL code:

$ OPEN/READ file NODE01:DKA100:[MYDIR]MYDCL.COM
$ CLOSE/DISPOSITION=SUBMIT file

Similar constructs exist in most language RTLs, mostly on the CLOSE statement (sorry, I'm not sure what it looks like in C - probably direct RMS services).

The trick to getting "full function" remote submission is to write your "real" SUBMIT command into a remote procedure and SUBMIT/REMOTE that (ie: an application of Hext's Law "All problems can be solved by the addition of one further level of indirection").

[Claus Olesen]

Thank you for the replies.

We are using OpenVMS accounts with almost all privileges incl. BYPASS
because we don't (think we) need security checks in what we're doing.


The return status from the SNDJBC with the node specification included was
%SYSTEM-F-IVLOGNAM, invalid logical name

But the following does work
$ submit/remote NODE01::DKA100:[MYDIR]MYDCL.COM

(e.g. MYDCL.COM does exist on the remote node and user proxies do exist.
But to be sure I also tried NODE01"username password"::... in the C-program
but got the same error message).

Before asking here I looked at the HP online Docs and also Googled and did
not anywhere find a confirmation of whether SNDJBC do or does not support
remote invocation. But perhaps if it did then HPs docs (system services
ref manual) would mention it.

Thank you for the suggestions of alternatives. The reason I wanted to use
SNDJBC is that I wanted to use a mechanism that is ready "out-of-the-box"
without explicitly having to run and maintain a (special) server at the remote end.

I think I'm leaning towards still using SNDJBC but to submit a local DCL that copies the "real" DCL to the remote node
followed by a submit/remote of that DCL and a delete of the DCL (either
by itself or from the local DCL).

Thank you very much for replying and so quickly.

[Hoff]

sys$sndjbc is specific to OpenVMS and to the OpenVMS queue manager, and AFAIK is not tied into the remote submission processing.

I'd be very surprised if SUBMIT/REMOTE uses $sndjbc. It opens up a remote connection and copies over the file.

Here's a full DCL of an example task-to-task server:
http://ftp.openvms.compaq.com/wizard/wiz_0159.html

TELL.COM is here, and it allows arbitrary remote commands:
http://vms.process.com/ftp/vms-freeware/NARNIA/COM/AAAREADME.TXT

The usual approach for remote submissions involves FAL/DAP, or RMS. (RMS is tied into FAL/DAP.)

DQS is the usual tool for command operations.

The brute-force solution is to SPAWN the SUBMIT/REMOTE command.

Ping HP with your question. Mayhap the documentation will be updated.

[Hein van den Heuvel]

Claus,

Welcome to the HP ITRC OpenVMS Forum

Be sure to carefully re-read John Gillings reply. I suspect he is right (he is always right, trust me) in that SUBMIT might do a sndjc for the normal work, but an rms open + close with fab$v_scf=1 for the remote submit. Sorry, no soures access here to verify. Anyway award him 10 points!
http://forums1.itrc.hp.com/service/forums/helptips.do?#28

Here is a demonstration in C:

$ create scf.c
#include
main (int argc, char *argv[])
{
FILE *fp;
fp = fopen( argv[1], "r", "fop=scf", "dna=.COM" );
return (fclose ( fp ));
}

$ cc scf
$ link scf
$ cre tmp.com
$SHOW TIME

$ mcr sys$login:scf "0""user password""::tmp"
$ type tmp.log
:

And now re-read John's closing paragraph on how to pass details.

Enjoy,
Hein

[Jan van den Ende]

Claus,,

I join Hein in welcoming you.

Please read

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

to find out how to thank those that helped.

Proost.

Have one on me.

jpe

[Volker Halle]

Claus,

the SYS$SNDJBC system service is using IPC to talk to the appropriate QUEUE_MANAGER process in the local node or cluster. The IPC interprocess communication service does not support DECnet, it only works inside a cluster, so there is no way for $SNDJBC to send a message to a QUEUE_MANAGER to a remote node via DECnet.

Volker.

[Claus Olesen]

Thank you for your welcome. Yes - this is my first posting - here. I used to ask the wizard (wiz_3768.html was one of my bigger undertakings on the AXP. Besides, I'm pleasantly surprised to see that it works unmodified on the I64) and I'm sorry to see that the wizard is gone but happy to see this community forum in its place.

I re-read your replies. Cool (sorry about that expression) - I'm going to go with your ideas e.g.

to submit an existing remote file as a batch job on the remote system then the following
C-program statement is all that it takes

fclose(fopen("NODE::DEV:[DIR]FILE.TYPE","r","fop=scf"));

I had forgotten about the existence of the OpenVMS creat extensions. Two of the others are tmp and tmd according to help crtl creat. Anyone know the difference - for use in a case where the remote DCL has to be written dynamically from the C-program?