Craig A. Berry wrote:
At 8:53 AM -0500 9/24/07, John E. Malmberg wrote:
This is not the first time I have brought this up on this list, and
the last time no one admitted to using this build option on VMS.
Not everyone subscribes to every list. The person most likely to
need SOCKETSHR support is someone on an older (like pre v7.0) version
of VMS who suddenly discovers they need a relatively recent version
of Perl and have to try to get it to build with whatever they have at
hand. This hypothetical person is perhaps a consultant called in to
make a machine that's been sitting in a corner for fifteen years talk
to the outside world, and such a person, even if reading this message
right now, might well not anticipate needing the support that you are
proposing to deprecate.
I have worked enough with CMU-IP and socketshr to know that it is
probably a lost cause for anyone trying to do anything serious with
socketshr. And I really tried hard to make it work.
About the only way the hypothetical consultant would probably get a perl
to work with socketshr is to get a perl version from that age.
Perl requires ANSI C now, and I would be surprised if the wrapper header
files from socketshr could compile with out editing.
The Configure.com has options to build Perl with SOCKETSHR/NETLIB
libraries instead of the CRTL libraries.
This is only used for CMU-IP. It is not used for any other TCP/IP
program available on VMS.
Except Pathway and Multinet and TCPWare and TCP/IP services, or
that's what the NETLIB documentation says, and the SOCKETSHR
documentation says it's based on NETLIB. It's true that the
actively-maintained stacks from Process and HP can all use the CRTL
interfaces, at least on VMS v7.0 and later (was that the turning
point?), but that's optional.
VMS 5.5-1 is the last release that socketshr was needed for. There are
posts archived on the SAMBA-VMS mailing list from the author of
socketshr, Eckart Meyer, who stated that it should not be used any more,
and there was no support for it. Web site support for Socketshr
disappeared about the time VAX/VMS 6.0 and Alpha VMS 1.0 came out.
I continued to try to get socketshr to be useful until DEC and Process
announced hobby licenses for their stacks. At that point, it was no
longer worth the effort.
As near as I can tell, since then, no one has admitted trying to build
anything with socketshr on any VMS related forum.
I do see some programs still using netlib, which may be needed if you
are doing asynchronous I/O and ASTs for TCP/IP communications and be
cross platform.
As CMU-IP is effectively stuck at VAX/VMS 6.x, because it is
missing the source for critical bug fixes needed to rebuild it,
>> I really doubt that it is in much use.
All the other TCP/IP product libraries are dynamically loaded by
the CRTL if needed.
They can be, for current and not-so-current versions of VMS, but the
vendor-specific APIs are still there. I can't say with any certainty
that no one building Perl in the future will ever need to use them.
The default is to use the CRTL interfaces, and that's obviously what
most folks should do and will do, but I see no reason to remove other
options.
I have looked through the source and have not seen any vendor specific
APIs present for TCP/IP in Perl. Everything I see indicates that only
the DECC socket library will work.
I think if someone were to try to revive socketshr, that they would
likely have to start completely over.
I do not think it has been possible for at least the last 6 years
to even build Perl with socketshr support.
I am recommending that unless someone speaks up soon that they are
building and testing current Perls with support for CMU-IP, that support
for SOCKETSHR/NETLIB be dropped from configure.
I vote to leave well enough alone. It costs nothing to maintain and
the effort expended to rip out the existing support would be much
better spent fixing bugs or adding new features.
True, my todo list is pretty long.
At the minimum, readme.vms needs to be fixed to no longer incorrectly
state that socketshr is the most portable method. Prior to VMS 5.5-2 it
may have been, but it has been a long time since then.
I also am recommending that the option to build without socket
support also be dropped, since the CRTL already returns the expected
>> ENOSYS error code when the socket routines are called on a system with
>> out socket support.
It's true that making sockets optional was something done
originally because a TCP/IP stack is an add-on on VMS and the C
run-time did not yet at that time support socket calls when no TCP/IP
product was installed. But since we offered the option, other
reasons to use it have occurred to people. Such as configuring Perl
without socket support in a secure environment so you can be sure
Perl programs aren't talking on the network. And who knows what
other reasons people might have. If you don't like the option don't
use it; having it there is barely noticeable if you don't use it, but
I see no reason to arbitrarily drop support for something that's been
there for a long time and has never gotten in the way that I recall.
I concede that someone may want to build a perl with no TCP/IP support
for security reasons.
I really would be happy if someone were to resurrect CMU-IP as an open
source alternative to the commercial TCP/IP stacks. But I just do not
see that happening.
-John
[EMAIL PROTECTED]
Personal Opinion Only
