[Info-vax] InfoServer 150

[Mark DeArman]

On Monday, January 28, 2019 at 5:57:38 PM UTC-8, Bill Gunshannon wrote:
> On 1/28/19 8:39 PM, Mark DeArman wrote:
> > On Monday, January 28, 2019 at 2:34:19 PM UTC-8, hb wrote:
> >> On 01/28/2019 11:10 PM, Mark DeArman wrote:
> >>> On Mon, 28 Jan 2019 16:20:11 -0500, Bill Gunshannon wrote:
> >>>
> >>>> (snip)
> >>>>
> >>>>
> >>>> Another data point....
> >>>>
> >>>> I ran all the diagnostics on the Infoserver and if the results are to be
> >>>> accepted it passed with flying colors.  So I guess I can eliinate
> >>>> hardware as the problem.  Don;t know what to do next.
> >>>>
> >>>> bill
> >>>
> >>> I'm trying a closer approximation to your steps right now.
> >>> I'm unpacking the infozip.zip on VMS7.3 VAX under simh,
> >>> with Unzip 6.0.
> >>>
> >>> I also recall, there were some problems with
> >>> the pre-5.5 versions unpacking newer (PC) Zip archive versions.
> >>> Although I typically saw that fail out as a checksum issue during
> >>> decompression on the VAX.
> >>>
> >>> I'll then use Bin mode FTP to move the img file back onto the PC and
> >>> compare the binaries.  Otherwise, I'll assume its just an issue with the
> >>> older CD Drive.  It is not like I haven't seen that before.
> >>>
> >>> I am kind of interested in the issue here, as I was thinking I might want
> >>> to restore some VAX hardware in the future.
> >>>
> >>> Steps:
> >>>
> >>> 1) On rx2620 VMS8.4
> >>> wget https://www.digiater.nl/openvms/freeware/v80/infoserver/infoserver.zip
> >>>
> >>> 2) Use ftp mode Image, move to Simh
> >>>
> >>> 3) Use Unzip 6.0 to decompress
> >>>
> >>> 4) set file /attrib=(rat:none, rfm:fix, lrl:512) AG-R7LFA-BS.IMG
> >>>
> >>> 5) ftp mode image back to PC
> >>>
> >>> Files are identical.  CRC32 F8E5A32A
> >>>
> >>> Mark
> >>>
> >>
> >> FWIW:
> >>
> >> # wget
> >> https://www.digiater.nl/openvms/freeware/v80/infoserver/infoserver.zip
> >> ...
> >> HTTP request sent, awaiting response... 200 OK
> >> Length: 47909376 (46M) [application/zip]
> >> Saving to: ‘infoserver.zip’
> >> ...
> >> # unzip infoserver.zip ag-r7lfa-bs.img
> >> Archive:  infoserver.zip
> >>    inflating: ag-r7lfa-bs.img
> >> #
> >> # mount -o ro,loop ./ag-r7lfa-bs.img /mnt
> >> (snip)
> > 
> > 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.
> > 
> > Seem to recall there was something about 512 vs 2048 CD
> > Drives booting on VAX too, but I don't recall how/if that was an issue
> > with burning them.
> > 
> > Mark
> > 
> 
> Well, now I am totally confused.  I went to the trouble of unpacking
> all this stuff on VMS because of all I have heard about losing VMS
> attributes and the damage it causes.  And now I have no idea what
> I am supposed to be doing in order to make usable disks for the
> machine.
> 
> Any chance someone can make real, functional ISO files that will
> work with any available CD Writing software and put them somewhere
> I can download them?
> 
> bill

1) Just unzip infoserver.zip on your PC

2) Or set the file attributes as I indicated above:
set file /attrib=(rat:none, rfm:fix, lrl:512) *.IMG 
before transferring to the PC.

3) change the file name to *.bin and add cue file.

Either method produces a CD-R usable on my
equipment here, but there could still be CD-ROM 
issues beyond this.

I don't have any equipment old enough to test
that.