UDP AST and LIB$SPAWN Hibernate

[RHM]

In order to communicate in 'real time' between multiple processes within our application I've added a UDP AST to our common initialization routines. This allows me to send datagrams between participating processes to view some critical internal tables to better support the application as well as drive certain state changes in near real time. The issue I've run into is that many of these processes use LIB$SPAWN to spawn off various command routines and most (not all) don't do anything more than pass the first command-string argument.

Without a NOWAIT request the parent process goes into HIB state and no longer processes AST's (or at least no longer processes the UDP read event AST that's hooked to it).

Is there any way to process UDP AST's when a process is placed into HIB when executing a SPAWN request?

Alternatively I've explored creating a jacket routine (eg., MY_LIB$SPAWN) to check the flags arg and if NOWAIT is not requested, then set it and then do a SYS$WFLOR on the sub-process completion status. Then I could do a global string replace of all LIB$SPAWN requests with MY_LIB$SPAWN requests rather than have to add the code to the many calls and increase risk of the change.

I've explored using optional arguments in F90 but have not been successful to date. Is it possible to declare a jacket routine so that an F90 app could call MY_LIB$SPAWN routine with partial arguments eg LIB$SPAWN(CMD,,,,,C) and have the jacket then call the actual lib routine with the optional arguments? If so is there any example code (in F90 or C/C++) of how to do this?

Thanks in advance for any guidance you may be able to provide.

[Hein van den Heuvel]

What's a UDP AST?
I have not seen that term being used before.
How do you declare one? Show code?

fwiw,
Hein.

[RHM]

Hi Hein. While my particular issue is with having the process that initiated the spawn respond to UDP (ie, IP datagram) AST's, the HIB process does not respond to any AST's I send it, including a SYS$FORCEX until the child process terminates. The code I'm using is derived from the TCPIP examples provided by HP and uses a QIO of the form:

status = sys$qio (EFN$C_ENF, /* event flag */
inet_channel, /* i/o channel */
IO$_READVBLK, /* i/o function code */
&iosb, /* i/o status block */
UDP_AST, /* ast service routine */
0, /* ast parameter */
read_buffer, /* p1 - buffer address */
read_size, /* p2 - buffer length */
&client_itemlst, /* p3 - remote socket name */
0, /* p4 */
0, /* p5 */
0 /* p6 */
);

...where the UDP_AST is the function to call when a read operation occurs.

Thanks,

-Bob

[Hein van den Heuvel · Accepted solution]

Oh that UDP. I suspected that, with the mention of datagram, but it still was not clear, and as it turns out it was relatively irrelevant.

This behaviour is explicitly documented in the RTL LIB$ manual:

http://ftp.openvms.compaq.com/doc/82final/5932/5932pro_045.html#spawn

"Unless the NOWAIT flags bit is set, the caller's process is put into hibernation until the subprocess finishes. Because the caller's process hibernates in supervisor mode, any user-mode ASTs queued for delivery to the caller are not delivered until the caller reawakes."

So you'll have to use NOWAIT.
I wouldn't use WFLOR but $HIBER + AST + $WAKE. If the LIB$SPAWN caller passes an AST address, then it probably already uses NOWAIT. If not, just replace the AST address and later use DCLAST to activate it.

Writing a jacket isn't to hard and possibly the best for a single function.
Either as a single routine, or the whole RTL.

As a single routine, just create a module my_spawn.
Make it have an entrypoint LIB$SPAWN.
Take the call. Use LIB$FIS to find the recall McCoy, remembering the address for a next time. Didle the arguments and call teh real thing.
Link my_spawn as a shareable.
Put the shareable in the option file or automatic link path.

Or replace it all....
See John Gilling FAKE_RTL article:
http://h71000.www7.hp.com/openvms/journal/v7/faking_it_with_openvms_shareable_images.html

Or... just forbid the spawn in what apparently should be a controlled environment. Sounds like conflicting requirement. Too often a spawn is used as a quick&dirty solution where a straight calleable is available (convert, edit, sort, submit..). Of course there are many things which are not calleable though (CC, LINK, Application programs without API,...)

hth,
Hein van den Heuvel

[RHM]

Hein - thanks very much. This gives me a lot of valuable information for further research. Many thanks!

-Bob

[Joseph Huber_1]

Your second question, passing optional arguments through F90 routines:

I think, as long as the F90 routine does not touch optional arguments, You can simply pass the formal arguments to the LIB$ routine without knowing their actual content.
But beware of the exception: in VMS F90 (and older F77 as well), arguments of type CHARACTER cannot be optional, even if they are not touched. Optional CHARACTER variables will access-violate already at routine entry. (At least up until Fortran V7.5, I doubt this restriction has changed in later versions).

As long as You don't need formal correctness (i.e. not writing INTERFACE for the routine, and do separate compilation), You could work around by faking the type of optional variable as e.g. INTEGER instead of CHARACTER.
If You have to acess the optional variable inside the F90 routine, then no way around, this will not work for character variables.

[Joseph Huber_1]

Attached are 3 example files demonstrating passing optional arguments through F90 routines. The C file is just to show the resulting pointers.

[Hoff]

Though this might well be a review for you and others here, do remember that the U in UDP is Unreliable. Really. UDP datagram messages are tossed out onto the network, and if they're received somewhere, then they're received somewhere.

If you're on the same node or in the same cluster, I'd suggest the use of locks in general (blocking-based doorbells, etc), but some details on what you're really up to (rather than the specific approach under consideration here) might help tailor an approach to the particular environment.

UDP is good for multicast updates and other such, where the contents of each arriving datagram entirely replaces the previous datagram. Where there are no dependencies and no sequences and no context.

The word "critical" isn't usually mixed together with UDP.

Stephen Hoffman
HoffmanLabs LLC

[RHM]

Joseph - thanks for your posts - they'll be helpful for references in future projects. It would be great if optional arguments could be interrogated locally (if present()) and passed along to called interfaces.

Hoff - understood and agreed. The advantage of UDP in our use is that its lightweight in terms of implemenation, directory service and rights requirements such as many other IPC mechanisms require such as SCS and lock management. While the data in the tables queried are critical (essentially providing a PEEK facility) whether one packet is lost is not as the product support analyst can easily retry the request (an atypical event within our cluster over LAN).

Thanks to all who responded. I'm new to this forum but its been wonderful how many quick and insightful responses I got in such a short time.

[RHM]

Pursuing jacket routine as suggested. Thanks again to all who responded.