Administrations around the world, led by the US federal and the Swedish governments, and the armed forces in both countries, are increasingly demanding Unix as a pre-requisite – but which Unix? The answer, by next year, is almost certain to be Posix. Posix is the name given to the Unix System V variant that is […]
Administrations around the world, led by the US federal and the Swedish governments, and the armed forces in both countries, are increasingly demanding Unix as a pre-requisite – but which Unix? The answer, by next year, is almost certain to be Posix. Posix is the name given to the Unix System V variant that is being hammered into a standard by the US Institution of Electrical and Electronic Engineers, and this week won endorsement from almost anybody who is anyone in the Unix world – and IBM for good measure too (CI No 604). The vote to confirm the Posix 1003.1 definition of Unix as an IEEE standard will be taken in the second half of this year.
This decision was taken at the 1003.1 group’s latest meeting in Atlantic City, New Jersey, where the half dozen outstanding issues relating to the system interface standard were cleared up by making a number of compromises and softening the Posix standard. Unresolved issues remain over the AT&T System V Interface Definition despite the company’s relaxation of the deadline for its implementation. After Posix is made an IEEE standard it will then be passed on to ANSI, the American National Standards Institution, which generally rubber stamps anything presented by the IEEE unless it is very contentious. After ANSI approves the standard, ISO, the International Standards Institution will review it and begin work to make it an international standard. This month ISO and IEEE representatives will be meeting to start this work on the assumption that Posix will become a standard. In order to speed up this standardising process the Posix group and the X3J11 group working on the C language have decided that anything to do with the C programming language will now be dealt with solely by the X3J11 committee, so the two groups held meetings at the same time in the same place in December. Despite complaints that the IEEE Posix 1003 effort has been too slow, the group claims that external events occuring during the second half of last year increased the visibility of the Posix standards efforts and encouraged speed. At the end of August the US National Bureau of Standards published notice in the Federal Register recommending the Posix standard as the basis for a Federal Information Processing Standard. This is a logical step considering the number of US Government procurements that specify Unix. At the same time the United States Technical Advisory Group for ISO agreed to recommend that the Posix effort be used as the basis for ISO work to develop an international standard for an operating system environment based on Unix. The IEEE Posix 1003 committee has three areas of interest which have been separated into sub-committees: 1003.1 deals with standards concerning a system interface; 1003.2 concerns itself with shells and tools; and verification testing is handled by 1003.3. Of the three areas the 1003.1 is the closest to becoming a standard.
Concerning verification testing methods the 1003.3 group will not actually develop the tests but will develop requirements for testing that come out of a study of the 1003.1 work. The 1003.3 group had its first meeting in September 1986 and is also interested in portability of test suites in terms of installation, execution and the reporting of results. At the moment it seems that AT&T is likely to produce test suites and the Combined Services Administration will implement the tests as it did with Cobol. Concerning the 1003.1 trial use standard, the main problems arose where it conflicted with AT&T’s System V Interface Definition. Many of the issues were cleared up at the Palo Alto meeting back in September by recommended changes but about six remained for the Atlantic City meeting to resolve. The differences between the two standards include return value types, error notifications and some areas which the SVID covers and Posix does not and vice versa. AT&T had decided that it was important for operating systems that conformed to the SVID to conform to Posix as well. At the December meeting these discrepancies were resolved by
compromises that tended to weaken the Posix standard. One instance of this is in dealing with read/write system calls. Posix adopts the Berkeley implementation and specifies that if a call is interrupted a record is kept of the number of units read or wrote. The SVID, on the other hand, merely specifies that a message is returned saying that the call was interrupted. From AT&T’s point of view, to adopt the Posix method over this issue would be a disaster as it wants to retain binary compatible code for its 3B family of machines. The resolution on this issue, typical of the compromises made at the meeting, is that the P1003 group would like to have a partial byte count returned but if it does not -1 must be returned, but for an application to be considered truly portable it must accommodate both types of behaviour. Some other potentially contentious issues raised at the meeting were either given to another body or will be dealt with by Special Interest Groups. One of these problems is that a negative offset in a file is defined by Posix as being an error but many applications depend on this facility. This problem will largely be dealt with by relaxing the wording of the specification but non-local gotos will be dealt with by the X3J11 body.
AT&T and Posix will then add anything that they consider necessary to make it more traditional Unix. AT&T wanted a shared memory specification to be included in the standard but this was passed over as it was judged too complicated for this stage in the standard’s life. IBM’s main interest in the standard concerns real-time issues as its version of Unix, AIX, has real-time capabilities so its part on the Special Interest Group concerning inter-process communications is to see that any real-time standard is not dissimilar to its own. Another small group was also set up to deal with numerical limits. Posix currently states that implementors document the limits that are enforced on users: objections were raised to this so the wording of the specification will be changed so that implementors specify a range. Military and Government pressure has been brought to bear concerning a standard for secure systems another special interest group exists to deal with this but the bets are that it will be another couple of years yet before it gets incorporated into the Posix standard.