At 02:33 PM 9/11/2002 -0700, [EMAIL PROTECTED] wrote: >> Does anyone with a >> support contract care to log a call on this and find out what the >> *real* magic number is for presence of __vms_waitpid? > >I have done this and am awaiting a response from HP/Compaq/Digital.
Thanks; let us know what they say. >In an earlier message, Craig A. Berry was found to say: >> waitpid with a -1 argument is not now and never has been supported on >> Perl for VMS (at least for processes created via Perl's spawning >> mechanisms) but as of 5.8.0 it should give you ENOTSUP rather than >> looping over all processes on the system. > >I am testing this on: >__VMS_VER = 70300022 >__CRTL_VER = 70300022 >__DECC_VER = 60590001 > >and Perl 5.8. My problem is that I am indeed receiving the 5.6.1 error ( >%SYSTEM-W-NOMOREPROC, no more processes) when using 5.8. Bummer. What does it take to make that happen. Will this do it? $ perl -"MPOSIX" -e "waitpid(-1,&WNOHANG); print $^E;" >Also, my group >gets to install Perl on older versions of VMS (back to 6.0, I didn't say >ancient!). I'd like to know why a -1 argument was not implemented for >earlier releases? Granted, the programming might be a little convoluted >and involve several system calls, but it doesn't seem un-doable. Was >performance the issue? Yes, but programmer performance, not system performance :-). If you look at Perl_do_spawn you'll see there are two different paths it can take for creating subprocesses. One of them (safe_popen) does maintain a linked list of its children and it's conceivable this list could be used to implement the POSIX-style -1 argument to waitpid(). Unless your question is about the C RTL and not Perl. In that case I have no idea why waitpid wasn't implemented earlier, though it became available in VMS 7.0 which is what, 6 years old now? >I need to get this working so that I can support POE on VMS, at least on >one machine. What's POE and why does it need to use a -1 argument to waitpid? If it's doing that it may well be making other unixy assumptions about how subprocesses work. It would be nice to have proper support for this, but in the meantime there may be other ways to get what you want. >Craig suggested that: > >> I think the workaround is just to hack vms.c so it uses a C RTL >> number higher than the one you have. The most that will get you is the correct ENOTSUP errno value, and the only places you wouldn't already get that you would get a compile error, and that would only happen if your C RTL version is 7.1-something. >I'd like to explore the code in the vms.c module. However, I am developing >on an AlphaStation 244. Is there a shortcut that I can use to avoid >building everything when I make a change to vms.c? Can I just build a >subset? If you know that what you're doing doesn't need to dynamically load any extensions, you can probably get away with $ MMK MINIPERL.EXE and then just test whatever you're doing with: $ mcr []miniperl myscript.pl Otherwise changes to vms.c do trigger a rebuild of all the extensions, though at least you wouldn't have to rebuild other parts of the Perl core.
