Leaving out a >>lot<< of detail, but under ASA was their directive: the Accredited Standards Committee X3
This means that the US government, particularly the US War Department (late DoD), would accept their recommendations. However, a published set of rules for how standards would be created, agreed upon, etc., for the USA became established.
One of their early roles was creating standards for the computer industry, such as what would become ASCII, a.k.a., ASA X3.4-1963, and ASA X3/INCITS 40-1966 - 9-track mag tape.
One of the things the folks at X3 had started working on we standards that allowed program interchange between different manufacturers, although allowing manufacturers to be independent and add their own features but keep a core that a programmer could rely upon. So, their purvey included creating standards for FORTRAN, Algol, Cobol, and later C. They also developed test suites for many of their standards and offered services to firms like computer manufacturers to certify that their products meet the standard. Thus, a program that worked when compiled under different manufacturer compilers could be written.
Note that AIEE/IEEE was a founding member of ASA, but it eventually became an accredited standards body independent of ASA/ANSI. The subtle difference was the idea of "sameness," which said this is functionally the same as something else made by two different electrical manufacturers and, as a result, could interoperate between them. This was important to the US DoD because they wanted more than one place to get similar products, at least ones that could play well together. So, they became where things like networking, power, etc., were defined and agreed upon. Of note, independent of IEEE, we were testing groups, but if you made an error, it was basically self-correcting -- people stopped using your product when it was discovered you could not handle back-back ethernet packets at full speed.
So what happened...
We graduated a bunch of young engineers of my generation who know C and UNIX. AT&T has made the sources to both technologies "open" and freely available (libre as opposed to beer). We take the knowledge with us, and they both start to be cloned. Since the microprocessor came in vogue around the same time, retargeting the C compiler at many places like Universities made sense - I did it (poorly) for the Dennis' compiler for what would become the 68000 @Tektronix in the summer of 1979. But if you look at the USENIX tapes from those times, you will see many different developer tools for those processors. However, since the AT&T tools were licensed, several implementations grew that were mostly, if not 100%, clean of any AT&T's IP.
Since there was no standard for the language itself, and the processors were not PDP-11, many differences crept into the different compiler implementations. The biggest was support for the x86 and target platforms such as CP/M and DOS, which did not store files in the same format as UNIX and differentiated between text files and binaries like earlier 12/18/36-bit systems from DEC had.
In the early 1980s, a group of compiler firms, originally from the PC business, applied to set up and create the ANSI X3.159 committee. [Thank the Lord, Dennis agreed to join it too, as he could rein in several of the worst proposals like near/far pointers, although the terrible text file support leaked]. It was a very slow process since a standard did not come about a vote until 1989 and was agreed upon until 1990.
Meanwhile, in UNIX land there, USENIX had started [see my paper: C.T. Cole, UNIX: A View from the Field as We Played the Game, October 19, 2017, Le CNam – Laboratoire, Paris France], but that was primarily an academic organization. Firms like manufacturers DEC, HP, Tektronix, and IBM, as well as ISVs such as Heinz's Interactive System Corporation and Microsoft, needed an organization that focused more on their needs as commercial ventures. /usr/group (which was later re-branded as Uniforum) was created. For many reasons (many of which have been discussed here), the manufacturer's versions of UNIX had begun to differ. But they had a common language C, since many, if not most, used AT&T licensed C compilers, the compilers' input syntax was already mostly common, but one of the things that this group realized was it was still "work" for an ISV to move their UNIX based application between systems and they needed something more than just a language standard.
To address this need /usr/group, formed a standard committee under Heinz's leadership. In 1985, we published the first UNIX standard. One of the members of the group, Jim Issak, who then was from another small manufacturer building a system with a UNIX-like OS, Charles River Data Systems (CRDS - BTW: pronounce that and smile -- marketing people are wonderful), realized that a /usr/group created standard was helpful to us in the USA marketplace since /usr/group was not accredited and thus our work would not be useful to be sent to the US Gov much less and alter International standards body such as ECMA or ISO.
BTW: since our OS's were already getting different beyond the system call layer, we decided to start with just the system call API which was mostly common, plus agree to an interface standard to exchange magnetic media. But this is where things like the file <unistd.h> come from to help make the differences contained in a manner that a recompile allowed code to move from one vendor's system to another.
By the early 1980 my former colleague, Maurice Graubie from Tektronix, had been the chair of the IEEE 802 committee, which had published its set of standards. BTW the number.X stuff raised huge hackles at IEEE at the time. It had never been done. Maurice had come up with solution as a way to keep the 801 standard together when it was beginning to diverge and fall apart with the Ethernet folks on one side and the IBM token ring folks on the other.
Since the OS was similar to other electrical standards, allowing one manufacturer to build something the US government buys and knowing they could get something similar from someone else, Maurice introduced Jim to the folks at IEEE. Jim succeeded in putting together all of the paperwork, getting the proper sponsorship from IEEE institutional members, and forming a committee to create IEEE Proposal 1003.
As the next /usr/group meeting approached, we were already starting to work on a revision. Jim explained the formal IEEE process. We officially voted to disband that meeting and reconvene as IEEE P1003, where Heinz graciously handed the gavel to Jim. It also set us back a bit because the /usr/group document was not in a form that IEEE could accept. So the first task was the rewrite (and use their voting process) to have it accepted. But because of Maurice's great compromise for the 802 committee, we started by saying this would be the first of N standards, i.e., 1003.1 for the system calls, and we would (like 802) create later standards for things like the commands. I know that both Maurice and Jim had a little pushback by IEEE NYC, but I am thankful that a good idea prevailed.
It's possible ANSI might able to do the same thing that IEEE did. But the difference is that members of the/usr/group were all institutional members of IEEE, and the style of things we needed to do at the time was really the sort of thing IEEE was already accustomed to doing. As for the language, since ASA/ANSI was already doing things there - that made sense.
BTW: it has been observed that IEEE is behind VHDL - which is a hardware description language. But against this more in their world -- it pushed to silicon manufacturers, so you know IP can be moved between different fabs. We can argue that it's a language, and ANSI would have been a good place for it.