The 16 examples of successful client/server and system automation projects given in this chapter are introduced in this section. Most of the examples include figures that summarize the system
configurations of the environments. Later sections provide technology discussions about these organizations and explore systems development and maintenance issues.
A major pipeline company transports around 1.1 MMCF of natural gas a day at all times, day and night, to ensure that Californians have enough electricity to live their lives in relative comfort. This wholly owned subsidiary of a $13.5 billion energy
company—the nation's largest provider of natural gas—found itself examining a changing marketplace, redefining its business goals, and determining how to support its new focus.
After focusing on business and operational changes, the company began to define what it would take to become a world-class servicer of natural gas shippers. They knew they needed to improve pipeline processes by optimizing gas volume and monitoring
throughput to prevent imbalances. They wanted to change their invoicing process and simplify other functions. This process of business reengineering would serve them well. An obvious next step was to review the company's computer systems.
At a time when the pipeline company needed improvement in quality and service, it needed flexibility in its systems. The existing systems ran on a number of IBM and DEC platforms—with some redundancies and delay between critical activities and
information availability. Review of their systems also revealed that technology had come a long way since these systems were developed in 1987. What this gas pipeline transportation company needed was streamlined systems for streamlined business processes.
Using a LAN running Novell NetWare Version 3.11, Microsoft Windows 3.0 with Powersoft's PowerBuilder 1.0 development package, a Sybase database engine, and a UNIX operating system for the database server, the company has implemented a transportation
contract system; a nominations, scheduling, and allocations system; and a customer service interface system (see Figure A.1).
The United States Postal Service (USPS) competes with commercial companies for provision of expedited mail service. The Comprehensive Tracking and Tracing (CTT) system's primary purpose is to track Express Mail to improve the competitive position of
this product for USPS.
CTT is used to monitor the movement of an individual piece of Express Mail from the time it enters the postal system (acceptance) through final delivery. Whenever a significant action occurs with a piece of mail, an event is generated to record that
action. Events occur at acceptance, as mail moves through intermediate points (enroute events), when the mail arrives at the postal unit for delivery, and finally when the mail is delivered (or a delivery has been attempted). (See Figure A.1.)
Figure A.1. The technical architecture of a major pipeline company's NSA system.
The heart of the data collection system is a series of handheld laser scanners, located in 16,000 postal locations, which read the bar-coded label identifications contained on each Express Mail piece. When fully deployed, scanners will capture almost
all event data.
CTT is a high-volume transaction system that uses client/server technology. The handheld scanners (client component) collect and then send data to an IBM mainframe host. The data on the host is stored in a DB2 database for inquiry and control. Figure
A.2 depicts a high-level view of the system components.
The Los Angeles Fire Department (LAFD) is a full-service metropolitan fire department. The LAFD responds to emergency medical service (EMS) calls as well as to fire and rescue incidents. Approximately 75 percent of all calls for service are for EMS
incidents. LAFD's 55 rescue ambulances transport patients to hospitals and provide paramedic services to patients.
Figure A.2. The components of the postal system's Comprehensive Tracking and Tracing Service.
The Fire Command and Control System (FCCS) II application is a customized computer-aided dispatch (CAD) program. The system is designed to fulfill all dispatch-related functions for the fire department. These include, among many other features,
recording the initial incident, dispatching the incident to the various units, and ongoing monitoring of the incident and the units.
FCCS II is a large system that encompasses workstation technology, client/server technology, and a DB2 back-end database. It is particularly interesting because it implements a fault-tolerant application using the client/server model and standard PC
workstation technology. In particular, the client workstations provide the capability of full-function dispatching without requiring the mainframe host to be available.
The system uses 70 IBM PS/2 workstations with Token Ring networking, 400 Motorola Digital Terminals (MDTs) and Travel Pilots (portable computers) located in the vehicles, and the Fireworks CAD software package from Lynx Graphics. Various interfaces to
an emergency service (E911)—SL-1/Positron, a Metromedia public pager system, a Centracom II radio system, an ADT 4504 display clock, a Veritrac 60-track voice recorder system, a digitized voice system, and communications to the city's IBM 3090
mainframe and to 114 separate fire station locations—are controlled by a set of IBM PS/2 Model 95 workstations.
The Superior Court of the County of Los Angeles has approximately 250 courtrooms located in the central courthouse and in the nine district courthouses around the county. The court employs approximately 300 judges for a system of day and night court
sessions. Its current load of more than 45,000 felony cases per year makes the court among the busiest in the world.
The Automated Case Tracking System (ACTS) is being designed and developed to provide automated support for the Los Angeles County Superior Court. The support provides an environment that standardizes and streamlines the workflow. This standardization
eliminates redundant manual effort and duplication of data entry, and reduces paper flow. The automated support also enhances the accuracy, consistency, and timeliness of management information reports. ACTS provides the court, staff, and litigants with
quick access to case information.
ACTS is a large system that uses client/server technology. Each court location contains multiple workstations attached to multiple Token Rings. Data is exchanged between these locations and the host IBM system via an extensive communications network.
Figure A.3 provides a high-level view of the system components.
The Los Angeles County Department of Public Social Services administers county, state, and federal welfare programs to local residents, including Aid to Families with Dependent Children (AFDC), food stamps, Medi-Cal, General Relief, and Greater Avenues
of Independence (GAIN).
GAIN Employment Activity Reporting System (GEARS) was designed and developed to support the GAIN welfare program. The purpose of the program is to provide a source of education and training to enable welfare recipients to find employment. During the
education and training programs, GAIN provides supportive services in the areas of transportation, child care, and ancillary expense payments. GEARS supports 250 GAIN case managers who coordinate an active caseload of 30,000 participants and a total
caseload of 220,000 participants.
Figure A.3. The components of the Los Angeles Automated Case Tracking System.
GAIN represents a large system that was developed under a very aggressive schedule. Although GAIN does not yet use client/server technology, it was developed using a systems development environment and uses remote network management servers that are
applicable in a client/server environment.
A public telephone communications supplier provides service to 4 million customers in a service area that covers approximately 40 percent of southern California and portions of northern California.
The objective of the Service Order Load and Retrieval (SOLAR) project was to provide a user-friendly, online order system that would simplify telephone service order processing and provide accurate and timely order information without rewriting the
existing systems. The major benefits of the system are an overall improvement in the quality of service to customers, a reduction in the number of order-processing personnel, and a dramatic reduction in the degree of training required for order-processing
personnel to become effective.
SOLAR handles the data entry requirements of the order-processing centers (OPCs), business service order centers (BSOCs), and customer service order centers (CSOCs). SOLAR automates service order issuance, routing, rate calculations, and file
maintenance, and also provides interfaces to many related systems.
SOLAR is an example of a large system that was built in a time-compressed schedule using a systems development environment. This system was designed to front-end existing batch systems to provide the end user with a better interface to the old systems,
without rewriting them. Figure A.4 depicts the conceptual view of the system.
Figure A.4. The components of the Service Order Load and Retrieval project.
The Winnipeg Fire and Ambulance Departments are separate organizations, each with its own dispatch and operational characteristics and requirements. FACCS is designed to allow the departments to share some common dispatch processing, although they
remain separate entities.
The Fire and Ambulance Command and Control System (FACCS) is a computer-aided dispatch (CAD) system that uses workstation pro-cessing, graphical user interfaces (GUIs), and client/server technology integrated with relational databases to support
administrative and reporting requirements in the same platform.
The primary FACCS token ring is composed of 10 IBM PS/2 workstations that provide the CAD functions, interfaces to existing fire and ambulance LANs, and communications to 27 fire stations and nine ambulance stations. Dispatching is done from
workstations running on a standard Token Ring LAN using a proprietary messaging protocol. The protocol implements a fault-tolerant application in which all workstations contain the same data. Data from the workstations is passed to an Oracle server for use
by the fire department and the billing administration. The Ambulance Department uses the IBM PC Database Manager product for its records. This data is then usable from workstations on the fire and ambulance LANs.
Dispatchers on the FACCS LAN may query data that exists on either the Oracle or Database Manager server and display this information on their workstations. Figure A.5 depicts the major components of FACCS.
Figure A.5. The components of the Fire and Ambulance Command and Control System.
The Agricultural Chemical division of Esso Chemical Canada (ECC) is located in Redwater, Alberta, with a Marketing office in Edmonton. The division produces approximately 1.6 million tons of fertilizer products annually, marketing and distributing to
customers around the world. Peak demand for products in the spring and fall seasons places tremendous strain on the marketing and distribution resources of the organization.
The System for Customer Appreciation and Marketing Potential (SCAMP) provides the operational components and the information environment required for ECC's marketing and sales business area. The system provides a dual operational-informational
environment that improves the quality of and access to information.
The development and operation of the system uses a client/server architecture, with Sun and IBM workstations and Sun servers. ECC uses the Oracle DBMS on the Sun servers. Figure A.6 provides a high-level view of the platforms.
Figure A.6. The technical environment of Esso's System for Customer Appreciation and Marketing Potential.
Syncrude Canada Limited is an integrated operation that produces synthetic crude oil from an oil sand deposit. The operation—consisting of an open pit mine, an extraction plant, a bitumen upgrader, and a utilities plant—can produce 55 million
barrels of synthetic crude oil per year.
The Slope Inclinometer System (SLOPE) was developed to assist the geotechnical engineers in determining ground movement near the edge of the pit in order to ensure the safety and productivity of the huge draglines used in the extraction of ore from the
mine. This is accomplished through the capture, analysis, and reporting of ground movement data in a responsive LAN environment, using intelligent workstations equipped with a graphical user interface (GUI). SLOPE uses a client/server architecture and a
mainframe DB2 database for data archiving. Figure A.7 provides a high-level view of the system components.
Figure A.7. The components of Syncrude Canada's Slope Inclinometer System.
The parent corporation of this large North American firm maintains a base of approximately 650,000 customers. During the spring of 1988, a staff of five senior executives left the home office. Their mission was to reengineer the business processes for
accidental death insurance and develop innovative ways and means to satisfy the parent company's clients' needs for insurance products and services, enabling the company to meet aggressive financial growth objectives.
This project took a new approach in meeting the company's data processing requirements for customer service. The project's mission was to build a customer service prototype and a fulfillment and billing system. To accomplish this, it was determined
that a model office should be created off-site as a research and development tool. This small-scale office was used to prototype concepts and was then able to implement proven new ideas incrementally in a "roll-out" mode in the home office. The
selected technical platform consisted of an Apple Macintosh/DEC VAX platform, using Oracle as the DBMS and Hypercard to build an object-oriented prototype.
The model office environment was designed to test new ideas for communications with the parent company. The overall application environment was meant to be very conceptual, dynamic, and iterative. The previous system did not provide statistics and
therefore did not provide suitable information for comparison with the model office. The model office is now the vehicle to generate information on future capacity needs. Figure A.8 provides a high-level view of the system components.
Figure A.8. The components of the Life Assurance Company model office.
In January 1991, Blue Cross of Atlantic began making the transition from developing and maintaining its business applications on an IBM 3090 M200 mainframe (at a very high cost in CPU cycles) to developing and maintaining them on IBM PS/2 workstations
in an OS/2 client/server networked environment. Blue Cross networked PS/2 Model 50s, 55s, and 70s. The transition took place using a two-phased approach over a course of eight months. Figure A.9 shows the development environment platform.
Figure A.9. The components of the Blue Cross of Atlantic client/server network.
In the first phase, a workbench environment was set up to assist in migrating OS/VS COBOL programs from the mainframe to workstations for maintenance activities. After maintenance was completed, the programs were remigrated back to the mainframe into
production.
A fundamental problem the Saskatchewan Liquor Board, SLGA, faced was obsolescence. NCR was no longer manufacturing the point of sale hardware in their retail operation. Servicing of this hardware consisted of cannibalizing older machines to keep the
existing machines running. As well, the VAX hardware used in their head office was operating at capacity. SLGA gave consideration to several alternatives before choosing a client/server architecture. This architecture fits well with the business goal of
giving each of the 84 retail stores more autonomy and, in the process, gives the SLGA the state-of-the-art in Liquor Boards.
The SLGA wanted to move into the new world. This meant moving to a client/server architecture. The Windows platform they are using for the head office functions provides them with a very intuitive access to their data. This also provides for a more
timely access to their data allowing them to make better decisions. This interface also presents the data in a manner that is much more flexible. This enables user-driven reporting, giving the user the capability to access the data in a way that makes most
sense at the time. This is a tremendous step from the batch reporting process to which they had become accustomed.
The Department of Child and Family Services provides family support services throughout the province of Manitoba. As in any jurisdiction, the social workers have the difficult task of tracking the requirements of families dealing with stress,
addictions, and other family problems. Social Workers spend most of their time in the field, yet a significant trail of paperwork must follow documenting the actions taken by the case worker, teacher, and police. This provides an audit trail of case notes
in the event that the case requires legal action at a later date. Either participants asking for help or a concerned agency may initiate activity in the Child and Family Services system.
Historically, the various jurisdictions have been very protective of the information maintained by the case workers. Significant problems arise caused by large number of families in need of support services being transient. This causes cases to
"fall through the cracks" as information remains local to a jurisdiction. It was often a problem to identify people previously in contact with agencies in different jurisdictions, accessing data, or establishing a dialog with the former case
worker.
The new system demands improvements in several areas. One of the key features in the new system is the standardization of program delivery. Through automation, the social worker can follow the legislated policies very easily. This provides a consistent
program delivery across the province. The process also improves the social workers' effectiveness through the building of workflow management into the system. The sharing of data across jurisdictions enhances the overall effectiveness of the program. By
having a clear and concise case record available, case workers are able to identify and track cases that used to fall through the cracks.
The system uses a client/server implementation for several reasons. The system requires data to have a central repository for continual tracking across a wide distribution base of jurisdictions while still enabling access to the data while the system
is offline. Client/server architecture provides this capability. The system requires an easy-to-use interface with integration to existing office standards such as WordPerfect. The system requires the central sharing and integration of case management
report data and includes this in management reports for online viewing and printing. Client/server architecture provides this capability.
The Ministry of Finance (Hacienda) in Mexico receives approximately 23,000,000 tax returns annually. Each form required substantial data entry on behalf of both the banks and the Ministry itself. The cost of manual data entry was exceeding $100,000,000
annually, with the banks being paid an average of $1.60 per form.
A scalable client/server architecture was designed to handle varying volume requirements. A base architecture also was established. As site volumes varied, replication of the architecture was able to meet the demand. The site with the greatest volume
requirements, Mexico City, duplicated this architecture four times. Each configuration featured data entry through image scanners and optical character recognition. An optical disk autochanger provided the storage of images. In addition, key entry from
images provided post-recognition edit checking, and networked access, over both local- and wide-area networks.
The Mexico City site configuration consists of four processing lines networked using an FDDI Backbone. Each line consists of a Ricoh IS-520 Scanner capable of scanning both sides of a form in two seconds. HNC and Xerox ScanWorks Optical Character
Recognition, with an HP 735 File Server, perform Database and queue management at 11 Key Edit Workstations. To support image storage and printing requirements, the sites also have two HP Optical Disk Library Units and two laser printers.
La Hacienda incorporates client/server technology throughout its architecture. It demonstrates the scalability of a client/server architecture and provides sophisticated work flow management that looks for available processors to load balance much of
the background processing.
The client/server architecture is very cost-effective for this type of system. It is quite clear that processors are becoming faster and cheaper at a rapid rate. Client/server architecture takes advantage of this trend.
Scalability comes with client/server architectures. This meant Hacienda was able to increase throughput by networking together subsystems of a convenient size. There are great savings in being able to do this. For example, the one-image-a-second
scanner was about one-third the price of its two-images-a-second competitor. Because the remote sites did not require the higher throughput scanner, they were able to save the price differential seven times. The work flow management software enables
Hacienda to take advantage of cheap processing power in an inexpensive manner.
The self-sufficiency Project is a seven-year research demonstration. The program's purpose is to test the effectiveness of an earnings supplement for qualified participants. The program focuses on the single-parent Social Assistance recipient who
agrees to take a job and leave public assistance. The program offers a supplement to each qualified individual for a limited three-year period. It is employment-driven because only those who work full-time will be eligible. It is also generous enough to
make work financially preferable to public assistance. The project operates out of offices in New Brunswick and British Columbia, with a payroll office in Halifax, Nova Scotia.
An interesting aspect of this project is the business engineering aspect that the client/server architectures provide. With the PMIS/SPS system, the creation of the business process took place in conjunction with the creation of the development system.
There were no models from which to draw requirements for the solution. In some cases, the formulation of system requirements may have shaped the business processes and procedures.
Development of the PMIS/SPS applications took place with the product, Ellipse. These applications operate over a Microsoft LAN Manager Token Ring network with an OS/2 1.3 server running Microsoft SQL Server 4.2a, and Microsoft Windows 3.1 clients. An
OS/2 2.0 client in each office provides a Microsoft Mail gateway and nightly database reconciliation. The application integrates commercial products from Microsoft, Pioneer Software, and Hilgraeve on the client desktop. These products provide the business
functions of participant correspondence, data for external agencies, electronic mail, and remote system management.
The client/server architecture provides the infrastructure for sharing and integrating information between applications while giving the client the ease of use of a graphical user interface. In addition, the architecture provides the scalability and
expandability that enables the deployment of the solution in other provinces—if the need arises.
In the second phase, a development environment was set up to assist in building future applications more effectively. Future applications are to be built on the workstation and then migrated up to the mainframe into production.
For readers who want to review the preceding specific projects in more detail, and in particular learn more about the specific technologies applied to solving the business problems presented, the following material and more specific examples will
represent an opportunity to learn how client/server computing is having a major impact on today's business environment.
Some Southern Californians would be in the dark if it weren't for this major pipeline company. The company is a wholly owned subsidiary of a $13.5 billion energy company—the nation's largest provider of natural gas. Early in the spring of 1991,
the pipeline company's executives found themselves examining a changing marketplace, redefining their business goals, and determining how to support their business focus. But they had a problem; their computer systems were not flexible enough to meet the
pipeline company's changing needs.
"The nature of the pipeline business has changed in the past five years. In an environment of open access transportation, you have to find a new way to differentiate your company in the marketplace. Our customers never see a molecule of gas. They
see the invoice and experience the service," explained the president of the pipeline company.
After focusing on needed business and operational changes, the company took a critical step; it began to define what it would take to become a world-class servicer of natural gas shippers. The employees knew they needed to improve pipeline processes by
optimizing gas volume and monitoring throughput to prevent imbalances. They wanted to change their invoicing process and simplify the functions they planned to focus on in the future. The next step was to review their computer systems.
At a time when the company needed improvement in quality and service, it needed new levels of flexibility, functionality, and accounting in its systems. The existing systems ran on a number of IBM and DEC platforms—with some redundancies and delay
between critical activities and information availability. (By the time measurement of gas volumes had been processed through the systems, the information was two days old. In addition, information related to the scheduling of gas transportation was on the
VAX; uploading to the mainframe made the cycle for related activities at least overnight.)
Review of the systems also brought to light the fact that technology had come a long way since these systems were developed in 1987. For example, in the existing computer systems, the gas measurement process caused prior-period accounting adjustments
to be the rule rather than the exception. Measuring movement of gas along a pipeline involves the difference between the pressure on one side of a compressor or meter and the other. For each delivery and receipt point along the pipeline, there are two
meters—that of the operator who is delivering gas to the pipeline (or receiving gas) and the company's meter. With two measurements, there is often a reconciliation to deal with.
With the new systems, the company wanted to invoice what it scheduled to transport rather than wait for actual measurements of what was transported. By rethinking and reengineering the way its business is done, the company changed business processes so
that the invoicing of gas scheduled to be transported along the pipeline is done the next day. Although there is some balancing to be done at a later point if "scheduled" doesn't become "actual," in the main, monies due are collected
weeks earlier, and the whole process is "cleaner."
After examining the options available, the company chose a client/server, graphical user interface (GUI) approach. When asked why, the president replied, "The culture in our company says that change is good and being on the leading edge is
important. The company was taking an innovative approach to their business. The client/server/GUI approach for the new systems seemed to mirror what was happening on the business side of things, and the resulting systems would be the right size for our
company."
The company required systems that could grow and migrate to new technologies as they were introduced. Some of the other requirements were:
The new systems needed to provide a new customer interface, simplify allocations (the operational core of the company's business), and eliminate duplicate data, duplicate functionality, and duplicate work effort in the process. The company also
finalized the decision to invoice for gas transportation on the day the gas flowed, based on scheduled rather than actual (measured) volume at this point.
As with most mission-critical systems, client/server systems developed to run on the company's local area network (LAN) operate in a multivendor environment. The production LAN itself is IBM Token Ring. The file server, a Compaq SystemPro 486/33, runs
NetWare Version 3.11, communicating with the other servers and the workstations on the LAN using the IPX/SPX protocol. It uses the TCP/IP Runtime System Token Ring option, which allows communications with the corporate IBM mainframe and DEC VAX.
The database server is a Sun Sparcstation running Sun OS (UNIX). Sybase SQL Server for UNIX Version 4.8 is the relational database management system. Because the company did not want to be confronted with an upgrade decision in the near future, the
user workstations are, in most cases, 486-based Compaq PCs. The workstation environment is MS-DOS Version 5.0 and Windows Version 3.0. Sybase Net-Lib for Windows, and Sybase DB-Lib for DOS/Windows.
The applications were developed using Powersoft's PowerBuilder Version 1.0 and BSG Consulting, Inc.'s Windows-based development toolset and architecture, BluePrint. A runtime version of PowerBuilder and Novell LAN Workplace for DOS round out the
development and operational PC environment. All printers are Hewlett-Packard LaserJet IIIs. Under this environment, the following applications were completed:
The president says the transition to the new systems was the smoothest he's ever seen. Around noon on conversion day he asked what had happened to the new systems. The response was, "We've been using them all morning."
Approximately 30 people, primarily in core business areas, use the new systems now, with the potential for about 300 users when additional integrated applications are completed.
Unemployment Insurance and Disability Insurance applicants who are denied benefits by the California Employment Development Department (EDD) have a right to appeal their cases to the California Unemployment Insurance Appeals Board (CUIAB). In certain
circumstances, employers may also appeal EDD decisions. CUIAB holds hearings, adjudicates the appeals, and provides decisions. Appellants have a second level of appeal within CUIAB when they do not agree with the initial decision. The board has 11 field
offices throughout the state, a Chief Administrative Law Judge Office, and an Appellate Office in Sacramento. Because of difficult economic times, the EDD case volume increased approximately 80 percent during 1991. Offices strained to maintain service
levels.
The automation project is reengineering an existing eight-year-old ICL distributed processing system, developing a new generation of business applications on a new hardware/software platform to improve the board's ability to deliver its mandate. The
$2.3 million project is based on a client/server architecture and includes application development, 130 Intel 386-based Digital Equipment Corporation workstations, 13 Novell V3.11 LANs with WAN connectivity servers, operating system and packaged software,
and five years of hardware and software support. Figure A.10 depicts a high-level view of the platform.
Figure A.10. The components of the California Unemployment Insurance Appeals Board's automation project.
The Comprehensive Tracking and Tracing (CTT) application tracks priority mail from receipt through delivery.
The handheld scanners are 80x86-based processors developed by Symbol Technologies of California. The processors run MS-DOS and three layers of software: IPL, communications, and application. All three layers were custom-developed for the CTT system.
When a postal employee finishes scanning several pieces of mail, the scanner (client component) is returned to a cradle. The cradle serves to keep the batteries recharged and provides the communications facility to the host environment (server component).
The scanner automatically dials a predetermined number to initiate data transmission after a fixed time. If the scanner is not in the cradle at that time, it will beep to notify the operator to return it to the cradle. If the scanner is unable to connect
to the primary phone number after several attempts, it tries an alternate phone number.
When the scanner does connect, it establishes its connection to the IBM Information Network (IIN). The scanner identifies itself to the IIN during login. Then a session is established with the CTT host in Houston, Texas. In general, the scanners can
access the IIN through local phone numbers from anywhere in the United States. IIN access is also available in several foreign countries. IIN provides the largest value-added network in the world.
When the scanner connects to the host (an IBM ES/9000 model 500) in Houston, it establishes a conversational session in a CICS region dedicated to capturing scanner data. At the communications level, the scanner communicates via the Extended Line Mode
Protocol. An application-level protocol has also been established. The design criterion was that if a session is lost for any reason (such as a local phone line failure), the data captured in the scanner must not be lost; the scanner must automatically
retransmit until the host acknowledges successful receipt. This verification is accomplished by a handshaking protocol in which the scanner and the host acknowledge to each other exactly where they are in the process after each major step in the
transmission. Any failure to acknowledge correctly causes the scanner not to delete the captured data, and retransmission occurs until a positive acknowledgment is received.
One of the first steps that occurs in the scanner/host data exchange is determining what version of software the scanner is running and what version of the ZIP code edit file the scanner is running. If either of the versions is not current, the host
either downloads new software immediately or requests the scanner to call back at a specific scheduled time to receive the new version of software. The scanner operator is unaware of this processing, because it occurs when the scanner is in its docking
station.
Once the data is captured on the mainframe, it is put into transient data queues (TDQs) within CICS. In addition, all data received from the batch transmissions is also put into TDQs within CICS. This allows all DB2 insert activity to be scheduled
within CICS and avoids contention between CICS and batch.
From this point, separate processes read the various TDQs and post data to the various partitions of the DB2 database. The database is partitioned to allow multiple concurrent tasks to be inserted to the database without fear of contention.
The database environment is unique in that more than 90 percent of the online activity on the database is insert activity. With overnight mail service, there is a large volume of mail event data captured, but chances are very low that someone will call
to inquire about a package if it is delivered on time. So the better the delivery service becomes, the larger the ratio of insert activity to inquiry will become. In this environment, performance is geared toward sustaining extremely large volumes of data
insertion.
The other factor that adds to the complexity of the operation is the requirement to provide 7-day-a-week, 24-hour-per-day operation.
The system is not yet in full production, but it is processing approximately 3.5 to 4 million events/acceptance records per week (more than 1 million via scanners). The current transaction rate is relatively consistent at 20 transactions per second.
Stress testing has shown a capacity for 400 transactions per second.
The Fire Command and Control System (FCCS) is a customized computer-aided dispatch (CAD) application. The main computing for the dispatching occurs on the workstations on the Token Ring. The system uses 70 IBM PS/2 workstations with Token Ring
networking, 400 Motorola Digital Terminals (MDTs), and the Fireworks CAD software package from Lynx Graphics. Various interfaces from the Token Ring to an E911 SL-1/Positron, a Metro-media public pager system, a Centracom II radio system, an ADT 4504
display clock, a Veritrac 60-track voice recorder system, a digitized voice system, the city's IBM 3090 mainframe, and 114 separate fire station locations are controlled by a set of IBM PS/2 Model 95 workstations.
In addition to an MDT, each fire station is also equipped with an ETAK Travel Pilot (TP) that can display the exact location of an incident on a screen of the streets in the city. The TP also calculates and transmits the exact longitude and latitude of
the vehicle back to the dispatch center via the MDT. This data allows the CAD to contain exact locations of all vehicles to facilitate assignments to new incidents.
Use of automated dispatching and electronic messaging between the dispatch center and field units will reduce dispatching time between the receipt of the call and unit dispatch from 76 seconds to less than 30 seconds. The system is designed to handle
300 incidents per hour with a maximum number of 1 million calls for service resulting in 500,000 incidents each year.
When an E911 or seven-digit call for service is received by the city's E911 operators, Fire Department incidents are transferred to the FCCS system via a Pac Bell SL1 device. The dispatch workstations are configured as call taker, radio controller, or
supervisor positions. An incoming call is routed to an available dispatch call taker who verifies the address and determines the appropriate incident type. The application is written using IBM's standard graphical user interface (GUI) using C and
Presentation Manager. This environment provides the functionality and performance necessary for this application.
The following is an example of one of the many features of the FCCS system that use the GUI and high-resolution graphics. If multiple callers dial E911 to report a fire, different call takers may receive these calls at different times. If the callers
report nearby addresses, the system prompts the call taker that another incident exists in the vicinity. The call taker can point the mouse device at the appropriate command and retrieve a high-resolution graphical map of the city that displays all nearby
incidents. In this way, if nearby incidents are reported on different streets, a call taker unfamiliar with the streets in the area can display a map and determine whether the current call is the same as an existing incident. This facility can help
dispatchers prevent an unnecessary redundancy of firefighters and equipment.
In parallel to this activity, a mainframe query is generated to search mainframe files for information (noncritical data) that may be associated with the address. This data is returned to the user and is indicated by the appearance of a check box on
one of the windows active on the PC workstation. If the user wants to review this information, he or she simply selects the check box and the data is displayed in another window (keeping the primary window available).
Once a call taker determines that fire units should be dispatched, he or she clicks the "dispatch" pushbutton, and the system determines the best units to dispatch. The system generates a digital or synthesized announcement, such as,
"Engine 13 respond to a trash fire at 1234 Maple Street." This message is sent through the communications network directly to the appropriate fire station. A control box automatically opens the door of the fire station and turns on the light in
the bay. When the firefighters get into the vehicle, the details of the emergency dispatch are already displayed on the screen of their MDT and the Travel Pilot is pointing to the location of the incident.
Once a unit is dispatched, the responsibility for the incident is transferred to the radio controller responsible for the part of the city where the fire is located. If the MDT operator in the vehicle fails to push the "en route" button on
the terminal within two minutes, the unit number on the radio controller's unit status screen begins to blink and a warning sound is generated. At this point the radio controller can use the voice radio to contact the unit and determine whether it is
already proceeding to the incident. Once the unit arrives at the incident, the MDT operator selects the "on-screen" button. This is the basic dispatch functionality provided by the FCCS system.
FCCS consists of two major technology platforms: the mainframe component was developed in COBOL using DB2, and the PC component was developed in C using Presentation Manager services under OS/2.
The following software tools are used for programming and development on the workstations:
For mainframe development, an internally developed Systemhouse systems development environment (SDE) was used to organize and manage various utilities and processes necessary for program and database development. The Automate-Plus CASE tool was used
exclusively for database normalization. The Query Management Facility (QMF) was the primary tool used for DB2 development.
To facilitate the programming effort involved with the many interfaces, custom-written utilities and simulators were developed. To enable individual program modules to be unit-tested, internally developed tools and drivers simulate various interfaces,
such as incoming E911 emergency calls, outgoing MDT dispatch messages, and incoming and outgoing fire station messages. These tools and utilities, developed by the senior technical architects, simplify the programming effort for the rest of the development
team.
Because of the complexity of the multiple technology platforms, many kinds of communications devices are required to support this application. Because all of the workstations have a complete copy of all program software and resident dispatch data, to
ensure fault tolerance, a network messaging protocol was developed to control communications between all the workstations on the Token Rings. Communications between the workstations (the client component) on the Token Ring and the IBM mainframe (the server
component for inquiry data) occur through an Advanced Program-to-Program Communication (APPC) facility between CICS and OS/2. The data radio subsystem is supported by standard base station and radio equipment provided by MDI. This includes modems,
antennas, radios, and controllers. Specially developed C programs control real-time interface cards (RTIC) in the interface computers that connect the external interfaces to the system.
The primary machine for the FCCS is an IBM PS/2 Model 70 (A21) with 8M of D-RAM and 120M of fixed disk storage. The primary dispatch workstation Token Ring (DWTR) contains 50 of these workstations. The external communications Token Ring (ECTR) contains
six IBM PS/2 Model 95s with 16M of D-RAM and 640M on SCSI fixed disks. Each of the 400 fire department emergency vehicles contains an MDI KDT480C terminal and ETAK Travel Pilot. The 114 LAFD fire stations contain an IBM PS/2 Model 50SX with 4M of D-RAM and
70M of disk storage. The Token Ring workstations use a custom-developed Lynx database file management structure. This file structure has been custom-developed to provide the fastest possible access time for time-critical emergency dispatching. The primary
operating system on the workstation Token Ring is IBM OS/2 Version 1.3.
FCCS II consists of one primary Token Ring and two supporting Token Rings. The primary Token Ring, referred to as the DWTR, is used to pass current dispatch data among participants on the ring. The participants are dispatchers, radio controllers, and
supervisors. The second Token Ring, the ECTR, is primarily used to pass data to and from the mainframe and the MDTs as well as to accept and receive data from other interfaces. The third Token Ring serves as a backup dispatch Token Ring. It is located
remote from the central site and is kept up to date with relevant dispatch data. This backup site, complete with its own MDT backup, will be used only if the main site is knocked out of service for an extended period of time. Communications between the
DWTR and ECTR are via two pairs of interface machines (PS/2s). They are in pairs to provide fault tolerance; one interface machine can take over all tasks that the pair run should one of them go out of service. The pairs of interface machines are kept in
synchronization via the ECTR.
An historical database is maintained on the city's IBM 3090 mainframe in 35 DB2 relational tables. Inquiry and limited updates are provided via city mainframe terminals. The connection between the Token Ring and the mainframe is via an IBM 3745-410
communications controller. Incoming messages from the Token Ring are placed on CICS's transient data queues (TDQ) for processing on the host. The communications between the Token Ring and the fire stations are provided via a time division mux (TDM) and a
digital access cross connect (DAC) switch. Actual communications are transmitted via the city's digital microwave radio system. The city's mainframe runs under MVS/XA with CICS.
The Automated Case Tracking System (ACTS) is being designed and developed to provide automated support for the Los Angeles County Superior Court. This support provides an environment that standardizes and streamlines the workflow. This system
eliminates the redundant manual effort and duplication of data entry, and reduces paper flow. This support also enhances the accuracy, consistency, and timeliness of management information reports. ACTS provides the court staff, litigants and other
interested parties with quick access to case information.
ACTS is designed to assist the court in fulfilling its role in the justice process by providing enhanced capabilities for
Previously, all of these functions were performed manually or with minimal automation support.
As a component of the County Justice Information System (CJIS), ACTS is designed to both transmit and receive data from other CJIS components, including the following:
These systems support the probation department, the Sheriff's department, the municipal courts, the public defenders' office, the superior courts, and the district attorney's office.
The vehicle for the transmission and reception of information from other CJIS components is the Proactive Information Exchange (PIX) system. PIX sends preestablished groups of data, known as datagrams, between systems. The PIX
"contract" between the sending and receiving systems identifies the event in the sending system's processing life cycle that will trigger the passing of data via PIX. PIX uses predefined rules to translate data from the sending system to the
structure required by the receiving system. PIX also performs certain edits and selects data that suits the requirements of the receiving system. The PIX datagram initiates, in the receiving system, a predefined transaction much like an existing online
transaction. PIX uses LU6.2 to ensure end-to-end message integrity.
The ACTS application uses client/server technology to satisfy two basic requirements: the need to have up-to-date case data available to a large number of users (ACTS and CJIS) and the need to record rulings made in the courtroom very quickly.
To satisfy the first requirement, the master copy of the ACTS database (DB2) is stored centrally on the mainframe. This master copy is accessible for adding, updating, deleting, and inquiring by all authorized users.
To satisfy the second requirement, a copy of the specific cases needed for courtroom processing is downloaded to a workstation database server (using the IBM Database Manager product). This workstation database server provides restricted access for
adding, updating, deleting, or inquiring. Only the workstations authorized to process a specific case are allowed access to it. Once the workstation user completes processing a case, all updated data is uploaded to the master copy of the ACTS database.
To maintain data integrity, programs that add, update, and delete data are sensitive to date and time stamps.
To ensure that data is transmitted to and from the workstation efficiently, an additional layer of application software has been developed to support four specific needs:
All four needs are satisfied using the same underlying software solution. The daily calendar is produced in an overnight batch job that, for each case on the calendar the following day, inserts a transaction that begins to send the electronic case data
to the appropriate workstation destination. The program that sends the case data to the workstation reads the master database (DB2), converts the data into delimited-string format, and sends it to a program on the workstation database server that inserts
the incoming data into the corresponding Database Manager database.
Similarly, the other needs are met by having a program (either mainframe or workstation, depending on the direction of data flow) insert a specific transaction, along with the necessary data that initiates the desired activity. The receiving program
responds to the transaction by reading and returning data or adding, updating, or deleting data depending on the request. Other than the distribution of the daily calendar, these transactions are initiated and processed online.
ACTS consists of two major technology platforms. The mainframe component was developed using TELON, under MVS, using DB2. The PC component was developed using Easel under OS/2, using DBM. Both components used the Excelerator CASE tool during the
analysis and design phases.
The ACTS mainframe architecture integrates the capabilities of TELON, DB2, and ISPF, using both procedural and nonprocedural coding methods. The mixture of procedural and nonprocedural techniques, employing the advantages of several software
disciplines, creates an environment that permits full development and fast prototyping of screen applications. With this development environment, the concept of "source code" encompasses more than just a series of language source statements in a
COBOL library; it includes an interlocking configuration of both specifications and instructions that, taken together, generate application programs.
The mainframe ACTS systems development environment (SDE) standardizes development. It extends the capabilities of TELON and provides the programmer with documentation and automated methods to code the following features:
The workstation ACTS SDE also standardizes development. Easel provides a tool for quick and efficient production of OS/2-based graphical user interface (GUI) systems. Included in its base components are a high-level language, a design tool for building
SAA/CUA compliant screens, SQL, DDE, 3270, and APPC support, as well as business graphics. The Easel Prototype Development Facility (EPDF) extends Easel into a powerful prototype and development tool.
EPDF includes
The ACTS Easel Prototype Development Facility (AEPDF) provides specific application extensions to EPDF. These extensions include the ability to classify activities by case type (to allow specialized window performance characteristics) and the support
needed to produce minute orders via an interface to WordPerfect.
Application peer-to-peer communication (APPC) is used to communicate between the mainframe and the system's workstations. APPC provides the ability for programs running on two independent conversations (LUs) (in any IBM SAA SNA platform) to communicate
directly with each other. EPDF provides an architecture to support this coding.
EPDF provides two additional transactions in each platform. Each transaction represents a "to" and "from" element: the "to" transaction element on the sending LU and the "from" transaction element on the
receiving LU from an APPC conversation.
EPDF uses CICS ISC to provide APPC support on the mainframe, and it uses OS/2 CM to provide APPC support on the workstation. An "outbound" and "inbound" queue mechanism is needed to store messages. For CICS the outbound and inbound
queues are CICS transient data queues providing recoverability. The "from" and "to" CICS transactions are triggered by the TDQ to provide an alternative to polling.
For OS/2, the inbound and outbound queues are implemented as OS/2 datasets or OS/2 DBM tables providing recoverability. The "to" and "from" transactions use system functions to poll the queues on a regular basis.
APPC allows for the initiation of the partner transaction when a conversation is initiated, and it is also used for the constant running of the conversation. In most cases, one CICS region will be communicating with many (probably hundreds, if not
thousands) of workstations. A single CICS region supporting all workstations is impractical. It is also impractical to use more than one CICS transaction. The overhead involved in initiating the partner transaction and starting the APPC session and
conversation each time information must be passed is minimal. Because ACTS has a low percentage of connectivity activity, initiating a partner provides a more efficient solution than having a constantly running conversation.
Performing the connectivity as a background task frees the application transaction from connectivity concerns. This provides a more performance-oriented, straightforward solution for the application software. All connectivity concerns are addressed by
the "to" and "from" transactions supplied by EPDF. This type of solution allows application processing to proceed despite system failures that inhibit connectivity. The impact of this solution is that updates do not occur simultaneously
in both platforms. Because there will be a minimal delay (approximately five seconds, depending on the network and network traffic), data may be temporarily out of sync because of system outages.
Figure A.11 depicts the communications at a particular site. In a multistory building there is a wiring hub installed on each floor. Each wiring hub is "backboned" with an Ethernet strand. The Token Ring on each floor is bridged to the
backbone Ethernet strand.
Installing these wiring hubs now enables the courts to upgrade backbone speeds and underlying protocols later by removing the Ethernet backbone cards and replacing them with FDDI Token Ring cards.
Figure A.11 also depicts 3270 terminals attached to a card that is emulating an IBM 3274 cluster controller. These cards have a standard 50-pin telephone company connection to a standard M66 punch-down block. The 3270 terminals use a coaxial cable to
twisted-pair conversion Balun to interface to the 3274 emulation card.
Figure A.11. A typical building's integrated LAN.
Note that Figure A.11 includes two T1-speed CSU/DSUs (digital modems). Because a municipal area network (MAN) is already in place, an intelligent T1 node (provided by vendors such as NET, NewBridge, Timeplex, and so on) has been chosen, along with a
CSU/DSU that plugs into the T1 node chassis. The CSUs provide a link for a building's Ethernet backbone to the host site's Ethernet backbone via a TCP/IP router. There are two CSUs to provide a redundant path to the host.
At the host site there is a similarly equipped wiring hub with a short Ethernet strand and router. The 16-Mbps Token Ring is bridged to the Ethernet strand. All program software and application data reside on an IBM 3090 mainframe located at the county
Internal Services Department's (ISD) installation. The IBM 3090 mainframe uses the MVS/XA operating system. The mainframe system uses DB2 as its file management system.
The GAIN Employment Activity Reporting System (GEARS) was designed and developed to support the Greater Avenue for Independence (GAIN) welfare program. The GAIN program, established in 1988, assists welfare recipients in finding employment by providing
education and training services. During the education and training process, GAIN provides supportive services in the area of transportation, child care, and ancillary expense payments. GEARS supports 250 GAIN case managers who are responsible for an active
caseload of 30,000 participants and a total caseload of 220,000 participants. GEARS provides the following capabilities:
Eligible AFDC participants are identified by the Los Angeles County Integrated Benefits Payments System (IBPS) and are transferred to GEARS via a tape interface. The participants are assigned to a GAIN case manager, an initial appointment is
automatically scheduled, and the appropriate notices are generated. Any participant who does not keep the appointment is automatically placed into noncompliance and a noncompliance appointment is scheduled. Repeated noncompliance results in reduction or
termination of AFDC Welfare benefits.
Each participant then begins an appraisal and assessment process to determine the individual's educational level and the type of job training needed to obtain gainful employment. The participant enters into a contract with the county to enter an
education or job training component. While a participant is undergoing training, GAIN will provide funds to pay for the cost of transportation, child care, and ancillary expenses, such as books and equipment. GEARS tracks and reports on all aspects of a
participant's progress through the GAIN program. GEARS has the ability to automatically generate all letters and notices required by the program. These notices may be generated in seven foreign languages according to the spoken language of the participant.
GEARS was developed using the following products from Software A.G. of North America, Inc.:
GEARS uses a standard system development environment (SDE), which provides the following features:
The use of the SDE ensured a consistent architecture across the entire GEARS system.
CON-NECT is an office automation tool with a wide variety of features, including calendaring, meeting scheduling, electronic mail, and reminders. GEARS used both the calendaring and reminding features of the product. Each user is assigned a cabinet,
the CON-NECT term for an office file. At logon time the cabinet is shown and appointments and reminders are displayed. The user is able to go directly from the cabinet to the GEARS application.
The GEARS network has two digital circuits and six analog circuits. The analog circuits generally support PCs running 3270 Emulation. These PCs are managed by the NetView control desk the same way as 3174 cluster controllers and 327x terminals. Figure
A.12 illustrates the network management components.
In a client/server network, it is important that fundamental network management processes are in place. A network management architecture is the single most important entity in a network. GEARS is a conventional SNA host/slave network that uses many of
the networking concepts required in a client/server network.
One concept that is common is that of redundancy. The GEARS architecture called for two telco data circuits to be dropped into each larger address. These circuits were ordered from the local exchange carrier as "diversified pathing."
Diversified telco circuits ensure that the two circuits are not multiplexed together on the same telephone company facilities. This technique reduces the risk of both circuits being "down" at the same time. Remotely bridged LANs can also use
diversification to ensure there is an alternate route back to the host.
Another concept that is common is that of load balancing. The GEARS architecture called for two large digital multidrop digital circuits (56Kbps). Analysis showed that an oversized multidrop circuit will handle individual bursts of data (print
streams) quickly while providing service to a larger number of users. Load balancing is an important mandatory feature in a network supporting client/server processing. In a bridged Token Ring LAN that is matrixed, each dynamic APPC (SQL call) session will
find the path of least resistance.
Figure A.12. GEARS network management components.
Network management, or proactive management, is another common concept. To proactively manage you need to know where your devices are and what they are connected to. You need to be able to run a nondisruptive loop-back test to sessions running at the
workstations. NetView is the central concentration point in this network. Each controller, terminal and printer ID, and modem is monitored and alerts are generated at the network control console. The architecture is designed so that problems can be
proactively avoided. For example, in the GEARS network, if a terminal is not on the network, while others on the same eight-port internal multiplexor are operational it is reasonable to assume the terminal is turned off. If all eight attached devices are
off the network it is reasonable to assume there is a problem. The network control staff will run loop-back tests through the controller to confirm that the problem is isolated to that particular mux, possibly will phone the users of those terminals to
confirm the eight devices are not shut off, then, if necessary, will dispatch a field service representative.
Proactive management is important at the session level and at the hardware level. The GEARS network employs modems and digital modems that support NetView's LPDA-2 (Line Problem Determination Aid Version 2).
These modems sense the telco line quality and report that line quality to the host-based NetView. LPDA-2 also supports loop-back testing directly from the NetView console.
In an online environment it is important to isolate a problem quickly without waiting for a phone call from the end-user. For example, with a solid network support architecture in place you can confirm that a circuit is working and that it is the
controller that has the problem. In most instances the problem will be detected and a technician dispatched before the users call to complain.
The objective of this development project was to provide a user-friendly, online order system that would simplify telephone service order processing and provide accurate and timely order information without having to rewrite the existing systems that
support this effort. The major benefits of the system are an overall improvement in the quality of service to customers and a reduction in the number of order processing personnel.
The Service Order Load And Retrieval system handles the data-entry requirements of the Order Processing Centers (OPC), Business Service Order Centers (BSOC), and Customer Service Order Centers (CSOC). It automates service order issuance, routing, rate
calculations, and file maintenance, and it also provides interfaces to the following systems:
All of the systems for which interfaces are provided are IMS DC/DB systems except for SSOAS which is a Tandem-based system.
SOLAR is comprised of the following functional areas:
The order entry and maintenance function provides a set of data entry and maintenance screens that will be used for order creation, service selection, and customer and billing information input and maintenance.
The work order function provides the selection and assignment screens that are required to select, route, display and print orders.
The close order function consists of the processes that mark orders complete and a batch process that reformats orders and passes them to the Mechanized Directory system.
The order inquiry function provides an inquiry on SOLAR orders in the Advance Service Order System (ASOS) format, an order itemization inquiry, an audit history inquiry, and an order investigation inquiry.
SOLAR functions will be used by the following personnel and departments:
The customer representatives use SOLAR to enter the order, and to capture the required information while speaking to the customer on the telephone.
The assignment department uses SOLAR to view the order to determine what facilities are required and then assign to the appropriate facilities required to complete the order.
The dispatch department uses SOLAR to obtain the necessary information to complete the dispatching of the order.
SOLAR was designed to front-end existing IMS based systems. Programmer access to the SOLAR system is via DB/2 and user access is via the SOLAR front-end. SOLAR manages the communications between the DB/2 view and the existing IMS application databases.
The technology base is TELON/DB2 Systems Development Environment (SDE). The basic infrastructure is depicted in Figure A.13, and includes:
Both the application requirements and the development environment were modified to simplify development and to standardize functionality. The resulting system has reduced the training time for order takers from six months to six weeks and significantly
reduced the staff turnover in this position.
Figure A.13. SOLAR application infrastructure.
All development was done on an IBM 3090 under the MVS/XA operating system. The project made extensive use of TPNS for performance and regression testing.
The Fire and Ambulance Command and Control System (FACCS) is a customized computer-assisted dispatch system (CAD). The dispatch functions are provided by software resident on the workstations on the Token Ring. Although there is one physical Token
Ring, there are two logical rings. The fire department workstations pick up only fire department messages and the ambulance department workstations pick up only ambulance department messages as they pass on the Token Ring. The system uses seven IBM PS/2
workstations with Token Ring networking and a CAD software package from Lynx Graphics. There are external interfaces to the E911 system, fire and ambulance stations, the WWVB clock synchronization, the Winnipeg City Police system, the two city utilities,
the ambulance department administration center, and the radio system.
Incoming calls may be from the E911 system or from a telephone call. The call is routed to a call taker who verifies the address, determines the incident type, and whether or not units should be dispatched. If units are to be dispatched, the system
generates a unit proposal to be accepted or modified by the dispatcher. The system alerts the dispatcher if the location has special requirements (such as a high-rise building or hazardous materials on site). Under certain circumstances the system will
generate an automatic transfer between departments; for example, a transfer to the fire department if information about an ambulance department call indicates that the patient is not breathing. A transfer between departments or to the Police Department may
also be manually requested by clicking a mouse pointer on a transfer pushbutton.
Dispatch instructions are sent to the fire or ambulance station over a leased line. Dispatch instructions are printed at the station and the gong is rung. The dispatched units indicate their progress by pushing buttons on a radio unit
("enroute," "at scene," "clearing scene," and so on).
The messages generated on the Token Ring are sent to a backup machine for each department and to an administration machine for each department (all PS/2s running OS/2 Version 1.3). Reporting information is extracted from the messages and stored on an
Oracle database for the fire department and a DBM database for the ambulance de-partment. These databases are used for statistical and management reporting. The ambulance department database is also used for generating invoices to be paid by the user of
the service or transmitted to Blue Cross for payment.
The primary machine for the FACCS system is an IBM PS/2 Model 70 with 8M of D-RAM and 120M of fixed disk storage. The primary dispatch workstation Token Ring contains seven of these workstations.
All of the programming and development on the workstations is done using the C programming language. Screens were built using Presentation Manager. The Token Ring workstations use a custom developed database file management structure, Lynx Database
Manager (LDM). LDM was developed to provide the fastest possible access time for the time-critical function of emergency dispatching. The primary operating system on the workstation Token Ring is IBM OS/2 Version 1.3.
Custom written utilities and simulators were developed to facilitate the programming effort. These internally developed tools and drivers simulate various interfaces, such as incoming E911 emergency calls or incoming and outgoing fire and ambulance
station messages, to enable individual program modules to be unit tested. The real-time interface cards in the interface machines (PS/2 Model 80 with 8M of D-RAM and 320M of fixed disk), which provide external communications, are controlled through special
C programs.
Also attached to the primary dispatch Token Ring is the fire department local area network. It is bridged to this ring by a PS/2 Model 80 with 600M of fixed disk and 12M of D-RAM running Oracle Server software. The ambulance department LAN is bridged
to the FACCS primary ring through a leased line on one of the interface machines. The 27 fire stations and nine ambulance stations are equipped with 386 systems with 1M of memory and without a hard drive. These systems are print servers and also control
the gong relay within the station.
The system provides ECC with the capability to develop and implement customer agreements, to process order transformation up to and including invoicing, and to perform price management. The application also provides the ability to maintain data on
products and services, customers, suppliers, and competitors. The system will handle the creation and monitoring of shipments and freight liabilities, forecasting, and process feedback information. The application includes interfaces to suppliers, other
corporate systems, and customers.
The development environment uses client/server technology with Oracle as the database. The development network consists of 14 SUN SLC workstations each with a 207M disk drive connected to two SUN SparcStation 2 servers using a Cabletron MMAC
concentrator with the 10BaseT wiring standard. There are two IBM PS/2 Model 70 386 workstations on the network as well as one IBM PS/2 Model P70. Printing is performed by a Hewlett-Packard LaserJet IIISI printer (17ppm). The network can also support 22
VT220 terminals, one terminal serially connected to each SLC, plus eight terminals on a terminal server.
The development software consists of Oracle's RDBMS, Oracle CASE tools, Oracle communication products, Oracle 4GL application tools, SQ Solutions, Inc. report writer (SQR), and WordPerfect 5.0 for word processing. Support of the production environment
is provided through dialup connection over a normal telephone link.
In the production environment, a SUN 4/470 Server will be attached to Esso's corporate network using DECNet. This will be available to all PCs, Macs, VT100s, and printers on the network.
The Syncrude open pit mine produces an average of 150,000 bank cubic meters (BCM) of oilsand per day from an area approximately 5 kilometers long by 9 kilometers wide. The mine is divided into four independent production systems, each consisting of a
large dragline, a bucketwheel reclaimer, and a series of conveyors. Each dragline uses a 60 cubic meter bucket to excavate the oilsand from the mine and deposit it in a series of windrows near the edge of the pit. The bucketwheel reclaimer then loads the
ore onto the conveyer system which moves it to the production area.
During mining, the draglines sit at the crest of a 40- to 50-degree slope that is 40 to 50 meters high. The weight of such a large piece of machinery operating so close to the slope face has the potential to cause instabilities in the ground, which may
result in the loss of a dragline. In order to understand and monitor the movements of the ground below the draglines, a series of vertical boreholes with grooved PVC pipe cemented into them are located in the operating bench (the area near the edge of the
pit). Probes are then lowered into these boreholes (called Slope Inclinometers or SIs) and the angle of incline is measured. Subsequent readings are taken, and any change in angle is used to measure the nature and velocity of ground movement at various
depths. If, during mining, the movement indicated by the SI increases, steps will be taken to ensure the safety of the dragline.
The movement of the SIs is measured via electronic signals that are transmitted from the probe and captured by special recorders that translate the data into digital form. These readings are monitored in the field using special software provided by
Pulsearch, a firm specializing in this technology. Stand-alone laptop computers are used to record, store, and monitor this data in the field. At the end of each shift, a diskette containing all the readings from that shift is transported to the
geotechnical office, where it is entered into the SLOPE system. The data is then available to the geotechnical engineering group via the Token Ring network.
This data is heavily used for analysis of current and historical movement patterns that, when combined with geological information, allows the engineers to reliably predict the likelihood of any major ground movements in the area of the current mining
operations. It also allows the definition of an effective, but not overly cautious, safety margin for dragline operations, which helps to increase productivity and reduce dragline downtime.
The system provides access to the corporation's IBM mainframe database in order to both archive data to, and access data from, an historical DB2 database.
The SLOPE system uses a client/server architecture based on the Microsoft/Sybase SQL Server and intelligent workstations equipped with an object-oriented graphical user interface (GUI) that conforms to IBM's Common User Access (CUA) guidelines.
The mouse-driven system relies heavily on the use of icons, graphs, scrollable online reports, and high-speed printers and plotters to assist in the rapid and on-demand analysis of movement data.
The SLOPE workstations are IBM PS/2 Model 55SXs and Model 65SXs with 8M of D-RAM. They operate under OS/2 Extended Edition (EE) Version 1.2.
The LAN and Database server is an IBM PS/2 Model 80 with 16M of D-RAM, also running OS/2 EE Version 1.2. A Microsoft/Sybase SQL Server is used as the database server.
Upload and download facilities are provided to the corporate IBM 3090 mainframe and a DB2 database is used to archive data that is no longer required on the LAN on a regular basis. This historical data can subsequently be retrieved and returned to the
LAN database as required.
Easel 2 was used as the primary development environment on the workstations. Some C programs were written to provide specialized graphics capabilities. The Excelerator CASE tool was used in analysis and design, while development took place using a
prototyping approach.
The parent company of this large North American company maintains a base of approximately 650,000 customers. The system developers used rapid prototyping techniques to develop functional building blocks for the business application and gain approval
from the users in servicing, billing, fulfillment (order processing and telemarketing), finance, marketing, and claim adjudication. Once the model office was working and accepted in prototype, it was transferred to the full-scale environment. In production
operation it is more efficient to run the applications locally in the workstations than from the database server. This keeps LAN traffic to a minimum. The database server is then accessed only when necessary to retrieve or update data. Applications such as
word processing, spreadsheets, and so on have their software and data files resident on the workstation hard drive. This gives the user maximum response and keeps the LAN available for database and communication services.
The basic technical environment consists of a series of networked applications running Hypercard and Oracle tied to a VAX 6220 running Oracle as a database server. Additionally, there is a download capability for existing client data from an Amdahl
5880. The Macintosh was chosen as a workstation because of its extreme amenability to rapid prototyping using Hypercard and Oracle SQL*Forms as a development environment. Oracle was chosen as the DBMS because of its multi-platform operating capability and
its ability to interface smoothly within the Hypercard environment. Silverun was used as the upper CASE tool. It provides a data dictionary, as well as data- and process-modeling capabilities.
The workstations selected were geared to provide the customer support representatives with the most flexibility and power on their desks to help them do their jobs effectively and efficiently.
The model office was designed for "roll-out" capability into the production environment. The architecture is directly scalable so that the home office can be implemented without having to redesign or reimplement any software or hardware
components. It was initially envisioned that the operating environment would be a workstation approach. This would allow for linear and incremental growth in terms of power and price. However, this evolved into a central file server design when it was
decided that the database in this particular application would not distribute well and central control and data management became significant issues. Therefore, a file server approach was developed in which workstations could be added and the file server
increased in power as necessary to meet increased load requirements without impacting the production environment. Appletalk is the LAN protocol. Physically, the network topology is a daisy chain. Optimally, the server is in the middle of the chain with the
most active workstations as close as possible to the printers on one end. The communication gateway is the Netway 1000AE from Tri-Data which provides up to 16 3270 sessions plus file transfer capability to the host. This uses a 9600 baud conditioned line
over sync modems and is connected to the LAN. The gateway allows a 3270 session to be displayed on the workstation in real time and allows other model office transactions to be performed concurrently.
The expected growth path of the system is first to add application functionality, secondly to add additional customers, and, as the system becomes saturated, migrate to a VAX-based Ethernet LAN. By implementing an SQL database architecture, migration
to another server should not impact the interface with the users and will insulate the workstation-based software from the new server.
In January, 1991, Blue Cross of Atlantic began making the transition from maintaining and developing their business applications on an IBM 3090 M200 mainframe (at a very high cost in CPU cycles) to maintaining and developing them on IBM PS/2
workstations in an OS/2 client/server networked environment (using models 50, 55, and 70s). This process was accomplished using a two-phase approach over a course of eight months.
In the first phase, a workbench environment was set up to assist in migrating OS/VS COBOL programs from the mainframe down to workstations for maintenance activities. After maintenance was completed, the programs were re-migrated back to the mainframe
into production.
In the second phase, a development environment was set up to assist in building future applications more effectively. Future applications are to be built on the workstation and then migrated up to the mainframe into production.
These goals were achieved, and the following objectives were met:
More specifically, productivity gains were realized in the following ways:
Several strategies were adopted in order to ensure that the objectives of the project were met:
Blue Cross had already made a significant investment in software products that were currently being used in the mainframe environment to maintain and develop business applications. In order to avoid costs associated with training and education of new
workstation products, they chose to continue with a platform and product base similar to the one used on the mainframe. A summary of the chosen mainframe/workstation products is as follows:
Component |
Mainframe Product |
Workstation Equivalent |
|
Hardware Environment |
IBM 3090 M200 |
PS/2 Model 50, 55, and 70 |
|
Operating System |
MVS/XA |
OS/2 |
|
Object Control |
PANVALET |
PAN/LCM |
|
Transaction Processor |
CICS |
CICSVS86 |
|
Data Environment |
DB2, VSAM |
XDB, simulated VSAM, Sequential |
|
Analysis/Design CASE Tools |
none |
TELON/TEAMWORK |
|
Productivity Tools |
TSO ISPF |
OS/2 SPF/2 |
|
TELON/PWS IPE Macros JCL Utilities |
IBM JCL |
CMD and REXX |
|
Screen Dev. Facility |
SDF |
CICSVS86 SDF |
|
Extract Aids |
custom routines |
Data extractions are done on the host |
|
Testing Aids |
various |
MF COBOL |
|
Debugging Aids |
various |
MF COBOL |
|
Dumping Aids |
IBM Utilities |
MF COBOL |
|
Languages |
COBOL, COBOL2 |
COBOL,COBOL2 |
The workstation environment installed was composed of
The LAN was linked to the mainframe via two IBM 3164 controllers using 3270 emulation software over a Token Ring network.
Before the implementation of the first phase of the project, the analysts, designers, and developers typically used the workstations for terminal emulation to the host and for word processing.
After the implementation of the first phase of the project, the maintenance programmers were using the workbench environment product set on the workstations for importing, changing, testing, and exporting objects back to the host into production. They
were also using terminal emulation and word processing.
After the implementation of the second phase of the project, the analysts, designers, and development programmers were using the development environment product set on the workstations for analyzing, designing, database administration, programming,
testing, and exporting objects to the host into production. They were also using terminal emulation and word processing.
An integral part of the development environment was the installation of the IPE. The IPE was written and enhanced over a period of 15 years by various technical architects. It was installed at Blue Cross to help development programmers decrease
development time and increase quality and uniformity. The IPE extended the capabilities of TELON and provided the programmer automated methods to code the following features:
The following paragraphs contain samples of how the two environments were used.
Application program maintenance using the new maintenance environment is depicted complete with scripts in Figure A.14.
When a maintenance programmer is assigned to make changes to a program, he or she must identify all components (submodule, copybooks, and BMS maps) needed in order to completely transfer the program and its associated routines from the host to the
Maintenance Workbench environment. This enables a proper testing of changes made to the program at the workstation. This set of components is referred to as an "Object List."
The components are then downloaded from the Host to the network server using the Import and Checkout Objects option of the Object Processing custom software residing on the network server. This process uses the Object List as input. Each object in the
list is checked out from the PANVALET library and downloaded to the corresponding PAN/LCM library on the server. The Object Processing module also checks out those objects that the programmer expects to change and move into his or her designated work area
from the PAN/LCM library.
Figure A.14. The Blue Cross maintenance environment.
The maintenance programmer then makes the necessary changes to the programs in his or her designated work area using the MicroFocus tool set to edit, compile, test, and animate (debug).
When the changes have been completed, the Export Source Objects option of the Object Processing software is used in conjunction with PAN/LCM to check the objects back into the LAN server PAN/LCM library. It is also used to upload the new version of the
objects to the Host PANVALET test environment. From there it is promoted into the production library.
Data for testing maintained programs is also obtained from the host data files. Data Extract custom software assists in preparing the appropriate test data files on the server. The process extracts data for testing from the host data files, imports the
data to the server into temporary sequential files, generates the required data structure (for example, VSAM file or DB/2 table) on the server, and populates the data structures with the imported data.
Printing is performed on workstation- and mainframe-based printers using custom developed print routines. Large printouts are printed on the mainframe printer. Small printouts (for example, SPF documents) are printed using customized print routines to
insert HP Laserjet printer codes directly into the SPF/2 document and to route the file to the network laser printer.
Backup & Recovery software is used to provide a partial or full recovery of the environment.
Application program development using the new development environment is depicted in Figure A.15.
During the analysis phase of a project, the analyst uses TELON/Teamwork to
PAN/LCM Archive is not used for versioning, because Teamwork controls versioning of its models and no external objects are created that can or need to be manipulated by LCM.
Figure A.15. The Blue Cross developmental environment.
The analyst may also consider using the prototyping facility of TELON/PWS to refine the user requirements, data model, and process specifications.
During the design phase of a project, the designer uses the TELON/Teamwork tool and the Teamwork Data Dictionary, and the SILC Design Methodology to
During the development phase of a project, the programmer uses the TELON/PWS facility, the IPE, and custom maintenance environment routines to
When a program is successfully unit-tested, the developer uses a custom function to check-in the TELON source to the LCM archive, which then checks-out the program specification and generates COBOL II source for the PC into the integration library
(again with read-only access). An executable version of the program is then created for access in subsequent integration testing. Batch programs are integration-tested using .CMD files or REXX execs to simulate the job stream that will be used on the
mainframe.
When the programs are successfully integration-tested, another custom function generates COBOL II source for the mainframe using the completed version of the TELON source in the LCM archive. Additional custom processes prepare the COBOL II source code
for compilation on the mainframe, and then export it to the mainframe. The maintenance environment also provides functions to export any associated PARMLIB, COPYLIB, DCLGEN, or DDL member to the mainframe. Any JCL required for batch testing must be derived
manually (at this time) from the .CMD files or REXX execs used in the maintenance environment.
Data in the Help and Tables XDB tables are exported from XDB to the host and then loaded into the corresponding DB2 tables.
Data for system testing can be created on the mainframe or brought up from the maintenance environment. At this point, system testing is performed on the mainframe using the scenarios defined during the design phase. Any modifications required as a
result of system testing must be done using the maintenance environment. This should not require bringing anything back from the mainframe. The modifications will be done directly in TELON/PWS, and then tested and moved back to the mainframe using the same
functions that are available during normal development.
Printing, backup and recovery, and system management are managed using the same procedures used in the maintenance environment.
The CUIAB application suite encompasses three primary subsystems, each serving the unique needs of part of the CUIAB operation within the context of a board-wide architecture and database structure. The three subsystems support the following office
systems:
Appeals filed in EDD offices are downloaded via the WAN to the local CUIAB office for processing. The office registers the case, calendars the hearing, sends notices to the involved parties, holds hearings, documents decisions, and informs the involved
parties of those decisions. The application supports case tracking, inquiry, document generation, and management reporting. Office automation functionality (word processing, e-mail, and calendaring) is also included.
The telecommunications network provides for communications within and between all CUIAB offices and with the State of California Health and Welfare Data Center in Sacramento.
The CUIAB application was designed to use a client/server arch-itecture. The system functions are logically shared between the workstations and the servers. The workstation handles the user interface including data entry, display, program navigation,
and option selection. On request from the workstations, the servers provide print, file storage, LAN control, database access, software storage, and communications services.
There are two servers on each LAN. A file server supports the Novell LAN-related functions. All programs and flat files reside on the Novell NetWare Version 3.11 file server. This facilitates program-level maintenance, security, and backup. All
database files reside on the Microsoft SQL Server database server. The database server handles all aspects of the relational database. In this way, such things as security, integrity, and the actual database searches are handled by the dedicated server.
Access to other LAN servers on the network is via Gateway Corporation's IPX Bridge/Router over a public data network (PDN). Both binary and ASCII files may be copied to or from any other CUIAB LAN. E-mail is sent to other LANs as required or on a
scheduled basis.
Access to the HWDC mainframe is via Gateway's G/SNA 3270 program running on the workstation, in conjunction with Gateway's G/SNA product running on the three centralized servers (Higher Authority, Inland, and Sacramento). Multiple concurrent 3270
sessions and local 3270 host printers are supported. File transfers to the mainframe are supported in either direction via the TSO file transfer facility. Electronic mail (e-mail) is localized to each individual LAN but can access other LANs in addition to
the PROFS and EMC2 mail users on HWDC. Microsoft Mail is the e-mail package. Scheduling is integrated with the e-mail package via Network Scheduler II. Both are Windows-based products.
The environment is based on Digital Equipment Corporation's personal computers configured in a client/server architecture. Local Area Network (LAN) and Wide Area Network (WAN) connectivity is based on Novell NetWare v3.11. Figure A.16 illustrates the
overall network architecture.
The following sections contain a more detailed narrative on the workstation, LAN, and WAN layers of the architecture.
Figure A.16. WAN and host connectivity overview.
The workstation hardware consists of Digital DECstation 320+ workstations. Each includes an Intel 386DX 20MHz CPU with 4M of D-RAM. The workstation is configured as a "hard diskless" LAN workstation, with a 3 1/2-inch floppy. It has much
greater expansion capability than traditional diskless stations, because it is actually a full desktop PC without a hard disk. It can also operate as a stand-alone PC as configured.
A bar code reader is connected between the keyboard and the system unit. The application is designed so that the user may use the bar code reader's wand to scan the case number or other bar-coded data interchangeably with the keyboard. For example,
when the application positions the cursor to the case number field, the user can either scan the case number bar code on the file folder, or type the case number at the keyboard.
Theft is discouraged by a device that attaches the workstation system unit, printer, and monitor securely to the desk.
MS DOS and Microsoft Windows 3.x provide a consistent user interface that is common to all applications (except WordPerfect 5.1 and 3270, which currently run in fullscreen mode). This reduces training time and is more productive and accurate for both
novice and expert users. The software running on the workstation is
DOS, MS Windows 3.x, and Easel/Win provide a consistent graphical user interface. Pull-down menus and pop-up message boxes simplify option selections and data entry. The interface complies with IBM's Common User Access (CUA) guidelines. The primary
advantage of CUA is that all applications written under it have the same "look and feel," thereby reducing training and increasing user productivity. CUA is part of IBM's Systems Application Architecture (SAA). Windows 3.x, Easel, and Gateway's
G/SNA products are all SAA-compliant.
Easel/Win is a productivity tool and Graphical User Interface (GUI) for developing windowed applications for personal computers. It currently runs under DOS, OS/2, and Windows 3.x. Easel/Win generates a state-of-the-art Macintosh-like user interface
with pull-down menus, pop-up dialog boxes, selection boxes, and so on that seamlessly integrates the CUIAB application with other Windows applications. With Easel/Win, maintenance costs will be lower because it requires much less source code to develop an
application compared to C or other 3GL languages.
The development team is using the Easel Workbench to develop the system.
The multitasking environment allows multiple applications to be run concurrently. The windowed environment allows multiple overlapping windows that display the active jobs together on the same screen. The same interface is used by OS/2 PM. Both OS/2
and DOS workstations may coexist on the LAN at the same time. The CUIAB application has been designed to run identically on either DOS/Windows 3.x or OS/2 PM. The other application software packages selected have both DOS and OS/2 versions available,
assuring a smooth migration when or if required.
The CUIAB application developers use the Easel Workbench development system under OS/2. OS/2 provides a more robust development environment than Windows. Since Easel/Win is upwardly source code compatible with Easel/2, the CUIAB application can be
tested in both environments by simply recompiling for Windows. The CUIAB/EDD application is being designed and tested to run with both Easel/2 under OS/2 and Easel/Win under Windows 3.x.
Each of the 13 primary locations has its own LAN based on Novell NetWare v3.11. As shown in Figure A.17, each LAN is a network of 8 to 30 workstations supported by a file server, a database server, a remote access gateway, an e-mail router, and a
bridge to other networks.
The file server is based on Novell NetWare v3.11. It provides basic flat-file and printer sharing among the workstations. Advanced features may be provided in the future by software modules called Network Loadable Modules (NLM). Currently available
NLMs, which will be installed at each LAN, include NetWare Remote Management Facility (RMF) and the tape backup NLM (ARCserve).
The database server is based on IBM's OS/2 standard edition running the Microsoft SQL Server database. It provides advanced database functions and security to the workstations.
The workstations and servers are physically cabled together as an Ethernet 10BaseT LAN running at 10Mbps. Each PC is connected in a star configuration via a central Ethernet concentrator using plenum-rated, unshielded twisted-pair wire.
Figure A.17. LAN overview—hardware and software.
The file server is a Digital DECstation 325c system with 8M of 32-bit D-RAM, 320M of hard disk memory, and a 1.3 gigabyte external tape backup unit. The software consists of MS DOS 3.3, Novell NetWare Version 3.11, and Cheyenne ARCserve tape backup
NLM.
The Database Server software is Microsoft SQL Server, the Microsoft OS/2 licensed version of the Sybase database. It runs on a dedicated PC under the OS/2 1.3 Standard Edition operating system. Both DOS and OS/2 clients can access the server over the
Novell NetWare Version 3.11 LAN.
This client/server architecture has proven to be the most effective method for database access. It offloads CPU processing from the workstation while maintaining a centralized approach to security, backup, and administration. The application will use
Structured Query Language (SQL) to access the database. The database will support both DOS (MS Windows 3.x) and OS/2 clients concurrently. The CUIAB application has been designed to run identically on both DOS/Window and OS/2 PM.
Easel/Win (for DOS/Windows 3.x) and Easel/2 (for OS/2) directly support the TRANSACT-SQL interface to the Microsoft SQL Server. Operating on a separate dedicated processor, the SQL Server is designed for growth and will support this application and
future applications.
The database server is a Digital DECstation 325c system with 8M of 32-bit D-RAM, 320M of SCSI hard disk memory, 40M of IDE hard disk, and an uninterruptable power supply (UPS). The software consists of IBM OS/2 SE 1.3 and Microsoft SQL Server for OS/2.
Each of the 13 LANs has a wiring concentrator that connects all the workstations, file server, database server, remote access gateway, e-mail router, and bridge machines via shielded twisted-pair (STP) Ethernet 10BaseT cable.
Cabletron provides an exceptional network management facility. One of the slots on the MMAC-8 contains the intelligent repeater Module (IRM) that has the dual function of a repeater and network management module. This hardware is used in conjunction
with the Remote LANView/Windows package to gather and display network diagnostics and performance measurement on the LAN and transmit it on request to the remote EDD/CUIAB support groups in Sacramento and Inland. Faults can be isolated to the individual
workstation and the workstation can be removed from and restored to the LAN remotely. This is a full-function network analyzer that also provides diagnostics, automatic fault isolation, monitoring, performance graphs, and control of not only a complete LAN
segment, but also of individual ports and the Workstation's Network Interface Card (NIC). Based on Microsoft's Windows 3.x and Hewlett-Packard's OpenView, it provides a graphical view of the WAN. The support staff can click pictures and icons to focus on
areas of interest.
Cabletron's 16-bit Desktop Network Interface (DNI) NIC cards are intelligent devices that fully support remote diagnostics via LANView/Windows. In addition, there are indicators on each card that display transmit, receive, collision, and link status. A
user can glance at the back of the card to visually confirm whether the device is connected to the concentrator and whether data is being transferred. The DNI NIC cards, the MMAC-8, and LANView/Windows support the industry-standard Simple Network
Management Protocol (SNMP). This allows any SNMP-compatible program, from any vendor, to interact with and support the management of the network.
Equipment and software level management is essential to successful remote management of LANs. The combination of the intelligent 16-bit DNI cards and LANView/Windows allows a remote network manager to interrogate and update a workstation's DNI to
determine the type of PC, levels of system and application software installed, the user's name and location, and other vital configuration management data.
Two Elgar IPS 1100 uninterruptable power supplies (UPS) will be installed on each LAN to protect both the file server and database server. This will provide a minimum of 20 to 30 minutes of standby power when the primary power fails. The servers are
notified of a power failure via the serial port connection to the UPS. Novell NetWare Version 3.11 then notifies the workstations, and does an orderly shutdown of the system. The workstations will probably have failed already, because they are not on a
UPS, but the orderly shutdown of the database and file servers will ensure that the databases and all other files will not be corrupted. Upon restoration of stable power, the servers will automatically power up, restart the applications, and be ready for
user logons.
The uninterruptable power supplies protect the file server, the database server, the tape backup unit, and the LAN wiring concentrator.
A Mountain FileSafe 1200 1.2 gigabyte DAT tape backup unit is installed on the file server. It will back up all files on both the Novell file server and the OS/2 database server to a single tape cartridge. Unattended backup will allow the LAN
administrator to insert the tape before going home at night, and the system will back up all data sets on both servers, automatically, overnight. EDD/CUIAB support staff also can start or monitor (or both) the tape backups remotely.
Each location has a combination of laser and dot matrix printers. The printers are attached to either the file server or any workstation. They may be shared by any user on the LAN/WAN.
The laser printers are HP LaserJet model IIID. Each IIID will be configured with 2M of memory, two letter-size trays, one legal-size tray, one bar code, and one more font cartridge. Two input trays of 200 sheets plus the 50-envelope power envelope
feeder may be installed at the same time. The printer has two font slots, one of which will be occupied by the bar code font cartridge.
The CUIAB application will use Structured Query Language (SQL) to access a Microsoft SQL Server relational database. Microsoft markets the OS/2 version of the Sybase relational database under license from Sybase Corporation. The software uses an
enhanced version of SQL called Transact-SQL. Transact-SQL is designed to benefit both SQL beginners and those who have SQL experience. Through the use of stored procedures, Transact-SQL has enhanced standard SQL database access. Stored procedures can
combine almost any SQL statement with control-of-flow language. This greatly enhances the power, efficiency, and flexibility of the SQL database language.
Easel provides an I/O interface designed for Microsoft SQL Server access. This makes it easier to code Easel programs that access the database.
The SQL Server controls referential integrity through the use of table creation parameters and system tables. The SQL Server automatically manages all requests to change the database and records each request on the system controlled transaction log.
This transaction log is then used to control database backup and recovery. Through the use of the SET statement each query against the database can be monitored for performance. Utilization of SP Monitor can also monitor the performance of the SQL Server
itself.
The database server will contain a separate hard disk drive for the database transaction log. This will enhance database performance as well as recoverability in the event of a problem.
The proposed WAN provides two major functions:
The physical layer of the WAN consists of leased-line modems, voice- grade telephone lines, bridges, gateways, and the front-end processor at the California State Health and Welfare Data Center (HWDC). The software layer at the host consists of CICS,
TSO, PROFS, EMC2/TAO, VTAM, and NCP. The PC software includes the gateway and protocol converters, bridge and routers, e-mail routers, and e-mail gateways. All of these products, working together, comprise the WAN.
The net effect of this configuration is total transparency across the wide area network. Any authorized user on any of the 130+ workstations can access any other LAN and can do anything that could normally be done if he or she were physically on the
other LAN. Any authorized user can also access the HWDC mainframe.
Gateways provide SNA access from the three central LANs (Sacramento, Inland, and Higher Authority) to the HWDC host. The gateways are based on Gateway Communications Inc.'s G/SNA Gateway product. This product is a combination of hardware and software
residing in a "gateway server." It communicates with the host over a leased voice-grade telephone line running at 9,600 bits per second. It uses an SDLC adapter in the Gateway server and a State-supplied synchronous modem (for example, Codex
model 1130).
G/SNA Gateway supports 3270 emulation with file transfer capability. G/SNA Gateway acts as a 3274-51C cluster controller and as such is a PU type 2 device. As configured, each of the three gateways will support 128 concurrent host sessions, or 384 host
sessions in total. This is well over the 20 host sessions per LAN requirement of the application. The workstation component acts as a 3278 or 3279 (CUT) device and can support up to 4 concurrent 3270 SNA sessions.
Gateway's 3270 emulator runs on the workstation in fullscreen mode. Although multiple 3270 sessions may be run concurrently, they cannot run in the background.
For inter-LAN connectivity, a bridge connects each LAN to the Public Data Network (PDN), and deciphers the routing information to deliver a data packet to its destination.
The bridges will be connected to a PDN via synchronous voice-grade leased lines running at 9,600 bits per second over state-supplied Codex synchronous modems. The PDN acts as a multiplexor so that each LAN is in effect simultaneously connected to every
other LAN.
A user on any LAN can log onto the server on any other LAN to transfer files. The user may, with proper authorization, also access the database or execute any job on the other LAN as if physically locally connected to the other LAN. However,
performance will be poor in this mode. This function rarely will be used for production work and is available primarily for support. Performance is determined by the speed of the lines into the PDN and has been set by the state to be 9,600 bps. This speed
is upgradable to 19.2Kbps. If two sites need to engage in a large amount of communication, a leased line service can be installed to upgrade the speed to 56Kbps or 1.2Mbps.
This WAN has been designed for light and infrequent data traffic, which is consistent with the autonomous functioning of the individual CUIAB sites. Performance will suffer if traffic grows due to new applications being installed. At that time,
upgrades to the number of lines and/or line speeds and/or dedicated lines may be required. The hardware and software have been chosen to be scalable in this regard.
There are 14 bridges, one for each LAN, and Rosemead. The bridges are based on the Digital DECstation 320+ PC. Each bridge consists of a DECstation 320+ with 1M of D-RAM, running MS DOS 3.3 and Gateway Communication's G/Remote bridge software.
There are three SNA gateways. Each consists of an adapter card and software and physically resides in the same machines as the bridges in Sacramento, Inland, and Higher Authority. In addition to the bridge equipment listed previously, the gateway
function will be provided by the following hardware and software:
Users on workstations directly connected to other LANs in the network can access all functions on a remote LAN by logging into that LAN as described in the WAN section.
As shown in Figure A.18, these requirements will be met via the use of Novell's NetWare Access Server software running on a dedicated remote access gateway on each of the 13 LANs. A Digital DECstation 325c 25 MHz/386 machine will act as the remote
gateway on each LAN. As configured, it will support four concurrent dial-in users via a Novell WNIM+ four-port adapter card and four state-supplied 2400 baud modems. The access gateway is expandable to support up to 15 concurrent dial-in users.
The remote user will be able to access all files on the Novell file server and transfer files in either direction between the remote PC and the file server.
In addition, the remote user will be able to run any character-based program as if directly connected to the local LAN, including e-mail, scheduling, word processing, and spreadsheets.
The CUIAB application is being developed as a Windows application and the communications traffic generated by a GUI application is not practical on a remote PC via the access gateway.
Figure A.18. Remote access overview—hardware and software.
From any CUIAB LAN workstation, EDD/CUIAB technical support staff will be able to log on to any LAN for the purposes of system and application support. Novell's Remote Management Facility will be used. It provides the necessary capabilities to manage
the LANs from any remote location.
Cabletron's LANView/Windows will be installed in Sacramento and Inland. It provides all of the necessary troubleshooting, preventative, and management capabilities. EDD staff in Sacramento and Inland can remotely monitor suspicious LANs or individual
ports, shut down a port, and determine if a machine is connected or powered on. To assist in asset management, staff can remotely view or update user name, machine type, location, contacts, and software levels.
Host access is supported via Gateway Communication Inc.'s G/SNA Gateway product.
An authorized user on any workstation on any LAN can start a 3270 emulation session on his or her PC and logon to TSO, CMS, CICS, EMC2/TAO, or PROFS on the host. This provides access to current and future applications on the HWDC mainframe. The 3270
emulation program runs as fullscreen applications on the workstations. The SNA gateways have been configured to support a maximum of 384 concurrent LUs (sessions) with the HWDC host (128 per gateway). Although all 130 workstations can start multiple 3270
emulation sessions, only 128 sessions per gateway can be active at any one time.
3270 file transfer is supported via IND$FILE. 3287 printer emulation allows the workstation's locally attached printer to act as a 3287 attached to a 3274 controller.
Each LAN will have Microsoft Mail for Windows installed to support the locally attached DOS/Windows workstations. Each LAN will also have the CUA character-based version of Microsoft Mail installed to support the remote (laptop) users.
Powercore Inc.'s Network Scheduler II for Windows is a full-function scheduling package that interfaces with Microsoft Mail. Each LAN will have both the character-based version (for remote users) and Windows version (for local users) installed.
E-mail is localized to each individual LAN. It provides a mailbox for each user that resides on the user's directory on the file server's hard disk. A post office resides on each LAN's file server. Because 80 percent of all mail typically is sent
within the same work group, this results in faster service with no mainframe overhead and reduced communications costs. Access to other post offices can be done as required or on a scheduled basis.
Access to PROFS and therefore EMC2/TAO on HWDC is via a Microsoft Mail PROFS gateway on the Sacramento LAN. PROFS users can create a memo in the standard PROFS format and send it to any user on the network. It will automatically be converted to the Microsoft Mail format when presented to the CUIAB user, and vice versa. Files can be attached to the e-mail and sent back and forth between the two different e-mail systems. The PROFS's gateway hooks into the existing EDD connection between PROFS and EMC2/TAO on the HWDC mainframe. In this way, any PC user can send and receive mail from EMC2/TAO mail users and PROFS mail users.
