Antonio Carlini wrote:
On 18/05/2021 10:17, Peter Coghlan via cctalk wrote:
The content of your posting which I was replying to and the error
message you
quoted suggested to me that your concern was that the bookreader files you are
attempting to read are "corrupt".
I think Zane was reading the files from an ISO image I made of a 1989
CONOLD CDROM.
That CDROM had previously been used as a toboggan by one or more members
the DEC Reading Engineering Team and so was somewhat heavily scuffed
when I got it.
I eventually recovered it through a process of manual polishing
involving sandpaper and elbow grease. I think ddrescue reported 2048 bad
bytes in the end (one sector).
It is entirely possible that one or more of the files is corrupt,
although the text files (the BOOKSHEFLF files, for example) seem OK.
The filesystem structures do seem OK, so maybe I was lucky.
My suggestion was intended to help you discover whether the bookreader files are
"corrupt" or the tools you are using to read them are mishandling them.
(In my experience "corrupt" files on VMS are usually due to file attributes
being lost when the files were transferred via some other system. On early
version of VMS, this can usually be fixed using Joe Meadows' "FILE" utility.)
In this case any corruption will be down to over-enthusiastic handling
20+ years ago.
I've been following the thread and I suspected as much too.
I was trying to offer a suggestion on how to narrow down whether the
bookreader files themselves are faulty or the applications being used
to process them are faulty as suggested elsewhere.
I also wanted to offer a reminder that incorrect file attributes are
just as likely, maybe more likely to mess things up as incorrect file
contents are, especially when bookshelf files which are just plain
text files as far as I recall, seem to be responsible for errors like:
%MGBOOK-E-READERR, Error reading bookshelf entry information
-RMS-W-RTB, 1022 byte record too large for user's buffer
Knowing more details about the problem may lead to finding a solution.
It has also since dawned on me that the objective of making the files
readable via HECnet can also be met in at least two other ways, either by
directing the X output from DECW$BOOKREADER running locally to an X display
elsewhere on the HECnet network using DECnet transport or by making it
possible for DECW$BOOKREADER running remotely to read the bookreader files
via the network. Therefore, it is not strictly necessary to use VTBOOK,
MGBOOK etc although it would be good to figure out exactly what is
stopping these applications from working correctly.
Regards,
Peter Coghlan.
Antonio
--
Antonio Carlini
anto...@acarlini.com
