[TUHS] 5ESS UNIX RTR Reference Manual - Issue 10 (2001)

[TUHS] 5ESS UNIX RTR Reference Manual - Issue 10 (2001)

[segaloco via TUHS]

Good evening, while I'm still waiting on the full uploads to progress (it's like there's a rule any >100MB upload to archive.org for me has to fail like 5 times before it'll finally go...) I decided to scrape out the UNIX RTR manual from a recent trove of 5ESS materials I received and tossed it up in a separate upload:

https://archive.org/details/5ess-switch-unix-rtr-operating-system-reference-manual-issue-10

This time around I've got Issue 10 from December 2001.  The last issue of this particular manual I found on another 5ESS disc is Issue 7 from 1998 which I shared previously (https://ia601200.us.archive.org/view_archive.php?archive=%2F12%2Fitems%2F5ess-switch-dk5e-cd-1999-05%2F5ESS-DK5E.zip&file=5EDOCS%2F93447.PDF)

The manual is in "DynaText" format on the CD in question, unlike Issue 7 which was already a PDF on its respective CD.  I used print-to-PDF to generate the above linked copy.  Given that the CD itself is from 2007, this may point to UNIX RTR having no significant user-visible changes from 2001 to 2007 that would've necessitated manual revisions.

In any case, I intend to upload bin/cue images of all 7 of the CDs I've received which span from 1999 to 2007, and mostly concern the 5ESS-2000 switch from the administrative and maintenance points of view.  Once I get archive.org to choke these files down I also intend to go back around to the discs I've already archived and reupload them as proper bin/cue rips.  I was in a hurry the last time around and simply zipped the contents from the discs, but aside from just being good archive practice, I think bin/cue is necessary for the other discs as they seem to have control information in the disc header that is required by the interactive documentation viewers therein.

All that to say, the first pass will result in bin/cues which aren't easily readable through archive.org's interface, but I intend to also swing back around on these new discs and provide zips of the contents as well to ensure the archives are both correct (bin/cue) and easily navigable (zip).

As always, if you have any such documentation or leads on where any may be awaiting archival, I'm happy to take on the work!

- Matt G.

[TUHS] Re: 5ESS UNIX RTR Reference Manual - Issue 10 (2001)

[Kevin Bowling]

On Mon, Jun 10, 2024 at 11:06 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>
> Good evening, while I'm still waiting on the full uploads to progress (it's like there's a rule any >100MB upload to archive.org for me has to fail like 5 times before it'll finally go...) I decided to scrape out the UNIX RTR manual from a recent trove of 5ESS materials I received and tossed it up in a separate upload:
>
> https://archive.org/details/5ess-switch-unix-rtr-operating-system-reference-manual-issue-10
>
> This time around I've got Issue 10 from December 2001.  The last issue of this particular manual I found on another 5ESS disc is Issue 7 from 1998 which I shared previously (https://ia601200.us.archive.org/view_archive.php?archive=%2F12%2Fitems%2F5ess-switch-dk5e-cd-1999-05%2F5ESS-DK5E.zip&file=5EDOCS%2F93447.PDF)
>
> The manual is in "DynaText" format on the CD in question, unlike Issue 7 which was already a PDF on its respective CD.  I used print-to-PDF to generate the above linked copy.  Given that the CD itself is from 2007, this may point to UNIX RTR having no significant user-visible changes from 2001 to 2007 that would've necessitated manual revisions.
>
> In any case, I intend to upload bin/cue images of all 7 of the CDs I've received which span from 1999 to 2007, and mostly concern the 5ESS-2000 switch from the administrative and maintenance points of view.  Once I get archive.org to choke these files down I also intend to go back around to the discs I've already archived and reupload them as proper bin/cue rips.  I was in a hurry the last time around and simply zipped the contents from the discs, but aside from just being good archive practice, I think bin/cue is necessary for the other discs as they seem to have control information in the disc header that is required by the interactive documentation viewers therein.
>

I have some of these CDs already and can compare notes with you:
DK5E-CD from 2004, OA&M from 2008.

I think you can just copy the SGML files to a HDD once you have
DynaText installed, so whatever is funky about the CDs is not terribly
important for use aside from the fidelity of your archival.  Some of
my CDs also use something called Eloquent Presenter which seems like a
HyperCard style program.  All the docs that aren't SGML are PDF,
including most of the schematics, plenty which look like scans of
originals.

