RollCall: A Flexible Distributed System and building it fast · RollCall: A Flexible Distn1>uted...

1'TANDEM

RollCall: A Flexible DistributedSystem and building it fast.

Lawrence T. RyanConsultant Group, Tandem CSO

Technical Report 88.8July 1988Part Number: 16469

RollCall: A Flexible DistributedSystell1 and building it fast.

Lawrence T. RyanConsultant Group, Tandem CSO

Technical Report 88.8July 1988Part Number: 16469

Tandem Computers July 1988 Page 1

RollCall: A Flexible Distn1>uted System and building it fast.

Lawrence T. Ryan

July 1988

Flexibility is key to on-line transaction processing systems. RollCall is a flexible online enrollment system designed to easily handle ad-hoc requests on Tandem's internalinternational network. An object-like front-end communicates with multiplefunctionally oriented back-ends through defined messages. The internal electronicmail system is used to communicate with employees. RollCall's front-end was builtusing code generation techniques facilitating prototyping and timely delivery of thefinal system.

Table of Contents

1. Overview 32. RollCall Architecture 4

2.1. The Front-End 62.2. The Back-End 72.3. Performance Considerations 8

3. The Presentation 83.1. COlIlII1ands 93.2. Explode/Select 103.3. 'fypes of Screens 13

4. Standard Functions 145. Design Methodology 14

5.1. The basic function 146. Development Notes 15

6.1. Prototyping 156.2. The Development Environment 16

7. Summary 178. Bilbliography 17


L Overview

A major goal in building operative systems is designing a basic set of functions forsupporting business procedures. The challenge is developing these functions to supportexisting standard business procedures. while. providing flexibility to support ad-hocand new procedures.

Example 1: Suppose we provide a system to enroll students in classes. A customer callsto enroll in a class. We start by finding an open class and filling out an enrollmentform. While entering billing information the customer asks. "Is that the same classJohn Smith is taking. I want to attend the same class.". We need to fmd the class JohnSmith is enrolled and place the new enrollment in that class. Furthermore. we want tosatisfy this request without restarting the whole procedure. Le.. reentering theenrollment information.

A business procedure is an ordinal sequence of basic functions. Each function performsan atomic action against the data-base. Each atomic action affects a data-basetransition from the current valid state to another valid state. Integrity constraintsascertain that the action is permissible. The follOWing diagram shows thisinterrelationship:

)User

Functions

,~'2 >'~..,'

: ~.i

Yo:..".'y~.~I loc

Principle components of an operative system.

Extending example 1. enrolling a customer is comprised of the following two basicfunctions:

o Find a class.o Enroll the customer.

These basic functions are manipulated through a set of commands. Some commands.such as help. are common and implemented throughout all basic functions. Othersbehave specifically for that function such as CANCEL CLASS.

In designing RollCall l we've used this paradigm where each Pathway(tm) requestorprogram is a basic function.• such as ENROLL-EMPLOYEE enrolls an employee in aclass. and CLASS-LIST shows a list of classes. We defined pelVasive commandsinvokable by standard 65302 function key. Furthermore. we defined a universal

1 RollCall is the new enrollment system used by Tandem's Education Department.2 6530 is Tandems standard terminal. Currently. RollCall only supports 6530's.


interface supported by all basic functions which supports the following twocapabilities:

o Any basic function may suspend and call any other basic function.

o Context may be passed between any two basic functions.

See the following diagram.

~niYer-S811yDefined

Inter-face

User

Interfaces in RollCall.

Applying this to example 1. when the customer requests to be enrolled in the same classas John Smith. through the call command the enrollments for John Smith aredisplayed. If John is enrolled for a different class the information is copied fromJohn's enrollment to the new enrollment.

This paper describes RollCall's user interface and how it handles the above problem.Section 2 provides a frame-work for describing the user-interface by describingRollCall's architecture. Section 3 details the user interface. section 4 describes thedesign methodology, and section 5 the development methodology.

The main thrust has already been stated: operative systems must be built to be flexible.The remainder of this paper explains how we built such a system with Pathway(tm).

2. RollCall Architecture

