[Info-vax] InfoServer 150

[Mark DeArman]

On Tuesday, January 29, 2019 at 7:08:41 AM UTC-8, Stephen Hoffman wrote:
> On 2019-01-29 01:39:08 +0000, Mark DeArman said:
> 
> > Yes, I believe the issue here is that the infoserver.zip was made with 
> > the VMS attribs striped so it would work on DOS. It extracts fine on 
> > Windows, which is normally a no-go.  Should have thought of this 
> > earlier.
> 
> According to unzip -Zv command on macOS, I did remember to use zip -V 
> when creating this particular zip, so the file attributes have been 
> preserved.  The presence of the PKWARE VMS stuff in the unzip -Zv 
> output means that zip -V was used.
> 
> That VTX/VXT in the abstract is probably my typo, too.
> 
> As for the extracted files, these are block / binary files, so they'll 
> extract and burn just fine on most any platforms, and using tools that 
> can perform raw burns.
> 
> The version of unzip that Bill is running is very old, known to have 
> various bugs and has security issues.  It's ancient.  Anything prior to 
> unzip 6.0 is badly outdated, and lacks 2 GB support.   unzip 6.0 has 
> some known bugs and some minor security bugs, too.  Writing parsers for 
> untrusted input is not easy.   Parsers for ASN.1 and otherwise have had 
> flaws, for that matter.  Sandboxes or separate processes are some of 
> the approaches for isolation.  But I digress.
> 
> > Seem to recall there was something about 512 vs 2048 CDDrives booting 
> > on VAX too, but I don't recall how/if that was an issue with burning 
> > them.
> 
> OpenVMS expects 512-byte optical drives on OpenVMS VAX, and VAX lacks 
> IDE/ATA, SATA, and USB support.  OpenVMS Alpha and OpenVMS I64 include 
> 512-byte support for SCSI, and 2048-byte support for IDE/ATA and SATA 
> and USB optical devices.  Writing optical media on OpenVMS is always 
> 2048-byte sectors, and uses one of various integrated or add-on tools.  
>  As for recording the files on OpenVMS and other platforms, the 
> commands and the tools that I and others have cited do work.
> 
> I spent quite a bit of time getting COPY/RECORDABLE_MEDIA available and 
> with generating disks using ported cdrtools on OpenVMS, in addition to 
> doing various CD images and kitting-related activities.  I had more 
> than a few of these optical-media-related discussions with folks over 
> the years too, and it was sometimes easier to send some of the folks a 
> disk than it was to pry them away from their assumptions and their 
> preferred and sometimes non-working tools.
> 
> Lacking details on the recording commands used, and lacking information 
> on whether a record and a rip shows any differences, nor the InfoServer 
> boot commands used, and other details.... Which makes these discussion 
> threads longer, too.
> 
> And optical media and optical media drives can be...  funky.  I had a 
> drive from a very well known brand utterly fail basic recording 
> operations.  There was a two-byte slip in recorded data, in a 
> seemingly-random range of sectors well along in the recording.  The 
> correct data was written (instrumented the driver), and the drive just 
> botched the recording process.
> 
> Now as for what's actually in those zipped disk images?  Donno.  
> Host-based InfoServer replaced hardware-based InfoServer a long time 
> ago.
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Thanks for clarification on this.

Mark