System 370 Capability in a Desktop Computer

7/29/2019 System 370 Capability in a Desktop Computer

1/11

System/370 capabi l i ty in adesktop computer

by F. T. KozuhD. L. LivingstonT. C. Spillman

A desktop computer with System/370 capability wasproduced by enhancing the IBM Personal ComputerXTwith additional hardware and developing software thatprovides a compatible interface.The com puter, th eIBM Personal Computer XT/370, and this softwarel-low users to run most System /370 Convers ational Mon-itor System application programs unaltered in a desk-top environment. The evolutionof the development anddetails of the function of the hardwareand softwareare described.

L rge investments have beenmade by many com-puter users in System/370 software and in theskillsneeded to develop, maintain, and use suchsoftware. IBM'S recently announced Personal Com-puter X T ~ OPC XTWO) running Virtual Machine/Personal Computer (VMIPC) software is a big steptowards using System/370 software in microproces-sor-based desktop computing systems. VM/PC is asingle-user control program which provides n inter-face that is compatible with the Conversational Mon-itor System (CMS) and capable of supporting mostexisting CM S application programs. The applicationprograms execute on the small, relatively inexpen-sive desktop computer just as they would on a largerSystem/370 mainframe and include user programs,editors, document composers, language processors,etc.The PC XTWO was produced by enhancing the hard-ware of the IB M Personal Computer XT (PC T) withthree cards: a communications card, a 5 12K memorycard, and a coprocessor card. Together these cardsprovide the System/370 instruction execution capa-bility along with the ability to connect to System/370 host systems. VM/PC not only provides the nec-essary interface to support CM S programs, but also

provides a means of coupling its CM S environmentwith a CMS environment running in a host processorand the ability to transfer filesbetween the IBMPersonal Computer Disk Operating System (PCms)environment and the VM/PC CM S environment.

In this paper, the evolution of the PC X T ~ Ond VM /PC is firstdescribed. The remainder of the paperprovides an overview of their function.BeginningsPC ~ ~ 1 3 7 0nd VM/PC evolved independently prior toFebruary 1982.Hardware development for the PC XT/370 began as anexperiment to implement the System/370 architec-ture in a microprocessor environment. After study-ing several types of microprocessors to identify onearchitecturally suitable as a base for System/370,BMselected the Motorola MC68000 microprocessor ndbegan working with Motorola engineers to developa customized microprocessor. At IBM'S site in Endi-cott, New York, a group in the engineering organi-zation wrote the internal microcode which allowedthe device to directly execute a large subset of thecommercial System/370 instructions. It was deter-mined that the remaining general-purpose instruc-

Copyright 1984 by International Business Machines Corporation.Copying nprinted orm orprivate use ispermittedwithoutpayment of royalty provided that ( I ) each reproduction is donewithout alteration and2) the Journal reference andIBM opyrightnot ice are included on the first page. The title and abstract, but noother p ortions, of this paper may be copied or distributed royaltyfree without urtherpermissionby omputer-basedandotherinformation-servicesystems.Permission to republish anyotherportion of this paper must be obtained from the Editor.

IBM SYSTEMS XXIRNAL, VOC 23. NO 3, 1984


2/11

Figure 1 Main menu of VM/PC

tions could be emulated using a generic MC68000microprocessor and that the floating point instruc-tions should be implemented in a dedicated chip toincrease performance of scientific an d engineeringapplications. To obtain this goal, IB M and Intel Cor-poration jointly defined another customized m icro-processor based on the Intel 8087 to execute System/370 floating point instructions directly.Using the multiple-microprocessor concept, engi-neers at Endicott designed and built a test card thatproved the feasibility ofa microprocessor-based Sys-tem/370. Two problems remained: the first was tofind a suitable base unit to con tain the System /370processor and the econd was the development of anoperating system that would make efficient use of t.The VM/PC software traces its origins to an activityinitiated at the IB M Cambridge Scientific Center tobuild a prototype of a CMS workstation. This proto-type was called CnS (C ambridge nano-System) andis described in Reference 1. Agroup from IBMSEndicott laboratory, jointly with Cambridge, devel-oped a version of CnS running on a 370 emulatedentirely in software written for a M otorola MC 68000ExoRmacs@system. Although CnS did not supportvirtual storage or full-screen displays and used dis-kettes for disk I/O operations, many of the feasibilityquestions were answered by this work.By early Februa ry 1982, Cam bridge had migratedCnS ton emulated System/370 environm ent

