Webinar examines 3000 sites' plans for 2012
3000 developer job requires no migration

What’s It All About, Posix?

By Brian Edminster

Editor's Note: The origins of HP 3000 Posix go back to 1992, when it arrived as part of MPE. Posix was HP’s first effort at making MPE more standards-friendly. The engineering led to the potential for open source programs such as Samba, Apache and more to make it across the porting divide — and give the systems their first genuine cross-platform tools. The Posix work in MPE made GNU C for the 3000 a possibility, back in the nascent era of the open source movement. Brian Edminster, who's establishing a repository for open source HP 3000 tools, explains what Posix means to the 3000 administrator and owner nearly 20 years later.

It’s really pretty simple. Posix is an attempt to create common ground – to facilitate creating portable software. It consists of file-system, shell, and programmatic interface specifications to the underlying system (Un*x or not!).

Posix standards came about because it was getting more and more difficult to write software portable across the various Un*x flavors – as each vendor created more and more proprietary ‘features’ into their Un*x OS variant. And invariably, the features – usually added in order to give that particular version of Un*x a competitive advantage, made the systems just a little bit more incompatible. This might be by making certain functionality easier to implement on their platform, or to make administration easier, or just to improve performance.

The downside of all this, is that the various Un*x variants were slowly diverging – even though they might well conform the the ‘Unix’ system standard. It was also recognized that it was becoming more and more difficult to create software that is portable accross systems. Something needed to be done, and IEEE came to the rescue.

Rather than enforce complete uniformity accross various Un*x variants, the Posix working group defined a series of what are essentially ‘lowest common denominator’ standards for various parts of a system (file-system, shell, api’s, and so forth) that wished to be labeled Posix Compliant. By using these constructs, it became much easier to write software that is out-of-the-box portable. That is, the software will compile with little or no changes when moved between platforms that have the requisite Posix environment and compilers.

Yes, it was still possible to take advantage of 'platform specific' features, as long as there was a Posix way of doing that as well – or if it was okay not to have full functionality on non-native platforms. This is commonly achieved by use of 'compartmentalizing' platform specific code and/or by using conditional compilation directives. (I'll have more on that in future articles.)

The real boon to Posix, however: it is possible to make software originally developed for the Un*x environment available on any platform with a sufficiently complete Posix environment. Several excellent examples of this are MPE/iX, Mac OS X, z/OS, and some more recent Server editions of Microsoft Windows. There’s even a non-server Posix implementation for desktop editions of Windows called Cygwin – that makes much Un*x style portable software available for desktops as well.

So what does all of this buy? In effect, a very large pool of software that might be usable to solve problems that might have been prohibitively expensive to address via the traditional route of proprietary and/or custom developed software.

More importantly – since Posix was added to MPE (that is – when MPE/XL became MPE/iX), it too received the same benefits of improved portability and broader base of developers that other Posix systems enjoy. Porting efforts to bring open source software to the 3000 have come from both individuals (i.e. The GNU GCC Toolchain – bringing both C and C++ and related development tools to MPE/iX, plus: BIND, PostgreSQL, Perl, OpenSSH, and a broad host of smaller tools and utilities) as well as efforts from inside HP (Apache/iX, OpenSSL, Samba/iX, and SendMail – all of which became part of the FOS and/or available via patches).

The Posix filesystem was even used to enhance the TurboIMAGE/XL database system to allow ‘Jumbo’ datasets, spawning TurboIMAGE/iX. By allowing the ‘container’ files that carry datasets contents to be broken into file ‘chunks’ that exist in the Posix filespace – capacities far beyond what the ‘native’ filesystem could accomodate are now possible.

A secondary benefit is that most portable software is written to industry standards, using tools common across platforms. In short, it potentially makes it much easier for your MPE/iX based system to ‘play nice’ with other systems. By using this type of software, your systems will be more likely able to ‘inter-operate’ with the rest of your enterprise, and the world at large. By now having tools available that are common to the Un*x space (various shells, plus a plethora of command-line tools, utilities, and scripting languages), it’s easier to find fresh technical talent to assist with development and system administration tasks.

So, there are some interesting quirks that a Un*x admin or developer will need to know how to deal with when working on a MPE/iX system – but we’ll cover some of those, as well as some useful tips and tricks to make the best of both the MPE and Posix worlds, in later articles.