On 12/05/2021 13:58, Malte Dehling wrote: Thanks. Nice work, particularly grouping them together, pulling out the JPEGs and seemingly mounting them to suck out the CD_CONTENTS.DAT! As a reward for your hard work here are a few more for you :-) I've now uploaded ag-nc67a-re.tar.xz, ag-mn36d-re.tar.xz and ag-pcy4c-xe.tar.xz. These are: AG-NC67A-RE - VMS Online Documentation Library??????? 1989-03 Disc 1 of 1 AG-MN36D-RE - VMS Consolidated Software Distribution? 1989-05 Disc 1 of 1 AG-PCY4C-XE - InfoServer V2.0 Software Base Level 10? 1991-11 Disc 1 of 1 AG-MN36D-RE in particular took over 5 days to rescue. In the end it managed 99.41% and couldn't get any more data off the CDROM when run with -R. So, despite the internet saying use 2000 and 3000 grit sandpaper, I went against all the advice and recklessly tried a seven minute does of 1500 frit sandpaper, followed by the usual vigorous polishing. I've included a "before" image of the rear (non-label) side of the CDROM and a triangular "blemish" is clearly visible near the centre and extending out into the data region. 2000 grit didn't touch it, I could still feel it afterwards with my fingernail. 1500 grit wiped it away completely and ddrescue got to work immediately and took just 10 minutes or so to recover the missing data (apart from 4096 bytes). I had previously tried the image out using SIMH back when it was at a mere 99% and it mounted happily (although it complained that it could not find the alternate home block). I copied all the files to NLA0: and there were no errors. I don't think that means that all the data blocks were good (since VMS would have no way to tell) but there were no errors noted in the filesystem structures, so that's at least some comfort. I haven't tried BACKUP/ANALYZE on all the savesets but that might be one way to test the integrity of those files. The InfoServer CDROM I included because it has some nice cover art with (I presume) the faces of five of the develpment team. Anyone know who they are? I suspect that if you really want to use an Infoserver you might be better off with the most up to date version on the most recent OpenVMS Freeware release. Incidentally, I'm currently working through my OpenVMS VAX (and a few Alpha) CONDIST CDROMs and pulling out all the CD_CONTENTS.DAT so I can put together a script to build a list of which sets hold any given version of a product. So if anyone has any missing sets, and wants to supply some, please do. This will all end up on github eventually. To save you some time, for versions sometime before MAR-1992, you need the CD_CONTENTS.DAT from every disc in the set as they each contain details of only the products on that disc. Beyond that data the format changed and the contents are identical on each disc. The old style looks like this: LABEL CD_BIN_92932 %TYPE CONDIST ! ! NOVEMBER CONDIST: DISC 2 OF 2 ! !PRODUCT NAME UPI INST VERSION KIT CH DIS ROOT SAVESET(S) and the new style looks like this: %DISC_PRODUCT_NAME1 VMS Consolidated %DISC_PRODUCT_NAME2 Software Distribution %KIT_PART_NUMBER QA-VWJ8A-A8. U01 %SPINE_PART_NUMBER AV-MN37Y-RE ! %DISC_PART_NUMBER AG-MN36Y-RE,AG-PASMS-RE,AG-PCXXM-RE,AG-PFXCJ-RE,AG-PJ4YD-RE,AG-PNTPA-RE %DFARS Y I already have 1989-05/07/11, 1992-03/05/07/09/11, 1994-11, 1995-01, 1996-03/06/09/12, 1997-03/06/09/12 and 1998-03, so anything else (or anything from any Alpha CONDIST release) would be cool. Antonio -- Antonio Carlini antonio at acarlini.com

That is INCREDIBLY useful. Especially when trying to figure out which SPL?s will have copies of the version you want. In fact it looks like I need to update at least a couple things. The joke is I?ve had the SPL with the kits for probably 15+ years. Zane

On Fri, May 14, 2021 at 09:40:34AM +0100, Antonio Carlini via cctalk wrote: I talked to him a while ago and I've sent him the cd_contents.dat files for your first round of uploads already (which is what he needs to update the database.) I'll send him the newer ones, too. Cheers, Malte -- Malte Dehling <mdehling at gmail.com>

On 14/05/2021 10:47, Malte Dehling wrote: Excellent. I did look at the CONOLD and there didn't seem to be anything that would help (other than the bookshelf files). There was the VTBOOK software on a DECUS release many years ago. It got stomped on for a while and then DEC gave up the fight against PDF and (I think) VTBOOK made it to the Freeware CD. That might help in working out the format. I rather suspect that if I'd stopped the initial ddrescue when it was at 99% and just gone straight to the 1500 grit sandpaper, then I could have saved my DVD-RW a few days of work. I've just catalogued the VAX CONDIST/CONOLD sets I have and it comes in at 14 or so. I'm hoping that someone tells me that they're already archived before I start on those :-) Antonio -- Antonio Carlini antonio at acarlini.com