246 KOZUH, IVINGSTON. AND SPILLMAN

housed as a coprocessor inside an IB M Personal Com-puter. Cambridge had built their prototype such thatthe System/370 environm ent could access its mem-ory via a 16-bit bus but still share that mem ory withth e PC. After evaluating the Cambridge prototype,the team from Endicott reached several conclusions:

First, while software emulatio n of System /370 wasfeasible, t acked ufficient perform ance for aviable product.Second, the required performance could beachieved by the custom System/370 processorchips under development in E ndicott.Third, to fully capture System /370 applications, avirtual mem ory environm ent would be necessary.For this, a fixed disk was needed to sup port paging.Thus, the Endicott team began developing a desktopversion of System/370 CM S running on the System/370 coprocessor. The System/370 was packaged in-side an unmodified PC XT , which contains he re-quired fixed disk.The PC X T / ~ ~ Ond the companion M/PC software arediscussed in detail in the rema inder of this paper.VM/PC co mp atibil i ty and versati l i tyCompatibility with the VM/CMS application interfaceis the cornerstone upon which the desktop System/370 was built. This interface is augmented by sev-eral other major features that comb ine to give theuser conven ient access to a road variety of functionssuch as the ability to move files between PC DOS an dthe local CM S environments, the ability to print fileslocally or on a irtual Machine/System Product (VM/SP) host printer, etc.2When the VM/PC software is initiated, the user ispresented with a me nu offering access t o four ses-sions. Eachsession (Figure 1) is independent andunique, a nd the four sessions are capable of beingrun concurrently:1. The Local 3270 Session allows full-screen accessto the CM S environment running on the System/370 processor inside the PC X T / ~ ~ O .2. The Remote 3270 Session provides use of the PC

xT/37O as an I BM 3270 display device.3. The Remote 3101 Session allows the op eration ofthe IB M 3101 Emulation Program, which permitsthe use of the PC X T / ~ ~ Os an IB M 3 101 display.The Remote 3 101 Session c an be used to com -IBMSYSTEMS J OURNAL, VOL 23, NO 3, 1984


3/11

municate with another computer (host or peer)via an R S ~ Connection.4. The System/370 Processor Control Session llowsmanipulation of the mem ory, registers, and otherfacilities of the System/370 processor inside thePC XTJ370.

The user can change from one session to another,without losing data, with a singlekeystroke. Forexample, a user could be checking the stock marketquotations offered by a subscription newsserviceover a telecommunications hookup theRemote3 I O 1 Session) while compiling a FORTRAN programon a host System/370 (the Rem ote 3270 Session)and, at the same ime, be running a CM S document-processing application (the Local 3270 Session).These overlapped functions could all be executingwhile previously spooled files are being printed onthe local printer (Figure 2).The VM/PC remote serverWhen r unnin g the Local 3270 Session, the user isprovided with a CM S environment that is a compat-ible subset of its VM/SP counterpart on the hostSystem/370 computer, and this local CMS interfacecan be e xpanded in a simple and effective way bycoupling it to a CMS environment located at a hostcomputer. This coupling is achieved by first acti-vating a program called the VM/PC Rem ote Server atthe users host CM S machine (Figure 3), and then,while in the Local 3270 Session, issuing commandsto link and access CM S minidisks on the ost machineas if they were on th e users desk.With the VM/PC Rem ote S erver active, moving a filefrom the host CM S environment to the desktop CMSenvironment (or ice versa) is done with the COPYRLEcomm and familiar to CM S users. It is also possible totell the CM S editor (XEDIT), running in the Local 3270Session, to edit a file that resides only on the host.This transparency of file access allows programsrunning in the esktop machine to read and/or writedata on host files without creating a local copy ofthe file. A locally runnin g CM S application can accessa mix of up to 26 host and local minidisks with thefamiliar filemode mechanism used to determine thesearch order. Applications can be installed or de-signed in order to exploit the advantages of havingdifferent types of information on different media.For exam ple, privacy considerations may uggeststoring certain data on a minidisk on a removablediskette. The VM/PC Rem ote Serve r also gives locallyrunning CM S programs the option of directing theirIBM SYSTEMS JOURNAL, VOC 23. NO 3, 1984

Figure 2 VM/PC concurrent session activityHOST

ASYNCHRONOUSDIAL-UP 1