Rollcall employs a centro-distributed structure with a network-wide deployed front-endand multiple back-ends. Each back-end represents one operation.


Tandem Corp. Internal Network

LondonRollCallSystem

CIS

HumanResourcesRollCallSystem

Courier

Santa ClaraRollCallSystem

Network of front-ends and back-ends.

Through a standardized message exchange any front-end may communicate with anyback-end. Each message consists of an IPC (InterProcess Communication) header andmultiple UOW's (Unit of Work). Each message is atomic and individually recoverablethrough TMF(tm) 1.

1 The mechanism for these messages is very similiar to the mechanism used byTransfer(tm). See the Transfer(tm) Programming Manual for more information.


Front-end communicates to back-ends via structured messages.

A VOW is a function to be perfonned. The following are some example VOW's:

ENROIL: Enroll either a customer or student.VIEW: Invoke any SQL view.FIND-CLASS: Find a class satisfying constraints.

Each VOW is individually processed. Some VOW's as a side-effect set a global variable.For example, FIND-CLASS sets the global variable CLASS-ID to the class found. If anENROIL VOW proceeds it, the ENROLL VOW will use this CLASS-ID for the enrollment.

The IPC header controls the processing of the VOW's, provides the identifier of the userrequesting the work, and indicates the users native language.

2.1. The Front-End

The front-end is built with Pathway(tm) requestors that run under Transfer(tm). Theuser may access RollCall through PS Mail(tm) by the extras function key or directly.

Before accessing any function the user is required to logon to Transfer. The usersTransfer profl1e is used to establish the following defaults:

o Default language.o Default output device.o Guardian(tm) userid.o RollCall defaults.

RollCall may have the functions written in multiple languages; based on the usersdefault language the corresponding functions will be called 1. Yet. with the callingcapability explained in section 1 the user may call a screen in any language.

The default output device is set for all print requests.

The users Guardian(tm) userid is used to start any processes on their behalf.

The user may specify that a specifc basic function is called after logon. Furthermore,they may preestablish a default back-end system for all work. This is a default. Pertransaction, the user may change the destination of a request.

1 Currently, RollCall is only written in English.

Tandem Computers July 1988 Page: 6

Example 2: A customer calls and asks to be moved from a class held in Germany to onein the USA. Germany and the USA each have their own back-end.

With RollCall, an admin can cancel the enrollment from the Germany back-end,change the class to a USA class, and send the enrollment request to the USA back-endwithout having to reenter any information. This procedure is a combination of twobasic functions:

o Cancel enrollment in Germany class.o Enroll customer in USA class.

2.2. The Back-End

The back-end consists of a set of dynamic PATHWAY serverclasses and an ENSCRIBEdata-base. Each back-end data-base is a logical partition of all back-end data-bases.This permits their combination at anytime for reporting across all data.

The serverclasses provide the following functions:

o Message procesSingo Formatted letter parsingo Letter generationo Journalling

As already stated, the back-end processes all messages created by the front-end. Thesemessages may be sent interactively, on-line, or staged through Transfer. All messagescontain the correspondent name of the requestor which is used by the back-end forsecurity checking.

Transactions may be submitted as formatted mail messages through electronic mail(PS/MAIL) or COURIERl. A letter parser parses the letter, constructs a message. andsends the message to the proper serverclass for processing. Provided the proper rulesare coded, any transaction may be submitted as a formatted message.

Example 3: An employee requests enrollment in a beta class through COURIER Sinceonly the class instructor may enroll students, the message is forwarded to theinstructor. Upon reading this forwarded message on their INBOX, the instructor decidesto authorize the enrollment by replying to the message. The message returns to RollCallwith the instructors correspondent name as the sender; therefore, the enrollmentcompletes successfully. This results in generating a letter and sending it to the enrolledemployee and their manager.

In this example, the transaction was captured at its source and never required reentry.Optionally, the instructor could reject the request by adding some comments andforwarding the message to the requester.

A letter generator communicates transaction results to interested parties via electronicmail. These letters are built using data-base information and may be sent to anycorrespondent or distribution list.