On 14/05/2021 13:40, Zane Healy wrote: I don't know how to programmatically check that the data blocks in that ISO are valid (by which I mean "match the original"). For backup savesets then BACKUP/ANALYZE is at least a starting point and the default is to write savesets with /CRC and to check the CRC on read. For DECW$BOOK stuff, I have no idea how you can be confident that it is 100% correct. Then again, it's just text you're going to read (line the [.LINE_DOCS] stuff) so I guess it's not hugely critical. Plus all the stuff I've recovered so far has at most 4096 missing bytes I think, which is 8 blocks at most. So the odds that you'd hit something bad are quite small. Antonio -- Antonio Carlini antonio at acarlini.com

On 16/05/2021 13:51, Malte Dehling wrote: That looks interesting: the fundamental VMS documentation is there, but very little of the layered product info is present. The MAR-1989 CONOLD has FORTRAN and DBMS and the JUL-1989 CONOLD has C, FORTRAN, PASCAL, GKS, DBMS, VDE and DECforms. So I would speculate that these would be amongst the earliest CONOLD distributions. I read elsewhere (comp.os.vms) that the first CONDIST went out in the VMS V5.0 timeframe and the 1989-05 CONDIST contains both VMS V5.0 and V5.1. VMS V5.0 was announced in APR-1998 (https://eisner.decus.org/anon/htnotes/note?f1=INDUSTRY_NEWS&f2=64.0)4.0), so it is possible that some earlier CONDIST may yet appear. I've put the CD_CONTENTS.DAT that I have up on github: https://github.com/AntonioCarlini/dec-cdrom-distros. (I just realised that I've mis-named the 1989-05 release as 1989-03 ... I'll fix that rsn). I guess that I should do something similar for the CONOLD CDROMs. Did you find DECW$SHELF to be enough to build up an accurate list of contents? Antonio -- Antonio Carlini antonio at acarlini.com

On 16/05/2021 21:00, Zane Healy wrote: V5.5-2 would be 1991-NOV or so. There's a CONDIST 1991-MAY on https://vaxstuff.files.wordpress.com/2020/08/.? and I have a CONDIST 1991-NOV. The next CONOLD I have is 1992-JUL (3 discs) (I can image that one next if it will help). There's a V5.5-2H4 OS CD on VaxHaven at http://vaxhaven.com/cd-image/AG-PXL1A-RE.iso.zip. Antonio -- Antonio Carlini antonio at acarlini.com

On Sun, May 16, 2021 at 2:03 PM Zane Healy via cctalk <cctalk at classiccmp.org> wrote: https://wiki.vmssoftware.com/OpenVMS VIKING V5.5-2H4 July 26,1993 Limited Hardware Release based on V5.5-2. Includes support for VAX 4000 models: 100A, 500A, 600A, 700A. Also supports 2nd SCSI adapter, KZDDA, on MicroVAX 3100 Model 90. Also includes support for DEFTA (FDDI to TURBOchannel adapter) and DEFQA (FDDI to Q-bus adapter) and Tagged Command Queuing (TCQ) for StorageWorks RAID Array 110 Subsystem.

Did you read these on a VAX? I?m trying to use MGBOOK (based on VTBOOK), to read the files from CDROM-AG-NC67C-RE-1989-07-VMS-CONOLD.iso. I?m on a system running VAX/VMS 5.5-2, and I am able to read the DECW$BOOKSHELF files, but not the DECW$BOOK files. I?m able to read the Bookreader documentation installed with VAX/VMS 5.5-2 just fine using MGBOOK. Error from in MGBOOK when trying to read a DECW$BOOK after reading a DECW$BOOKSHELF file. %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000011, PC=00003B2F, PSL=03C00000 Error from MGBOOK when trying to read a DECW$BOOK directly. %MGBOOK-E-READERR, Error reading bookshelf entry information -RMS-W-RTB, 1022 byte record too large for user's buffer Zane

On May 17, 2021, at 1:54 PM, Malte Dehling <mdehling at gmail.com> wrote: Thanks! Knowing that helps. I don?t have a monitor on any of my VAXstations, so couldn?t try that. Zane

On May 17, 2021, at 2:43 PM, Peter Coghlan via cctalk <cctalk at classiccmp.org> wrote: I?m trying to make the files readable via HECnet, so I need VTBOOK, MGBOOK, or similar. I see that at least an early Freeware CD had VTB, but the copy I downloaded appears to be corrupt. Zane

On 18/05/2021 10:17, Peter Coghlan via cctalk wrote: 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. In this case any corruption will be down to over-enthusiastic handling 20+ years ago. Antonio -- Antonio Carlini antonio at acarlini.com

Correct. I?m not really concerned with corruption of the BOOK files, I think my problem is with the tool I?m trying to read them with. Since Malte Dehling reports being able to read them with DECW$BOOKREADER, I think they?re okay. Zane

Zane Healy wrote: FILE is a tricky keyword to search for, isn't it :-) I think it should be on the freeware CDs but there is also a copy here: http://vms.process.com/fileserv-software.html Regards, Peter Coghlan.