Tymshare PDP-10 tapes

Peter Coghlan cctalk at beyondthepale.ie
Mon Mar 8 17:40:29 CST 2021


Tony Aiuto wrote:
> On Sat, Mar 6, 2021 at 11:48 PM Jim Carpenter <jim at deitygraveyard.com> wrote:
>> On Sat, Mar 6, 2021 at 8:07 PM Tony Aiuto via cctalk
>> <cctalk at classiccmp.org> wrote:
>> > I think that is an artifact of the files being created with the wrong
>> names.
>> > For example, with tape 169249, after you skip the UFDs, tito -t prints
>> >
>> >    (SYS)            .SHR    1977-01-26 22:22   [1,4]
>> >    (SYS)            .LOW    1977-01-26 22:23   [1,4]
>> >    (SYS)            .SHR    1986-08-19 03:53   [1,4]
>> >    (SYS)            .LOW    1975-10-24 14:52   [1,4]
>> >    (SYS)            .SAV    1964-01-02 00:01   [1,4]
>> >    (SYS)            .SAV    1964-01-02 00:01   [1,4]
>> >
>> > All the file names are missing. That seems not right.
>>
>> Very not right, because this is what tito -t is giving me:
>>
>>    (SYS)          PIP   .SHR    1977-01-26 22:22   [1,4]
>>    (SYS)          PIP   .LOW    1977-01-26 22:23   [1,4]
>>    (SYS)          LOGINN.SHR    1986-08-19 03:53   [1,4]
>>    (SYS)          COBOL .LOW    1975-10-24 14:52   [1,4]
>>    (SYS)          BINCON.SAV    1964-01-02 00:01   [1,4]
>>    (SYS)          VPDATA.SAV    1964-01-02 00:01   [1,4]
>>
>> Those are the first 6 after the UFDs, and extensions and
>> date/timestamps match yours. I don't have any, at least on 169249,
>> missing the first part of the file name.
>>
>> Jim
>>
>
> Well. I'm stumped right now.  I verified the tape checksum again, and even
> got a fresh copy from http://vtda.org/bits/software/DEC/PDP-10/tymshare/.
> That is not the problem.
>
> I'm building tito on a generic Debian linux (x86_64, debian 4.19, gcc
> 8.3.0) so I doubt this is a portability problem.  I'll try again next
> weekend.
>

Out of curiosity, I tried building tito on VMS (with DECC V7.3-009 on an
Alphaserver 800).  I had some errors compiling memory.c but it appears
the code involved does not get called by tito so this didn't cause me
any problems.  I was able to list the contents of tape 169249 with the
resulting executable and the output I got matched the "right" output
above exactly.  I didn't see anything that looked wrong elsewhere in the
file listing either.

Regards,
Peter Coghlan.


More information about the cctech mailing list