agq@itd1.dsto.oz (Ashley Quick) (01/08/91)
Here are some questions about Apollo and OSF/1.
These questions are directed at HP and also Mentor Graphics. I would
appreciate it if representatives from both organisations could either
post responses or mail me, so I can post a summary.
OSF/1 - Mentor Application Support
----------------------------------
The organisation I work for has about 60 (and always increasing)
Apollo nodes. About 30-40 of these are DN3000's / 3010's. Some of
these are being upgraded under the recent discount upgrade plan, but
not all. In fact, we do not anticipate upgrading ALL of the nodes.
We would like to continue to run Mentor Applications, such as Neted,
QuickSim, etc and also the Context tools DOC, PicEd, etc.
Will Mentor continue to support their products on the old platforms
under DOMAIN/OS for the forseeable future?
Will Mentor permit interoperability / data exchange between platforms
which run DOMAIN/OS and those which run OSF/1?
DOMAIN/OS and the OSF/1 DCE
---------------------------
All sorts of stories abound about which Apollo platforms will or will
not be able to run OSF/1.
There is also a supposed commitment by HP/Apollo to continue the
support and development of DOMAIN/OS, through a release SR11 and
beyond. I have heard that SR11 will be the last ever release of
DOMAIN/OS. I have also heard that an SR12 will follow, etc.
Just which platforms will be supported for running OSF/1?
What is HPs future direction for DOMAIN/OS ? Will it continue to be
supported and developed?
I have heard that SR11 will bring compatibility with the OSF/1 DCE
(Distributed Computing Environment). Will this mean that DOMAIN/OS
nodes and OSF nodes can:
- exchange files (ie file system compatibility)
- create processes (similar to "crp")
- interchange information using NCS
What level of compatibility will be provided between the DOMAIN/OS
user environment and OSF/1? Will it be OSF/Motif/HP-VUE and goodbye
to the Display Manager?
Will OSF/1 on an HP/Apollo series 900 support the token ring adaptor?
Just what will be LOST from DOMAIN/OS facilities now available when
the OSF DCE bits are added under SR11?
At present under DOMAIN/OS, we can do things like "pst -n //fred"
and the interrogation is handled by magic in the kernel of the other
node. No special process or configuration is needed. Is this kind of
facility available in OSF/1 also?
OSF/1 system software and programming
-------------------------------------
As some people are aware, DOMAIN/OS provides a rich set of system
services to programmers. It provides BSD 4.3 and SYS5.3, as well as
the DOMAIN/OS calls.
The DOMAIN/OS calls are divided up into "managed" parts, such as the
event count manager, the mailbox manager, the process manager, etc.
Does the kernel of OSF/1 have the same sort of concept? Are the
calls available? Is the system divided into a set of logical
groupings rather than the cryptic mess of UNIX? (or as well as?)
I know that OSF/1 is based on the "Mach" kernel. This does not help me
at all, as I do not know what kind of services are available from
Mach. Can these be described? Can you recommend a good reference
book?
Does the OSF/1 operating system support some of the more elegant
DOMAIN/OS concepts such as:
- event counts (does UNIX support these?)
- multiple threads in a single process
- mailboxes for single server, multiple client data transfer
- user space loadable device drivers (rather than in
UNIX where devices must be added by changing the kernel)
- the system library concept (where librarys can be added
and then become "known" through the Known Global Table)
If OSF/1 provides services not available under BSD4.3 or SYS5.3, will
those services be available as part of the DOMAIN/OS DCE in SR11?
The OSF/1 File System
---------------------
There has been the odd word or two that OSF/1 will use "The Andrew
File System". What is this and what is the implication????
I believe that AFS does not use the Apollo type concept of the
network root (//), but that nodes are referred to through some kind
of black box magic directory (/AFS on each node). Is this so?
If so WHY????? [What about all of the things like the IBM PC network,
all of the other microsoft stuff which refers to \\machine_name or
similar - seems a sensible convention to me and it implies the
hierarchy]. By that way, the // convention IS posix compliant - 'cos
somebody posted the posix rules to the net about 6-8 months ago.
Is the OSF/1 file system typed? Can new type managers be added, as in
DOMAIN/OS? If not, why was the decision made not to use the typed
file system. [After all - DOMAIN/OS is pretty close to a genuine
object oriented operating system - which things like HP Open
Whatchermacallit on the PC is supposed to be just getting close to!]
All of these questions may take a bit of answering - but they
will help to set my mind at rest, as well as many other people.
Remember: customers are VERY IMPORTANT! Without them, you would not
be in business - we need information to be able to make informed
purchase decisions in future. Futhermore, we are not all smiles and
happy when we buy equipment and are then told that our very expensive
investment is WORTHLESS because it will not be supported as from
Thursday lunch-time.
Thanks in advance
Ashleigh Quick
AGQ@dstos3.dsto.oz.au
Ashleigh Quick | ACSnet: AGQ@dstos3.dsto.oz
Defence Science and Technology Organisation| Internet: AGQ@dstos3.dsto.oz.au
PO Box 1600 | Phone: (Intl) (+61 8) 259 6975
Salisbury 5108 AUSTRALIA | (Local) (08) 259 6975odonnell@apollo.HP.COM (Rose O'Donnell) (01/15/91)
> > DOMAIN/OS and the OSF/1 DCE > --------------------------- > > All sorts of stories abound about which Apollo platforms will or will > not be able to run OSF/1. > > There is also a supposed commitment by HP/Apollo to continue the > support and development of DOMAIN/OS, through a release SR11 and > beyond. I have heard that SR11 will be the last ever release of > DOMAIN/OS. I have also heard that an SR12 will follow, etc. There are no plans that SR11 will be the last release of DOMAIN/OS (or that any specific one will be) nor does that make any sense. The needs of the customer base will determine the level of support that HP gives to Domain; HP does recognize the value of supporting existing customers and maintaining their investments in HP. We do expect of course that over time, interest in Domain will wane as OSF/1, DCE and other technologies provide a more standard implementation of the Domain functionality. But that time is not yet and we do understand that! > > Just which platforms will be supported for running OSF/1? HP-PA platforms, 900 series 68k systems and DN5500 machines are currently scheduled for OSF/1 ports. Eventually, of course, ALL HP unix-based products will offer OSF/1, since OSF/1 is the strategic OS for HP. > What is HPs future direction for DOMAIN/OS ? Will it continue to be > supported and developed? Yes. See above. > > I have heard that SR11 will bring compatibility with the OSF/1 DCE > (Distributed Computing Environment). Will this mean that DOMAIN/OS > nodes and OSF nodes can: DCE on Domain is planned as soon as possible to provide maximum interoperability to Domain users. Whether or not it's SR11 depends as much on the Open Software Foundation and when they release it, as on our ability to port it quickly. > - exchange files (ie file system compatibility) Depends on the files. OSF/1 doesn't support/recognize typed files, but will certainly exchange ascii files; HP-OSF/1 will not execute Domain binaries (no _$ calls on HP-OSF/1). > - create processes (similar to "crp") OSF/1 and Domain/OS both support rlogin and rsh. We have no plans to add crp semantics to HP-OSF/1 (not standard, and 'better isn't better, the standard is better' - that's the big lesson of Apollo, right?)... > - interchange information using NCS Yes, of course. > > What level of compatibility will be provided between the DOMAIN/OS > user environment and OSF/1? Will it be OSF/Motif/HP-VUE and goodbye > to the Display Manager? It will be Motif/HP-VUE. We are looking at providing some DM (or DM-like) features to HP-OSF/1 to make the transition easier (support old habits), but we haven't picked the set yet and we are definitely not porting the DM to OSF/1 in anything like it's totality (too big an investment for the payback, not 'standard', etc.). > > Will OSF/1 on an HP/Apollo series 900 support the token ring adaptor? Yes. > > Just what will be LOST from DOMAIN/OS facilities now available when > the OSF DCE bits are added under SR11? We can think of NO Domain/OS features that have to be sacrificed to add DCE to Domain (they sit side-by-side). There are some inherent incompatibilities (acls comes most easily to mind, but then, OSF/1's acls are currently not the same as DCE's acls, and POSIX acls are something else again still), but we do not expect to have to introduce any serious compatibility problems when we put DCE on Domain. We won't put ALL of DCE on Domain (it is multi-faceted); Episode file system is the most obvious example; also, all the servers (as opposed to the clients) might not need to run on Domain in a heterogeneous environment. We will, however, ensure that Domain/OS systems play cleanly and well in a DCE environment. > At present under DOMAIN/OS, we can do things like "pst -n //fred" > and the interrogation is handled by magic in the kernel of the other > node. No special process or configuration is needed. Is this kind of > facility available in OSF/1 also? sigh. These features are embodied in the Domain kernel and are Domain-based protocols. No equivalences exist in OSF/1 and we have no plans to add them (not standard). As you can divine, we deem it very important to be seen as not adding proprietary features; if something can't be made to work on all vendors' versions of OSF/1, we have to think real hard before offering it on our version. Of course one could build an NCS-based client/server set that would implement pst-like functionality (without kernel mods); but we have no plans to do that at this point... > > OSF/1 system software and programming > ------------------------------------- > > As some people are aware, DOMAIN/OS provides a rich set of system > services to programmers. It provides BSD 4.3 and SYS5.3, as well as > the DOMAIN/OS calls. > > The DOMAIN/OS calls are divided up into "managed" parts, such as the > event count manager, the mailbox manager, the process manager, etc. > > Does the kernel of OSF/1 have the same sort of concept? Are the > calls available? Is the system divided into a set of logical > groupings rather than the cryptic mess of UNIX? (or as well as?) Well, you should read the OSF/1 AES and decide for yourself. Most of those calls are standard Unix (POSIX/XPG3) calls. However, OSF/1 does contain sets of manager-based interfaces (e.g. threads and the loader), which are not yet part of the AES (guaranteed, stable calls). It is certainly a direction for OSF/1 (no '$'s though!). > > I know that OSF/1 is based on the "Mach" kernel. This does not help me > at all, as I do not know what kind of services are available from > Mach. Can these be described? Can you recommend a good reference > book? Mach is a message-based kernel that provides a number of new services. None of the interfaces to these services are in the OSF/AES yet, nor is it clear when they will be (they are available though and presumably might be used by 'early adopters'). Some OSF facilities such as P1003.4a pthreads do, however, use the underlying Mach services. The text of a book, "The Design of the Mach Operating System", Bitar, Shienbrood and Langerman will be available from Prentice-Hall sometime this year. In the meantime, you can refer to numerous articles in the USENIX proceedings from the past three years. > > Does the OSF/1 operating system support some of the more elegant > DOMAIN/OS concepts such as: > - event counts (does UNIX support these?) Event counts are a form of synchronization. OSF/1 provides similar functionality using different synchronization paradignms. > - multiple threads in a single process Yes, and fully supported in the kernel also (something Domain doesn't support yet, but will at sr11). > - mailboxes for single server, multiple client data transfer No mailboxes, but NCS-based client-server support. > - user space loadable device drivers (rather than in > UNIX where devices must be added by changing the kernel) No, but OSF/1 does support dynamically-loaded device drivers in the kernel, so you get the same effect. For developers, it's not as easy to create/debug drivers, but it's just as convenient for users, since you don't have to rebuild/shutdown to load a driver. Also, streams modules, internet protocol modules and filesystems can be dynamically loaded in OSF/1 and the design is extensible to support dynamic loading of other kernel modules in the future... > - the system library concept (where librarys can be added > and then become "known" through the Known Global Table) The shared library implementation on OSF/1 is amazingly similar to the Domain one (designed by Domain-conversant engineers). It has both public and private known-global capabilities, in a hierarchical override order. > > If OSF/1 provides services not available under BSD4.3 or SYS5.3, will > those services be available as part of the DOMAIN/OS DCE in SR11? hmmmm. We have no plans to put certain OSF/1 features back into Domain (like the MACH interfaces). The DCE services are distinct from OSF/1 services (for the most part, DCE is layered on the base system...). Domain will have pthreads and a kernel threads interface very similar to Mach's in sr11. > > > The OSF/1 File System > --------------------- > > There has been the odd word or two that OSF/1 will use "The Andrew > File System". What is this and what is the implication???? The Andrew File System is a networked file system, very similar to the Domain Network File system, tho not exactly the same. Big advantage is that Andrew works over wide-area nets (and OF COURSE it will be everywhere, not just on Domain!). Of course, Andrew is not strictly part of OSF/1 but part of the DCE. > > I believe that AFS does not use the Apollo type concept of the > network root (//), but that nodes are referred to through some kind > of black box magic directory (/AFS on each node). Is this so? > If so WHY????? [What about all of the things like the IBM PC network, > all of the other microsoft stuff which refers to \\machine_name or > similar - seems a sensible convention to me and it implies the > hierarchy]. By that way, the // convention IS posix compliant - 'cos > somebody posted the posix rules to the net about 6-8 months ago. Correct, but Posix only allows '//', it certainly doesn't encourage it, nor is it about to be adopted by other Unix vendors. DCE (of which Andrew is part) contains its own naming services and conventions. It DOES support the concept of a 'global' root; and in fact DCE naming services are more comprehensive (and heterogeneous) than Domain naming (which is supported only by Domain systems). You can get papers from OSF. Also, note that Domain uses a peer-to-peer model where all machines are equal players in the file system. AFS has distinct clients and servers. While it is conceivable that you could set up every machine to be a server under DCE, this is not currently practical, both from cost and administrative standpoints. > > Is the OSF/1 file system typed? Can new type managers be added, as in > DOMAIN/OS? If not, why was the decision made not to use the typed > file system. [After all - DOMAIN/OS is pretty close to a genuine > object oriented operating system - which things like HP Open > Whatchermacallit on the PC is supposed to be just getting close to!] No, OSF/1 does not support typed files. Neither does DCE. I think this is something we have to get to, but it is NOT something that one vendor is likely to implement unilaterally (else it would be proprietary, not interoperate and we would be right back where we are now, with features that are not portable). However, I firmly believe that over time we (that's the greater industry 'we', as well as HP) will regain in OSF/1 some of the advanced (tho not new) features of Domain, typed file systems being the most important I think (since the Andrew File System has taken care of the functionality of the Domain Network File system). > > All of these questions may take a bit of answering - but they > will help to set my mind at rest, as well as many other people. Hope this helps. All answers are NOT commitments made by HP in any legal sense (I feel the need to say that!), tho they do reflect what we are doing. > > Remember: customers are VERY IMPORTANT! Without them, you would not > be in business - we need information to be able to make informed > purchase decisions in future. Futhermore, we are not all smiles and > happy when we buy equipment and are then told that our very expensive > investment is WORTHLESS because it will not be supported as from > Thursday lunch-time. Understood. And in fact, very well. Actually ADUS helped HP remember that, so we (techies) are grateful! Rose ODonnell odonnell@apollo.hp.com HP Apollo Systems Division