[VMIPC cMsENVIWNMENT IPC XTi370

printer output to the host or to the VM/SP RemoteSpooling Communications Subsystem (RSCS) net-work at the host.IMPORT and EXPORT commandsWith all the facilities VM/PC provides the CMS user, itis possible to overlook the fact that VM/PC itself is aPC DOS application running under the standard ver-sion of that operating system. The PC XT/370 is alsofully compatible with the PC XT and, when not run-ning VM/PC, the user may be running PC DOS appli-cations. Because both PC DOS an d CMS applications

KOZUH. LIVINGSTON. ND SFILLMAN 247


4/11

Figure 3 Coupling of host CMS and desktop CMSenvironments

COAXIALCABLE

maybe run on the same system, wo new CMScommands were added to VM/PC to move data be-tween the VM/PC CM S environment and the PC w senvironment:IMPORT, which copies PC w s files to files on CMSminidisksEXPORT, which copiesCM S files to PC DO S files

Both commands perform data conversion (ASCII/EBCDIC) if specified.PCXT/370 hardware overviewThe PC x ~ / 3 7 0 ~s comprised of a PC XT and threeadditional cards: the P C I ~ ~ E M ,C / ~ ~ O - P ,nd pc/370-

248 KOZUH. LIVINGSTON,ND SMUMAN

M. The P C / ~ ~ ~ E Mard emulates an IBM 3277-2 ter-minal and provides a high-speed link by which pro-grams and data are transferred between he PC ~ ~ 1 3 7 0and a System/370 host. Local System/370 processingfunctions and address multiplexing between the PCXT and the System/370 processor are performed onthe PC/VO-P card. The P C / ~ ~ O - Mard implements5 12 Kof parity-checked, read/write, random access mem-ory (RAM) as a two-ported memory.The ~ q 3 7 0 - p ndP C I ~ ~ O - Mards are connected via a ribbon cable andfunction as a unit. All cards use metal oxide semi-conductor large-scale integration MO S LSI) and stand-ard 74 s and 7 4 ~ s eries logic on multilayer printedcircuit boards.The ~ q 3 7 0 - p ard can be partitioned as shown inFigure4. As previously mentioned, three microproc-essors are used to implement the System/370 proc-essing functions. A custom-developed System/370Subset microprocessor performs mostf the System/370 commercial nstructions. Floating point, includ-ing extended precision, nstructions are executed bya custom-developed Floating Point microprocessor,which works in close conjunction with the System/370 Subset microprocessor. The remaining instruc-tions are emulated by an MC68000R microprocessorwhich also performs other tasks such as exceptionhandling.Dynamic address translation (DAT) is accomplishedthrough the use of a page table consisting of staticRAM chips. This realization provides forM of virtualmemory arranged in 4K pages. Reference, change,page fault, and parity indicators are provided to assistthe paging process nd ensure proper operation. Thismethod takes the place of the traditional main stor-age page table and table look-aside buffer (TLB). Itsmain advantage is the reduced complexity that thestatic RAMS offer compared to the TLB without theloss of speed associated with page table located inmain storage.Address multiplexing s performed on the P C ~ O - Pcard to reduce the number of signal ines on theribbon cable betweenhe ~ w 7 0 - p nd PC/370-M cards.Four address spaces are multiplexed to the P C / ~ ~ O - Mcard:1. Control storage2. The 480K real address space f the PC X T ~ Oith3. The 480K real address space f the PC u 3 7 0 with4. A 384K subspace of the PC XT

DA T onDAT O f f

IBM SYSTEMS JOURNAL,VOL 2 3 , NO 3,1W


5/11

Figure4 PCI370-P card

DATA BUS TOiFROMPC i370-M CAR D

CONTROL BUS TOiFROMPC i370-M CAR D

P C XT 110CHANNEL mError and exception detection logic is provided for1. Off-boundary accesses2. Odd program counter3. Virtual storage out-of-bounds, i.e., beyon d 4M4. Real storage out-of-bounds, i.e., beyond 480K5 . Page faults6. Page table p arity errorsThe remaining logic consists of control logic whichcoordinates system function and provides for hard-ware assistance of the execute instruction, modi-fication of the page table, and selection of DAT on orOff.

