topic sys$sndjbc in Operating System - OpenVMS

sys$sndjbc

Claus Olesen — Wed, 07 Feb 2007 18:10:14 GMT

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?

Re: sys$sndjbc

Arch_Muthiah — Wed, 07 Feb 2007 19:51:40 GMT

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

Re: sys$sndjbc

Hoff — Wed, 07 Feb 2007 20:08:37 GMT

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.

Re: sys$sndjbc

John Gillings — Wed, 07 Feb 2007 21:34:55 GMT

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").

Re: sys$sndjbc

Claus Olesen — Wed, 07 Feb 2007 21:51:34 GMT

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.

Re: sys$sndjbc

Hoff — Wed, 07 Feb 2007 22:11:19 GMT

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.

Re: sys$sndjbc

Hein van den Heuvel — Wed, 07 Feb 2007 23:56:17 GMT

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

Re: sys$sndjbc

Jan van den Ende — Thu, 08 Feb 2007 03:26:48 GMT

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

Re: sys$sndjbc

Volker Halle — Thu, 08 Feb 2007 13:45:07 GMT

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.

Re: sys$sndjbc

Claus Olesen — Thu, 08 Feb 2007 14:13:59 GMT

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?

Re: sys$sndjbc

Hein van den Heuvel — Thu, 08 Feb 2007 15:04:19 GMT

http://h71000.www7.hp.com/doc/731FINAL/4523/4523pro_005.html#742_fabl_fopfield

"FAB$V_TMP
Temporary file; indicates that a temporary file is to be created and retained, but that no directory entry is to be made for it. This option is used solely as input to the Create service. If you have a NAM or NAML block, you are given the file identification (FID) of the file, which you can use to reopen the file. If you do not have a NAM or NAML block or if you do not save the FID, the file becomes inaccessible once it is closed. The FAB$V_TMD option overrides the FAB$V_TMP option. "

"FAB$V_TMD
Temporary file marked for delete; indicates that a temporary file is to be created but is to be deleted when the file is closed. This option is input only to the Create service. The FAB$V_TMD option takes precedence over the FAB$V_TMP option. "

I don't think you can combine either with scf. The TMD woudl delete it before it is used by the job controller. The tmp option would be fine for submit, but you would not be able to readily delete the file when done.

Hein.

Re: sys$sndjbc

Claus Olesen — Thu, 08 Feb 2007 15:45:28 GMT

Thank you Hein
for the explanation of TMP v. TMD. (I guess the TMP option might be among a sys admins worst nightmares explaining where all that disk space went).
I'm all set - thanks again to everybody.
Claus