> All that to say, the first pass will result in bin/cues which aren't easily readable through archive.org's interface, but I intend to also swing back around on these new discs and provide zips of the contents as well to ensure the archives are both correct (bin/cue) and easily navigable (zip).
>
> As always, if you have any such documentation or leads on where any may be awaiting archival, I'm happy to take on the work!

FWIW I have a fully working 5ESS that I turned off last week (actually
a 7 R/E - 3B21D, CM3 (Global Message Server), 20k lines a mix of POTS,
ISDN, PRI trunks) and it is coming home with me at the end of the
month.  Small matters of loading, unloading, AC PDU and getting a
sizable DC power plant and unbounded wiring are in my future.  Why? I
dunno but full send.  I need to have a think on how to be public with
all this going forward, I do want to share the system and the goal is
historical preservation and learning with interested parties.

> - Matt G.

[TUHS] Re: 5ESS UNIX RTR Reference Manual - Issue 10 (2001)

[Jim Carpenter]

On Tue, Jun 11, 2024 at 2:06 AM segaloco via TUHS <tuhs@tuhs.org> wrote:
> In any case, I intend to upload bin/cue images of all 7 of the CDs I've received which span from 1999 to 2007, and mostly concern the 5ESS-2000 switch from the administrative and maintenance points of view.  Once I get archive.org to choke these files down I also intend to go back around to the discs I've already archived and reupload them as proper bin/cue rips.  I was in a hurry the last time around and simply zipped the contents from the discs, but aside from just being good archive practice, I think bin/cue is necessary for the other discs as they seem to have control information in the disc header that is required by the interactive documentation viewers therein.

Bin/cue is a PITA. You've checked that a simple raw image isn't
adequate? Perhaps the viewer was just checking the volume label?


Jim

[TUHS] Re: 5ESS UNIX RTR Reference Manual - Issue 10 (2001)

[segaloco via TUHS]

On Tuesday, June 11th, 2024 at 6:37 PM, Jim Carpenter <jim@deitygraveyard.com> wrote:

> On Tue, Jun 11, 2024 at 2:06 AM segaloco via TUHS tuhs@tuhs.org wrote:
> 
> > In any case, I intend to upload bin/cue images of all 7 of the CDs I've received which span from 1999 to 2007, and mostly concern the 5ESS-2000 switch from the administrative and maintenance points of view. Once I get archive.org to choke these files down I also intend to go back around to the discs I've already archived and reupload them as proper bin/cue rips. I was in a hurry the last time around and simply zipped the contents from the discs, but aside from just being good archive practice, I think bin/cue is necessary for the other discs as they seem to have control information in the disc header that is required by the interactive documentation viewers therein.
> 
> 
> Bin/cue is a PITA. You've checked that a simple raw image isn't
> adequate? Perhaps the viewer was just checking the volume label?
> 
> 
> Jim

What would you suggest?  My main point of reference is years and years of being in the console video game scene, bin/cue is the most accessible of the high fidelity formats I've seen for things, compared with say cdi and mdf/mds.  Does a plain old iso suffice for all relevant data from the media?  Frankly I've never done dumps on a UNIXy computer with an optical drive, only Windows boxen, so can't say I'm hip to the sort of disc image you get doing a dd from an optical /dev entry, maybe I just need to get a UNIX of some kind on my old beater game machine with an optical drive to do these dumps going forward.

Either way, open to suggestions on what format is the ideal combination of capturing everything that matters from optical media while not using too onerous or closed up of an image format.  This is not an area I'm "with the times on", I just went straight to what was customary for myself over a decade ago when I was last diligently interacting with optical media preservation.

- Matt G.

[TUHS] Re: 5ESS UNIX RTR Reference Manual - Issue 10 (2001)

[Andrew Warkentin]

On Tue, Jun 11, 2024 at 9:41 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>
> What would you suggest?  My main point of reference is years and years of being in the console video game scene, bin/cue is the most accessible of the high fidelity formats I've seen for things, compared with say cdi and mdf/mds.  Does a plain old iso suffice for all relevant data from the media?  Frankly I've never done dumps on a UNIXy computer with an optical drive, only Windows boxen, so can't say I'm hip to the sort of disc image you get doing a dd from an optical /dev entry, maybe I just need to get a UNIX of some kind on my old beater game machine with an optical drive to do these dumps going forward.
>
The vast majority of non-game software was distributed on discs that
were formatted with a single data track and no special formatting.
These can be safely imaged in flat (ISO) format. The main reason to
use the lower-level formats is for discs with disc-based copy
protection or multiple tracks (usually one data track and multiple
audio tracks), both of which are very uncommon for non-game software.
BeOS install CDs are the one exception I can think of; these have an
ISO-format boot track followed by one or two BFS-format system tracks
(separate system tracks are used for x86 and PPC), although even these
aren't actually dependent on multiple tracks and can be run from a CD
with just the system track if a boot floppy is used.