The PC/UO-M card (Figure 5 ) provides a two -portedstorage system consisting of 5 12K of memory, con-tiguous with respect o the ystem /370 address space.32K are reserved for control storage which containsthe system microcode and interprocessor commu-nications areas. Only 384K of read/write RA M ad -dress space is vailable above the 256K on the systemplanar of the PC XT. To make the entire 5 12K ofSystem/370 memory accessible to he PC XT, thecenter two 128K portions are interchanged via abank select mechanism. Byte and halfword accessesby the System/370 processor are allowed, whereasall accesses by the PC XT are on a byte basis only.System/370 and PC XT accesses are arbitrated, withIBM SYSTEMS JOURNAL,OL 23,NO 3, 19% KOZ~H,LIVINGSTON.AND SPILLMAN 249


6/11

Figure5 PC/370-Mcard

CONTROL BUSDATABUS PC XT 110CHANNEL

priority going to the PC XT when simultaneous ac-cesses occur. The use of a two-ported memory allowsfor ease of interprocessor communication and con-current processor operation.The PC ~ ~ 1 3 7 0ffers most of the facilities providedby a System/370 mainframe with the following ex-ceptions. I/ O instructions are not implemented sincethere are no 110channels. However, there are equiv-alent functions implemented via the DIAGNOSE in-struction. Since DAT is somewhat unique in its im-plementation on the PC XTNO, some modification ofthe LOAD REAL ADDRESS and PURGE TLB instruc-tions is required. Twonew operations associatedwith DA T were added: MAKE ADDRESSABLE andMAKE UNADDRESSABLE. The timing functions avail-able in System/370 are restrictedsince the PC XTclock is used as the time-of-day clock. These restric-tions include decreased resolution, no interval tim-ing, and no TIME-OF-DAY CLOCK control switch.Since the system is a single-user workstation, storage

keys are not implemented and, if read, appear to bezero. Finally, a subset of the PER facility is imple-mented. Even with the aforementioned restrictions,a large number of applications will run unmodified.Hence, the PC XT/370 running under VM/PC is truly adesktop System/370.VM/PC structureVM/PC consists of the following major components:

Installation/Local-an interactive aid for copyingthe system files from the distribution diskettes tothe users fixed diskInstallation/Remote Server-a bootstrap for in-stalling the Remote Server on the host VM systemfrom the distribution diskettesConjigurator-an interactive data collection pro-gram that performs the directory maintenancefunction for VM/PC250 KOZUH. LIVINGSTON. AND SFILLMAN IBM SYSTEMS JOURNAL,VOL 23, NO 3, 1984


7/11

