comp.software-eng archive file "blurb/PCTE-ATIS-CAIS" last changed 31 Jul 1993 This file contains information on the following subjects. Numbers in column 1 count distinct messages with the corresponding subject. 1 ATIS Background 3 ATIS Overview (long) 1 ATIS+PCTE+BMS (long) 1 ATIS, PCTE 1 ECMA-162 Draft 9 Issue 1 (PCTE Ada binding) available for anonymous FTP 1 PCTE 1 PCTE History 5 PCTE and ATIS 14 PCTE vs. CAIS-A 2 PCTE/ATIS 1 summary of replies : PCTE and ATIS implementations ------------------------------------------------------------------------ From: gwharvey@lescsse.jsc.nasa.gov (Greg Harvey) Subject: Re: PCTE vs. CAIS-A Date: 4 Nov 91 15:33:52 GMT Organization: Lockheed Engineering and Sciences In <9110301738.AA08190@cnam.cnam.fr> bortz@CNAM.CNAM.FR writes: >I would like to know the main services PCTE offers that : > - CAIS-A > - ATIS >don't offer. >And what the two later offer that PCTE doesn't. I'll kick this off with what little understanding I have (A VERY little.) CAIS was developed in response to the STONEMAN (MIL-STD-1838A) specs for an Ada Programming Support Environment (APSE.) If I recall correctly, Softech did the work on that environment very early, and then the contract to do CAIS-A was awarded to Softech by NOSC in 1985. Softech characterizes CAIS as a KAPSE (Kernel APSE) which provides ``advanced object management system supllemented with operating system services.'' The goals of the CAIS-A work were: produce an upwardly compatible CAIS revision, support distrubuted environments, provide strong typing of database objects, allow secure implementation to be built, and support transations. Softech has also been involved in the attempt to merge CAIS-A and PCTE/PCTE+. This effort is the PCIS (Portable Common Interface Set Programme.) The last I heard out of either ECMA or PCTE people is that PCTE+ had won out with no changes. This was followed by announcements by HP and DEC indicating they would be supporting the PCTE standard in future products. ATIS (Atherton Tool Interface Spec?) is Atherton's specs for data exchange through it's backplane if I recall. Another very interesting technology to pitch in here is the Message Broker Server, the core technology for HP Softbench and Sun ToolTalk. This technology was developed at Brown University (I've been told.) Supposedly another revision is under way at Brown, which MIGHT be included on a certain three-letter machine in the not so distant future. Atherton pitched the MBS as being complementary to their ATIS and to PCTE. They felt that all three technology sets would work together to make a nice system. Sorry, but I'm short on more specifics... at least this is a start. From: anderson@bigun.enet.dec.com (Keith J. Anderson) Subject: Re: PCTE vs. CAIS-A Summary: ATIS and OMG ORB Date: 5 Nov 91 21:22:48 GMT Organization: Digital Equipment Corporation (Australia) In article , gwharvey@lescsse.jsc.nasa.gov (Greg Harvey) writes... >ATIS (Atherton Tool Interface Spec?) is Atherton's specs for >data exchange through it's backplane if I recall. I understand that ATIS was written as a result of some joint work that Digital and Atherton did on backplane integration technologies. One of the ideas was to remove UNIX and C dependencies, generalise some areas a bit more, so that the design could support the concepts of CASE tools as well as traditional Information Systems style thinking : to support use of multiple tools and varied data entities that are conceptually related (data-flow diagrams, documents, source files, object files, tests, tasks). I was told Atherton's current product had no direct relationship to the ATIS work. Rumour says that at the time that ATIS was proposed to ANSI IRDS, it was realised that the document could not be named after a company, so ATIS was changed to A Tools Integration Standard. ATIS was accepted as a working draft for repository-style technology at one level of ANSI IRDS and is still evolving there. It has also been proposed to the CASE Integration Standard body. Digital has based its CDD/Repository V5.0 repository product on the ATIS work. ATIS is based on several "models": an object-oriented model (encapsulation, inheritance, typing, messages, methods, attributes), versioning model (for those objects that are descended from a versioned type, which is most; variant and merge support), configuration management model (collections, versioning, reserve, replace, partition control model (promotion, context, partition : implement the software process in the ATIS repository), tools integration model (extensible, invocation methods, store data, messaging, version control). ATIS provides a level of *data* integration : you can track changes to product, tools, and other objects over time, and you model your software lifecycle in there. ATIS provides basic "hooks" for invoking tools and other applications : hence an ATIS-compliant repository could invoke tools. Of course, not everyone wants/needs a repository-based environment, and it is hard to do well. >Another very interesting technology to pitch in here is the >Message Broker Server .... We call this *control* or dynamic integration. Our DEC FUSE CASE tool product set is based on a late version of the Brown Uni technology. The ability for a tool to communicate with another tool is great for a lot of CASE environments. In the large scale or complex environments that need repository, you still want this tool to tool communication too. ATIS provides the basics for that by realising that tools have invocation methods, plus realising that in lots of environments you want the data integration and control. The real interesting work going on here is with the Object Management Group, which have just done Request Broker technology. Imagine generalising (greatly) the message broker server idea to being network wide object request broker services : that is what OMG did. The final technology for V1.0 of ORB is based on a joint merger of (a) the Digital/HyperDesk proposal, (b) the joint SUN/HP proposal. Digital's proposal was based on our Application Control Architecture Services product, of which V2.0 is shipping, and which our ATIS-compliant repository can use for tool integration. From: gt@hpfcbig.SDE.HP.COM (George Tatge) Subject: Re: PCTE vs. CAIS-A Date: 5 Nov 91 17:41:20 GMT Organization: HP SESD, Fort Collins, CO Technically speaking, there isn't a world of difference between CAIS/A and ECMA PCTE. There is, however, a world of difference in terms of support and likely usage. It seems very clear that ECMA PCTE will be the open Unix repository standard. It has been endorsed as the data repository portion of integration frameworks by HP, IBM, DEC, BULL, and a host of users. IBM and HP made a joint announcement at Unix Expo last week to the effect that they will both be using ECMA PCTE in their CASE Frameworks. From: mcgregor@hemlock.Atherton.COM (Scott McGregor) Subject: Re: PCTE vs. CAIS-A Date: 7 Nov 91 18:46:59 GMT Organization: Atherton Technology -- Sunnyvale, CA Some minor corrections to article <1991Nov5.055816.18175@ryn.mro4.dec.com>, where anderson@bigun.enet.dec.com (Keith J. Anderson) writes: > I was told Atherton's current product had no direct relationship to the ATIS > work. Kieth was misinformed, Atherton's current product remains based upon the ATIS standard. Those with further interest in Atherton's products' relationships with various standards may wish to contact Atherton's principal architect and representative to various standards committees, Eric Black (ericb@atherton.com). > Rumour says that at the time that ATIS was proposed to ANSI IRDS, it was > realised that the document could not be named after a company, so ATIS was > changed to A Tools Integration Standard. The history in the rumor isn't all quite right, but the name is correct: ATIS = A Tool Integration Standard. With reference to PCTE, Atherton is a member of the Thomson Information Technology Group, which also includes Syseca, and Emeraude from which the commercial version of PCTE originates. For more on what cooperation or interoperability is possible between current and future PCTE and ATIS offerings, I would again encourage you to contact Eric Black for details. European customers may wish to contract our European Sales Manager, Giorgio Vanzini, Wiessenstrass 10 a, 8952 Schilieren-Zurich CH, Switzerland). Also of possible interest may be the announcement that the framework adopted for use in the European Space Shuttle Columbus project (subcontractor is CRI) is based upon ATIS (currently using Atherton's Software BackPlane). CRI's implementation is currently being demonstrated around the US. Other points about ATIS and Atherton's views of the complementary nature of broadcast message services appear to be correct as they appeared in the previous articles. Presumably the other information provided by Keith about DEC's products should be regarded as authoratative. From: mcgregor@hemlock.Atherton.COM (Scott McGregor) Subject: Re: PCTE vs. CAIS-A Date: 9 Nov 91 03:11:40 GMT Organization: Atherton Technology -- Sunnyvale, CA In article <440014@hpfcbig.SDE.HP.COM>, gt@hpfcbig.SDE.HP.COM (George Tatge) writes: > It seems very clear that ECMA PCTE will be the open Unix repository standard. I wonder if it may be a little premature to be counting chickens that haven't hatched yet. I can understand the enthusiasm, but I also remember that lots of vendors were on the OS/2 bandwagon when it was just a promise, but the original ground swell of promised support didn't materialize when OS/2 finally shipped. In the end, the unforecasted introduction and success of MS-Windows 3.0, changed the playing field in ways that weren't predicted earlier. These statements by system vendors are all well meaning, but the future is always full of surprises. I wish the best of luck to the ECMA PCTE developers, but it is perhaps prudent to temper our enthusiasm until the paper standard becomes an ubiquitous *in use* standard. The good news is that at least there are alternatives in the meantime. The PCTE implementation available today (PCTE V12 from Emeraude--if you can get it for your platform) isn't the same as the ECMA PCTE specification. So far, the only framework product that I am aware of based on PCTE V12 is Syseca's Enterprise 2. The last I heard, ECMA PCTE remains a specification standard, without any running, available commercial reference version in code yet. I would appreciate a posting by anyone who can give an update on how things are proceeding with respect to implementation, and when, and from where, the first executable version is expected. > It has been endorsed as the data repository portion of integration frameworks > by HP, IBM, DEC, BULL, and a host of users. Again, it may be just a tad premature to say "the" data repository, for now it is probably best to say they have endorsed ECMA PCTE as "a" repository solution. At least today DEC and IBM endorse and support other repository solutions as well; they have to endorse solutions which are available today: at Tri-Ada, DEC was demonstrating Cohesion, their ATIS-based solution, and IBM *sells* both AD/Cycle and the Atherton Software BackPlane (also ATIS-based) repository solutions. Of course there are also numerous repositories available today from other independent software vendors as well. In the end, the only standards that will matter will be those you can buy, and with so many players there is plenty of room for a surprise commercial offering that becomes a de facto *in use* standard, eclipsing ECMA PCTE and other proposed standards. On the other hand, if ECMA PCTE gets into wide spread use, cementing its standard position, that's great too. > IBM and HP made a joint announcement at Unix Expo last week to the effect > that they will both be using ECMA PCTE in their CASE Frameworks. Does anyone know if IBM or HP has committed to any committed dates for availability of their ECMA PCTE solutions? Have they announced who will do the development and ports of their PCTE solutions? If you know, please post! Scott McGregor From: pav@otter.hpl.hp.com (Paul Vickers) Subject: Re: PCTE vs. CAIS-A Date: 11 Nov 91 10:23:21 GMT Organization: Hewlett-Packard Laboratories, Bristol, UK. In article <40901@athertn.Atherton.COM>, mcgregor@hemlock.Atherton.COM (Scott McGregor) writes: > The PCTE implementation available today (PCTE V12 from Emeraude--if you > can get it for your platform) isn't the same as the ECMA PCTE > specification. So far, the only framework product that I am aware of > based on PCTE V12 is Syseca's Enterprise 2. Emeraude v12 is available on IBM, HP, DEC, Sun and Bull platforms. Emeraude v12 implements PCTE 1.5, the precursor of ECMA PCTE, plus some additional services. The additional metabase and versioning services are compatible with those introduced in ECMA PCTE. My guess is that Emeraude will incrementally add other ECMA PCTE services. SFGL have a framework and environment product, EAST, built on PCTE v12. Two other companies, Verilog and Heuristix, recently announced they are developing PCTE implementations. In my opinion, environment users will *not* be concerned about the technical differences between PCTE 1.5 and ECMA PCTE. Environment builders and tool builders may want to plan for evolution towards ECMA PCTE, and the best way to do that would be to gain experience with PCTE 1.5. From: tking@src.honeywell.com (Tim King) Subject: Re: PCTE vs. CAIS-A Date: 11 Nov 91 23:37:18 GMT Organization: Honeywell Systems & Research Center In article <40814@athertn.Atherton.COM> mcgregor@hemlock.Atherton.COM (Scott McGregor) writes: SM> Kieth was misinformed, Atherton's current product remains based upon the SM> ATIS standard. Those with further interest in Atherton's products' SM> relationships with various standards may wish to contact Atherton's SM> principal architect and representative to various standards committees, SM> Eric Black (ericb@atherton.com). Could either you or Eric provide some more details on Atherton's relationship to ATIS? From previous discussions with Atherton personnel, etc, it is my impression that the Atherton Backplane predates the "standard" ATIS. Is this correct? For example, I have some Atherton viewgraphs (circa 1987) in which ATIS is barely mentioned, and is never referred to as a standard. Perhaps this is a chicken/egg question. Also, which standards body sponsored/endorsed the ATIS standard (eg, IEEE, ANSI, etc)? What's the appropriate standards number so I can order a copy (eg, IEEE Std xxx-yyyy)? SM> The history in the rumor isn't all quite right, but the name is correct: SM> ATIS = A Tool Integration Standard. I have a paper by a gentleman from DEC in which the acronym ATIS is expanded to "Atherton Tools Integration Services". Unfortunately, I have no idea if/where/when this was published or when/how I obtained it, although it may have been through an early connection with the CIS committee (which also has an interesting history of acronym expansions). In this paper, he states that, for legal reasons, the "Atherton" had to be removed, so he called it CATIS for "Common Applications and Tools Integration Services". As you state, ATIS is now the correct acronym and its current expansion is "A Tool Integration Standard". Is this the correct history? From: mcgregor@hemlock.Atherton.COM (Scott McGregor) Subject: Re: PCTE vs. CAIS-A Date: 11 Nov 91 22:50:18 GMT Organization: Atherton Technology -- Sunnyvale, CA In article <28030008@otter.hpl.hp.com>, pav@otter.hpl.hp.com (Paul Vickers) writes: > My guess is that Emeraude will incrementally add other ECMA PCTE services. > Two other companies, Verilog and Heuristix, recently announced they are > developing PCTE implementations. Are there any committed dates for ECMA PCTE implementations by Emeraude, Verilog, or Heuristix, that anyone knows of? Uncommitted futures are risky to build business decisions on (unless you are a research laboratory?) > SFGL have a framework and environment product, EAST, built on PCTE v12. I had forgotten about EAST. Is there any public information about the numbers of actual users with experience with EAST? > In my opinion, environment users will *not* be concerned about the technical > differences between PCTE 1.5 and ECMA PCTE. Environment builders and tool > builders may want to plan for evolution towards ECMA PCTE. Of course the danger here is always that some framework vendors' product built on PCTE 1.5, will be become an evolutionary dead end, as they take their knowledge from 1.5 and implement a completely new product based on ECMA PCTE. Or that business might be exited, if too many ECMA PCTE competitors pop up. As long as sales of PCTE 1.5 and PCTE 1.5 based frameworks is low the former is a strong risk for anyone purchasing it. If forecast sales for ECMA PCTE grow, the latter may be a risk. While the differences in the underlying PCTE definition may not concern the end users, the differences in the exterior presentations of the frameworks they purchase (e.g. EAST vs. Enterprise 2) will no doubt matter much more, and should one or the other not survive the transition, the underlying similarity of the standards they were based on will probably be of little solace to the end users who purchased it. Scott McGregor "risk happens!" :-) From: ericb@athertn.Atherton.COM (Eric Black) Subject: Re: PCTE vs. CAIS-A Date: 14 Nov 91 19:42:28 GMT Organization: Atherton Technology, Sunnyvale, CA In article <1991Nov11.233718.833@src.honeywell.com> tking@src.honeywell.com (Tim King) writes: >Could either you or Eric provide some more details on Atherton's >relationship to ATIS? The relationship of Atherton the company to ATIS is one of parentage; Atherton originated ATIS (the "A" in "ATIS" originally stood for "Atherton") and approached DEC in 1988 with the idea of developing a standard for tool integration services in an IPSE. Together with DEC and others, Atherton has continued to develop ATIS with an eye towards its becoming a standard. Atherton remains one of the driving forces behind ATIS; along with DEC, other participants in the ATIS effort include IBM, Unisys, Boeing, Loral, Software Productivity Consortium, Software Productivity Solutions, IDE, Cadre, Interleaf, SofTool, and Verdix. The relationship of Atherton's product, Software BackPlane, to ATIS is twofold. The first is, again, one of parentage; the first version of ATIS was a generalization of a portion of the programmatic interface to Software BackPlane Release 1.0. The second is that Software BackPlane is a production quality commercial implementation of an IPSE based on ATIS, and is available today (send your check to the address below! :-). >From previous discussions with Atherton personnel, etc, it is my impression >that the Atherton Backplane predates the "standard" ATIS. Is this correct? >For example, I have some Atherton viewgraphs (circa 1987) in which ATIS is >barely mentioned, and is never referred to as a standard. Perhaps this is >a chicken/egg question. Well, since the ATIS effort did not get off the ground until 1988, and in 1987 was only an Atherton proposal to DEC that we work together on it, and polish it into something that we could invite others to work with us on, that's not surprising. ATIS has been referred to as a "specification", not a "standard", because it has not been a standard, only a specification which is intended to be proposed as a standard. In 1990, an augmented version of ATIS was adopted by ANSI IRDS (X3H4) as a working draft standard. So since then, it has been legitimate to refer to "IRDS ATIS" as a "standard", or more properly as a "draft standard". A purist might object to a reference to "ATIS" as a "standard". As many people are wont to misuse terms somewhat cavalierly, the distinction between "ATIS" and "IRDS ATIS" was not always made clear, resulting in some confusion due to apparent multiple versions of ATIS. >Also, which standards body sponsored/endorsed the ATIS standard (eg, IEEE, >ANSI, etc)? What's the appropriate standards number so I can order a copy >(eg, IEEE Std xxx-yyyy)? As I said above, ANSI X3H4 has adopted IRDS ATIS as a working draft standard, which is titled "ANSI X3H4 Working Draft: Information Resource Dictionary System ATIS". A new ANSI Technical Committee, X3H6 "CASE Tool Integration Models" (CTIM), has just been formed, and will have its organizational kick-off meeting next January. The first order of business is the separation of ATIS into two portions: a lower-level object-oriented substrate which becomes the domain of X3H4 (IRDS), and higher-level models which are the domain of X3H6 (CTIM). >SM> The history in the rumor isn't all quite right, but the name is correct: >SM> ATIS = A Tool Integration Standard. > >I have a paper by a gentleman from DEC in which the acronym ATIS is >expanded to "Atherton Tools Integration Services". > [...] The history of the ATIS and related acronyms is truly involved, and probably of interest only to some. At various points each of these acronyms were tried: ATIS - Atherton Tool Integration Services ATIS - Atherton Tool Integration Standard CATIS - Common Application and Tool Integration Services ATIS - A Tool Integration Service ATIS - A Tool Integration Standard At the present time, ATIS in the context of X3H4 (IRDS) has the last expansion. In the context of the CIS (CASE Integration Services) committee, ATIS has the penultimate expansion. It may be advantageous to the general level of understanding for the acronym ATIS to be replaced by something altogether different in light of the impending division between X3H4 (IRDS) and X3H6 (CTIM). Please see article <41122@mango.athertn.Atherton.COM> for more history. >Any information you or Eric could provide would be useful in clearing up my >(and perhaps others') confusion. Thanks. I hope this has helped more than it has added to the confusion. That was the intent, in any case :-) From: gt@hpfcbig.SDE.HP.COM (George Tatge) Subject: Re: PCTE vs. CAIS-A Date: 15 Nov 91 17:24:22 GMT Organization: HP SESD, Fort Collins, CO My, but this has gotten lively while I was away building a real framework (my house). I have no intention of getting into long winded debates with Scott; he would simply out volume me. I also wonder if we wouldn't just be talking to ourselves- I mean, I wonder how many people really care. I do have a few comments though: 1. Scott points out that there are risks associated with trying to determine the future. For most people in this business, that must come as quite a shock. (I'm sorry, I don't really want to turn this into unbridled sarcasm.) So, let's make the obvious disclaimer, "Warning, anything I say about the future may or may not come to pass. Use my predictions at your own risk!" 2. Scott is walking a very fine marketing line to state that Atherton's Backplane is based on the ATIS standard. I won't recount the whole history here (but I could because I was there for all of it) but CIS (the eventual name of the group where this transpired) as a group was never anything more than a vehicle for Atherton/DEC to push the Atherton technology as a standard. Several members left CIS for this very reason. 3. Scott's attacks (although worded carefully) on PCTE are symptomatic of PP disease (proprietary paranoia). Vendors who see a threat to their proprietary products coming from an open, international standard, often must find ways to attack the standard. It is completely understandable, but regretable. Finally, I stand by my predictions (see above disclaimer). If you are in a position where you must try to anticipate the future, I believe that you are at least a three to one favorite if you pick ECMA PCTE as the best bet for the OPEN, STANDARD, INTERNATIONAL repository for Unix. From: ericb@athertn.Atherton.COM (Eric Black) Subject: ATIS Background Date: 13 Nov 91 23:09:51 GMT Organization: Atherton Technology, Sunnyvale, CA I was just passed a pointer to the discussion of PCTE, CAIS-A, and ATIS here. As one of the primary authors of ATIS, I think I can help fill in some background and history, and respond to some misinformation. I'll do this in four separate articles; otherwise it would be too long and no one would read it. This one has background and history of ATIS. A second to follow will contain history of PCTE, PCTE+, and ECMA PCTE, and a third will contain more specific technical information about ATIS. Yet a fourth article will discuss how ATIS relates to PCTE and BMS technologies. Copyright 1991 by Eric Black, All Rights Reserved. ATIS BACKGROUND ATIS is a specification for services which make it easier to integrate a tool into an IPSE (Integrated Project Support Environment). The terms SEE (Software Engineering Environment) and SDE (Software Development Environment) are also in use; all three [IPSE, SEE, SDE] can be considered equivalent. ATIS is NOT a specification for data exchange, contrary to what Greg Harvey said, although two tools which store data using ATIS services will find it easy (even trivial) to locate the data of the other tool. Making sense of that data is outside the scope of ATIS (and PCTE and CAIS-A, for that matter); other standards such as CDIF (CASE Data Interchange Format) and IEEE P1175 are tackling that problem. As Tim King pointed out, there is an interesting history of acronym expansions related to ATIS and CIS. It's not so confusing when put into historical perspective. Today the acronym ATIS stands for "A Tool Integration Standard". ATIS was initially proposed in 1988 by Atherton Technology and DEC. At that time, ATIS stood for "Atherton Tool Integration Services". As part of the effort to make the specification non-proprietary, as well as suitable for being proposed as a standard, it was desired to remove the name of a company from the name of the spec. We played around with various possibilities, including CATIS (Common Application and Tool Integration Services) [which appears on a document cited by Tim], OOTIS (Object Oriented Tool Integration Services), and others not worthy of mention, finally settling on ATIS (A Tool Integration Standard). This name change took place long before ATIS was submitted to ANSI IRDS, contrary to what Keith Anderson said. So ATIS is a specification, a document. What's this "CIS" thing? That's simple, too. CIS (CASE Integration Services) is a committee, i.e. a group of people, representing framework/environment vendors, hardware vendors, CASE tool vendors, and end users, who are all interested in and trying to standardize various aspects of IPSEs (or SEEs, or SDEs, whichever you prefer). Among those aspects are data interchange between tools, user interface and presentation, control integration (i.e. invoking the right tool in the right way at the right time), and data integration (of which data interchange and translation is a small part). All these aspects are important and, we believe, standardization of all is required for effective and systematic (as opposed to ad hoc) use and combination of CASE tools from multiple providers. The CIS committee is chartered with adopting, and developing where necessary, standards in these areas. There are other efforts in the areas of Presentation Integration (e.g. Motif, OpenLook, and perhaps others), Data Interchange (e.g. CDIF, IEEE P1175, and others), Control Integration (e.g. the Object Request Broker specification from OMG, and various products based on the Broadcast Message Server technology developed at Brown University, including HP's SoftBench, Sun's ToolTalk, and DEC's Fuse, standardization of which may begin shortly under the auspices of the fledgling "CASE Communique" consortium). Where such standards exist or are likely to exist soon, they are to be adopted. Where they do not exist, such as in the area of Data Integration, CIS undertook to develop them. The ad-hoc group working on ATIS agreed in February 1990 to "give over" development of ATIS to the CIS committee. ATIS AND THE STANDARDIZATION PROCESS In February 1990, an augmented version of ATIS, with extensions for more general information systems use, was submitted to ANSI IRDS (X3H4) for use as a standard. It was accepted by ANSI IRDS as "ANSI X3H4 Working Draft: Information Resource Dictionary System ATIS". In the more modern era :-), the CIS committee proposed to ANSI the formation of a new technical committee chartered to develop models relating to integration of tools in an environment. This is essentially the charter of CIS, except that it is at a higher level of abstraction; i.e., specific interface details, language bindings, etc., are not within scope. The proposal was accepted by ANSI, and the new TC is designated X3H6, and is titled "CASE Tool Integration Models" (CTIM). The X3H6 organizational and kickoff meeting is tentatively scheduled for Jan 27-28 in Washington DC at CBEMA. [anyone interested is welcome; please send email or call me for details] A shallow reading of the X3H4 and X3H6 base documents reveals significant apparent overlap; this is not surprising, since both are essentially the original ATIS. During the next several weeks, X3H4 and X3H6 representatives will be working on a division between the two. Qualitatively, that division quite straightforward; the repository and object-oriented substrate layers of the ATIS model go to X3H4, the versioning, configuration, work flow control, correspondence, and name service layers go to X3H6 (for more information on those layers, please see my separate article which discusses the content of ATIS). MINISTRY OF MISINFORMATION Now, I must correct some other misinformation which I observed in previous articles in the PCTE vs. CAIS-A thread: Because Software BackPlane runs on several versions of Unix as well as on VMS, and always has, it is not UNIX specific; since ATIS was originally based on Software BackPlane, it is not UNIX specific (notwithstanding to Keith Anderson's implication). On the contrary, Software BackPlane and ATIS have always gone out of their way to be OS platform independent to the greatest extent possible. Of course, now that even Ken Olson's well-known contempt for UNIX has turned around and DEC is embracing POSIX (in VMS 5.5), perhaps some of the contortions can be relaxed. Keith is also mistaken when he says that "Atherton's current product has no direct relationship to the ATIS work". Atherton's product *is* the prototypical ATIS! In fact, it is the ONLY commercially available ATIS implementation to date. There is an ATIS implementation is under development by DEC, CDD/Repository, which is currently in field test, but is unavailable to Joe Random at this date. Furthermore, that DEC product runs only on VMS; to my knowledge commitment to an availability date for the Ultrix version has not been given. It would be accurate but perhaps misleading to say that neither Atherton's product nor DEC's product adhere 100% to the ATIS standard; misleading because ATIS is not yet a standard, accurate because the ATIS proposed standard is a document undergoing modification and some details (esp. names) have been changed since Atherton and DEC implemented their products. This is not unlike statements from C compiler vendors that they were "ANSI C compliant" before the ANSI C standard was finalized. From: ericb@athertn.Atherton.COM (Eric Black) Subject: ATIS Overview (long) Date: 13 Nov 91 23:12:46 GMT Organization: Atherton Technology, Sunnyvale, CA This article gives a brief(!) overview of the technical content of ATIS, and discusses how ATIS fits together with repository standards such as PCTE and IRDS and with BMS technologies such as SoftBench and ToolTalk. A preceding article titled "ATIS Background" dealt with the history of ATIS. Articles to follow will give a brief history of PCTE and how ATIS fits together with PCTE and BMS. Copyright 1991 by Eric Black, All Rights Reserved. ATIS OVERVIEW ATIS (A Tool Integration Standard) is a specification which addresses those aspects of the IPSE which are critical to the tool integrator (or tool implementor, if the tool is designed from the start for integration into an IPSE). ATIS is not an IPSE, nor is it a specification for an IPSE; it is a specification for only a portion of the semantics and the interfaces of a complete IPSE. As such, it does not pretend to satisfy all of the requirements of an IPSE, but does define services which address all or a portion of many of those requirements, and at the least do not conflict with any of those requirements. Integration of a tool with the IPSE (and with the other tools which are already integrated) involves three distinctly different yet overlapping aspects of integration: Data Integration: managing the tools data and data sharing among tools Control Integration: invoking the correct tool at the correct time and in the correct way Presentation Integration: integrating the user interface of the tool with that of the environment and the other tools ATIS focuses on Data Integration and Control Integration (because the ATIS data model is object-oriented, it necessarily involves both data and control). It intentionally does not address Presentation Integration at all; an environment based on ATIS could, for example, use OSF/ Motif or Open Look presentation services equally well. The ATIS specification addresses the Data Repository, Data Integration, Communication, and portions of the Task Management Services areas of the ECMA Reference Model for Engineering Frameworks (popularly if inaccurately known as "The Toaster Model" -- hi, George!). ATIS is based on an object-oriented data model. This is not to say that an ATIS implementation must be object-oriented, or programmed in an object-oriented language, but that the interface to ATIS services is object-oriented. The reason for this is that based on experience with Atherton's Software BackPlane (Release 1.0 of which was the prototype for the first version of ATIS), the object-oriented model allows a tool integrator to specify and enforce integrity constraints which can more effectively and requiring less knowledge of the implementation than do more "traditional" models, and to publish tool services and make use of public services provided by other tools without requiring knowledge of how that service is provided or how that particular tool is invoked. It also facilitates the concept of "triggers" -- something which must be performed before or after a given operation; this allows enforcement of go/no-go decisions which are specific to the particular group or project without modifying the tool, and allows for easy extension of the existing system by "stacking" setup and takedown triggers before and after an existing method. Further, by providing security on a per-object basis, since methods are themselves objects, ATIS allows much finer resolution of access permissions than the typical Read/Write/Delete/Execute granularity found in non-message-based systems. In summary, object orientation allows ATIS to meet the IPSE requirements of Ease of Extensibility, Administrative Control, Integrity Enforcement, Data Integration, Control Integration, Customizability, Reusability, Security, and Evolution much more readily (for a description of each of these requirements, see [Nolan88]). ATIS defines a number of semantic models. Some of these models are identified but at present unspecified in ATIS. That is, their importance is recognized, and their place is identified in the ATIS documents, but they are not yet defined. The semantic models defined by ATIS are: Basic object-oriented data model; objects, messages, methods: A minimal type (class) hierarchy with at least single inheritance of both attributes and behavior. This model does not require an object-oriented internal architecture; the interface to the services specified in this model follows the object-oriented model of behavioral polymorphism accessed by sending messages to objects. The minimal type hierarchy includes only those types required to implement the basic object-oriented data model. It requires the services of an underlying persistent repository, but does not specify the interface to that repository. ATIS can just as readily be implemented using, for example, an object-oriented database, an entity-relationship database, or a relational database. In fact, examples of each of these exist or or under development. In the separation of ATIS into X3H4 and X3H6, this model will go to X3H4 (IRDS). Versioning model: Introduces new types and new messages to support a model of object mutability combined with the ability to take snapshots of an object; the snapshots are linked together with predecessor/successor relationships which indicate the genealogy of the data. New versions are created as mutable copies of their predecessor (as a result of sending the reserve message to the predecessor), and can be changed until such time as they are made immutable (by sending them the replace message). Primitives to support this model may be provided by the underlying repository; for example, PCTE defines versioning primitives on which this model may be constructed. We expect the separation of ATIS into X3H4 and X3H6 to result in the versioning model going to X3H6, with lower-level primitives going to X3H4. The remaining ATIS models go to X3H6: Configuration model (composite objects): Provides a model for grouping specific versions of objects into a configuration which can then be manipulated as a single entity, and is itself versioned. Work flow control model: Adds types and semantics which can be used to enforce project development methods and policies, but does not define a specific work flow or design method. This is the "Management" part of "Configuration Management", among other things. Tool integration / client registration model: Provides the mechanism for extending the environment by adding new tools and applications, including defining new types, new messages, new implementations of messages (i.e. method functions). Features are added to simplify data and control integration of an existing tool and requiring no or minimal modification of the tool (non-intrusive). Transaction model: Introduces the notion of atomicity of operations. A nested transaction model is specified, but the precise semantics of the model are as yet unspecified (still To Be Done). Security model: Currently provides only for discretionary access control; mandatory access control is possible, but not required by ATIS. Defines basic access rights (Read, Write, Execute, Delete, etc.), and applies them to the object-oriented model. Because the access permissions can be applied to message and method objects as well as project data, very fine control over operations and not just data objects can be obtained. Reconciliation of the ATIS security model with that of PCTE is a desirable goal, and one which is not thought to be particularly difficult; until that is accomplished, however, the security model of ATIS is To Be Done. Name services model: Provides for mapping in both directions between an objects internal name (its unique object ID) and a human-readable external name. This is still To Be Done. Correspondence model: Provides facilities to meet the requirements of Traceability. Some relationships between components need to be updated automatically whenever the components participating in the relationships are updated; others must not be updated, but should result in the notification of the owner(s) of the components that the other component in the relationship has changed. This implies that relationships must be first-class objects in the ATIS data model so as to allow for type-specific refinement of the behavior of the relationships. Unfortunately, this tends to conflict with the requirement that they be sufficiently light-weight that very large numbers of relationships may be stored and manipulated efficiently. Pending resolution of this conflict, this portion of the ATIS specification is To Be Done. ATIS BIBLIOGRAPHY ATIS Specification: [CIS 91] CASE Integration Services Committee, CIS Base Document V1.0, October 1991 Related Standards: [ECMA 90] European Computer Manufacturers Association, "ECMA PCTE Standard", ECMA-149, December 1990 [EIA 90] Electronic Industry Association (EIA), "CDIF: Framework for Modeling and Extensibility", EIA-PN2387 [IRDS 88] ANSI X3 Technical Committee X3H4, "Information Resource Dictionary System", X3.138-1988 Background: [Beyer 90] Beyer, H., Chapman, K., and Nolan, C., "A Comparison Analysis of Repository Approaches", available from CIS committee secretary [Black 89] Black, E., "Software Configuration Management with an Object-Oriented Database", Proceedings of the 1989 Winter USENIX Technical Conference, San Diego (January 1989) [Black 91] Black, E., "Tool Integration Approaches in an Object Oriented IPSE", Proceedings of the 5th International TOOLS U.S.A. Conference, Santa Barbara (July-August 1991), Prentice-Hall [Black 91] Black, E., "ATIS, CIS, PCTE, and Software BackPlane", to be presented at Toulouse 91 [IEPG 89] Independent European Programme Group Technical Area 13 (IEPG TA-13), "Introducing PCTE+", April 1989 [Matthews 90] Matthews, E., and Burns, G., "VADS APSE: An Integrated Ada Programming Support Environment", Proceedings of the First Symposium on Environments and Tools for Ada, Redondo Beach, CA (April-May 1990) [Nolan 88] Nolan, C., "CATIS Requirements and Goals", September 1988, available from CIS committee secretary [Paseman 88a] Paseman, W., "Architecture of an Integration and Portability Platform", Digest of Papers from the Spring 1988 CompCon Conference, San Francisco (March 1988) [Paseman 88b] Paseman, W., "Tools on a New Level", UNIX Review, June 1989 [van Riel 91] van Riel, W., "Integrated Project Support Environments: Benefits and Functions", Proceedings of the International Workshop on UNIX-Based Software Development Environments, Dallas (January 1991) The CIS committee secretary is: Ms. Kathy Chapman Digital Equipment Corporation 110 Spit Brook Road Nashua, NH 03062-2698 USA email: chapman@tle.dec.com From: ericb@athertn.Atherton.COM (Eric Black) Subject: PCTE History Date: 14 Nov 91 02:52:02 GMT Organization: Atherton Technology, Sunnyvale, CA This article gives a summary of the history of PCTE from an American point of view. Since PCTE is mainly a European initiative, much of this history seems to be unknown in the US (although to be sure, several Americans have been involved in the development of PCTE almost since its inception; hi, Tim, Herm, and others!). What follows is my interpretation of what I have gathered from conversations with and exposure to the European PCTE community, particularly Ian Campbell and Regis Minot, both of GIE Emeraude, and from various articles and publications. Corrections to possible misinterpretation on my part are, of course, welcome. Copyright 1991 by Eric Black, All Rights Reserved. PCTE HISTORY PCTE, "A Basis for a Portable Common Tool Environment" (yes, the "A Basis for" was left out of the acronym, and seems to have been forgotten), was started in 1983 as an ESPRIT (European Strategic Programme for Research and Development in Information Technology) project. It was intended to meet many of the same goals as the Tool Support Interface of the Kernel Ada Programming Support Environment (KAPSE) as identified in the Stoneman report [BUXT80], but not specific to Ada. This being the case, it is not surprising that PCTE and CAIS-A are quite similar, since they are solving the same problem and according to the same specification. But note that neither CAIS-A nor PCTE are specifications for an environment, but only for the "kernel" or "framework" upon which an environment can be built. The term "PCTE" has multiple bindings, in that there are at least three different specifications by that name; more accurately, they are PCTE 1.5, PCTE+, and ECMA PCTE. The three are genealogically related, as shown in the following diagram and text (tiltng your head and squinting may make the diagram more easily interpreted :-). ... -> PCTE 1.4 \ PCTE 1.5 ---X---> ECMA PCTE (ECMA-149) \ / PCTE+ --------- The first public release of PCTE was Version 1.4 in 1986, with a C function binding published in 1988. This initial work was performed by a consortium of six European manufacturers: Bull, GEC, ICL, Nixdorf, Olivetti, and Siemens, who jointly funded the work with ESPRIT. In 1986 the PCTE Interface Management Board (PIMB) was formed and given ownership of the PCTE specification, which is under formal configuration control through the PIMB. Public comment was incorporated into the specification, resulting in PCTE 1.5 in November 1988. In 1987 the Independent European Programme Group (IEPG), a research group sponsored by NATO defense ministries, began a project to evaluate and evolve the PCTE specification into a language-independent interface set suitable for both defense and commercial users. Extensions and modifications to PCTE 1.5 resulted in 1988 in a version called "PCTE+". IEPG TA-13 (Technical Area 13) is now in the "assessment phase" of PCTE+, which is scheduled to be complete in December 1992 ("complete" == "funding shut off"). That assessment includes prototyping PCTE+ implementations on Unix and on VMS with both C and Ada language bindings, building prototype environments using those PCTE+ implementations, and evaluating their effectiveness on some trial projects. In the meantime, PCTE 1.5 was submitted to the ECMA General Assembly in 1989 as a proposed ECMA standard, and the ECMA TC-33 Technical Committee was established to hammer PCTE into an ECMA standard. During that process, it was apparent that PCTE 1.5 was deficient in certain respects, many of which were identified by IEPG in their development of PCTE+. As a result, at some point in 1989-90 PCTE 1.5 was dropped as the baseline for ECMA PCTE and PCTE+ selected in its place. Changes and extensions were made such that the three versions of PCTE (PCTE 1.5, PCTE+, and ECMA PCTE) are somewhat different in detail from each other. ECMA PCTE was accepted by the ECMA General Assembly as ECMA standard ECMA-149 in December 1990. In 1983, three French companies, Bull, Eurosoft, and Syseca, formed a joint venture, called GIE Emeraude, to develop and market a commercial implementation of PCTE. The first production version of that product, called Emeraude V-12, is basically PCTE 1.5 with some PCTE+ extensions, was released in 1989 and is still today the only commercially available implementation of PCTE, although three other PCTE implementations (actually, PCTE+) have been announced but are not yet available. PCTE OVERVIEW The main features provided by PCTE 1.5 are: - portability of tools to different platforms; insofar as PCTE is available on a platform, and a tool uses PCTE facilities exclusively, the tool should be portable to the platform - the Object Management System; information management system which provides an E-R data model [CHEN76] with transactions and distribution across multiple workstations on a network - schema management; object, attribute, and relationship type definitions are grouped into Schema Definition Sets, and a type definition may be distributed across multiple SDSs - execution control; tools (processes) may be started and stopped in a uniform manner - communication; inter-process communication via message queues (a cleaner model than TCP/IP and nowhere near as messy as raw sockets) In summary, if you picture PCTE as a "next-generation operating system", where the file system is replaced by a database (on which a UNIX file system can be emulated trivially), you won't go far wrong. Participants in the IEPG TA-13 assessment of PCTE+ reported at the PCTE '91 conference in The Hague that one of the most useful features of PCTE is the Schema Definition Set. Distributing definition of a type across several SDSs facilitates better understanding because the multitude of details are not presented all in one place, only those details pertinent to a particular limited scope. The ability to rename and type-coerce attributes which are "inherited" from another SDS makes it easier for the environment builder to piece together tool A and tool B even though they require conflicting definitions on a type they share. The transaction model which provides for nested transactions is also quite nice. The extensions PCTE+ made to PCTE 1.5 include: [IEPG89] - composite entities; the ability to treat a collection of objects as a single object for certain operations - version support; maintaining multiple versions of entities, including composite entities, while allowing tools to be unaware of the existence of other versions of the entities - security; both discretionary and mandatory access controls - executing processes are represented as objects in the object base - the metabase; the type definition mechanism is self-referential and queriable (can be browsed) - multiple inheritance of entity type definitions - type definition modes; permits definition of constraints on the modification or deletion of objects and their relationships - notification of specified object accesses - accounting - real and enumeration attribute types - operating system independence (achieved by specifying POSIX!) The main differences between PCTE+ and ECMA PCTE are documentation changes. There is a single language-independent abstract specification document (ECMA-149), with separate C (ECMA-158) and Ada (ECMA-???) language binding documents. In addition, some editorial changes were made to the specification to improve consistency and readability. The functional changes are relatively minor: - precise cardinalities on link types - new "owner" access right - link destination is made transparent to the implementation - new operation to query all objects of a given type in a given volume In an article to follow, "ATIS+PCTE+BMS", I will discuss how ATIS fits together with PCTE and with BMS (Broadcast Message Service) technologies. -Eric REFERENCES and BIBLIOGRAPHY [BOUD88] G. Boudier, F. Gallo, R. Minot, I. Thomas, "An Overview of PCTE and PCTE+", Proceedings of the Third ACM Symposium on Software Development Environments, Boston, November 1988 [BUXT80] J. Buxton, "Requirements for Ada Programming Support Environments: STONEMAN", US Department of Defense, 1980 [CHEN76] P. Chen, "The Entity Relationship Model: Towards a Unified View of Data", ACM Trans. on Database Systems, 1(1), March 1976 [ECMA90] European Computer Manufacturers Association (ECMA), ECMA PCTE Standard, ECMA-149, December 1990 [ECMA90] European Computer Manufacturers Association (ECMA), PCTE C Programming Language Binding, ECMA-158, June 1991 [IEPG89] Independent European Programme Group Technical Area 13, "Introducing PCTE+", 1989 [PIMB88] PCTE Interface Management Board, "PCTE Ada and C Functional Specifications", Version 1.5, November 1988 From: mcgregor@hemlock.Atherton.COM (Scott McGregor) Subject: Re: PCTE vs. CAIS-A Date: 20 Nov 91 03:25:32 GMT Organization: Atherton Technology -- Sunnyvale, CA I'm mystified by the apparent personal turn in gt's posting. It is not my intention to upset anyone at HP, a company where I worked for a decade and whose good will I continue to be interested in. If I have offended anyone at HP (or not!), I hope they will write me off-line and help me understand how I have offended them, and what I can do to make things right. George is quite right in criticizing my verbosity, an unfortunate trait that I work on diligently, if somewhat unsuccessfully. So I'll try to keep the rest of my posting brief. 1. I appreciate gt's concession regarding futures. We have many years of business experience, and many readers have not, and it is important to me to keep their interests at heart. While I agree in part with gt's original posting with regards to PCTE futures, my posting was intended to correct an important omission about currently available products which could be confusing to some readers. It is not only unethical to position possible futures against currently purchasable competing products, it is outright illegal in the U.S. (see CDC vs. IBM 1966 $6M consent decree). Since many readers neither know the law nor what (is/is not) purchasable today, marketing folk such as gt, and R&D folk like me, have an obligation to be clear. Vapourware is vapourware, paperware is paperware, and purchasable products are purchasable products. I only strive to see the readers will be clear as to which is which. 2. Regardless of the ATIS/CIS history (see Eric Black's 11/14 post) which has apparently so polarized gt's opinions, ATIS *is* a working draft standard (ANSI IRDS ATIS) in a recognized open standards organization (ANSI) which is at least as well known as ECMA. Eric documents that ATIS is a living standard with X3H4 and X3H6 committees working on it. The world has often had several possible standards to chose from and, as they evolve, new ones that unify or replace old ones often result. These committees could well unify ATIS and PCTE, or replace both--we will have to wait and see. 3. I certainly don't mean to "attack" PCTE, a standard that offers capabilities not found in ATIS or Inter-tool Message Systems like Sun's ToolTalk or HP Softbench. All these capabilities have roles in the solution to customer problems. But this is different from saying PCTE is the one and only exclusive solution needed. In fact, if a standard was so exclusive that it could not allow capabilities that it did not cover to be provided to customers it would be a mockery to call it "open". PCTE need not be so exclusive; and as Eric notes, Atherton continues to work towards a rich melding of solutions from a number different sources, including PCTE, ATIS and Inter-tool messaging systems. I celebrate the more typical HP collaboration with ISVs, in the OSF, and in their OSE announcement, etc., which reflect a cooperative stance and not the us vs. them, all or nothing, dichotomy reflected here. Atherton has indeed contributed substantially to advancing ATIS to ANSI adoption and in the process has contributed substantial amount of its proprietary development to the public domain. This is surely no different than HP's contribution of its proprietary X toolkit technologies to the OSF Motif standard, or AT&Ts contributions to ANSI C standards. If there is anything odd to remark on it is that Atherton, a smaller independent software vendor, is participating equally with giant multi-billion dollar system vendors like HP, IBM, DEC, Sun and AT&T. Far from any paranoia of comparison, Atherton welcomes comparison of its multivendor products with the single systems vendor repositories purveyed by these giants. Our products are available today, on multiple vendors platforms and represent several generations of experience and refinement when other competitors are just getting to market with their first offerings. Clearly, our product is not right for everyone. Head to head comparisons of products available today are fair--no doubt Atherton will lose some. Atherton can not collaborate in positioning unpurchasable futures against today's products, whether from HP, Atherton, DEC, or IBM because it is not only irresponsible to other contributors, but is unfair to customers who need to make purchasing decisions today. George has promoted his view of "the" single ECMA PCTE CASE standard excluding all others. We can agree to disagree, amicably I hope. My view, which includes a substantial contributory role for PCTE, is one of an open set of collaborating standards from various standards organizations, covering many aspects. It takes many standards to effectively cover the CASE Framework needs of customers today, just as it takes CASE products from many software vendors to solve real customer problems today. I wonder if it will be so very different in the future. I'm sure others will want the last word on this controversy; let them have it. This will be my last posting on this topic, and I will return to the more R&D oriented news topics that I typically participate in. Scott "too verbose, but trying to improve" McGregor P.S. I just finished a lot of work on my house too! It can certainly make clear the difference between the paper projections and the finished product, project and schedule. Good luck on your house, George! From: ericb@athertn.Atherton.COM (Eric Black) Subject: Re: PCTE vs. CAIS-A Date: 20 Nov 91 20:51:55 GMT Organization: Atherton Technology, Sunnyvale, CA This discussion has all the earmarks of an incipient flame fest, but at the risk of fueling it further, I'd like to comment publicly, George. In article <440015@hpfcbig.SDE.HP.COM> gt@hpfcbig.SDE.HP.COM (George Tatge) writes: >2. Scott is walking a very fine marketing line to state that Atherton's >Backplane is based on the ATIS standard. I won't recount the whole >history here (but I could because I was there for all of it) but CIS >(the eventual name of the group where this transpired) >as a group was never anything more than a vehicle for Atherton/DEC to >push the Atherton technology as a standard. Several members left CIS >for this very reason. Well, you were there for the early part of it. HP left CIS largely because CIS refused to push HP's proprietary SoftBench product as the single one-and-only standard for integration, in the [now acknowledged to be] mistaken belief that messaging was sufficient and that a repository was unneeded. As we all know now (!), not only is there room for both, but actually both are required. >3. Scott's attacks (although worded carefully) on PCTE are symptomatic >of PP disease (proprietary paranoia). Vendors who see a threat to >their proprietary products coming from an open, international standard, >often must find ways to attack the standard. It is completely >understandable, but regretable. I do not believe Scott was attacking PCTE. Scott is an engineering manager, not a marketeer, although sometimes he plays one on TV. His definition of "now" does not include 2 years in the future. His article pointed out that even though PIMB has titled ECMA PCTE as "The Open Repository", the fact remains that it is unavailable today and other solutions are. Your implication that his article was a defensive attack based on a threat to a proprietary product is unfair. His question about committed dates for the IBM/HP announcement regarding ECMA PCTE is valid. I need not point out, although I will :-), that Atherton (through its stockholders) has proprietary interest in PCTE as well, and that Atherton some time ago announced that future versions of our environment products will be compliant with ECMA PCTE. But that's future, and there are customers who need solutions *now*. Some companies can sell futures (or more accurately, can muddy the water with FUD and still survive), but smaller companies like Atherton have to look not only to the future, but also to putting dinner on the table tonight. And their customers do, too. >Finally, I stand by my predictions (see above disclaimer). If you >are in a position where you must try to anticipate the future, I >believe that you are at least a three to one favorite if you pick >ECMA PCTE as the best bet for the OPEN, STANDARD, INTERNATIONAL >repository for Unix. I agree with you. And that's where companies including Atherton are betting, too. As Scott points out, though, even 3-1 odds don't guarantee the outcome. Hope you've got more than the framework up on your house, now that winter's setting in! A framework by itself doesn't make a warm toasty environment in the face of the elements! From: ericb@athertn.Atherton.COM (Eric Black) Subject: Re: PCTE vs. CAIS-A Date: 20 Nov 91 20:25:33 GMT Organization: Atherton Technology, Sunnyvale, CA In article <28030008@otter.hpl.hp.com> pav@otter.hpl.hp.com (Paul Vickers) writes: >Emeraude v12 is available on IBM, HP, DEC, Sun and Bull platforms. Emeraude >v12 implements PCTE 1.5, the precursor of ECMA PCTE, plus some additional >services. The additional metabase and versioning services are compatible >with those introduced in ECMA PCTE. My guess is that Emeraude will >incrementally add other ECMA PCTE services. The current release of Emeraude, V12, is indeed PCTE 1.5 plus some extensions. Those extensions put V12 on the path toward ECMA PCTE, but there remains a non-trivial amount of work to make Emeraude into an implementation of ECMA PCTE. Do not let the use of terms such as "incremental" mislead you into believing that an ECMA PCTE implementation will be available in the near future (for reasonable interpretations of "near" -- governmental & defense schedules may consider 5 years to be "near future", and 2 years to be almost the same as right now, but the commercial software industry does not). The point Scott was trying to make was that you can not write a check today and walk away with an ECMA PCTE product. If you need a solution TODAY, by definition it can't be ECMA PCTE. As you point out, Paul, Emeraude V12 is a step in that direction, and it is a good idea for environment builders to gain experience with what there is today, even though it is not ECMA PCTE. But let's not have any contracts specifying ECMA PCTE just yet because said contract would be impossible to fulfill. The V20 release of Emeraude will be ECMA PCTE. No availability date has been officially announced for that product, but do not expect it before late 1993, and a conservative environment builder will probably observe it for a time before "betting the ranch" on it. The fact remains that there is no production-grade version of ECMA PCTE, and very likely will not be, for 2 or 3 years yet. Commercial deployment of PCTE is down the road a piece. Of ECMA PCTE, certainly, by definition. But even of PCTE 1.5. There are projects TODAY using Software BackPlane, even though the current release of Software BackPlane is not PCTE compliant. As has been publicly announced, a future release of Software BackPlane will be fully compliant with ECMA PCTE. That is a serious commitment, and Atherton's relationship with Thomson shows the clout and resources to follow through on that commitment. As a product-oriented engineering manager, Scott, like others, sees what is true now, what is not true now, and can tell the difference between the two and how that can change in the future. Marketing-oriented people often have a broader sense of "now" than do engineers. There seem to be many misunderstandings, even flame wars, which boil down to this kind of difference in connotation. >SFGL have a framework and environment product, EAST, built on PCTE v12. At the recent PCTE '91 workshop in Den Haag, it was stated by SFGL representatives (J-PB) that EAST is still under development, but early versions have been field tested. General availability, let alone deployment, is still in the future. Again, this is the product-oriented mindset. I can't plunk down a check and walk away with product. >Two other companies, Verilog and Heuristix, recently announced they are >developing PCTE implementations. Again, these are partial implementations of PCTE+, in both cases built on top of a relational database (Oracle). Neither is ECMA PCTE, but the interesting thing about those announcements is the level of excitement generated by them. This comes back to your point about gaining experience before ECMA PCTE is available. But again, there is talk in the US defense community and among commercial developers as well of imposing contractual requirements for ECMA PCTE *now*. > >In my opinion, environment users will *not* be concerned about the technical >differences between PCTE 1.5 and ECMA PCTE. Environment builders and tool >builders may want to plan for evolution towards ECMA PCTE, and the best way >to do that would be to gain experience with PCTE 1.5. But I think one of Scott's points is that there is little benefit from PCTE for the end user, although many end users have been told that they will derive direct benefit from it. Tool builders and environment builders, yes, but the benefit to the end user is indirect. Such is true of UNIX, too. Scott was not "attacking" PCTE; he was saying that ECMA PCTE is not available today (November 1991) and even when it is available it does not solve all of the problems of the end user. -Eric -- Eric Black "Garbage in, Gospel out" Atherton Technology, 1333 Bordeaux Dr., Sunnyvale, CA, 94089 Email: ericb@Atherton.COM Voice: +1 408 734 9822 VAX: +1.408.744.1607 From: ericb@athertn.Atherton.COM (Eric Black) Subject: ATIS+PCTE+BMS (long) Date: 20 Nov 91 22:55:26 GMT Organization: Atherton Technology, Sunnyvale, CA This article explains how ATIS, PCTE, and BMS can all play together. Preceding articles dealt with the history of ATIS, a quick-and-dirty overview of ATIS, and the history of PCTE. Copyright 1991 by Eric Black, All Rights Reserved. ATIS, PCTE, and BMS TOGETHER ATIS = A Tool Integration Standard, a specification and proposed standard PCTE = Portable Common Tool Environment, a standard BMS = Broadcast Message Service, refers collectively to several broadcast or multicast messaging technologies based on the work done on the FIELD project at Brown University; product examples include ToolTalk, FUSE, and others, as well as SoftBench; there currently is no specification for BMS, let alone a standard I assert that ATIS, PCTE, and BMS are in no way competitive or interchangeable specifications or technologies. The situation is *not* that of being forced to choose one another. On the contrary, the three are complementary, and all are desirable in a software development environment. Recall that the acronym PCTE originally stood for *A Basis* for a Portable Common Tool Environment [emphasis added]. PCTE is not an environment, nor is it a specification for an environment; it is a specification for a framework, i.e., a set of building blocks from which an environment can be built. Nor is ATIS an environment; ATIS specifies services and interfaces to those services to enhance tool integration and customization of the tools within an environment. And BMS technology by itself does not provide an environment. None of ATIS, PCTE, and BMS specifies a complete environment, but together they specify many of the services which can be used by the environment builder, the tool implementor, and the environment customizer, so that the end user is presented with a unified environment populated with the tools of his choice, and not only the choice of the tool vendor or environment builder. The various aspects of integration are popularly partitioned along three, sometimes four, orthogonal axes. These are: - data integration: managing tool data and data sharing between tools - control integration: invoking the correct tool at the correct time and in the correct way - presentation integration: integrating the user interface of the tool with that of the environment and of other tools - process integration: managing use of the tool along with other tools in such a way as to implement the organization's software engineering process (a specialization of portions of both data and control integration) It has been suggested that PCTE, now officially christened "The Open Repository", provides the data integration services required in an environment, BMS technology provides control integration services, and Motif or OpenLook provide presentation integration services, resulting in a complete environment: PCTE + BMS + [Motif|OpenLook] = IPSE I assert that this is still incomplete, that the process integration requirements of the environment customizer and end user are not adequately addressed. ATIS is intended to meet those needs. That equation should read: ATIS + PCTE + BMS + [Motif|OpenLook] = IPSE One characterization of the difference between ATIS, PCTE, and BMS is that PCTE focuses on benefits to the tool implementor, ATIS focuses on benefits to the environment builder or customizer, and BMS focuses on the benefits to the individual end user. A successful environment will suit the needs of tool implementors, environment builders, individual uses, and managers as well. Combining ATIS, PCTE, and BMS is not only possible, it is a good idea. The portability afforded by PCTE is only of indirect benefit to the end user (in the form of greater availability and lower cost of tools). PCTE benefits the tool implementor by providing numerous common services which are needed by many tools, thereby removing the need for each tool to provide such services itself (almost invariably in different and often incompatible ways). That portability is only between PCTE implementations. Arguably, OS/360 provided similar portability to applications which ran under it; those applications were "portable" to all OS/360 implementations. In this sense, we could say that "portability == ubiquity". Because PCTE largely resembles a superset of a UNIX-like operating system (actually, POSIX), many UNIX applications will require a minimum of re-engineering to operate in an environment based on PCTE. In this sense, we can say that "portability == retargetability". ATIS does not address portability per se; of course, one of the expected "side-effects" of all standardization is portability, particularly portability of knowledge and expertise, and possibly (but not necessarily) portability of code and applications. ATIS specifically addresses tool integration services. It assumes that conforming environments will have solved the portability problem separately. Even if portability is not an issue, integration of a chosen set of multiple tools into a unified custom environment is still important, and ATIS addresses those needs. Ease of integration *by other than the tool implementor* is quite loudly voiced as an urgent need by the user community, and is quite distinct from the issue of portability. If portability of tools is required, one solution is to use the portability services provided by PCTE. ATIS should be complementary to PCTE, and should be able to use PCTE as a portable base on which to provide integration services. The problem is that PCTE also defines some of the integration services, e.g. by specifying an object management system (OMS). Tools do not need an object management system to be portable, but an object management system is required for data integration (even if that OMS is just a file system). This is not to say that PCTE should not have an OMS, but rather to suggest that PCTE is trying to solve some of the integration problems as well as the portability problems. ATIS and PCTE are not fundamentally in conflict, although there are some specific details in the two specifications in their current form which make it difficult to combine them without undue awkwardness. For example, there are incompatibilities in the precise contents and ordering of the minimal (base-level) type hierarchies as currently specified. To the extent that the specifications are unchangeable, this conflict can not be resolved. However, I believe that such resolution is achievable without violating the spirit of (or losing any good points from) either specification. Both PCTE and ATIS have the notion of attributed objects with individual identity, but PCTE emphasizes identification of objects by navigating to them, and ATIS makes the object identity and its use explicit. Both have relationships (links) between objects. Both have the idea of different versions of the same data by using successor-predecessor relationships between objects representing those versions. Both have composition of objects into configurations, which are objects themselves. One distinction between ATIS and PCTE might be stated that ATIS is object-oriented with entity relationships added as a straightforward extension to the model, whereas PCTE is entity-relationship based with some object orientation added, specifically, inheritance of attributes but no encapsulation and inheritance of behavior (code). ATIS provides encapsulation of behavior in the form of methods which are associated with the type and not with the tool. This encapsulation allows integrity constraints to be enforced because all manipulation of the state (attributes) of an object is done exclusively through those method functions, invoked via the public message interface; attributes (including relationships) are never manipulated directly by a tool or application, so constraints enforced by the method code are always enforced and can not be bypassed. It also facilitates sharing of functionality because a particular function or operation may be used by many without requiring each one to provide the code which performs that function. PCTE specifies multiple inheritance (of attributes), but ATIS requires only single inheritance, and allows a conforming implementation to have multiple inheritance. Another difference is that objects in PCTE tend to be fairly heavy-weight; the overhead of a minimal object is on the order of 128 bytes. Tools tend to store data in objects which correspond roughly to files, with finer-grained data stored inside those objects in private formats. ATIS encourages finer-grained storage of tool data in objects much smaller than files so that other tools have visibility of that data without resorting to private interfaces between the tools. For performance reasons, a tool may still store data in a private format within a coarse-grained object, but may publish portions of that data for other tools by copying the actual internally-used data to fine-grained objects whose format and meaning are published in the repository schema. The message-passing model of BMS fits in nicely with the message-passing model of ATIS. Right now there is confusion among the various players, including SoftBench, ToolTalk, FUSE, the Object Request Broker, and ATIS, but concensus will be and is being reached. The important thing to keep in mind about ATIS is not that a particular messaging mechanism is specified, because it is not; the important point is that ATIS specifies a model for registering tools and tool capabilities which is based on messages and methods being represented by 1st-class objects which can be created, queried, and operated on just like any object. Sending of an ATIS message causes an ATIS method to be invoked. That method function may implement the ATIS message semantics by direct subroutine call to embedded code, or by remote procedure call to another process possibly on another machine, or by spawning a subprocess running another program, or by interpreting a specialized script language, or even by sending a BMS message. The particular choice of implementation is up to the tool integrator or environment customizer, and depends upon a number of factors, including the architecture of the tools which provide the required functionality. It matters not at all to the end user whether a multicast BMS message is sent, causing another tool to be started automatically, or code implementing the function is dynamically loaded and executed in the same process. It does, however, matter to the environment customizer who has to put together the specific tools and capabilities chosen for the environment. BMS technology is another tool in the customizer's toolbox for integrating the CASE tools chosen by the end user (or the end user's manager). And the way things look now, the customizer is likely to have to deal with collections of tools which use different messaging technologies and different packaging. The confusion and competition between SoftBench, ToolTalk, and FUSE would seem to be more harmful to the needs of the end user than any possible confusion between PCTE and ATIS. The ATIS models for tool registration and implementation of work flow control rules make possible (well, actually, I should say "make reasonable") an entirely new class of tool, the "process engineering" tool. Because the particular implementation technologies of the various CASE tools are hidden behind the uniform ATIS message-passing model, the process tool can implement work flow and process rules for software development without regard to the details of how the softare tools are implemented and invoked. Those details must be known to the environment customizer who integrates those tools, but once integrated, the services provided by those tools can be used by other tools, including the process tool, using the uniform ATIS messaging model. And in fact, the Object Request Broker specification will likely be adopted as the standard syntax for ATIS message passing. I hope this and the preceding articles are helpful in promoting understanding of what ATIS is all about and we're trying to do in its continuing evolution. As should be obvious by now, questions and contributions are welcome. Let me put in another plug for the new ANSI X3H6 accredited standards technical committee, "CASE Tool Integration Models" (CTIM). CTIM will be an "ecumenical" organization, in the sense that all the "religions" alluded to in this PCTE vs. ATIS vs. BMS thread will be represented, and the output of CTIM will be independent of any single religious point of view. The organizational meeting will be in Washington, DC, next January 27-28, at CBEMA (near the Capitol). If you'd like more information about participating in the work of X3H6, please send mail to me at the address below. Also, I will be at Toulouse '91 in December talking about things such as I have briefly (!) touch on in these several messages. Perhaps we can meet and talk face-to-face. -Eric -- Eric Black "Garbage in, Gospel out" Atherton Technology, 1333 Bordeaux Dr., Sunnyvale, CA, 94089 Email: ericb@Atherton.COM Voice: +1 408 734 9822 VAX: +1.408.744.1607 From: sad@sei.cmu.edu (Susan Dart) Subject: Re: PCTE Date: 21 Nov 91 16:06:35 GMT In an attempt to present some information about PCTE, I include part of a report that I wrote about SDA's PCTE seminar. There is a lot of "interest" for PCTE in the USA by vendors, but more significantly by the government. In Europe, there is already quite a bit of experience with PCTE which is being passed onto the USA. A very easy way that one can see the difference in benefits between ATIS and PCTE is to use the Software Backplane environment from Atherton and use the EAST environment from SFGL, respectively. employer's. Susan Dart sad@sei.cmu.edu TRIP REPORT ON PCTE SEMINAR 1. Overview ============================================================ Traveler : Susan Dart (Environments Project) Dates : October 1-2 1991 Seminar : PCTE Seminar Location : Reston, VA. Purpose : get an overview of PCTE from some experts Findings : 1. This was a significant meeting for PCTE since it represents the first major discussion of PCTE in the USA. 2. There is a LOT of interest in the US for PCTE. Vendor tool coalitions are seen as short term solutions, while PCTE's tools and environments are seen as long-term solutions. 3. There are now 3 vendors selling PCTE. (Emeraude, Verilog, Heuristix) 4. Two environments based on PCTE will be available at the end of this year (EAST, Enterprise II) and 3 others are being developed (Vulcan, Hyperweb, Atmosphere). 5. There was a lot of interest in the work of implementing Softbench on PCTE. 6. There is already some user experience with PCTE (from environment vendors and tool vendors' evaluations). PCTE encourages tool writers to develop more "open" tools. 7. Many companies in the USA have already committed to PCTE (including several government projects). .... ============================================================ 2. Introduction This report highlights the noteworthy aspects of the PCTE seminar. It begins with a description of useful acronyms followed by an overview of the seminar in general terms. Then a detailed description is given of very interesting presentations and news items that came out during the presentations. I conclude with some personal comments.... 3. Acronyms and Descriptions BMS = Broadcast Message Server from Hewlett Packard CAD = Computer Aided Design CAIS = Common APSE Interface Set CFI = CAD Framework Initiative CM = Configuration management East = environment on top of PCTE Entreprise II = environment on top of PCTE ECMA = European Computer Manufacturer's Association IEPG = Independent European Programme Group IPSE = Integrated Project Support Environment ISO = International Standards Organization NIST = National Institute of Standards and Technology NSE = Network Software Environment from Sun PCTE = Portable Common Tool Environment; it is a set of standardized, public tool interfaces to basic environment mechanisms (kind of like Unix System V, but more stuff) which support a common interface to a set of cooperating, data sharing tools. It is supposed to be a solution to a variety of integration and portability problems encountered when running multiple tools from multiple vendors on multiple platforms. There are various "flavors" of PCTE: - PCTE 1.5 = currently available version of PCTE. This is the version that people generally mean when talking about PCTE. - PCTE+ = extensions by the defense community to handle security and operating system independence issues - ECMA PCTE = standardized (Dec. 1990) version of PCTE accepted by ECMA. Implementations available possibly in 1994. STARS = Software Technology for Adaptable, Reliable Systems 4. Overview of the Seminar Forty people attended the seminar, including the 5 speakers. The focus of the seminar was for tool builders, yet in the audience were managers and end-users as well. As a result, many thought-provoking issues were discussed, relating to the strategic positioning of PCTE, its productization, its future, transition to the standard version of PCTE (ECMA PCTE), as well as technical issues such as limitations of PCTE. The seminar was excellent. I found it to be a VERY significant meeting. It marked the start of a major swing towards PCTE in the USA. Even the speakers were surprised as to the kinds of questions posed. The objectives of the course were to describe the PCTE model and its concepts, the rationale for those concepts and how to use them. Objectives were met as far as possible in 2 days, and even more. Included in the seminar were results from PCTE 91, such as the work on Softbench BMS and PCTE, which was held in The Hague the previous week. Speakers and topics at the seminar were: - Bill Riddle (SDA Inc.): Status of PCTE. Inter process communication. - Ian Thomas (SDA Inc.) : Ian did most of the presentations since he was one of the original designers of PCTE. Topics were History and strategic nature of PCTE. Data manipulation in object management system. Process management. Distribution. ECMA PCTE vs. PCTE 1.5. Tool writers guidance and process. - Brian Nejmeh (Instep Inc.): Basic mechanisms of PCTE. Using object contents, Integrability characteristics of tools. - Ant Earl (HP Research Labs. England): A broadcast message server on PCTE. - J. Bourguignon (SFGL, France): EAST: Building an IPSE on to of PCTE: lessons learned. It was clear that the speakers were "pushing" PCTE, but they readily admitted any shortcomings or difficulties with PCTE and said it isn't the solution to all problems, just a few. User experiences indicate that PCTE does help tool writers develop more "open" tools. Useful documentation for users of PCTE: Interface Specification and Ian Thomas' Tool Writers Guide. Ways of keeping up to date about PCTE: subscribe to the free PCTE newsletter (that we currently receive), join the USA PCTE user's group (headed by Ian Thomas) if you are an end-user of PCTE, and attend the SDA seminar series and PCTE conferences in Europe (such as PCTE '91). 5. Interesting Information Given At Presentations Environments using PCTE: - EAST from SFGL (France) - Entreprise II (Syseca, France; a French Dept. of Defense contract) - Vulcan (Heuristix, India) - Hyperweb Tool Set (Vista Technologies, USA) - Atmosphere: ESPRIT2 project PCTE implementations: Emeraude provides an implementation of PCTE 1.5 on many platforms; Heuristix (India) provides a partial implementation of PCTE+ on 386 with Santa Cruz Operation (SCO) Unix platform; and, Verilog (France) provides an implementation of PCTE 1.5 on VAX VMS with Oracle. Standards activities: ECMA is submitting ECMA PCTE standard to ISO and IEPG is supporting this. NIST will use ECMA PCTE specification as the basis for development of an integration set of environment public tool interface standards. European and Japanese activities: Quasi-government organizations in Europe (European Space Agency, French Defence Ministry) are exerting a major pull on PCTE. There is increasing interest from Japan in PCTE since it's felt that Sigma did not meet its objectives there. Computer vendor activities: - Two STARS primes (IBM, Unisys) have adopted PCTE as their base. - IBM will use PCTE as part of the support for an integration of AD/Cycle and AIX. IBM supported PCTE standardization in Europe. - Informal discussion have started on merging PCTE with the framework being developed by the CAD CFI. - HP have integrated PCTE and Softbench and will release that as a product one day. - DEC will use PCTE as the data repository within their Cohesian product. - DEC and HP actively worked for PCTE standardization in Europe. - Sun will continue on a relatively independent path (from PCTE) based on ToolTalk the and Object Management Group (OMG). - CADRE, IDE, Mark V, as well as other tool vendors (not named), are committed to porting their products to PCTE. Nejmeh's talk on Integrability Characteristics of Tools was not about PCTE but focused on open tool architectures. He listed a set of characteristics that tools need to have in order to be open. This list concurs with what our group has recognized as important characteristics. No access to source code is needed. His list included: - Openness: user can invoke tool fragments and access the data the tool consumes/produces - Extensibility: the functionality of the tool can be easily enlarged in terms of operations and data is manipulates - Location independence: tool doesn't make any assumptions about where its data and binaries reside - Non-assuming: tool doesn't make arbitrary assumptions regarding the network on which it will run - Tool Fragment invocation: every operation the tool provides is accessible outside of the native user interface of the tool - Data import: a foreign tool can produce data that can be processed by the tool - Data export: the data the tool produces can be processed by a foreign tool - Object schema extension: a user can define additional properties of an object and set/get the values of the properties - Contextual information exportation: a tool provides a mechanism that upon selecting objects in a tool, exports the values of the specified properties for the selected objects - Operation extensions: tool provides a mechanism that, upon establishing the context within a tool, enables a user-defined operation to be invoked on the context. Ant Earl's presentation of BMS on PCTE drew everyone's attention. When looking at the typical "toaster model" for environments, his architecture shows that PCTE represents the data repository and integration services, while BMS represents the message services. He concluded that the advantages of the BMS approach are: it's conceptually simple; there is no significant performance overhead; it enables independent tools to cooperate, it doesn't conflict with PCTE, it enables tool interchangeability, and it is evolutionary in that it is easy to provide a message interface and use existing tools. The tools he implemented were a tool manager to start/stop tools, a monitor for message traffic, a development manager for navigating the object base, a graphical object browser, an attribute browser, the Softbench editor for editing contents of a PCTE object, and the Softbench debugger for debugging PCTE static context. He found that users tend to get lost very easily in the object base so a browser is a must. Also, version management is very difficult. The benefits of using PCTE are that is encourages a sound engineering approach to building and designing tools and the PCTE services are useful building blocks. He expects there to be more benefits for tools using the repository. PCTE does provide help for the tool writer although that person must make engineering tradeoffs. One problem is that Emeraude PCTE doesn't give the tool writer much of a feel for the cost of each operation to assist the writer in knowing which operation is more efficient. He feels that PCTE tool writers need: guidance on design and performance optimization, guidance on migration to ECMA PCTE in increments, a user's group to share experiences and to agree on schemas, complementary facilities of a BMS, and more support from the manufacturers for the standard. His overall conclusions were that BMS provides a low-cost, flexible approach to integration yet PCTE offers tighter integration via its repository. And that PCTE and BMS together offer an open standards framework and an evolutionary path for existing tools. And HP will follow this approach for its framework product. J. Bourguignon's presentation of EAST says that EAST fully exploits the PCTE functionalities. EAST provides support for a project data base via the PCTE repository facilities and support for the development process via the EAST process modelling and management capabilities. EAST provides management services for process, project, configuration, and documentation. Many third-party tools are already integrated including: Teamwork, AdaNice, CPX, ACT, C, Ada and Fortran compilers. On top of PCTE they built a browser, query facility, build tools, and data model editor. PCTE is not object-oriented, yet it gives the appearance of such. After 3 years of experience in using PCTE, he feels that PCTE can be used at 2 levels: tool integration and information system modeling for software development. He emphasized that his company seriously underestimated the amount of training required to learn PCTE. Understanding Unix is not good enough for learning PCTE. His entry level staff had difficulties learning PCTE. On the technical side, he suggests a naming policy is definitely needed for the data schemas and "easy links" are needed between the host operating system and the PCTE implementation. He gave statistics on the EAST information system in relation to PCTE concepts: 130 schemas, 221 object types, 395 link types and 676 attribute types. One question I raised was how did he expect EAST to change at EAST took on ECMA PCTE (whenever that's available). He said that Emeraude PCTE already has some ECMA features so he didn't see significant problems although security would definitely not be implemented. His conclusions were: the data model is the most salient PCTE feature; the tools are designed with openness in mind and tools data schemas MUST be published and standardized. For instance, in theory the tools that are implemented in another PCTE based environment, such as Entreprise II, cannot be integrated into EAST because their schemas are very different. In effect, PCTE gives a language for defining structures but no policies about the nature of the structures. The rest of this section are general comments. It is still not clear what kind of a product PCTE is and how it is expected to be marketed. For instance, is it part of a platform, an environment, a CASE tool coalition product? No one knows at this point and it is impossible to predict. At least hardware suppliers know they have to provide PCTE for their platform in order to sell their hardware in Europe. PCTE 1.5 is a complex model and so there are difficulties which were discussed: navigation is cumbersome, operating on fine-grain objects is not easy, data structure schemas are not standardized so can differ, metadata is not supported, cannot emulate certain kinds of data models such as relational and network model (as can IRDS), no direct support for encapsulation of object types with operations, users see the "delete" operation as very "painful", can't manipulate sets of objects, lack of query language (this would be a value-added service), schema definition sets are difficult to change (as the data model evolves), cannot browse into the object base, deadlock can happen, careless use of links can harm the database, and PCTE presents a different way of viewing things (e.g., an object is identified by navigation path rather than a name). "PCTE doesn't guarantee integration. There is a need to agree on the schemas for integration. Integration is a measure of agreement." ECMA PCTE addresses: security, version support, metadata support, processes as objects, composite entities, multiple inheritance, extended attribute types, definition modes in data schemas, notification of object accesses, and accounting. What will be the form of the PCTE world? Will PCTE be given free of charge to users or be part of some package such as a tool coalition within the CASE community? Will there be some unification of work between CASE/CAD/CAE/...? It is impossible to say or predict the answers to these questions now. What will be the key factors affecting the purchase of PCTE by an organization? What will be the migration paths to PCTE? There is clearly an intellectual jump in understanding PCTE so training is very important. What will be the technology transfer facilitators? Community acceptance, articulate advocates, good experiences, company signup and cost-benefit analysis. PCTE is the repository of the future for Europe but it's not obvious whether it is for the USA yet. Will PCTE, IRDS, others become standards in the USA? Will one of them be chosen at The Standard? 6. Personal Comments Disclaimer: these are my own opinions and do not necessarily represent those of my employer. ... When does an organization need to worry about PCTE? Now, since environments are available and tools will be available by '94. Who owns the tool integration problem? tool vendors, framework builders, customizers, end-users? It's not clear yet. But it could be the hardware vendors since they won't be able to sell their hardware in Europe (and probably the USA) unless it has PCTE, or an implementation exists. Tool coalitions (tool integration pacts between several vendors) are seen by some people as a short-term solution to the environment/integrated CASE tool needs in the USA. PCTE is seen as a longer term solution, although better tools and standard data schemas still need to be developed. Are we sure that environments of the future will have a repository? Yes, in my opinion, there definitely is a need for a global focus across tools and their data. This is evident just looking at CM tools: many of the tools encourage the user to have separate databases of CM information, but once users have the many databases, they find they don't have a global view across all databases. They have to access each database individually to find information. What's missing is a higher level view of all the data across the databases, a global view. Experience with PCTE and its environments will show the benefits and problems of using a common, global repository. Tool coalitions in the USA may eventually solve the global view problem by building some mechanism on top of the coalitions so then that will show the benefits and problems of not using a common, global repository. ... I wanted to know why there are now 3 vendors of PCTE (since there really used to be only 1 and only 1 was expected). Apparently the 3 existing implementations of PCTE differ in their quality and features they provide for the customer. Hence, we expect to see competition between the PCTE vendors. Who has been looking at PCTE? Many compiler companies have already been CLOSELY evaluating PCTE. US hardware vendors have been evaluating PCTE and realize that there is a need to provide PCTE on their platform so that they can continue to sell in the European marketplace. Instep will be publishing papers soon about their experiences with PCTE. ... I wanted to find out how groups have been experimenting with PCTE to determine suitable ways for us in our experimentation. Also, I wanted to know what the pitfalls of using PCTE are. The several groups I talked to ... all picked a particular tool integration scenario, such as, integrate a compiler and debugger on PCTE. The problems found included: PCTE has a long learning cycle; the most useful documentation seems to be Ian Thomas' tool writers guide; designing the data schemas is the most crucial task - they should not be written in haste; before being written, the process model for the tools to be installed must be well understood; then the schemas can be written; it is difficult to evolve schemas so it's best to get them right the first time. Each tool's schema should be written in mind with other tools' schemas. It is impossible to say when we will see the first implementation of ECMA PCTE. A full implementation is at least 3 years away. It is more likely that subsets of ECMA PCTE will appear and so customers will incrementally upgrade to these subsets. The availability of ECMA PCTE critically affects companies building environments. For instance, a technical problem concerns triggering mechanisms; environments need a triggering mechanism for implementing tasks yet the current implementations of PCTE do not provide triggers. So, do the environment vendors implement their own triggering mechanism now or wait for another 4 years when, hopefully, the ECMA PCTE may include such? It is a very tricky, strategic decision for environment vendors. PCTE is clearly a major force in Europe. All the major computer companies there have "bought in" to the technology. It is not clear how it will fare in the USA. But since many vendors in the USA sell to Europe, I expect PCTE will "take off" in the USA because of the existing momentum and availability of implementations. ... Susan Dart From: hm@csd.cri.dk (Henrik Maegaard) Subject: PCTE/ATIS Date: 22 Nov 91 09:49:18 GMT Organization: Computer Resources International A/S r George, Scott, and Eric, May a humble user of the technology share some concerns with you? This discussion is going in a completely wrong direction. We, the users of the technology are getting a little scared when the technology providers launch themselves into this kind of heated argumentation. As far as I'm concerned there are two important issues to discuss: 1) Acceptance of a set of standards by the system vendors, tools vendors, AND users. Softbench, ToolTalk, PCTE and ATIS being some. 2) Availability of tools and implementations that either adheres to accepted standards or can be expected to do so in the future. For a systems integrations house such as CRI both issues are important. But please note that we do not make our money by talking about Software Development Environments, we build them. And we need to build them based on mature technology. Also, we are not religious about one technology or the other. We have found that the object-orientation offered by Atherton is helping us being productive. At the same time we see that the PCTE standard is being more and more accepted. We expect to see, over time, the gap between the two to close. Meanwhile we occupy ourselves in providing solutions to our customers rather than fighting religious wars. Henrik Maegaard, Project Manager for the European Space Agency Software Development Environment for the Columbus Space Station. Computer Resources International Bregnerodvej 144 DK 3460 Birkerod, Denmark hm@cri.csd.cri.dk / From: marick@m.cs.uiuc.edu (Brian Marick) Subject: Re: ATIS Overview (long) Date: 21 Nov 91 17:27:08 GMT Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL As a person who builds tools, I am most interested in what I have to do to fit into ATIS. Are there published scenarios, case studies, or user's manuals? (As we've discussed in this group before, it's often hard to extrapolate from a raw specification to what will happen when you try to use it.) If there are no readily-available published descriptions, could an ATIS person build us one? To be concrete: a couple of students of mine built a copylefted branch coverage tool. It takes C programs and produces two files: - an instrumented C program. - a "map file" describing the instrumentation. The normal build process is then used to make an executable. The executable is tested in the normal way. It emits a log file. That log file is combined with the map file to produce a report about that test. Reports may be combined and summarized. Suppose we wanted to adhere to ATIS. What would we do first? What would we do next? How long would it take? What's the learning curve? Would the tool still be usable in non-ATIS environments? I suspect people on the user side would also be interested in how a user now uses the integrated tool. Thanks. Brian Marick Motorola @ University of Illinois marick@cs.uiuc.edu, uiucdcs!marick From: ericb@athertn.Atherton.COM (Eric Black) Subject: Re: ATIS Overview (long) Date: 22 Nov 91 18:34:18 GMT Organization: Atherton Technology, Sunnyvale, CA In article <1991Nov21.172708.10871@m.cs.uiuc.edu> marick@m.cs.uiuc.edu (Brian Marick) writes: >As a person who builds tools, I am most interested in what I have to >do to fit into ATIS. Are there published scenarios, case studies, or >user's manuals? (As we've discussed in this group before, it's often >hard to extrapolate from a raw specification to what will happen when >you try to use it.) Unfortunately, at this point there is no such document for ATIS. The official ATIS documents are pretty much either high-level overviews or dry specifications. My company has documentation such as you want for its product, Software BackPlane, but that includes numerous facilities which are not part of ATIS. Creating such a document for ATIS is on the list of critical tasks for ATIS continuing development. I expect to be taking a crack at that in the near future, and will be happy to post it here. That won't be for a while yet, as I will be out of town (out of the country, actually) all of December. Numerous apologies for starting what looks like may be a fruitful discussion and then disappearing. Please don't interpret my silence on the net during December as anything other than what it is: an extended business trip, with a whole week of vacation tacked on at the end. >Suppose we wanted to adhere to ATIS. What would we do first? What >would we do next? How long would it take? What's the learning curve? >Would the tool still be usable in non-ATIS environments? Quick-and-dirty short answers: 1) The usual rules for object-oriented analysis and design apply. Identify the object types (classes), the operations they perform, partition things cleanly. This part is still pretty much an art, not a science (no matter what some CASE tool vendors claim). Doing it for ATIS is no different, really. 2) Part of designing your types of course includes deciding where to insert your new types in the predefined type hierarchy; you want to maximize inheritance so as to minimize your work. Because ATIS allows but does not require multiple inheritance, you should expect to have single inheritance. 3) An additional step for ATIS (as opposed to a "traditional" OOPL) is the decision as to data object granularity. Keeping data at a level of granularity corresponding to files is straightforward, and makes a lot of sense if you are integrating an existing tool which uses files. If you are creating a new tool, consider carefully how you want the tool to store its data. Rather than having a big object with bulk data contents (which are accessed using normal file I/O) in which your tool places its fine-grained data, you may wish to have your tool store its fine-grained data as instance variables on the object using the datatypes ATIS defines. This lets other tools access that data as well without requiring them to know the internal data format of your file. Decisions to be made here include how fine-grained to make this data in instance variables, and whether the tool will use those instance variables in its operation or merely place a copy of the "real" data there so that other tools can get to it. For example, you might keep memory position-independent data structures in a file (the object's bulk data), read those structures into memory for speedy access during operation, and write the data back out to the file when done (or at the end of a transaction, or a user command, or whenever it's appropriate for the tool). This is nothing new; text editors do it all the time. One thing that ATIS lets the tool integrator/implementor do in addition is to place some of the data, whatever is meant to be available to other tools, in an easily accessible place -- instance variables on the object. 4) Various kinds of method function are provided by ATIS, including statically linked machine code, dynamically loaded machine code, interpreted scripts, and execution of a subprocess. Each is appropriate in some cases. Figure out how best to implement what you need. 5) The "method map" feature of ATIS means that you need to decide which roles are to have access to your new methods. If any user in any role should be able to invoke your new methods (by sending the appropriate inherited or new messages to objects of your new type), then simply attach the methods to the default method map. 6) Details about how you actually create your new types and new messages in a live ATIS system (you can do it at runtime, you don't take it off-line and recompile everything) make too long an answer for me to give right now. I'll do that when I get back in January, or someone else might jump in and do it while I'm gone. A quick runthrough is: - create the type, using the "new" message sent to ELEMENTTYPE - ornament your new type by defining new instance variables as needed - create any new messages, again using "new", sent to MESSAGE - create any new methods, either refinements for inherited messages or methods which implement new messages; again, use the "new" message, this time sent to METHOD - attach the new methods to the appropriate method maps, so that users in various roles either do or do not have access to the methods you have defined We have found that the learning curve is quite short to the first "plateau". Users in our tool integration course are able to do all the above for simple encapsulation integrations of existing tools by the second day. As is always the case, more complex and more flexible systems require more training. We have found that 3 months can make a person an expert, able to do almost anything, although perhaps not always aware that there may be a better way to do a certain thing. I think that's pretty good. As far as the tool being usable in non-ATIS environments, most of our tool integrations to date have been "non-intrusive", that is, encapsulating an off-the-shelf tool which expects to operate in a file system environment. Of course the tool is still usable in a non-ATIS environment. For tools which are implemented specifically for use with ATIS, it is possible to engineer the tool so it can also work without ATIS. One simple approach is for the tool, when invoked, to "stick its head up" and see if it's running in an ATIS environment or not. Probably the simplest way to do this is by passing a command line argument. I hope these quick answers are helpful. Once again, I apologize for the fact that I will be out of reach for a month or more starting after Thanksgiving, but I will be archiving comp.software-eng in my absence and will catch up on my return. Don't stop the discussion, just don't expect an answer from me for quite a while. From: ericb@athertn.Atherton.COM (Eric Black) Subject: Re: PCTE/ATIS Date: 26 Nov 91 22:10:32 GMT Organization: Atherton Technology, Sunnyvale, CA Well, said! Nonetheless, I've never been good at keeping quiet... In article hm@csd.cri.dk (Henrik Maegaard) writes: > [...] As far as I'm concerned there are two important >issues to discuss: > >1) Acceptance of a set of standards by the system vendors, tools > vendors, AND users. Softbench, ToolTalk, PCTE and ATIS being > some. We were not sufficiently diligent in keeping the discussion oriented toward technical and other substantive issues, understanding of which (and the tradeoffs involved) is required for real (as opposed to dictated) acceptance of any standard. But as you know, there is very little understanding of what PCTE, ATIS, CAIS-A, BMS, ABC, and whatever other acronyms you care to toss in, really are. At this point there is awareness that they exist, and that does cause confusion as unknown acronyms are included essentially as checklist items by well-meaning but ignorant (no negative connotation implied here) requirements writers. There is an international community working in these areas, but there is no exposure on USENET. Arguably, comp.software-eng is not the right place, but it is equally arguable that it is. Maybe we should start a discussion in comp.std.misc, and if the volume grows, create a new group such as comp.std.sde? >2) Availability of tools and implementations that either adheres > to accepted standards or can be expected to do so in the > future. This is always a "chicken-and-egg" kind of problem. Tool vendors will not make the significant investment required to implement or modify tools to operate in an environment until that environment achieves a certain level of ubiquity (i.e. available total market), and that won't happen unless tools are available. There are a few brave (and far-sighted, forward-thinking :-) tool vendors, such as Verdix, who are willing to make that investment once they are convinced along the lines of your first point, above. But you are absolutely correct, paper standards and endless discussions do not help the end user. This is always a problem. >For a systems integrations house such as CRI both issues are >important. But please note that we do not make our money by >talking about Software Development Environments, we build them. >And we need to build them based on mature technology. Also, we >are not religious about one technology or the other. It is critical for all to keep this in mind. Few end users are willing to bet their own ranch on "bleeding edge" technology. Results from actual experience and deployment in the field are what count. Something brand new is risky; if new packaging of old and familiar technologies can solve the problem better than the old technologies in their old forms, then this is much less risky (to the extent that the packaging, the new part, is a smaller fraction of the whole). Kind of an engineering trade-off... >We have found that the object-orientation offered by Atherton is >helping us being productive. At the same time we see that the >PCTE standard is being more and more accepted. We expect to see, >over time, the gap between the two to close. Meanwhile we occupy >ourselves in providing solutions to our customers rather than >fighting religious wars. Atherton is incredibly proud of the job that CRI has been able to do for the European Space Agency on the Columbus project. Of course, we believe part of that is because of the architecture of Software BackPlane, and it's good to hear you say that. That is the basis of the original ATIS, and the whole reason was that we believed it would make the job easier for environment builders such as CRI. We also expect to see PCTE achieving a high degree of ubiquity in the future. That doesn't help customers today, though. A clear migration path from today to tomorrow exists, even if some parts of the path are obscured by shrubbery from our present vantage point. Religious wars don't help clear the path, and arguing about the destination is pointless, especially if there is a tidal wave rising behind you! From: gt@hpfcbig.SDE.HP.COM (George Tatge) Subject: Re: PCTE vs. CAIS-A Date: 2 Dec 91 13:31:11 GMT Organization: HP SESD, Fort Collins, CO In comp.software-eng, ericb@athertn.Atherton.COM (Eric Black) writes: >This discussion has all the earmarks of an incipient flame fest, but at >the risk of fueling it further, I'd like to comment publicly, George. Forget the flaming, let's just keep it to a good old fashion disagreement. >Well, you were there for the early part of it. HP left CIS largely >because CIS refused to push HP's proprietary SoftBench product as the >single one-and-only standard for integration, in the [now acknowledged >to be] mistaken belief that messaging was sufficient and that a >repository was unneeded. As we all know now (!), not only is there >room for both, but actually both are required. Yes, I was there, and you were not. Your accusation that HP left "because CIS refused to push HP's proprietary SoftBench product..." is, quite simply, a lie. At that time, long before HP purchased Apollo, it was Apollo who was pushing hard on their technology (code named ACTIS). As a matter of record, I was chastised openly in the group for NOT presenting the SoftBench technology for consideration. In fact, the loudest complaints about our LACK of putting forth SoftBench technology came from Bill Paseman (then, VP at Atherton). I have no idea where you got your information but it is 180 degrees out of line with what happened. HP, Sun and others left simply because it seemed like endless arguments to no avail, with neither Atherton, nor Apollo willing to compromise. >Hope you've got more than the framework up on your house, now that >winter's setting in! A framework by itself doesn't make a warm toasty >environment in the face of the elements! How right you are!! I'm still working on the framework and it leaves you completely exposed to the frigid wind (wind chill index at -28 the other day). I really wish I had a complete, warm environment! g (it's cold in them thar hills) t From: shields@stars.reston.unisys.com (Tom Shields - Unisys) Subject: ECMA-162 Draft 9 Issue 1 (PCTE Ada binding) available for anonymous FTP Date: 14 Feb 92 03:08:05 GMT Organization: Paramax Tactical Systems - STARS Program An electronic copy of ECMA-162 Draft 9 Issue 1 (ECMA PCTE Ada binding) is now available for anonymous ftp from "stars.rosslyn.unisys.com" in the ~ftp/pub directory as file ECMA_162.tar.Z (compressed tar file). This file is 350039 bytes in this form; its uncompressed form requires 1171456 bytes, and it requires 1139Kbytes to extract under SunOS. Remember to set your FTP file transfer mode to "binary" to get this file! I will update this file as updates are provided by ECMA/TC33/TGEP. Please feel free to retransmit this message to other interested parties. From: ewoods@hemel.bull.co.uk (Eoin Woods) Subject: Re: PCTE and ATIS Organization: Bull HN UK Date: Mon, 22 Jun 92 11:46:46 GMT Jenny.Rowland@levels.unisa.edu.au writes: >I am interested in information on: >1. availability and cost of PCTE and of ATIS, especially to universities and > research institutes; For a PCTE implementation (called "EAST") - note that PCTE is a standard, not a product - contact SFGL. SFGL, 14 Rue de la Ferme, 92100 BOULOGNE, France Tel: +33-1-46-94-77-77/00 FAX: +33-1-46-94-77-99 Email: Beatrice.Mauger@sfgl.sfgl.fr From: ronp@oodis01.af.mil (Contractor Ron Dr. Peterson) Subject: Re: PCTE and ATIS Date: 24 Jun 92 15:36:48 GMT Organization: Hill AFB, Utah Actually, EAST is a Software Engineering Environment _based_on_ PCTE. In particular, EAST uses the Emeraude V12 implementation of the PCTE 1.5 standard. For information in general about PCTE, you may want to contact: European Computer Manufacturers Association (ECMA) 114, Rue du Rhone CH - 1204 Geneva Switzerland tel.: +41 22 735 36 34 or line up some commercial training/consulting from: Software Design & Analysis Inc (SDA) 1113 Spruce St., Suite 500 Boulder, Colorado 80302 tel.: (303) 444-9100 For information on the Emeraude V12 product try: GIE Emeraude c/o Bull S/A 68, route de Versailles 78430 Louveciennes France Two other companies are now providing implementations of PCTE: Heuristix (India) -- a partial implementation of PCTE+ Verilog (France) -- a VAX VMS version of PCTE 1.5. Another SEE based on the Emeraude implementation is Syseca's Entreprise II. For more info on that one contact: Syseca 315, bureaux de la Colline 92213 Saint-Cloud France Tel.: +33.1 49 11 70 00 For more information on environments (SEEs), you can request the Software Engineering Environments Report >from the USAF Software Technology Support Center at Hill AFB, Utah. Tel.: (801) 777-8045 or 1-800-392-1798 From: kissman@sda.com (Mark Kissman) Subject: Re: PCTE and ATIS Date: 24 Jun 92 13:28:14 GMT In <1992Jun22.114646.17849@hemel.bull.co.uk> ewoods@hemel.bull.co.uk (Eoin Woods) writes: >For a PCTE implementation (called "EAST") - note that PCTE is a standard, not >a product - contact SFGL. "EAST" is an environment product built on top of a PCTE implementation from GIE Emeraude. This implementation is of PCTE 1.5 which is *not* a standard. The standard version is ECMA PCTE. SDA distributes the Emeraude implementation (called V12). For more information, please contact me. From: Jenny.Rowland@levels.unisa.edu.au Subject: summary of replies : PCTE and ATIS implementations Date: 24 Jul 92 08:01:21 GMT Organization: University of South Australia Recently I asked about PCTE and ATIS. > I am interested in information on: > > 1. availability and cost of PCTE and of ATIS implementations, especially to universities and > research institutes; > 2. any attempts at building environments (either commercial or research) > using PCTE or ATIS and comments on ease of doing so/success/ease of tool > integration/etc..... Here is a summary of the replies: ----- From: IN%"goutal@hammer.crim.ca" 6-JUL-1992 06:39:31.60 CC: Subj: RE: PCTE and ATIS Hi, If you need informations about PCTE you could reach Leigh Grubdy from PCTE users Group e-mail L.grundy@bull.com There is a mailing list about PCTE (pcte@bull.com) and there is also a free newsletter about PCTE. ---- From: IN%"hodges@stars.boeing.com" 7-JUL-1992 05:30:20.67 Subj: RE: PCTE & ATIS Jenny, I am supporting the US STARS contract for Boeing, We are building an environment using the DEC CDD/R, CDD/A products that support the ATIS specification. The results to date have been outstanding we have a simple prototype that we are building upon incrementally. Other STARS contractors are building on Emeraude and EAST foundations. I cannot attest to their progress thus far in that they have not demonstrated it to the world. In addition to STARS there are several successful implementations of ATIS environments in existence, two are offered commercially: 1) Verdix APSE is built upon Atherton based technology Contact: Tim Ruhe: timr@verdix.com 2) CRI (Denmark) is offering the integrated environment that they built upon Atherton for the European Space Station Columbus as a commercial product. Contact Henrik Maegaard: hm@csd.cri.dk 3) Loral Aerospace has built a proprietary environment upon Atherton. It appears to be comprehensive but there is not much firm information available. Contact: Bill Sweet: (408) 473-5027 If you want to follow the STARS work you can request to be added to the mailing list of our newsletter by e-mailing a request to anita@stars.rosslyn.unisys.com. Also you could plan to attend our STARS 92 conference in Washington D.C. 8-10 December 1992. You also can subscribe to our bulletin board and our library of released documents and prototypes by contacting: MR. LAWRENCE JACOWITZ IBM CORPORATION (304) 594-1762 DIR ASSET BLDG. 2600, SUITE 2 2611 CRANBERRY SQUARE MORGANTOWN, WV 26505 FAX SECT: jacowitz@wmavm7.vnet.ibm.com (304) 594-3951 ----- Date: Mon, 22 Jun 92 10:21:40 MDT From: kissman@sda.com (Mark Kissman) Subject: PCTE and ATIS >I am interested in information on: >1. availability and cost of PCTE and of ATIS, especially to universities and > research institutes; SDA is a distributor of Emeraude's implementation of PCTE 1.5 (this is virtually the only commercially available implementation at this time). It runs on most of the UNIX platforms. A standalone license is US$8,180 (US$1,227 for qualifying universities) and documentation is US$550 plus shipping. Annual maintenence contract is 15% of license cost or US$1,670 minimum. If you are interested a more detailed product description, please let me know. >2. any attempts at building environments (either commercial or research) > using PCTE or ATIS and comments on ease of doing so/success/ease of tool > integration/etc..... SDA is aware of several organizations building environments on PCTE (mostly US DoD). Two French companies, SFGL and Syseca are building enviroment products based upon PCTE (EAST and Enterprise II). ----- Date: Mon, 22 Jun 92 14:10:04 PDT From: paul@hal.com (Paul Sander) Subject: RE: PCTE and ATIS Organization: HaL Computer Systems I'm afraid I can't help much with PCTE (or PCTE Plus), but I do know that there are two implementations of ATIS. One is from DEC, but I understand that it is expensive, performs poorly, and it's quality of implementation isn't all that great. The other is Atherton Technology's "Software BackPlane" product. It's a commercial product and costs a couple of thousand US dollars per seat. Software BackPlane goes beyond ATIS in its object oriented-ness also. You can reach them by writing to: Atherton Technology 1333 Bordeaux Drive Sunnyvale, CA USA 94089 Their telephone number is (408) 734-9822. They are also quite familiar with PCTE Plus, so you might write to John Gregory, gregory@Atherton.COM to see how they might be supporting it. Finally, the CIS committee (which wrote the ATIS document) is now X3H6, which is part of ANSI. Eric Black is involved with that effort, and you can reach him at eric%mirador@sun.com . Date: Thu, 2 Jul 92 18:19:07 PDT From: "Keith Anderson: CASE marketing, Australia, New Zealand 03-Jul-1992 1118" Subject: ATIS, PCTE Hi Jenny - I think we meet once at ICSEA? As you will have heard by now, PCTE and ATIS are both names of standards efforts. Atherton Technology (California) have a product that they claim is ATIS compliant, and of course Digital is now shipping CDD/Repository on VMS which is based on the ATIS work. CDD/R evolved from the ATIS work originally done together by Digital and Atherton, but it has evolved and so names and some capabilities are different. I can't yet publicly say what Digital is doing with PCTE except that we have said that we are actively working on integration of PCTE and CDD/Repository technologies.