Most dumping programs should be able to show you how the discs are
formatted; if they only have a single track each, ISO format should be
sufficient.

[TUHS] Re: 5ESS UNIX RTR Reference Manual - Issue 10 (2001)

[Wesley Parish]

On 12/06/24 17:43, Andrew Warkentin wrote:
> On Tue, Jun 11, 2024 at 9:41 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>> What would you suggest?  My main point of reference is years and years of being in the console video game scene, bin/cue is the most accessible of the high fidelity formats I've seen for things, compared with say cdi and mdf/mds.  Does a plain old iso suffice for all relevant data from the media?  Frankly I've never done dumps on a UNIXy computer with an optical drive, only Windows boxen, so can't say I'm hip to the sort of disc image you get doing a dd from an optical /dev entry, maybe I just need to get a UNIX of some kind on my old beater game machine with an optical drive to do these dumps going forward.
>>
> The vast majority of non-game software was distributed on discs that
> were formatted with a single data track and no special formatting.
> These can be safely imaged in flat (ISO) format. The main reason to
> use the lower-level formats is for discs with disc-based copy
> protection or multiple tracks (usually one data track and multiple
> audio tracks), both of which are very uncommon for non-game software.
> BeOS install CDs are the one exception I can think of; these have an
> ISO-format boot track followed by one or two BFS-format system tracks
> (separate system tracks are used for x86 and PPC), although even these
> aren't actually dependent on multiple tracks and can be run from a CD
> with just the system track if a boot floppy is used.
>
> Most dumping programs should be able to show you how the discs are
> formatted; if they only have a single track each, ISO format should be
> sufficient.

FWIW, I've successfully dd'ed cds and cd-roms into iso files and burnt 
copies. I've never made use of the bin/cue setup, and wouldn't know how 
to work it.

Wesley Parish

[TUHS] Re: 5ESS UNIX RTR Reference Manual - Issue 10 (2001)

[Ralph Corderoy]

Hi Andrew,

> Most dumping programs should be able to show you how the discs are
> formatted; if they only have a single track each, ISO format should be
> sufficient.

Presumably, it's fairly simple to look at the text-file cue-sheet, if
bin/cue had been used, to see an ISO would have been good enough?
https://en.wikipedia.org/wiki/Cue_sheet_(computing)#Cue_sheet_syntax

And then perhaps there's a command to extract the ISO from the bin/cue
files.

-- 
Cheers, Ralph.

[TUHS] Re: 5ESS UNIX RTR Reference Manual - Issue 10 (2001)

[Arno Griffioen via TUHS]

On Wed, Jun 12, 2024 at 09:12:04AM +0100, Ralph Corderoy wrote:
> And then perhaps there's a command to extract the ISO from the bin/cue
> files.

'bchunk' is one that does exactly that.

Also 'fuseiso' allows mouting a BIN/CUE file/image as a regular filesystem to 
read the files if you just want to use them as-is.

							Bye, Arno.

[TUHS] Re: 5ESS UNIX RTR Reference Manual - Issue 10 (2001)

[segaloco via TUHS]

On Wednesday, June 12th, 2024 at 1:41 AM, Arno Griffioen via TUHS <tuhs@tuhs.org> wrote:

> On Wed, Jun 12, 2024 at 09:12:04AM +0100, Ralph Corderoy wrote:
> 
> > And then perhaps there's a command to extract the ISO from the bin/cue
> > files.
> 
> 
> 'bchunk' is one that does exactly that.
> 
> Also 'fuseiso' allows mouting a BIN/CUE file/image as a regular filesystem to
> read the files if you just want to use them as-is.
> 
> Bye, Arno.

bchunk is likewise my tool of choice for that sort of thing.  I think what I'll go with is the bin/cue for completeness but also a zip of the contents composited together.  Someone who specifically needs the disc image data can probably figure out bchunk and then an archive will be present in a form navigable through archive.org's interface with the composite pieces from each collection (i.e. a merge of the discs for a multi-disc set).  That should hopefully satisfy various needs.

- Matt G.