Editing 5ESS Switching System (section)

== Software ==
{{unreferenced section|date=April 2025}}

The development effort for 5ESS required five thousand employees, producing 100 million lines of system source code, mostly in the [[C (programming language)|C language]], with 100 million lines of [[header files]] and [[makefile]]s. Evolution of the system took place over 20 years, while three releases were often being developed simultaneously, each taking about three years to complete. The 5ESS was originally U.S.-only and the international sales resulted in a complete development system and team, in parallel to the U.S. version.

The development systems were Unix-based mainframe systems. There were around 15 of these systems active at the peak. There were development machines, simulator machines, and build machines, etc.  Developers' desktops were multi-window terminals (versions of the [[Blit (computer terminal)|Blit]] developed by [[Bell Labs]]) until the mid 1990s, when [[SUN workstation|Sun workstations]] were deployed.  Developers continued to login into the servers for their work, using [[X Window System|X11]] on their workstations as a multi-window environment.

Source code management was based on [[Source Code Control System|SCCS]] and utilized "#feature" lines to separate source code between releases, between features specific to US or Intl, and the like. Customisation around the [[Vi (text editor)|vi]] and [[Emacs]] text editors allowed developers to work with the appropriate view of a file, hiding the parts that were not applicable to their current project.

The change request system used the SCCS MR to create named change sets, tied into the IMR (initial modification request) system which had purely numeric identifiers.  An MR name was created with subsystem prefix, IMR number, MR sequence characters, and a character for the release or "load".  So, for the gr (generic retrofit) subsystem, the first MR created for the 2371242 IMR, destined for the 'F' load, would be gr2371242aF.

The build system used a simple mechanism of build configuration that would cause makefile generation to occur.  The system always built everything, but used checksum results to decide if a file had actually changed, before updating the build output directory tree.  This provided a huge reduction in build time when a core library or header was being edited.  A developer could add values to an enum, but if that did not change the build output, then subsequent dependencies on that output would not have to be relinked or libraries built.