The Session Group-three VM/K components thatoperate concurrently w ithin the PC XTWO:Control Program I/ O Services (cpro)-the partof the system that runs in the 8088 microproc-essor and manages the 110 operations and themultiple sessionsControl Program 370 (c~370)the control pro-gram (CP) functions that run in the System/370and provide the virtual machine facilities forrunning environme nts such as the CM S compo-nentConversational MonitorSystem (CMs)-the vir-tual machine environm ent supplied with VM/PCRemo te server (VMPCSERd-the ho st resid en t pro-gram that permits transparent interaction betweenthe local CMS and host CMS environments

Figure 6 shows the structure f the session group andits relationship to PC DOS and to the VM/PC Remote

Th e VM/PC application interfacepermits most CMS applications torun unaltered.

Server. Note that all I/O operations are performedfrom the 8088 microprocessor environment, not theSystem/370 environment.The versatility of the VM/K sessions was a chieved byrunning the System/370 and 8088 processors inde-pendently and concurrently. By assigningall ealdevice I/O operations, the 3270 an d 3 101 emulationfunctions, and theprinting o f spool files to the 8088processor, the S ystem/370 processor is able to runlocal CMS applications while the othe r activities pro-ceed.Like its VM/SP counterpart, VM/PC has both CP an dCMS components. In VM/PC , he CP componentoperates partly in the 8088 environment and partlyin he System/370 environm ent.The System/370part of CP concentrates on managing the single vir-

Figure 6 VM/PC structure/- A 1

REMOTE SERVER

COAXIAL LOCAL3270 SES SIONCABLE (SYSTEMI370 PROGRAMS)I8088PROGRAMS

tual machine in which the CMS component runs itscomm and a nd application interface.The user,when interacting with the Local 3270Session, has access to both CP an d CM S commandscompatible with those on the host VM environment.With these CP comm ands, he user can establishlinks, alter the spool characteristics of the printe r,format minidisks, trace and debug programs runningin the System/370 virtual machine, query the m em-ory size, etc.The CMS comm ands available to the user allow himto e dit files, define and run execs in either EXEC orEXEC 2 languages, sort files, print files, load and runprogram text files, generate modules, run variousapplication programs an d language processor prod-ucts. etc.Application and system interfacesAlthough the compatibility of the VM/PC applicationinterface permits most CM S applications to run un -altered, the interface also allows the user to developnew or modified applications with confidence thatsuch applications will run o n both the ho st VM systemand on VMIPC.Th e CM S of VM/PC has a file system compatible withthe VM/SP extended disk formatting file system.

IBM SYSTEMS J CURNAL, VOC 23. NO 3, 1924


8/11

Figure 7 Input/output flow within VM/PC

APPLICATIONROGRAM I

34

1617

SATISFIES REQUEST(HERE ASSUME NOT POSSIBLE)FROM BUFFER F POSSIBLECAUSING EXCEPTIONISSUES DIAGNOSEFOR 110UPDATES CONTROL TABLESRETURNS TO CALLER

5 BUILDSPARAMETER LIST7 SSUES REAL DIAGNOSE FOR I106 FIXES PAGES CAUSING INTERRUP TTO8088

i 5 DOESLPSW$ 14 FIELDSNTERRUPT3, TO RETUR NTO FILEYSTEM

8 COPIESPARAMETERS9 SETS UP FOR AND CALLS PC DOSTO SYSTEM1370 PARAMETER LISTSYSTEM1370

12 POSTS110RESULTS13 GENERATES 110 INTERRUPTTO

J

7Lun>8WW0m

Also, the internal controlblock layouts and nucleusarea contents of the CM S of VM/PC have been designedto permit existing applications that rely on theselayouts and areas to functio n successfully.VM/PC offers an application interface through its CMS,but it lso mak es available a system-level DIAGNOSEinterface. This interface, similar to its cou nterpa rt nVMISP, is available both to CM S applications and tothose interested in developing software that will runin the System/370 virtual machine without the as-sistance of CMS.The comb ination of application and system inter-faces gives he VM/PC user a compatible environm entfor running existing applications a nd im plementingnew applications.

252 KOZUH, LIVINGSTON, AND SPIUMAN

Files and 1/0 operationsAll of the XT/370 disk files used by VM/PC are PC w sfiles. In fact, all of the disk I/O operations are per-formed by VM/PC using PC DO S calls. By doing so, VM /PC was able to avoid the development expense ofduplicating PC DOS file-support facilities as well as totake advantage of any future file-support enhance-ments that become available through PC DOS.When an application program running under CM S inthe Local 3270 Session requests a disk I/O service, asequenc e of events is initiated th at involves all threeof the Session Group comp onents as well as PC DOS.Figure 7 summarizes the steps involved in a typicalrequest to read a disk record. The step s are as follows:

1. The application program builds a parameter listdefining the read request. The list includes thename of the file, the file type, its disk locationexpressed as a filemode , the relative record n um -ber, the amo unt of data o be read, and hestorage location into w hich to rea d the file.2. The application program then issues a standardCMS read macro (BREAD) to invoke the CM S filesystem.3. The CM S file system analyzes the request andattempts to satisfy it using data already in oneof its buffers. In this e xamp le, it is suppose d thatthe buffers are found n ot to contain the neededdata.

4. Th e CM S file system prepares for and issues an110DIAGNOSE instruction. Since CM S is operatingin the System/370 problem state, the DIAGNOSEinstruction results in a privileged operation ex-ception, which causes program control to betransferred to CPYO.

5 . C P ~ O , perating in the System/370 supervisorstate, constructs a control block containing pa-rameters defining the read request from the in-formation made available by CMS.6. C P ~ Ohen ensures that the buffers designated asI/O areas and control areas are in real memoryand that paging activity will not overw rite theseareas before the requested read is completed.This is called page fixing.7. CPVO next issues a DIAGNOSE instruction, whichcauses the System/370 hardware to present aninterrupt to the 8088 processor.8. Th e CPIO program, running on the 8088 proc-essor, fields the interrup t and reads the controlblock constructed by CPYO to determine henature of the request.

IBM SYSTEMS JOURNAL,VOL 23, NO 3, 1984


9/11

9. Determining thata file read is needed , CPIOprepares and issues a call to PC DOS.10. PC DOS issues the file read using the file controlblock identified by CPIO. In this example, dataread from the disk is ead directly into the ufferthat was page-fixed earlier (Step 6) by cP370.1 1. Upon completion of the file read, PC DOS returnscontrol to the application program.12. The application program, in this case CPIO, up-dates the control block constructed by CPYO(Step 5 ) to indicate the completion of the re-quested service.1.3. CPIO concludes by generating an I/O interrupt tothe System/370 processor.14. CPVO fields the interrupt an d updates its internalcontrol areas.15. C P ~ Ohen concludes by initiating the standardProgram Status Word exchange (LPSW instruc-tion) used to transfer control o another pro-gram. In this case, the other program is the CM Sfile system, which ha d called C P ~ ~ OStep 4).16. Upon regaining control, the CM S file system up-dates its file control tables.17. The CM S file system then returns control to th eapplication thathad originally requested theread (Step 2).18. The application resumes processing.

