Re: Problem with VMS Carriage return carriage control files in 5.10 and 5.12

Hi,

we are currently testing perl 5.10.1 in our development environment. We
also ran into some issues which i did some initial analysis on.
Unfortunately, i am not directly involved in testing 5.10.1 and didn't
find time to get as far as collecting exact details in an isolated test
case yet.

There are two issues i have off the back of my mind:

1)  Random problems with carriage return and vmsopen()

I suspected it had something with buffering in connection with vmsopen().
For our purposes, i changed the record format from "rfm=var" to
"rfm=stmlf" and files looked fine
(Although this does smell like a regression from 5.8.6, the modules in
our case probably should not have been using "rfm=var" in the first
place...)



2) File::Spec::VMS->catpath() was making some "vmsify path" routine create
illegal VMS filenames like "LOG:[]filename.txt" instead of  LOG:filename.txt
(which made File::Copy->copy() break)

To continue our tests, we added something similar to "s/:[]/:/" as a
kludge in File/Spec/VMS.pm
 

Regards,

Mudiaga Obada
 

On 22.04.2010 16:25, Craig A. Berry wrote:
>
> On Apr 21, 2010, at 11:55 PM, Carl Friedberg wrote:
>
>> About 7 weeks ago, I put 5.10.1 into production. It looked good until
>> the overnight production ran, and then all hell broke loose. I did
>> not have time to poke around, but the symptom was that completely
>> trivial perl scripts failed, with extra line breaks being thrown into
>> the output. I put the old version back, and everyone was happy again.
>> The offending (trivial) perl script was replaced with an awk script.
>
>
> First of all, it's good to see people using Perl in production on
> VMS.  Obviously it's a bit distressing to find out about an impediment
> to using the current or previous version just after a new major
> version has been released.  I think the next steps are to narrow down
> further where the behavior changed by testing against 5.8.9 and
> 5.10.0.  If anyone has the opportunity to do that, please speak up.
>
> The unwanted line break in Martin's example occurs at exactly 4048
> bytes into the file.  There is likely a buffer involved, but not a
> mailbox buffer since as far as I can tell there's no mailbox
> involved.  Of course it's possible this example dodged a bullet by
> hitting a record boundary earlier on and the real magic number is
> something less than 4048.  I'm going to have a crack at narrowing this
> down further.
> ________________________________________
> Craig A. Berry
>