[Info-vax] InfoServer 150

[Bill Gunshannon]

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?
> 
> 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?

> 
> 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.

bill