System/370-8088 interprocessor com mun icationIn the previous description of the steps involved inan 110activity, it was mentioned that the System /370 and the 8088 processors comm unicate by inter-rupting each other. This mechanism is used when-ever the CPYO an d CPIO need to communicate.Eitherprogram can interrupt the other. The PY O programuses a DIAGNOSE instruction to generate a level 7interrupt to the 8088 processor. T he CPIO programexecutes an OU T BYTE instruction to set one of the PCX T ~ Oontrol registers so that a System/370 inter-rupt is generated.Regardless of which program interru pts the other,the reason for the interrupt is conveyed in a controlblock constructed by the interrupting program. Thecontrol block, called a Personal Computer InterfaceBlock (PCIB), contains thepointers and status nfor-mation needed to respond to the interrupt (Figure8) .Concluding remarksAlthough VM/PC does not incorporate all the func-tions of the larger VM/SP, it does introduce a new andIE)M SYSTEMS X)URNAL. VOL 23. NO 3. 1984

Figure8 The Personal Computer InterfaceBlock (PCIB) isused during the System/370-8088 communicationAPPLICATIONPROGRAM

CPlO DIAGNOSEINSTRUCTION CMS

>OUT BYTEINSTRUCTION E lCP370++8088 SYSTEM/370exciting capability to the System/370 user comm u-nity. The host feel s eal. The com patibility isreal. The strategy of both the hardware an d softwaredevelopment to preserve native PC XT capability isexpected to accrue benefits for the PC ~ ~ 1 3 7 0sers asthe base XT product evolves.EXORmacs is a registered trademarkof Motorola.AcknowledgmentsDevelopment efforts for both the PC X T ~ Ond theVM/X software were centered at IBMS Endicott Lab-oratory. The hardware was developed by the Proc-essor Development organization, and the softwareand floating point microprocessor by the Engineer-ing/Scientific Systems and Advanced Technologyorganization.In addition to the contributions of IBMS CambridgeScientific Center, he IB M Thomas J . Watson Re-search Center contributed the nucleus for the designof the VM/PC Remote Server.4The Research Centeralso provided ameans of subsetting the CM S filesystem an d provided valuable assistance in th e de-velopment of significant parts of the CPIO compo-nent.Th e IB M United Kingdom Laboratories Limited pro-vided a CM S relocating loader technique which al-lowed VM/PC to supportCMS SUBSET mode operation.They also contributedameans of establishing areliable commun ications path between the host an dthe PC ~ ~ 1 3 7 0 .

KozUH, LIVINGSTON. ANDPILLMAN 253


10/11

