Tops-10 Fortran-10 v11, TSU keys?
retro98
Hello folks,
I'm experimenting with simh running tops-10 and I'm looking to update
Fortran v11 using the Tops-10 704 TSU04 update tapes (from the archives
at pdp-10.trailing-edge.com)
Unfortunately, all those files are encrypted and I can't find the
decryption *.key files :(.
I believe the keys are on the product tape, BB-D480G-SB, but the tape
image available at the aforementioned archive site, is truncated or
otherwise incomplete or damaged. Any one know the keys or where else
they can be found?
Alternative is to crypto analyze the encryption used and to assess if
it's breakable. The effort could be useful to recover other files on the
TSU tapes with lost keys.
Well, anyone know anything about the details of the encryption used, or
any tips on how to find out? Looks like the decrypt binary utility
included with the TSU is [10,7,tsu]decrypt.exe.
Thanks for any input. ..retro98
Al Kossow
> Well, anyone know anything about the details of the encryption used, or
> any tips on how to find out? Looks like the decrypt binary utility
> included with the TSU is [10,7,tsu]decrypt.exe.
>
I'm willing to search the LCG backup tapes for them if someone can tell
me what to look for and what volume(s) they would be on.
retro98
Al Kossow wrote:
The Fortran-10 v11 decryption key files appear in the last save set on
the dec magtap product tape label BB-D480G-SB.
The tape image archive I'm referencing is
http://www.bitsavers.org/bits/DEC/pdp10/magtape/dec_distribs/BB-D480G-SB_FORTRAN10_V11.0.tap.gz
and the identical copy:
http://pdp-10.trailing-edge.com/tapes/BB-D480G-SB_FORTRAN10_V11.0_short.tap.bz2
These tape images are truncated in the fortran compiler saveset. The
file listing ran as follows:
..
309 []lexica.bli
310 []lexica.rel
311 []lexnam.bli
312 []lexsup.bli
313 []lexsup.rel
314 []listng.bli
315 []listng.rel
316 []listou.bli
317 []listng.rel
318 []listou.bli
listou.bli is incomplete, and all the savesets and files afterwards,
including decrypt keys, are missing. It would be good to recover those
files for the archives too. Disk copies of the file in this save set
probably reside in [10,7,ftncmp].
I think the missing savesets that follow are:
fortran build tools
autopatch decryption keys
The last save set on a good tape should include the decryption key files
with names including:
FORLIB.KEY
FORO11.KEY
SINGLE.KEY
I hope there's enough info here to help in a search. Thanks, retro98
Al Kossow
>
> I hope there's enough info here to help in a search. Thanks, retro98
>
It is unlikely that another copy of the tape will be in the archive.
What I was looking for was someone inside DEC who was familiar with the
development machines for information on where the keys or the encryption
tools were stored.
jmfbahciv
I can't help. I have no idea how the Autopatch tapes were built.
Sorry.
/BAH
Tim Shoppa
Seeing as how both DD-480F-SB and DD-480G-SB are short/truncated, I'm
of the belief that the problem is not that those particular tapes were
"bad" but that some peculiarity in the tape mastering process seems to
have mangled the distribution sets.
So Al is aiming at exactly the right place: we need to find the
development disks/backups/tools.
Someday Al, in our copious free time, you and me should find a way to
index the backup tapes that can't be made public. I'm guessing the
tape images could be kept embargoed on your end but we somehow publish
directory listings... is it that easy, or is it more complicated?
Those 6250BPI backup sets are tough cookies. 1600 BPI distribution
tapes only have problems exceedingly rarely (and when they do, as in
DD-480F-SB and DD-480G-SB I believe them not to be media errors but
mastering errors) but 6250BPI sets on sticky Memorex MRV tapes, I
don't even like thinking about them!
Tim.
Al Kossow
> Seeing as how both DD-480F-SB and DD-480G-SB are short/truncated, I'm
> of the belief that the problem is not that those particular tapes were
> "bad" but that some peculiarity in the tape mastering process seems to
> have mangled the distribution sets.
>
No, they are just sticky tapes. I may make another pass over those once
I have 9 track analog data recovery going.
> Someday Al, in our copious free time, you and me should find a way to
> index the backup tapes that can't be made public. I'm guessing the
> tape images could be kept embargoed on your end but we somehow publish
> directory listings... is it that easy, or is it more complicated?
>
I should be able to automate it. It probably will be OK to put the directories
up.
> Those 6250BPI backup sets are tough cookies. 1600 BPI distribution
> tapes only have problems exceedingly rarely (and when they do, as in
> DD-480F-SB and DD-480G-SB I believe them not to be media errors but
> mastering errors) but 6250BPI sets on sticky Memorex MRV tapes, I
> don't even like thinking about them!
>
Thankfully, most only required baking. It was a one-shot deal though.
retro98
> Seeing as how both DD-480F-SB and DD-480G-SB are short/truncated, I'm
I think BB-D480F-BB_1985_short.tap.bz2 (fortran-10 v10) is complete, but
I didn't check to see if they could be corrupted. Nevertheless, the file
name is marked as short.
Here are the file details I have:
$ ls -la BB-D480F-BB_1985_*
-rw-r--r-- 1 root root 19510700 Jun 14 14:11
BB-D480F-BB_1985_short.tap
-rw-r--r-- 1 root root 8305018 Jun 14 11:42
BB-D480F-BB_1985_short.tap.bz2
$ md5sum BB-D480F-BB_1985_short.tap
81eebd926c75be72937aff4212f6869a BB-D480F-BB_1985_short.tap
$
The last save set of DD-480F-SB is "Autopatch files for FORTRAN V1" and
the .key files in that save set appear intact. Those keys won't work
with encrypted fortran-10 v11 files though (I tried).
BB-D480G-SB_FORTRAN10_V11.0_short.tap really is short/truncated, as far
as I can tell.
Tim Shoppa
> > Someday Al, in our copious free time, you and me should find a way to
> > index the backup tapes that can't be made public. I'm guessing the
> > tape images could be kept embargoed on your end but we somehow publish
> > directory listings... is it that easy, or is it more complicated?
>
> I should be able to automate it. It probably will be OK to put the directories
> up.
http://pdp-10.trailing-edge.com/tools.tgz has the tools I use to
unpack, make directories of, and index all common PDP-10 tapes.
Included are versions of backup10 and read20 that know how to read
tape images (after having been run through split_tap).
It auto-determines several common backup saveset types and if boot
blocks are present will succesfully skip over them.
The tools can get fooled on multi-tape savesets but it at least
handles many of them.
Tim.
jmfbahciv
/BAH
jmfbahciv
/BAH
Tim Shoppa
Generally no. There are some tapes in the archives that came in as
6250 BPI's and were succesfully read (e.g. KLAD tapes etc.) but
generally the DEC distribution tapes were 1600 BPI, and that's a good
thing.
What Al and I are talking about are the backup tapes of the LCG
development systems as handed down through the Boston Computer Museum,
I think from my very brief inspection of them at CHM a few years back
that they are mostly from the very late 70's and early-mid 80's. They
are generally 6250 BPI on sticky tapes, a yucky combo in terms of head
stiction but one that Al has an excellent oven technique to deal
with :-).
I am personally always in hope that little gems of the 60's and early
70's are hidden on those reels, but lacking a roadmap as to what might
be where and knowing that non-publicly-distributable stuff personal
stuff may be scattered everywhere it can be overwhelming without the
pointers that Al is asking for.
Tim.
Al Kossow
>
> What Al and I are talking about are the backup tapes of the LCG
> development systems as handed down through the Boston Computer Museum,
> I think from my very brief inspection of them at CHM a few years back
> that they are mostly from the very late 70's and early-mid 80's.
These actually were a donation from Compaq/HP through Tim Litt as he was
cleaning out the lab, and included their TOAD. This occurred in 2003.
Backup tapes are mostly from the early 90's. Earliest are a few from 1026
1026_BLKX_19871105_1of2.tap, for example.
latest are from 1026 in 1994 (DSKA,DSKB,DSKC)
and a large set of CFS dumps from 1991 and some dumps
of SMP from 1990 and 1991
Distribution tapes go back into the 80's. Many of those I have not touched
since they are 800 bpi, which requires more work to recover.
There are currently around 450 tape images archived.
Here are the CFS directories for 90 and 91.
CFS_TSU04_19910205_1of1.tap may be a good place to start looking.
CFS_AP41DS_19900906_1of1.tap CFS_EXODUS_19900817_2of2.tap CFS_MOLD_19900817_2of2.tap CFS_SAGE_19900817_FULL_1of1.tap
CFS_AP41_19900906_1of1.tap CFS_FBOX_19900816_1of1.tap CFS_MOOSE_19900817_1of1.tap CFS_SCORCH_19900814_1of1.tap
CFS_AP61DS_19900906_1of1.tap CFS_FTN_19900619_1of2.tap CFS_MORDOR_19900814_1of3.tap CFS_SLICE_19900814_1of2.tap
CFS_AP61_19900906_1of1.tap CFS_FTN_19900619_2of2.tap CFS_MORDOR_19900814_2of3.tap CFS_SLICE_19900814_2of2.tap
CFS_AP70DS_19900906_1of1.tap CFS_FTN_19900814_1of1.tap CFS_MORDOR_19900814_3of3.tap CFS_SNARK_19900813_1of4.tap
CFS_AP70PS_19900906_1of1.tap CFS_GALAXY_19900813_1of2_er.log CFS_MRAUG_19900906_1of1.tap CFS_SNARK_19900813_2of4.tap
CFS_AP70_19900906_1of1.tap CFS_GALAXY_19900813_1of2_er.tap CFS_MRCHIP_19900906_1of1.tap CFS_SNARK_19900813_3of4_3er.log
CFS_ARK_19900906_1of1.tap CFS_GALAXY_19900813_2of2.tap CFS_MRDALE_19900906_1of1.tap CFS_SNARK_19900813_3of4_3er.tap
CFS_AUGGIE_19900817_1of2.tap CFS_GALKS_19900906_1of1.tap CFS_NAP_19900618_1of1.tap CFS_SNARK_19900813_4of4.tap
CFS_AUGGIE_19900817_2of2.tap CFS_GIDNEY_19900910_1of1.tap CFS_NAP_19900813_1of2.tap CFS_SQUIRL_19900309_1of1.tap
CFS_B3620_19900814_1of1.tap CFS_GINSU_19900906_1of1.tap CFS_NAP_19900813_2of2.tap CFS_SQUIRL_19900726_1of1.tap
CFS_BOXWK_19900816_1of3.tap CFS_GREEN_19900816_1of2.tap CFS_NETPKG_19900906_1of1.tap CFS_SQUIRL_19900906_1of1.tap
CFS_BOXWK_19900816_2of3.tap CFS_GREEN_19900816_2of2.tap CFS_NETU_19900906_1of1.tap CFS_SUDCOM_19900816_1of1.tap
CFS_BOXWK_19900816_3of3.tap CFS_GREG_19900906_1of1.tap CFS_NET_1of1_short.tap CFS_T22_19900906_1of1.tap
CFS_CDUMP_19900906_1of1.tap CFS_HPE_19900906_1of2.tap CFS_OLDCLO_19900906_1of1.tap CFS_TEST_19900906_1of1.tap
CFS_CHIPS_19900906_1of1.tap CFS_HPE_19900906_2of2.tap CFS_OPR_19900814_1of2.tap CFS_THEP_19900813_1of1.tap
CFS_CLOY61_19900906_1of1.tap CFS_IBOX_19900816_1of1.tap CFS_OPR_19900814_2of2.tap CFS_TSUKS_19900906_1of1.tap
CFS_CLOYD_19900813_1of2.tap CFS_IDEA2_19900817_1of2.tap CFS_PABST_19900906_1of1.tap CFS_UCD36_19900906_1of1.tap
CFS_CLOYD_19900813_2of2.tap CFS_IDEA2_19900817_2of2.tap CFS_PASCAL_19900817_1of1.tap CFS_V40DN_19900906_1of1.tap
CFS_CPG_19900906_1of1.tap CFS_IDEA_19900816_1of2.tap CFS_PB_19900821_1of1.tap CFS_VENCP1_19900816_1of2.tap
CFS_DALES_19900906_1of1.tap CFS_IDEA_19900816_2of2.tap CFS_PERF*_19900906_1of1.tap CFS_VENCP1_19900816_2of2.tap
CFS_DBMS20_19900814_1of2.tap CFS_IGUANA_19900816_1of1.tap CFS_PUBLIC_19900813_1of2.tap CFS_VENEG1_19900816_1of1.tap
CFS_DBMS20_19900814_2of2.tap CFS_JACK_19900906_1of1.tap CFS_PUBLIC_19900813_2of2.tap CFS_VENEG2_19900817_1of1.tap
CFS_DBMS20_19900911_2of2.tap CFS_JAWS_19900906_1of1.tap CFS_RANDOM_19900813_1of2.tap CFS_VENFG1_19900816_1of1_1e.log
CFS_DESERV_19900816_1of2.tap CFS_JP70DS_19900906_1of1.tap CFS_RANDOM_19900813_2of2.tap CFS_VENFG1_19900816_1of1_1e.tap
CFS_DESERV_19900816_2of2.tap CFS_JP70PS_19900906_1of1.tap CFS_REL7_19900814_1of2.tap CFS_VENFG2_19900817_1of1.tap
CFS_DICE_19900814_1of1.tap CFS_JUNKM_19900906_1of1.tap CFS_REL7_19900814_2of2.tap CFS_VENIG1_19900816_1of1.tap
CFS_DML60_19900906_1of1.tap CFS_LINK_19900814_1of1.tap CFS_RIP20_19900817_1of1.tap CFS_VENIG2_19900817_1of1.tap
CFS_DMLPS_19900906_1of1.tap CFS_LSCAD_19900816_1of1_5er.log CFS_RIP_19900813_1of2.tap CFS_VENMG1_19900816_1of1.tap
CFS_DNET41_19900906_1of1.tap CFS_LSCAD_19900816_1of1_5er.tap CFS_RIP_19900813_2of2.tap CFS_VENMG2_19900817_1of1.tap
CFS_DSK0_19900817_1of2.tap CFS_MBOX_19900816_1of2.tap CFS_ROCKET_19900906_1of1.tap CFS_WHITE_19900814_1of2.tap
CFS_DSK0_19900817_2of2.tap CFS_MCA_19900817_1of1.tap CFS_RONCO_19900813_1of1.tap CFS_WHITE_19900814_2of2.tap
CFS_DSKC_19900817_1of1.tap CFS_MISKIN_19900817_1of1.tap CFS_RSU2_19900906_1of1.tap CFS_WORK_19900813_1of4.tap
CFS_DTR20_19900906_1of1.tap CFS_MKT_19900817_1of2.tap CFS_RSU_19900906_1of1.tap CFS_WORK_19900813_2of4.tap
CFS_EBOX_19900816_1of1.tap CFS_MKT_19900817_2of2.tap CFS_SA06_19900906_1of1.tap CFS_WORK_19900813_3of4.tap
CFS_ELF_19900816_1of1.tap CFS_MODRED_19900817_1of1.tap CFS_SA26_19900906_1of1.tap CFS_WORK_19900813_4of4.tap
CFS_EXODUS_19900817_1of2.tap CFS_MOLD_19900817_1of2.tap CFS_SAGE_19900817_1of1.tap
CFS_AP41DS_19910207_1of1.tap CFS_GREG_19910121_1of1.tap CFS_RANDOM_19910114_2of2.tap
CFS_AP61DS_19910214_1of1.tap CFS_HPE_19910214_1of2.tap CFS_REL41A_19910107_1of1.tap
CFS_AP61_19910207_1of1.tap CFS_HPE_19910214_2of2.tap CFS_REL41A_19910214_1of1.tap
CFS_AP70DS_19910121_1of1.tap CFS_IBOX_19910212_1of1.tap CFS_REL7_19910108_2of2.tap
CFS_AP70DS_19910214_1of1.tap CFS_IDEA2_19910212_1of2.tap CFS_REL7_19910116_2of2.tap
CFS_ARK_19910207_1of1.tap CFS_IDEA2_19910212_2of2.tap CFS_RIP20_19910212_1of1.tap
CFS_AUGGIE_19910201_1er.tap CFS_IDEA_19910214_1of2_2e.log CFS_RIP_19910114_1of2.tap
CFS_AUGGIE_19910201_1er_tr2.tap CFS_IDEA_19910214_1of2_2e.tap CFS_RIP_19910114_2of2.tap
CFS_AUGGIE_19910214_1of2.tap CFS_IDEA_19910214_2of2.tap CFS_RIP_19910211_1of2.tap
CFS_AUGGIE_19910214_2of2.tap CFS_IGUANA_19910214_1of1.tap CFS_RIP_19910211_2of2_1e.log
CFS_B3620_19910214_1of1.tap CFS_JAWS_19910207_1of1.tap CFS_RIP_19910211_2of2_1e.tap
CFS_BOXWK_19910214_1of3.tap CFS_LINK_19910214_1of1.tap CFS_ROCKET_19910121_1of1.tap
CFS_BOXWK_19910214_2of3.tap CFS_LSCAD_19910212_1of1_1e.log CFS_RONCO_19910116_1of1.tap
CFS_BOXWK_19910214_3of3.tap CFS_LSCAD_19910212_1of1_1e.tap CFS_RSX20F_19910214_1of1.tap
CFS_CHIPS_19910207_1of1.tap CFS_MBOX_19910212_1of2.tap CFS_RSX20F_19910214_FULL.tap
CFS_CLOYD_19910211_1of2.tap CFS_MBOX_19910212_2of2.tap CFS_SAGE_19910212_1of1.tap
CFS_CLOYD_19910211_2of2.tap CFS_MCA_19910212_1of1.tap CFS_SCORCH_19910116_1of1.tap
CFS_CLOYD_19910215_1of2.tap CFS_MISKIN_19910212_1of1.tap CFS_SLICE_19910215_1of1.tap
CFS_CLOYD_19910215_2of2_1er.tap CFS_MKT_19910214_1of2.tap CFS_SNARK_19910114_2of4.tap
CFS_CPG_19910207_1of1.tap CFS_MKT_19910214_2of2.tap CFS_SNARK_19910114_3of4.tap
CFS_DALES_19910207_1of1.tap CFS_MODRED_19910215_1of1.tap CFS_SNARK_19910114_4of4.tap
CFS_DBMS20_19910116_1er.tap CFS_MOLD_19910214_1of2.tap CFS_SNARK_19910211_1of1_1e.log
CFS_DBMS20_19910214_5er.tap CFS_MOLD_19910214_2of2.tap CFS_SNARK_19910211_1of1_1e.tap
CFS_DESERV_19910214_1of2.tap CFS_MONCRS_19910214_1of1.tap CFS_SNARK_19910211_4of4.tap
CFS_DESERV_19910214_2of2_sh.log CFS_MOOSE_19910117_1of1.tap CFS_SNARK_19910212_1of4.tap
CFS_DESERV_19910214_2of2_sh.tap CFS_MORDOR_19910108_3of3.tap CFS_SQUIRL_19910116_1of1.tap
CFS_DICE_19910116_1of1.tap CFS_MORDOR_19910110_1of3.tap CFS_SUDCOM_19910212_1of1.tap
CFS_DTR20_19910207_1of1_1e.log CFS_MORDOR_19910110_3of3.tap CFS_THEP_19910116_1of1.tap
CFS_DTR20_19910207_1of1_1e.tap CFS_MORDOR_19910212_1of1_1e.log CFS_TSU04_19910205_1of1.tap
CFS_EBOX_19910212_1of1.tap CFS_MORDOR_19910212_1of1_1e.tap CFS_TSUKS_19910207_1of1.tap
CFS_ELF_19910212_1of1.tap CFS_MORDOR_19910214_2of2.tap CFS_UCD36_19910207_1of1.tap
CFS_EXODUS_19910214_1of2.tap CFS_MRCHIP_19910207_1of1.tap CFS_V40DN_19910207_1of1.tap
CFS_EXODUS_19910214_2of2.tap CFS_MRDALE_19910207_1of1.tap CFS_VENCP1_19910212_1of2.tap
CFS_FBOX_19910212_1of1.tap CFS_NAP_19910114_1of2.tap CFS_VENCP1_19910212_2of2.tap
CFS_FLDI70_19910214_1of1.tap CFS_NAP_19910114_2of2.tap CFS_VENEG1_19910212_1of1.tap
CFS_FTN_19910214_1of1.tap CFS_NAP_19910211_1of2.tap CFS_VENEG2_19910212_1of1.tap
CFS_GALAXY_19910114_1of2.tap CFS_NAP_19910211_2of2.tap CFS_VENFG1_19910212_1of1.tap
CFS_GALAXY_19910114_2of2_1e.log CFS_NETPKG_19910207_1of1.tap CFS_VENFG2_19910212_1of1.tap
CFS_GALAXY_19910114_2of2_1e.tap CFS_NETU_19910207_1of1.tap CFS_VENIG1_19910212_1of1.tap
CFS_GALAXY_19910114_2of2_1er_try2.log CFS_NET_19910207.tap CFS_VENIG2_19910212_1of1.tap
CFS_GALAXY_19910114_2of2_1er_try2.tap CFS_OPR_19910215_1of2_er.log CFS_VENMG1_19910212_1of1.tap
CFS_GALAXY_19910211_1of2.tap CFS_OPR_19910215_1of2_er.tap CFS_VENMG2_19910212_1of1.tap
CFS_GALAXY_19910211_2of2.tap CFS_OPR_19910215_2of2.tap CFS_WHITE_19910108_2of2.tap
CFS_GALKS_19910207_1of1.tap CFS_PB_19910212_1of1_3.tap CFS_WHITE_19910116_2of2.tap
CFS_GIDNEY_19910211_1of1_2e.log CFS_PB_19910212_1of1_3e.log CFS_WHITE_19910214_1of1.tap
CFS_GIDNEY_19910211_1of1_2e.tap CFS_PERF_19910207_1of1.tap CFS_WORK_19910114_1of2.tap
CFS_GIDNEY_19910215_1of1.tap CFS_PUBLIC_19910114_1of2.tap CFS_WORK_19910114_2of2.tap
CFS_GINSU_19910207_1of1.tap CFS_PUBLIC_19910114_2of2.tap CFS_WORK_19910211_1of2_1e.log
CFS_GREEN_19910214_1of2_2e.log CFS_PUBLIC_19910211_1of2.tap CFS_WORK_19910211_1of2_1e.tap
CFS_GREEN_19910214_1of2_2e.tap CFS_PUBLIC_19910211_2of2.tap CFS_WORK_19910211_2of2.tap
CFS_GREEN_19910214_2of2.tap
1026_AP10_19900813_1of2.tap 1026_BLKY_19900814_1of2.tap 1026_DSKB_19900813_1of2.tap 1026_SIRS_19900814_1of2.tap
1026_AP10_19900813_2of2.tap 1026_BLKY_19900814_2of2.tap 1026_DSKB_19900813_2of2.tap 1026_SIRS_19900814_2of2.tap
1026_BLKK_19900814_1of2.tap 1026_DSKA_19900503_1of2.tap 1026_PIT_19900813_1of1.tap 1026_SIRS_19901029_1of2.tap
1026_BLKK_19900814_2of2.tap 1026_DSKA_19900503_2of2.tap 1026_RENG_19900814_1of3.tap 1026_SIRS_19901029_2of2.tap
1026_BLKX_19900814_1of2.tap 1026_DSKA_19901002_1of2.tap 1026_RENG_19900814_2of3.tap
1026_BLKX_19900814_2of2.tap 1026_DSKA_19901002_2of2.tap 1026_RENG_19900814_3of3.tap
1026_BLKG_19910117_2of2.tap 1026_BLKX_19910116_2of2.tap 1026_DSKB_19910114_2of2.tap 1026_RENG_19910116_1of3_3e.tap
1026_BLKJ_19910117_2of2.tap 1026_BLKY_19910116_1of2.tap 1026_DSKB_19910116_1of2.tap 1026_RENG_19910116_2of3_1e.log
1026_BLKK_19910116_1of1.tap 1026_BLKY_19910116_2of2.tap 1026_DSKB_19910117_2of2.tap 1026_RENG_19910116_2of3_1e.tap
1026_BLKL_19910116_1of1_1e.log 1026_DSKA_19910117_1of2_1e.log 1026_DSKC_19910116_1of1.tap 1026_RENG_19910116_3of3.tap
1026_BLKL_19910116_1of1_1e.tap 1026_DSKA_19910117_1of2_1e.tap 1026_DSKD_19910117_1of1.tap 1026_SIRS_19910116_1of2.tap
1026_BLKX_19910116_1of2.tap 1026_DSKA_19910117_2of2.tap 1026_RENG_19910116_1of3_3e.log 1026_SIRS_19910116_2of2.tap
KL1026_DSKA_19920611_1of2.tap KL1026_DSKB_19920611_1of2.tap KL1026_DSKB_19920819_incr.tap KL1026_DSKB_19921207_incr.tap
KL1026_DSKA_19920611_2of2.tap KL1026_DSKB_19920611_2of2.tap KL1026_DSKB_19920909_incr.tap KL1026_DSKC_19920611_1of1.tap
KL1026_DSKA_19920909_incr.tap KL1026_DSKB_19920721_incr.tap KL1026_DSKB_19921118_incr.tap
KL1026_DSKA_19930203_1of2_1e.log KL1026_DSKB_19930203_1of2.tap KL1026_DSKB_19930630_2of2.tap
KL1026_DSKA_19930203_1of2_1e.tap KL1026_DSKB_19930203_2of2.tap KL1026_DSKC_19930203_1of1.tap
KL1026_DSKA_19930203_2of2.tap KL1026_DSKB_19930319_incr.tap KL1026_DSKC_19930630_1of1.tap
KL1026_DSKA_19930630_1of2.tap KL1026_DSKB_19930406_incr.tap
KL1026_DSKA_19930630_2of2.tap KL1026_DSKB_19930630_1of2.tap
DSKA_19941116_1of7.tap DSKA_19941116_6of7.tap DSKA_complBkup_04_19941116.tap DSKB_19940601_2of3.tap
DSKA_19941116_2of7.tap DSKA_19941116_7of7.tap DSKA_complBkup_05_19941116.tap DSKB_19940601_3of3.tap
DSKA_19941116_3of7.tap DSKA_complBkup_01_19941116.tap DSKA_complBkup_06_19941116.tap KL1026_DSKC_19940610_1of2.tap
DSKA_19941116_4of7.tap DSKA_complBkup_02_19941116.tap DSKA_complBkup_07_19941116.tap KL1026_DSKC_19940610_2of2.tap
DSKA_19941116_5of7.tap DSKA_complBkup_03_19941116.tap DSKB_19940601_1of3.tap
glen herrmannsfeldt
(someone wrote)
>> The Autopatch tapes were shipped on 6250 BPI?!!!!!
> Generally no. There are some tapes in the archives that came in as
> 6250 BPI's and were succesfully read (e.g. KLAD tapes etc.) but
> generally the DEC distribution tapes were 1600 BPI, and that's a good
> thing.
From IBM tape drive statistics that I remember, 1600 was always
more reliable than 800, and 6250 more reliable than 1600.
800 uses NRZI, requiring that all tracks clock together.
(It must be odd parity, or you can't write X'00')
Any head skew difference between the writing drive and reading
drive makes it much less reliable.
1600 uses PE (phase encoding), such that each track clocks
separately. The result is much less sensitive to head skew,
and so much more reliable.
6250 is GCR, (group code recording) which gives the drives
a good chance to recover from read errors. With bad drives
or tape, though, I suppose it could be less reliable.
-- glen
jmfbahciv
I know. We had a hard and fast rule about never shipping in 6250.
/BAH
jmfbahciv
> Tim Shoppa wrote:
>
>>
>> What Al and I are talking about are the backup tapes of the LCG
>> development systems as handed down through the Boston Computer Museum,
>> I think from my very brief inspection of them at CHM a few years back
>> that they are mostly from the very late 70's and early-mid 80's.
>
> These actually were a donation from Compaq/HP through Tim Litt as he was
> cleaning out the lab, and included their TOAD. This occurred in 2003.
>
> Backup tapes are mostly from the early 90's. Earliest are a few from 1026
>
> 1026_BLKX_19871105_1of2.tap, for example.
BLKX: was used as the KL front end and was our CUSP archive. this
was the pack that contained all the CUSP sources and build procedures
we used to make distribution tapes for the CUSP tape.
BLKY: was the front end pack for the second CPU KL and contained
all the sources and build procedures for the Customer Supported
Tape and Unsupported Tape (I never built the stuff on the
Unsupported Tape but put everything there that I, or anybody
in-house, thought might be useful to customers.
> latest are from 1026 in 1994 (DSKA,DSKB,DSKC)
These were our public structures. DSKA: was usually the pack
we used to dump crashes. DSKB: was the primiary public
structure and DSKC: was the secondary public structure.
>
> and a large set of CFS dumps from 1991 and some dumps
> of SMP from 1990 and 1991
>
> Distribution tapes go back into the 80's. Many of those I have not touched
> since they are 800 bpi, which requires more work to recover.
>
> There are currently around 450 tape images archived.
<snip -20 system saves--I don't know much about these)
The one called EBOX and a couple others may be saves
from the hardware engineering system; but I'm simply guessing.
>
> 1026_AP10_19900813_1of2.tap 1026_BLKY_19900814_1of2.tap
> 1026_DSKB_19900813_1of2.tap 1026_SIRS_19900814_1of2.tap
> 1026_AP10_19900813_2of2.tap 1026_BLKY_19900814_2of2.tap
> 1026_DSKB_19900813_2of2.tap 1026_SIRS_19900814_2of2.tap
> 1026_BLKK_19900814_1of2.tap 1026_DSKA_19900503_1of2.tap
> 1026_PIT_19900813_1of1.tap 1026_SIRS_19901029_1of2.tap
> 1026_BLKK_19900814_2of2.tap 1026_DSKA_19900503_2of2.tap
> 1026_RENG_19900814_1of3.tap 1026_SIRS_19901029_2of2.tap
> 1026_BLKX_19900814_1of2.tap 1026_DSKA_19901002_1of2.tap
> 1026_RENG_19900814_2of3.tap
> 1026_BLKX_19900814_2of2.tap 1026_DSKA_19901002_2of2.tap
> 1026_RENG_19900814_3of3.tap
Those SIRS saves would have all the SPRs that the SIRS group
ever entered in machine-readable format.
RENG: was the private pack of Release Engineering. There may
be a few gems on those.
I have no idea what PIT was.
AP10: was the private structure used for all the -10 autopatch
tape making.
>
> 1026_BLKG_19910117_2of2.tap 1026_BLKX_19910116_2of2.tap
BLKG: was another archive but I can't recall its designation.
Perhaps languages. There used to be a memo that described
which classes of sources were to go on each Black Pack.
> 1026_DSKB_19910114_2of2.tap 1026_RENG_19910116_1of3_3e.tap
> 1026_BLKJ_19910117_2of2.tap 1026_BLKY_19910116_1of2.tap
BLKJ was a new designation but I can't remember what for. Maybe
it was the front end pack for the third KL CPU.
> 1026_DSKB_19910116_1of2.tap 1026_RENG_19910116_2of3_1e.log
> 1026_BLKK_19910116_1of1.tap 1026_BLKY_19910116_2of2.tap
BLKK: was the pack that contained all the monitor sources
and ANF-10. These were the sources that went on the
monitor distribution tape.
> 1026_DSKB_19910117_2of2.tap 1026_RENG_19910116_2of3_1e.tap
> 1026_BLKL_19910116_1of1_1e.log 1026_DSKA_19910117_1of2_1e.log
Don't remember what BLKL was used for.
> 1026_DSKC_19910116_1of1.tap 1026_RENG_19910116_3of3.tap
> 1026_BLKL_19910116_1of1_1e.tap 1026_DSKA_19910117_1of2_1e.tap
> 1026_DSKD_19910117_1of1.tap 1026_SIRS_19910116_1of2.tap
I don't remember a DSKD: It could have been somebody's private
pack for stand alone.
If you have any questions, ask me.
/BAH
jmfbahciv
> Al Kossow wrote:
If you can find any tapes of BLKC: guard it with your life. That
is the pack that had all the interesting old stuff archived on it.
The Level D memo is there and other old stuff that I can't
recall at the moment.
/BAH
Al Kossow
> jmfbahciv wrote:
>> Al Kossow wrote:
>
> If you can find any tapes of BLKC: guard it with your life. That
> is the pack that had all the interesting old stuff archived on it.
>
Here are the dumps of SMP. looks like BLKC is there.
SMP_BLKA_19900906_1of2.tap
SMP_BLKA_19900906_2of2.tap
SMP_BLKB_19900906_1of1.tap
SMP_BLKC_19900906_1of2.tap
SMP_BLKC_19900906_2of2.tap
SMP_BLKD_19900906_1of1.tap
SMP_BLKF_19900906_1of1.tap
SMP_BLKG_19900906_1of2.tap
SMP_BLKG_19900907_2of2.tap
SMP_BLKJ_19900906_1of1_1er.log
SMP_BLKJ_19900906_1of1_1er.tap
SMP_BLKM_19900906_1of1.tap
SMP_BLUI_19900906_1of1.tap
SMP_DCUS_19900906_1of2.tap
SMP_DCUS_19900926_FULL_1of2.tap
SMP_DCUS_19900926_FULL_2of2.tap
SMP_DSKV_19900906_1of1.tap
SMP_GENL_19900906_1of1.tap
SMP_IRS_19900906_1of1.tap
SMP_WSM_19900906_1of1.tap
SMP_BLKA_19910117_1of2.tap
SMP_BLKA_19910117_2of2.tap
SMP_BLKB_19910117_1of1.tap
SMP_BLKC_19910117_1of2.tap
SMP_BLKC_19910117_2of2.tap
SMP_BLKD_19910117_1of1.tap
SMP_BLKF_19910117_1of1.tap
SMP_BLKG_19910117_1of2_short.ta
SMP_BLKJ_19910117_1of2_1er.log
SMP_BLKJ_19910117_1of2_1er.tap
SMP_DCUS_19910117_1of2_2e.log
SMP_DCUS_19910117_1of2_2e.tap
SMP_DCUS_19910117_2of2.tap
SMP_DSKS_19910117_1of1.tap
SMP_DSKV_19910117_1of1.tap
jmfbahciv
> jmfbahciv wrote:
>> jmfbahciv wrote:
>>> Al Kossow wrote:
>>
>> If you can find any tapes of BLKC: guard it with your life. That
>> is the pack that had all the interesting old stuff archived on it.
>>
>
> Here are the dumps of SMP. looks like BLKC is there.
Good. That pack may contain the memo which describes what
the other Black Packs contained. One was for languages but
I can't recall which one that was (I never used it). The
languages' storage was before the language split off
organizationally) into little groups; then they had their
own private packs and stopped using the Black Packs.
I should know what BLKA: and BLKB: were used for but I cannot
remember right now.
BLKC: should also contain all the specs that had been written
when the PDP-10 group was in Maynard.
>
> SMP_BLKA_19900906_1of2.tap
> SMP_BLKA_19900906_2of2.tap
> SMP_BLKB_19900906_1of1.tap
> SMP_BLKC_19900906_1of2.tap
> SMP_BLKC_19900906_2of2.tap
> SMP_BLKD_19900906_1of1.tap
> SMP_BLKF_19900906_1of1.tap
> SMP_BLKG_19900906_1of2.tap
> SMP_BLKG_19900907_2of2.tap
> SMP_BLKJ_19900906_1of1_1er.log
> SMP_BLKJ_19900906_1of1_1er.tap
> SMP_BLKM_19900906_1of1.tap
> SMP_BLUI_19900906_1of1.tap
> SMP_DCUS_19900906_1of2.tap
> SMP_DCUS_19900926_FULL_1of2.tap
> SMP_DCUS_19900926_FULL_2of2.tap
> SMP_DSKV_19900906_1of1.tap
> SMP_GENL_19900906_1of1.tap
> SMP_IRS_19900906_1of1.tap
> SMP_WSM_19900906_1of1.tap
I don't remember DCUS:, DSKV:, GENL:, IRS:, nor WSM:.
WSM: smells of somebody's initials and, thus, would be
a private pack. DCUS, as a guess, would have been used
for some kind of DECUS work, but I can't recall what that
was (it vaguely rings a bell).
IRS: may also have been somebody's initials and a private pack.
All private packs were used for new development.
GENL: and DSKV: must have been hardware engineering. If so, you might
find very useful stuff on those.
>
> SMP_BLKA_19910117_1of2.tap
> SMP_BLKA_19910117_2of2.tap
> SMP_BLKB_19910117_1of1.tap
> SMP_BLKC_19910117_1of2.tap
> SMP_BLKC_19910117_2of2.tap
> SMP_BLKD_19910117_1of1.tap
> SMP_BLKF_19910117_1of1.tap
> SMP_BLKG_19910117_1of2_short.ta
> SMP_BLKJ_19910117_1of2_1er.log
> SMP_BLKJ_19910117_1of2_1er.tap
> SMP_DCUS_19910117_1of2_2e.log
> SMP_DCUS_19910117_1of2_2e.tap
> SMP_DCUS_19910117_2of2.tap
> SMP_DSKS_19910117_1of1.tap
> SMP_DSKV_19910117_1of1.tap
Since these are all on 2 tapes, they will be at 6250 BPI.
/BAH