Paris Metro riding DCE as route to distributed; early user migrating Unix applications; OSF, others to supply missing pieces - the Regie Autonome des Transport Parisiens' use of the Open Software Foundation's Distributed Computing Environment - Global Software Experiences

Early user migrating Unix applications; OSF, others to supply missing pieces

Some time ago, the information systems (IS) managers at the Regie Autonome des Transport Parisiens (RATP), which runs the Paris subway, or metro, decided it was time to move from a "politique fournisseur" (supplier politic) to a "politique utilisateur" (user politic). In short, they needed to put their users' needs first.

The change meant trying to create what most vendors claim their systems provide -- a "distributed" information architecture that would let RATP users access data from a variety of Unix-based applications, said Janik Taillandier, director of RATP's information systems and telecommunications.

Most of RATP's mainframes are from Paris-based Groupe Bull. The company has been primarily a Bull site for the past 20 years. However, RATP's systems also include machines from Digital Equipment Corp., Maynard, Mass.; Hewlett-Packard Co., Cupertino, Calif.; Sun Microsystems, Inc., Mountain View, Calif.; and IBM.

Now RATP is moving some of its personnel, accounting and administrative mainframe-based applications into a distributed Unix environment, which will eventually comprise 150 systems. It plans to continue buying Unix-based computers from a range of selected suppliers, Taillandier said.

With a large number of heterogeneous Unix systems, said Taillandier, the organization determined it needed to "go further than Unix" to ensure application interoperability. RATP then decided to experiment with building an information architecture based on the Distributed Computing Environment (DCE) from the Open Software Foundation (OSF), Cambridge, Mass.

DCE is an integrated set of services that support development, use and maintenance of distributed applications. It is based on technology from HP, DEC, Siemens-Nixdorf Informations-systeme AG, Munich, and Transarc Corp., Pittsburgh. OSF designed the DCE architecture and integrated the technologies.

Established in 1948, RATP operates the world's second longest metro, after New York City, as well as the city bus line. It boasts 38,000 employees and an annual budget of $3.6 billion. RATP's IS division, staffed by approximately 800 people, maintains a budget of $80 million. The company's multiple DPS Bull mainframes are located in two production centers, north and east of Paris. One center is dedicated to personnel systems, the other to commercial systems.

MORE THAN 'TOUCH OF A KEY'

Taillandier said RATP has no target date to finish migrating to the heterogeneous, distributed architecture. "We have a few million lines of Cobol code, so it's not possible to do that with the touch of a key," he said.

So far, the group is operating several of the migrating applications on a limited basis, on approximately 20 Unix systems.

One personnel application for new hires, for example, is not directly connected to the personnel system interface. It operates on the Unix system with a database of 20,000 names, making frequent file transfers to the mainframe, Taillandier said.

"The people on this system are able to use their workstations for DPS emulation," he said. However, he added, "It's not yet a distributed application because they're not using RPC [remote procedure calls] to automatically access the data."

Ensuring that such remote access is swift and painless was a large part of the motivation for experimenting with OSF's DCE technology, said Pascale Blanc, an IS engineer. "I started my first training sessions on DCE and its services with Bull in January 1992. I started programming in March," said Blanc, who is running the experiment.

"There are many, many things to look at in this product. There are some functions that don't work, that aren't very advanced," she said. "It's not easy to jump right in. [DCE] offers the ability to do lots of things, but just the process of familiarizing yourself with the technology and with all of the primitives is long. The documentation alone is enormous; five big, big books!"

Blanc has spent her time developing an ensemble of client/server programs using DCE's RPC and Threads service. OSF chose the RPC and Threads implementations from HP-Apollo and DEC, respectively.

The tools came in an early version of DCE that RATP received from Bull. It represented "an experimental snapshot from mid-1991 from OSF," said Taillandier. Bull, along with other vendors such as HP, were early adopters of DCE.

Using the initial version of DCE, Blanc has been unable to get the client/server applications she developed on two Bull DBX/2 Unix machines to run on an HP9000 Series 700. The Series 700 runs HP's later version of DCE. "Right now, the HP machine is isolated from the two Bull machines. I'm in the middle of trying to find out why they don't work on the HP," she said.

