[Info-vax] InfoServer 150

[Bill Gunshannon]

On 1/28/19 9:29 PM, Mark DeArman wrote:
> 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.

Nothing.  One linefeed and then after a 30 seconds or so the led
on the drive goes out and then nothing.

Maybe it's just time to give up.

bill