In working to get RSYNC to work on OpenVMS, I have run into difficulty mapping the do_fork() calls to the native APIs. OpenVMS does not currently implement a fork() function. The closest that it has is a spawn() function. It works like a system() call that is not blocking. You pass the program or command to spawn(), and the input/output channels all in one call, and it returns the pid of the new child process. Also, the child and the parent do not share any I/O context. They must set up all I/O descriptors from scratch. Now I was able to make a replacement sock_exec() so that I can now launch a captive server that was good enough to pass the daemon test. This leaves three fork() calls to deal with. Because of the way that RSYNC is currently organized, the fork() is being done at a different point than the remote command is being executed. For two of them, the fork() calls are being called from main/do_cmd() and util/piped_child() and util/local_server(). I have not quite determined exactly how these are used. It looks like I will have to intercept these calls at the util/piped_child call from do_cmd(). What I am not sure of is what the I/O connection between the parent and the child in these two cases are. Once that is solved, it looks like the main/do_recv() calls do_fork() in some sort of receive function. For this on OpenVMS, I was looking to convert to AST driven. Basicially file I/O on OpenVMS can be done non-blocking in a background thread. So can socket I/O. I am looking at this as an alternative to spawning a second process and setting up the communication channels between it. The sequence is that an I/O request is posted, and a completion routine is specified, repeat forever, with out any waiting in the chain. If anyone who has more understanding of the internals has any suggestions for me, I am interested. Thanks, -John wb8tyw@qsl.network Personal Opinion Only