[Info-vax] InfoServer 150

[Mark DeArman]

On Monday, January 28, 2019 at 6:13:25 PM UTC-8, Bill Gunshannon wrote:
> On 1/28/19 9:05 PM, Mark DeArman wrote:
> > 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
> 
> Which infoserver.zip?  The one from digiater or the one from HP?

Either, they CRC'd the same.

> > 
> > 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.
> 
> Just the three line cue file that someone posted here?

Yes.  Its just at track layout for the CD.  For a disk like
this it is simple.  Just change the filename for what ever
image you want to burn.

> 
> > 
> > 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.
> > 
> 
> I'll give it a another try.  What's a few more coasters.  Pretty soon
> I'll have the whole set.

Been there :-P

This was why I was suggesting, at least attaching the *.img in simh
first to rule out corruption during transfer issues.
Even without an OS you can read the volume header from the sim>
prompt.

Mark