Cited referencesI . T. D. R osato, MICRO CMS/370 (Cam bridge nano-System),SHARE Proceedings, SHARE 58, Los Angeles, CA (Ma rch 16,

1982).2. IBM Virtual Machine/Personal Computer Users Guide,6936733, IBM Corporation (1983); available through IBMbranch offices.3. IBM PC XT/370 Technical Reference, 6936732, IBM Corpo-ration (1983); available through IBM branc h offices.4. B. C. Gold stein, R. A . Heller, F. H. Moss, and I. Wladawsky-Berger, Directions in cooperative processing between worksta-tions and hosts, IBM Systems Journal 23, NO. 3, 236-244(1984, this issue).Reprint Order No. G321-5222.Frank T. Kozuh IBM Systems Technology Division, P.O . Box 6,Endicott, New York 13760. Mr. Kozuh joined IBM in 1966 andsince that time has held numerous technical and managerialpositions dealing with software and microcode development. In1978 he became involved with various microprocessor-based ac-tivities in th e laboratory, including the prototyping activitieswhichpreceded the development of VM/PC. In early 1982, heoined theEngineeringS cientific Systems and Advanced Technology orga-nization to manage the develop ment of the VM/PC software. Mr.Kozuh received a B.S. in mathematics from th e Unive rsity ofDayton in 1964 and an M.S. in applied mathematics from hr d u eUniversity in 1966.David L. Livingston IBM Systems Technology Division, P.O. Box6 , Endicott, New York 13760. Mr.Livingston joined IBM inSeptember 1981 and has since worked as a h ardware engineer forthe PC XT/370. He received a B.S.E. in 1976 and a n M.E. in 1 978in electrical engineering from Old Do minion University.Thomas C. Spillman IBM Systems Technology Division, P.O.Box 6, Endicott, New York 13760. Mr. Spillman joined IBM in1960 and has been involved in various operating system andcompiler development projects since that time. Currently with theEngineering/Scientific Systems and Advanced Technology orga-nization, he has been involved in the specification and development of VM /PC from the early prototypes through delivery of heproduct, serving as the Project Manage r of the effort. Mr.Spillmanreceived a B.A. in mathematics from N orth T exas State Universityin 1960.

254 COZUH. INNGSTON. ANDSPILLMAN IBM SYSTEMS JOURNAL,VOL 23, NO 3. 1984


11/11

A t ight coupling ofworkstations

by D. M.Chess

This paper addr esses the p roblem f situations inwhich people at phys ically distant locationsmust haveaccess to essentially the same co mputing environmentat the same time. That is, ach user must be able toprovide input to w hatever application or system is ac-tive, and must be provided with all relevant output.Common examplesof this situation are demonstra-tions, presentations, education, nd troubleshooting.A prototype system has been developedo study waysof solving this prob lem in the microc omp uter works ta-tion environment. The prototype allows users atwoISM Personal Compu ters o share access to th e com -puting environment through the keyboard and the dis-play screen by tightly coupling the com puters.

A comp uting power is distributed t o small sys-tems, away fr om large central sites, the ph ysicaldistance between workstations presents some newproblems and makes som e old ones more severe. Inparticular, there are man y situations in which twoor more relatively distant people, at relatively inde-pendent workstations, need to be able to interactwith the sam e com puting en vironme nt' at the ametime. Tw o exam ples may serve to give an indicationof the problem.In the first example, an independent software autho rin Portland, Oregon, wishes to de monstrate a newprogram to a business in New York that packagesand distributes software. The autho r cann ot affordthe time an d money to go there in person, but doesnot want to send the program by m ail.In the second example, an executive needs to learnto use the latest financial forecasting package from ateacher in his company's education departm ent. Theexecutive and the teacher both have the program,but the teacher is at a different site, and travel willbecostly. Since the package runs on a personalIBM SYSTEMS XXIRNAL. VOL 23. NO 3, 1984

comp uter that is only very loosely connected to themainframe computer network of the company, noway exists to provide remote teaching through thecentral computing system.These two examples represent a general type of sit-uation that the spread of computing, and of distrib-uted small-scale comp uting in particular, is m akingmore common. These situations are characterizedby the following conditions:

There is a need for more thanone person tointeract with the same com puting environm ent atthe same time.The more nearly identical the comp utingenviron-ments, as perceived by each person involved inthe interaction, the better. If, for instance, someI/O device s available to one person bu t not toanother, it may still be possible o accomplish theobjective, but it will be m ore difficult.Either the people involved are not at ocations thatare physically close,or the I/O devices involved donot lend themselves to use by more thanon eperson.

The obvious approach to solving the problem inthese situations is to have the people involved be inthe same place, interacting with the same physicaldevices. In the case of the dem onstration, the dem-onstrator and the nterested audience can take turnsat the keyboard, and all of them can see the displayscreen. With a larger audience, a closed-circuit tele-Copyright 1984by International Business Machines Corporation.Copying in printed form or private use is permitted withoutpayment of royalty provided that (1) each reproduction is donewithout alteration and (2) the Journal reference and IBM copyrightnotice are included on the first page. The title and abstract , but noother portions, of this paper may be copied or distributed royaltyfree without further permission by computer-based and otherinformation-service systems.Permission to republish any otherportion of this paper must be obtained from the Editor.

CHESS 255

System 370 Capability in a Desktop Computer

Documents

Transcript of System 370 Capability in a Desktop Computer