Front page | perl.vmsperl |
Postings from September 2002
Re: Building Perl 5.8.0: Problem with undefined __VMS_WAITPID
Thread Next
From:
paul.simons
Date:
September 11, 2002 14:34
Subject:
Re: Building Perl 5.8.0: Problem with undefined __VMS_WAITPID
Message ID:
OF8CF0A0AE.89C48672-ON88256C31.00740C3E-88256C31.00766A11@esca.com
> 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.
In an earlier message, Craig A. Berry was found to say:
> That was the error on 5.6.1 and it was due to the fact that the
> waitpid implementation calls sys$getjpi, and a pid of -1 is the
> directive for sys$getjpi telling it to do a wildcard search. So it
> scanned all processes on your system and then blew up instead of
> waiting for the first available child to give up the ghost, which is
> what the -1 argument to waitpid is supposed to mean.
>
> 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. 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?
I need to get this working so that I can support POE on VMS, at least on
one machine. 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.
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?
--
Paul Simons (paul.simons@tde.alstom.com)
Bellevue, WA
ALSTOM's T&D Energy Automation & Information Business
CONFIDENTIALITY: This e-mail and any attachments are confidential and may
be privileged.
If you are not a named recipient, please notify the sender immediately and
do not disclose the
contents to another person, use it for any purpose or store or copy the
information in any medium.
"Craig A.
Berry" To: "jesper.naur" <jesper.naur@post.tele.dk>
<craigberry@ma cc: "VMSPERL mailing list" <vmsperl@perl.org>
c.com> Subject: Re: Building Perl 5.8.0: Problem with undefined
__VMS_WAITPID
08/22/2002
14:59
At 9:03 PM +0200 8/22/02, jesper.naur wrote:
>
>$ cc/ver
>Compaq C V6.2-008 on OpenVMS Alpha V7.1-1H2
>
>When building an unpatched Perl 5.8.0, I get the following error:
>%LINK-W-NUDFSYMS, 1 undefined symbol:
>%LINK-I-UDFSYM, __VMS_WAITPID
>%LINK-W-USEUNDEF, undefined symbol __VMS_WAITPID referenced
> in psect $LINK$ offset %X00001AF0
> in module VMS file PERL580_SRC:[000000]LIBPERL.OLB;1
>Link /NoTrace/NoMap/Exe=PERL.EXE perlmain.obj, perlshr.opt/Option,
perlshr_attr.opt/Option ,[]crtl.opt/Options
>%LINK-W-SHRWRNERS, compilation warnings
> in shareable image file PERL580_SRC:[000000]PERLSHR.EXE;1
>[snip]
>
>In VMS.C, I find the following at line 2653:
>
>#if defined(__CRTL_VER) && __CRTL_VER >= 70100322
but what you have is:
>__VMS_VER = 70110822
>__CRTL_VER = 70110822
>__DECC_VER = 60290008
>
>
>I have looked quite a bit around, and I have been unable to figure out
where __vms_waitpid is supposed
>to come from. Is this something, which existed or comes to exist in a C-
or VMS-version different from mine?
Thanks for the thorough report. It's not supposed to be available
until VMS v7.2. Whoever built the standard headers on my v7.3, CC
6.5 system thought 70100322 was the magic number for existence of
__vms_waitpid:
$ search sys$common:[decc$lib...]*.h __vms_waitpid/win=11
******************************
SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]WAIT.H;2
#if (__CRTL_VER >= 70100322) && defined(_VMS_WAIT)
# ifdef __CAN_USE_EXTERN_PREFIX
# pragma __extern_prefix __save
# pragma __extern_prefix "__vms_"
# else
# define waitpid(__p1,__p2,__p3) __vms_waitpid(__p1,__p2,__p3)
# define wait3(__p1,__p2,__p3) __vms_wait3(__p1,__p2,__p3)
# define wait4(__p1,__p2,__p3,__p4) __vms_wait4(__p1,__p2,__p3,
__p4)
# endif
#endif
I wonder if it isn't just a mistake in wait.h that should be 70200xxx
and of course I just propagated the error to vms.c. I would
ordinarily expect 70200xxx to be the beginning of the 7.2 range, but
I trusted what I found in the header, assuming it meant C RTL
versions were beginning to lag OS versions. 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?
You can of course verify whether your system really does have the
function by checking the "records matched" entry from the following
search:
$ SEARCH/STAT/NOOUTPUT SYS$LIBRARY:DECC$*.EXE __vms_waitpid
Files searched: 2 Buffered I/O count: 15
Records searched: 4281 Direct I/O count: 271
Characters searched: 2191872 Page faults: 32
Records matched: 3 Elapsed CPU time: 0 00:00:00.15
Lines printed: 0 Elapsed time: 0 00:00:00.16
I think the workaround is just to hack vms.c so it uses a C RTL
number higher than the one you have.
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
Thread Next