Example 4: The Education Admin graduates students upon class termination. Thistransaction triggers letters to be generated for each student and sent to Human Resource(Personnel). Based on this letter, the employees transcript is updated. Therefore, withinminutes of graduation, an employees transcript reflects their successful completion ofthe class.

I Courier is Tandems internal system for submitting formed letters via Transfer.


Journalling allows logging of any event. This facilitates system auditing. problemtracing. and notification of unusal circumstances. Optionally. these jounalled eventsmay be escalated by sending an electronic mail message to a predefined distributionlist. A unique distribution list may be assigned to each event type.

Example 5: An unathortzed employee tries to cancel a class causing a security violationto be logged. Since this event type is escalated to the local system manager. anelectronic mail message is created and sent to him. When the system manager receivesthis message on his INBOX. he forwards it to the emloyees manager asking. "Why is youremployee doing this?".

2.3. Perfonnance Considerations

When designing systems careful attention should be payed to optimizing theconstrained resource; typically. in an international network the network isconstrained. By having a front-end that can hold context and a back-end we couldoptimize the number of messages and their size. The message size varied from 100 to2000 bytes.

We minimized the number of messages in two ways:

o careful interface designo all transactions are atomic

The user interface permitted the partial entry of any key for finding information. ThIspermitted the user to rapidly retrieve the desired information with minimuminteractions.

We adopted this rule: All transactions are atomic. Threrefore. the data-base does notneed to be queried to submit a transaction and a transaction requires only one message.

3. The Presentatlon

Today we interact with an increasing number of computer-based systems. Often. eachsystem dons a unique interface with limited inter-system integration. RollCallameliorates these issues by adopting and enhancing Transfer/Mail's user interfacestandard. Furthermore. inter-system integration is provided through two key features:

o Any RollCall program may call ANY other program. including anotherRollCall program. a Pathway requestor program. and a Guardian program.

o Context may be passed between any two RollCall programs.

The Transfer/Mail presentation style has been adopted and extended for all screens.The screen layout is very similiar and function key usage is the same. For example. F15is help on all screens and the bottom line is an option line for entering text needed by acommand.


All screens have a standard layout shown as follows:

