On a related note, is there any point in investigating the use of the OpenVMS porting library for building/maintaining Perl?
http://www.openvms.compaq.com/openvms/products/ips/porting.html To anyone out there who might be looking at bringing up Perl6 on OpenVMS, this might be a good direction. Jordan Henderson Defense Automatic Addressing System Center WPAFB, OH DSN: 986 3804 Commercial: (937) 656 3804 Facts are meaningless. You could use facts to prove anything that's even remotely true. - Homer J. Simpson -----Original Message----- From: Craig A. Berry [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 1:29 PM To: Carl Friedberg Cc: [EMAIL PROTECTED] Subject: Re: FW: Hoff on ODS-5 system disks and case issues Carl, Thanks for the reference. I am aware of the existence of the documentation that Hoff mentions and have some familiarity with -- though not necessarily complete command of -- its contents. Acting on it is another matter entirely. There are a number of things that need to be done in Perl to catch up with current CRTL capabilities and ODS-5 generally. For starters, there is the way vmstar works on ODS-5 volumes. By default, recent versions of it allow formerly illegal characters in directory and file specs and escape them with the caret (^) per ODS-5 guidelines. So, for example, when you unpack the Perl source tarball your top-level Perl directory will be [.perl-5^.8^.0]. In order to even set default to that you will need to have extended parse style enabled (not to mention better than average facility with the top row of the keyboard!), but extended parse causes the build of the Encode extension to fail, no doubt due to some conflicting assumptions about legal characters and/or case. The Encode build needs to be fixed to work in all combinations of disk structure level and parse style. There is the -o | /ODS2 option available in vmstar to force legal ODS-2 names, and that will dodge the foregoing problems. However, it needlessly upcases the filespecs in addition to translating illegal characters. It would be nice to have it preserve case but perform the other translations like unzip does. Those are all just issues that come up getting Perl to build. There are many places in the test suite and even in some core modules where filename case is assumed to be lower (and even forced to be). Each of these will need to be addressed in a way that continues to work for ODS-2 but also handles case properly for ODS-5. In general, the basic assumption is changing from "filename case is always lower" to "filename case may be mixed and should be preserved where possible but case preservation cannot be assumed or required." We need to look into honoring DECC$xxx logical names, especially DECC$ARGV_PARSE_STYLE and DECC$EFS_xxx. It would be nice not to have to quote everything on the command line and to preserve filename case when we can. Perl's utime() implementation should handle the true access time field available on ODS-5 volumes rather than conflating it with the modification time as is necessary on ODS-2. We need to figure out if an ODS-5 volume with hard links enabled can support what symbolic links are expected to do in Perl. Then we need to be able to configure for it and have a way to test for it on a per-volume basis and change all the tests that assume VMS can't do it. Using NAML rather than NAM blocks when parsing filespecs would allow us to handle paths longer than 255 characters. There are lots of places in vms.c that do their own filespec parsing based on the traditional delimiters (<>[]:). It's entirely possible for legal ODS-5 filespecs to get parsed incorrectly. Not sure how to handle that. OK, I've worn myself out just making the list, which I'm sure isn't even complete. Anyone want to get to work? At 1:09 PM -0500 11/20/02, Carl Friedberg wrote: >This note is on DecuServe (eisner.decus.org) from Hoff in response to an >issue >I've encountered running an ODS-5 system disk on VMS 7-3.1 > >Note his comments about CRTL documentation, please :-( :-) (it's the >good news >and the bad news). > >Carl > >-----Original Message----- <snipped> -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
