From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31366 invoked from network); 26 Sep 2023 11:29:05 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 26 Sep 2023 11:29:05 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id B4FF84029B; Tue, 26 Sep 2023 21:28:58 +1000 (AEST) Received: from anduin.eldar.org (anduin.eldar.org [IPv6:2001:470:c620:0:280:c8ff:fef8:70bc]) by minnie.tuhs.org (Postfix) with ESMTPS id 4F8C240299 for ; Tue, 26 Sep 2023 21:28:48 +1000 (AEST) Received: from anduin.eldar.org (IDENT:brad@localhost [127.0.0.1]) by anduin.eldar.org (8.16.1/8.13.8) with ESMTPS id 38QBSJsZ000260 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 26 Sep 2023 07:28:20 -0400 (EDT) Received: (from brad@localhost) by anduin.eldar.org (8.16.1/8.13.8/Submit) id 38QBSJDw004392; Tue, 26 Sep 2023 07:28:19 -0400 (EDT) From: Brad Spencer To: Andrew Hume In-Reply-To: <92D94A5E-AE0F-446D-8C26-C8EF1E672230@humeweb.com> (message from Andrew Hume on Mon, 25 Sep 2023 18:50:52 -0700) Date: Tue, 26 Sep 2023 07:28:19 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (anduin.eldar.org [0.0.0.0]); Tue, 26 Sep 2023 07:28:20 -0400 (EDT) Message-ID-Hash: PF7ZUCWRYDMF7X23Q23RSLCFNGJEKKKM X-Message-ID-Hash: PF7ZUCWRYDMF7X23Q23RSLCFNGJEKKKM X-MailFrom: brad@anduin.eldar.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: segaloco@protonmail.com, tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Known Specimens of Pre-5ESS UNIX Telephone Switching Software? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Andrew Hume writes: > i=E2=80=99m sure there are standing references to all this. but as i reca= ll, > the 5ESS was a more or less local switching system. > > the guts of the long distance network were embedded in the (roughly) 140 = 1ESS=E2=80=99s. they ran > a completely separate (and substantially older) code that supported thing= s like SS7 (signaling code > that was NOT embedded in the voice channel). the 1ESS was a complex piece= of equipment. > > my interaction with this was tangential. throughout the 1980-90s, i had a= tight grip on how > accounting messages were handled within AT&T and wrote some C code that h= andled a > a transition from one level of the standard software to another level. an= d that code ran inside > the 1ESS. > > but this was a long time ago. > >> On Sep 25, 2023, at 6:24 PM, segaloco via TUHS wrote: >>=20 >> Hello, my studies lately bring me to the question: Are there any extant = examples of telephone switching software, built on UNIX, from the various p= arts of the Bell System prior to the introduction of the 5ESS and 3B20D? M= y focus veers earlier as some 5ESS/3B20D/DMERT technology is still in activ= e use, that sleeping dragon can lie. >>=20 >> What's gotten me curious is reading about 1ESS in a BSTJ volume I picked= up, noting the particulars on how previous concerns of manual and electro-= mechanical systems were abstracted into software. Even without surviving e= xamples, were previous systems such as the 1ESS central control ever ported= to or considered for porting to UNIX, or was the hardware interface to the= telco lines too specific to consider a future swap-out with, say, a PDP11 = running arbitrary software? Columbus's SCCS (switching, not source code) a= lso comes to mind, although all I know that survives of that is the CB-UNIX= 2.3 manual descriptions of bits and pieces. >>=20 >> By the way, it's funny, I have UNIX to thank for my current experiments = with telephones and other signalling stuff, what with making me study the B= ell System more generally. It's starting to come full circle in that I wan= t to take a crack at reading dialing, at least pulse, into some sort of sof= tware abstraction on a SBC that can, among other things, provide a switchin= g service on top of a UNIX-like kernel. I don't know what I'd do with such= a thing other than assign work conference call rooms their own phone numbe= rs to dial with a telephone on a serial line...but if I can even get that f= ar I'd call it a success. One less dependency on the mobile... >>=20 >> - Matt G. So... I am speaking from a single point of view about stuff I worked on a very long time ago.... On the operations support system I worked on at AT&T/Lucent... we supported all manor of switches, all of those made by AT&T/Lucent and a whole lot made by other companies. This is what I recall... I believe that the 1A had left the building and no longer existed in any installed base in the US when I started, although we supported it still in our software because of the pain of ripping it out. The 1E did exist in some numbers (I may have these backwards, BTW... it might have been the 1A that existed and the 1E had crossed the rainbow bridge). I do recall that either the 1A or 1E had a lot of features, but it may have been more of a case of it just being around a long time and was infected with warts. The work horses, however, were the 4ESS and the 5ESS. The 4E did the long haul work and was often configured in a tandem set up (that was the term used, Tandem, which meant something specific at the time). The 4E was also a very large monster of a device... taking up pretty much an entire floor of a building. The software in it was very old with lots of add on sub-devices to provide new ability (our product used some of those sub-devices). Those sub-devices might have run their own operating systems and could have been computers all by themselves... that is, there were multiple glued together computers to get the 4E effect. The 5E was a lot cleaner and much smaller. It also had some sub-device stuff going on but nothing like what the 4E had. I do seem to recall that the 5E runs some version of Unix, at least on part of the device, but I don't remember if the main switching engine did, however (I suspect not, BTW). I am almost 100% sure that the 4E did not run Unix on the main switching engine, but it would not surprise me that it found its way into it somewhere or other (probably in multiple places given how large the device was). The 5E and 4E may have started out life with particular roles, but this wasn't very strict. That is it was completely ok for a 5E to do long haul work if so configured and it was very possible for a 4E to terminate a call. There was a great deal of flexibility present. AT&T long wire was a bit of a different place with respect to the 4E.. I seem to remember that at the time I was there they had something like 800 4E configured to do long distance service in the US. At least the traffic management part was managed by a set of Amdauls (using Unix as the operating system I believe) running an operation system product that was very much related to the one I worked on... simular internals for example and in my early days we all sat in the same group. The product I worked on also supported the SS7 switches (I say "switches" here, but that probably isn't exactly what they were. I also don't remember their actual names... STM, maybe??). I worked with the SS7 development group on a new operations system interface and during that conversation they mentioned that the SS7 switch ran a more or less unmodified Unix Solaris (one would assume on a Sparc). They also mentioned that they had performed kernel modifications in the past, but the cost of maintaining that sort of thing was very high, so they had moved away from doing that towards a more "push it to userland" way of thinking. --=20 Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org