12(3

45S7a9101112131415161718192021222324

Normal Field: _

ErrorI Advisory LineF\lnction 1<ey line 1F\lnction 1<ey line 2F\lnction 1<ey line (3

Comma.ncrLine

Standard screen layout.

Pa.ge x ofy MORE

The screen title is the same as the program name.

The error line shows all messages. They remain until the user presses a function key.

If the screen contains multiple pages the function keys NEXT PAGE and PREVIOUSPAGE are used to traverse the pages and the text "Page x ofy" is displayed on the top lineto show the current page.

Lines 21 through 23 show the currently active function keys.

The 24th line. called the OPTION LINE. is an unprotected reverse field. Here. the userenters any text required by a command.

The screen area consists of the remaining 18 lines. This area may contain text.protected fields. and un-protected fields.

3.1. Commands

A command is any user request initiated by pressing a function key. A function key Isany of the keys Fl through F16. SF1 through SF16. NEXT PAGE. PREY PAGE. ROLLDOWN. or ROLL UP (RETURN is not considered a function key). These commands mayuse the current cursor position and text in the option line. The follOWing commands areuniversally invokable from any screen:

oHelp


o Scroll through valueso Print Screeno Recover Screeno Read First & Nexto Enter an IR (Incident Report)o Exito Call any Guardian or Pathway program

Help is provided for each screen and each field on each screen. The user may obtainhelp on any field on any screen by positioning the cursor to that field and pressing FI5.

For fields with a known number of values. the permitted values may be viewed byplacing the cursor at the field and pressing the ROLL DOWN key. This will sequencethrough the defined values one at a time. This command can be used so the user candiscover the valid values and automatically have it filled 1.

By pressing F9. any screen may be printed to the output device specified in the usersprofile. The output may be redirected to another device by entering its name in theoption line before pressing F9.

Recover Screen will recover the users screen.

A screen may have multiple keyed fields. By placing the cursor in one of these fields.entering a value. and pressing a READ function key a record may be read. READ FIRSTreads the first record matching or greater then the value: READ NEXT reads the nextrecord greater than the existing value.

At anytime the user may submit a problem report or request an enhancement.Automatically. the user-id. time. date. version of software. and program name areentered into the form. The user only needs to classify the problem and explain it. Aftercompleting the form. the user submits the IR by entering FII which sends a mailmessage to the system manager respsonsible for the current back-end system the user isworking with.

The user may exit a program at anytime by pressing FIG.

Seamless integration between RollCall and other programs is provided through FI4. Byentering a program name in the option line and pressing this key any other programmay be called. including. any RollCall program. any Pathway(tm) program (no linkagesection), PS Mail(tm), or any $SYSTEM.SYSTEM Guardian(tm) program. PS Mail(tm)is accessed using the current user-id. not requiring a logon. The users Guardian(tm)user-id is used to start Guardian(tm) programs.

Other standard commands are provided. including:

o Addo Updateo Delete/Cancel

3.2. Explode/Select

As already described in the previous section. any function may be called from any otherfunction: this does not address the following situation.

1 This capability was not implemented due to time constraints. but it's possible toimpliment using Pathmaker(tm).


Example 6: An enrollment request contains infonnation about the customer anddesired class. Customer infonnation probable already exists in a customer file and theclass infonnation is in the schedule. To reduce errors and expedite entry of anenrollment the system should be able to move this infonnation into the enrollment.

Explode/Select are commands that allow moving of context between any two functions.Explode moves context from the current ifunction to the function being invoked andselect returns context from the invoked function to the original function.

3.2.1. Explode

Explode work on a per field basis. The user moves the cursor to a field and presses theexplode key (FlO). This will save the current function and call another function passingthe name and value of the exploded field. The receiving function verifies that a validfield is received and then executes a READ FIRST using the exploded field value as thepositioning value.

Example 7: A user wants to see what customers are taking classes about Pathway atSanta Clara. The follOwing diagram depicts one sequencing of explodes that willaccomplish this. The user first views a list of courses. looks for detail about a specificcourse. views the classes being given for the exploded course. verifies that the loc num ofa class is Santa Clara. explode the particular class to see the class roster. and finallyexplodes an enrollment in that class.

COURSE-MANAGEMENT

r- J Course ID

Course, Name

LOC

(Loer )

(courS.IO )

COURSE- LIST

L.·····..·····i Course NameEN RO LL - CUSTOMERLoc Num .........•...................!

c::::~~;·:;···_····1 (C1lO )

[ass 10 y_.!

CLASS-ROSTERTravsersing infonnation with Explode.

The above is not the only way of linking this infonnation with explode. Users mayexplode from any explodable field to any function that can do a READ FIRST on thatfield.


Another way of accomplishing example 4 is to call COURSE-LIST. explode to CLASSLIST using COURSE NAME. Each class on CLASS-LIST may then be exploded toCLASS-ROSTER to see the students enrolled.

There's a myriad of ways to link the information using Explode.

3.2.2. Select

When the user finds the desired information. the select (F11) key maybe pressed toreturn the found information to the origination function. This information will fillthe exploded field and optionally fill-in other fields on the screen.

The following is a simple example of using select and explode. For example. a clerkwants to pull information from a customer file to complete an enrollment. The cursoris positioned on the student name field and the explode function key pressed.

Enrollment Service

Student Name: mCompany Name: "-Company Address:

~ ..........

Cless Name:Class Date:

Cursor

A list of student names would be diSplayed. The clerk can then browse through lookingfor the desired name. When found. the clerk can then position the cursor to the nameand hit the explode key again.

Student List

Name Comp-anY.: Ty.p.eBBill Good MicroSoft Customer

A. Herzfeld Apple CustomerJoe NonStop Tandem Analyst

\\

Cursor

This will show a complete deSCription of the student.


Student Information

Name: Bill GoodCompany: MicroSoftAddress: 10700 Northup Way

Bellevue, Wa. 9a004

Type: customer

If the clerk now hits the select key, all data will be copied about the student back to theenrollment. This includes the student name, classification, address, and etc.. Theenrollment screen will be redisplayed showing all of these fields ffil-in.

Enrollment Service

Student Name: Bill GoodCompany Name: Microsoftcompan.:rc Address:

lO 00 Northrup V ayBellevue. Va. 98004

Class Name:Class Date:

The EXPLODE/SELECT capability is the most powerful unifying concept. It allowsconstruction of new functions and their IMMEDIATE integration with the existingsystem without changing any existing code. Furthermore, we train the user how to usethe capabiltity, without knowing how they'll use it. The user can use this capability toinnovate new procedures and handle ad-hoc procedures.

3.3. Types of SCreens

When classifying the screens in any application, there are three overall screen types:

o Menuo Browsingo Transaction

These three screen types are supported under the defined presentation methodology:each is actually a subset of the defined standard.

A menu screen shows the available functions and allows the user to select the functionto execute. Although with the call capability (FI4) this capability is superfluous, it'sprovided for novice users. A menu program does not support explode/select and thefunction keys are used to call other programs.


A browsing screen shows a list of items organized by various keys. Only reading isallowed. Furthermore. if in explode mode one of the listed records may be selected.Likewise. any listed record may be exploded to a detail screen.

A transaction screen allows a user to submit a transaction. These screens support thefull standard. including. explode/select.

4. Standard Functions

Some standard functions are provided; these functions provide features unrelated to aspecific business procedures. As already stated. these functions may be called from anyother function. The follOWing standard functions are defined:

oIRo CREATE-MAILo PARAMETERS

IR (Incident Report) allows a user to submit a problem. When called. this functionautomatically fills-in the date. time. version. and name of the calling function. Thetype of problem (Critical problem. normal problem. or requested enhancement) andtext explaining it is the only required information. The IR is mailed to a distributionlist associated with the current default back-end system.

CREATE-MAIL functions similiar to create mail in PS/MAIL(tm).

PARAMETERS allows a user to change their current defaults. including:

o Guardian(tm) userid and passwordo Default output filenameo Default back-end system

5. Design Methodology

The RollCall front-end was deSigned using an "Object-Oriented" methodology. This is amethod of system specification by encapsulating functionality into modules. Eachmodule has a prescribed interface with an associated behavior: modules internalizetheir methods.

Rollcall manifests objects as Pathway requestor programs. Each program provides abasic business function through the user interface described in section 3. Programs cancall each other using a univerally defined interface.

5.1. The basic function

Each function is designed independently. There are no hard-coded dependenciesbetween these functions. All dependencies are defined through the universal interface.

When a function is called. it verifies if it's a call or explode. If an explode. the functionchecks to ascertain that the context passed is valid for it's capability. If the function isunaware of the context. it rejects the request. If the data is valid. the function performsa read first on the passed value and displays the information.

When the user explodes a field. they may optionally place a program name in the optionline. If no name is prOVided. a default program is used for the explode. The informationentered into the field is sent to the program exploded to.


If the user presses select. the program returns the selected value to the calling program.

5.1.1. The universal interface

The universal interface allows any function to call and pass context to anotherfunction. The following infonnation is passed:

o Action codeo Logical Data Nameo Logical Data Valueo Associated Value

The action code specifies whether the communication is a call. explode. or select. TheLogical data name is the name attached to the element. The Logical Data Value is theactual value. Associated values is a way of passing other infonnation with the element.For example. COURSE-ID is the Logical Data Name for the product number assigned to aTandem class. It has the follOWing structure:

o Logical Data Name:COURSE-IDo Logical Data Value: Tandem product numbero Associated values: COURSE-NAME

where COURSE-NAME is a string reprsenting the name in the course catalogue.

Whenever the user places the cursor on a field of type COURSE-ID and hits explode. thisinfonnation is passed to the called program. The called program takes thisinfonnation. validates that it knows it. and perfonns a READ FIRST based on theinfonnation passed.

6. Development Notes

Any experienced programmer will immediately recognize that defining. building. andmaintaining this standard is a comprehensive undertaking using conventionaldevelopment standards. We built RollCall. consisting of over 60 Pathway requesterprograms and 50 UOW types. in 6 months and in production within 9 months. Our staffconsisted of 2 developers. 1 part-time QA & control person. and 1 project manager.How? We protoctyped with a code generation methodology based on PATHMAKER (tIn).

6.1. Prototyping

Prototyping is a strategy for detenning system requirements through extensive userdiscourse and construction of a real model. Prototyping is based on realizing thatpeople better understand a real model then a logical model written down on paper.

Effective prototyping requires the ability to qUickly construct a model and evolve it toa real system. Developing prototypes by writing programs is too costly and takes toolong; tools are mandatory.

We analyzed using workstations for building the prototypes. but qUickly realized thatthe prototype would eventually be disposed. Instead. we built all prototypes in aTandem-based environment and found that this provided a smooth migration pathfrom first mock-up to the final production system. In fact. we employed prototypingcontinuously throughout the project. even to test and review enhancements with theusers.


6.2. The Development Environment

RollCall's front-end was generated using PATHMAKER(tm) and a code generator writtenin MUMPs. The following diagram depicts the development environment.

SCOBa.copylib

•

MumpsSkeleton

MumpsParameter

File

Development Environment for front-end.

DDUtm) was used to define all data structures and records. PATHMAKER was used todefine all screens and generate the base requestor code. Originally. all requestors weredefined as PATHMAKER DB type requesters. This allowed us to demonstrate the systemusing a real data-base with real data. Integrating the prototype with real data permitedtesting process flows through the system with the user.

Subsequently. we tried enhancing these DB type requestors so that our own functionscould be added: we could'nt. DB type requestors prohibits user defined working storageand sending messages to selVers. These restrictions forced us to convert all requestersto PATHMAKER TRNS type requesters. Since PATIIMAKER prohibits changing arequester type, we directly modified the dictionary to preserve all screens.


Explode. Select. and some other features could not be implemented using Pathmaker'scode generator based on the dictionary. Instead. we implemented these features with acode generator written in MUMP's. This code generator was about 200 MUMP'sstatements. It took two files as INPUT: a skeleton file and a parameter file. Theskeleton file was SCOBOL statements which were modified by the code generator basedon the parameter file. The result was a SCOBOL copylib that was included in the finalcompile.

In retrospect. code generation methodology based on a skeleton severely shortened ourdevelopment cycle by allowing easier and quicker management of change. This allowedus to build early mock-ups of the system for review with the user. These early reviewsallowed us to build a more accurate system satisfying the users real requirements. andnot necessarily the ones reflected on paper.

Managing change allowed step-wise refinement from preliminary mock-up to aproduction quality system.

7. Summary

The RollCall front-end uses an object-like methodology for deplOying functions. Thispermits construction of new and ad-hoc procedures easier and without programmodification. Furthermore. it allows integration of new functions without modifyingexisting functions.

The code generation methodology. based on PATHMAKER(tm). allowed early reviewwith the user allowing a more accurate system to be built. Furthermore. it allowed thechanges to these prototypes to be managed such that they eventually became theproduction version.

Finally. by integrating electronic mail with RollCall a closer connection wasestablished with users reducing transaction reentry and timely notification of results.

8. Bilbliography

PATHMAKER Programming Manual. Part no. 82450. Tandem Computers Incorporated.

TRANSFER Delivery System Programming Guide. Part no. 84030. Tandem ComputersIncorporated.

P. W. Metzger. 1981. Managing a Programming Project. Prentice-Hall. N.J..

K. E. Lantz. The Prototyping Methodology. Prentice-Hall. N.J..

W. M. Newman. 1987. Designing Integrated Systems for the Office Environment.McGraw-Hill. N.Y.. N.Y..

B. J. Cox. 1986. Object-Oriented Programming; An Evolutionary Approach. AddisonWesley. Reading. Mass..


Distributed by'1'TANDEM

Corporate Information Center10400 N. Tantau Ave., LOC 248-07Cupertino, CA 95014-0708

Date post:	13-Jul-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

RollCall: A Flexible Distributed System and building it fast · RollCall: A Flexible Distn1>uted...

Documents