"There are some things that work, like compilation. All of the RPC primitives work well at the moment of exporting the interface, and also at the client/server level. When the server listens for the client, it's okay, and when the client looks for the server, that's okay. But when the client makes an [RPC] with the name of the operation to be executed by the server, it doesn't work. It's a porting problem," she said.

It is impossible to predict, she added, whether the problem will disappear when RATP installs the new version of DCE, which will arrive soon from Bull.

DCE includes several other services. There are two service directories: The local Cell Directory Service (CDS) is based on technology from DEC, and the Global Directory Service (GDS) is an implementation from Siemens, based on the X.500 standard. The Security Service implementation came from HP, based on Kerberos from the Massachusetts Institute of Technology, Cambridge, Mass. HP also contributed technology for the Diskless Support Service. The Distributed Time Service (DTS) is based on DEC technology. And the Distributed File Service (DFS) technology came from Transarc, based on the Andrew File System from Carnegie-Mellon University, Pittsburgh.

"At the level of directory, I've used the CDS to define the machines in the cell," Blanc said. She has not tested the CDS yet "because it involves localization between cells. The CDS interoperates with the GDS when it locates a service in its own cell." She has briefly examined the CDS-Control Program, "which allows me to look at a small database of the servers that have been recorded."

Next on Blanc's experimentation list is the security product. Neither the diskless support nor the DFS functions are ready for experimentation, she added. The problem with DFS, said Taillandier, is that "it's based on the Andrew File System which is a complicated, powerful and robust product, but it's difficult to stabilize." DFS's arrival, said OSF, is scheduled for June 1993.

Taillandier said it will probably be mid-1993 before the RATP has a handle on DCE's range of capabilities. "Testing DCE means more than just compiling the program to see if it runs [on another machine]," he said. RATP also needs to see if the program "works when a communication line goes down."

In order to build a new information systems architecture in a reasonable amount of time, using DCE as the foundation, the RATP will not build every function from scratch. For distributed online transaction processing, for instance, Taillandier said the company will begin experimenting with Transarc's Encina by year-end.

"We consider the services provided by DCE as first class, but at quite a basic level. Since the company business is to transport people and not to build an information system, we will probably use the finished product [Encina] on top of DCE for distributed OLTP," he said.

OSF's DCE "substantially establishes" the base for delivering commercial quality, distributed OLTP applications, said Jeffrey Eppinger, Transarc's manager of transaction processing architecture. "However, many customers will require additional services. Encina products provide programming, runtime and administrative services necessary for networks of computers to perform complex processing on heterogeneous, distributed data," he added.

Specifically, the Encina Toolkit extends the DCE core services with basic functionality needed to support the transaction model. Other Encina products, such as Encina Monitor, Structured File Service and Peer-to-Peer Communication Services, use the toolkit as a foundation to provide the additional functions necessary for commercial OLTP. Transarc began shipping its source DCE-based version of Encina in February, and has been shipping Encina code to certain end-user customers.

"If Encina works, we would begin building the [distributed OLTP] system using about 200 people," said Taillandier. "We will use other DCE-based products where they are applicable. With those, we should have a lot of the bricks for the wall, but we will still be missing the distributed management pieces, such as how to do distributed backup and software maintenance."

The OSF's Distributed Management Environment (DME), which addresses these areas, is not ready yet. According to OSF, DME services will be available around the third quarter of 1993. The framework for building applications is expected at year-end 1993.

Notwithstanding such gaps, the RATP's Blanc said DCE has evolved since RATP began the project. For example, she said, "The documentation now has lots of practical advice for application development that it didn't have at the beginning."

"DCE is a giant step forward," said Taillandier. "The problem will be to have people culturally migrating [from a hierarchical Cobol environment]. But they have certainly picked the best parts of technology and glued them together."

[Johnston is a freelance technology writer based in Paris.]

COPYRIGHT 1992 Wiesner Publications, Inc.
COPYRIGHT 2004 Gale Group