I need to make clear that I spent a lot of years working with VMS (still do!), and I've also spent a lot of time working with Perl... however I don't actually work with Perl on VMS (not enough to count for anything, anyway).
Perl on VMS has to interpret the record semantics to work with <> (it just has to!), of course it doesn't, actually.. it just relies on RMS (right?). You need to understand that as a logically record-structured filesystem, RMS doesn't actually have to have carriage control actually in the file: the default record structure for a sequential file is a byte count (< 32K) plus the data (plus a pad byte if necessary to stay 16-bit word aligned.. is that right?). The carriage control JUST HAPPENS. It is possible to do block I/O (READ/WRITE) instead of logical I/O (GET/PUT) (yeah, 20 years ago I had fun doing it), but I don't know about Perl's efficacy. If you have a file that's corrupt, you might look at SET FILE/ATTR to change the file (if possible make a copy, however maybe record semantics will interfere with doing this in the obvious fashion) so that it can be read as oooohhh.. 512 byte blocks... and then munge through those with Perl, in a more .*n.*xy byte stream fashion. (Stay *away* from CONVERT, you don't want no steekin' CONVERT.) It's possible that the error log has information that Perl is not returning (because RMS is protecting userland from the damage). High-water marking might work against you as well... maybe. >> -----Original Message----- >> From: Atkinson, Robert [mailto:[EMAIL PROTECTED] >> Sent: Monday, November 03, 2003 7:21 AM >> To: [EMAIL PROTECTED] >> Subject: File Read Error >> >> I am using a bit of Perl script to try and examine a corrupt RMS file. >> >> The file has a few invalid records in it, where the record length exceeds >> the >> maximum record length in the file header. >> >> Although there are a lot more records in the file than reported, the >> program >> seems to stop at the first corrupt record, but does not report any kind of >> error. >> >> I assume the file corruption is causing the program to fail, but surely it >> should report some kind of VMS error status? >> >> Any ideas? >> >> Robert. >> >> ***************************************************** >> >> $thefile = "GAMSYF:[RAA.DAT]DCLLOG.ROB"; >> open(INFILE, "$thefile") or die "The file $thefile could not be found.\n"; >> >> $LineCount = 0; >> >> while(<INFILE>) { >> >> $TheLine = $_; # Save the line's contents >> >> chomp($TheLine); # Get rid of the line break >> >> $LineCount = $LineCount + 1; # This is the easy part! >> >> $LineLen = length($TheLine); >> >> if ($LineLen > 100) {print "Line $LineCount is $LineLen long\n"}; >> if ($LineCount > 2096657) {print "= $TheLine\n"}; >> } >> >> print "Number of lines $LineCount\n"; >> I don't see the error reporting... Henderson, Jordan wrote: >The <> operator just stops on EOF or error. > >You have to explicitly access the error codes. Try printing the system >variable >$! at this point. I wouldn't be terribly surprised if the return from that >variable isn't entirely helpful in this case, however. Good advice, however after a recent traumatic experience with Perl 5.8 on Linux, I'm ready to drag out the FileHandle or Posix guns before going through it again. >You may have to resort >to sysopen and sysread or even reading the data in with low-level VMS calls to >really get to the bottom of a problem such as this. Amen... errr... word!... errr.. block! Carl Freidberg wrote: >Have you run ANALYZE/RMS/INTERACTIVE, or just ANALYZE/RMS >on the file? > >Have you tried DUMP/RECORD and DUMP/BLOCK? > >Is the file organization SEQ, REL, or IDX? > Good questions. HTH.. -- Fred Morris [EMAIL PROTECTED]
