CA2025170A1 - Portable and dynamic distributed applications architecture - Google Patents

Abstract

ABSTRACT OF THE DISCLOSURE

A system and method is disclosed for enabling a plurality of computers and associated computer resources, some or all of which may be of heterogeneous configuration, to cooperatively process a variety of applications such that the execution is transparent to the user regardless of where the application is actually executing. This distributed applications architecture performs an information distri-bution service between multiple transaction processing systems by working with a transaction processor via communi-cation channels to other hosts within the network and a dialog manager (26) which uses a transaction processor interface (78) to communicate with the transaction processor. Additionally, the architecture employs a map service (36,40) to provide an editor to allow application programmers to create the maps (40) for the application panels, a compiler to generate the maps into linkable form, and a linkable interpreter which translates the linkable form into the screen presentation format for that platform.
Furthermore, to distribute an application, the source code for the procedures (32), views (38) and panels are moved as a block to the new system. This is possible because once the application source code is complete, all of the applica-tion logic, user interface control tables, view definitions, and other application-specific tables for one transaction definition are packaged by the present invention in a single load module on the system where the application will reside.
The load module is them compiled using the target system's compiler, link editor, and bind process. Thus, all environment-dependent variations of import/export, including network protocol, operating systems, processor types, etc., are automatically integrated with the application at load module bind time. Therefore, no source code changes are necessary.

Description

r~ S~

PORTAB~E ~ND DYN~MIC DI~TRIB~TED APPLIC~ATION~ ~RCH~T~CTnR~

BAC~GROUND OF TH~ IN7~NT~ON
Fiel~ of the Invention This invention relates generally to computPr ~o~twars architectures, and more particul~rly to a system and method enabliny a pluraliky of computer~ and aesociaked computer resources, some or all o~ which may be heteroganeous in configuration, to coop~rativDly process a variety o~
applications ~;uch that the u~er sees the same image of the application no matter where the application is actually executing.

~e3arip ion oP thle ~elate~ ~r~
In todayl6 proc~s~ing e~vironment, busines6 appli~ations may be designed and imple~ented to operat~ in either a tran~ackion mode or an interactive modo. ~ran~action moda ls normally u~;ed whsn implementing applic:ation~ wikhin an ~nvironmerlt in which many u~ero ara ¢omp~tia~g for lirnitod resourae~. InteractivQ mode i8 most effectively used when resource can be dedicated to a user. In ither mode, sharing o~ processor, data ba e, and~or terminal resources 18 normally limi~ed to a homogeneous se~ o~ processors, operating ~yste~s, and/or transac~ls3n proae sing monitors.

Applicatione; impl0mented u~ ng the transaation model, generally are structured as shown in Figure 1. Each application load module includse logic ~or initialization, da~a impor~, da~a proce~;6ing, data export, arld t2rmination.
., .
Application logic: is most frequently writterl in "C" or COBOL program languages. User int~rface (e.g., screen forrtlat) control tables are defined and packaged separately ~rom the application ' s load module~ although there is strong l TI-13766 i 1, , . . , . , . .. , . . ~ . . . . . . .

.... , . -. : . : , , .- , , -: , .. ... ;-,: .:, ,.. ;. , , .:: . : - - :

:.~ , ,. . ,, , .,, , .- . , ~. , : , .: : . : , : . , : ~ . ~

CO~ ng bekween the user in~er~ace dPfinition and the application's data processing logicO ~orking storage contain~ data elements which are in a fo~m dir~ctly usabl~
by the application program.

Looking now at Figure 1, initialization logic 12 provides for opening data sets, connecting to any data bases needed for the par~icular instanc~ o~ the application, and initialiæing worklng s~orage 10 ~o default value~. Complex applications are implemented as dialogs consistlng of sevsral transac~ion executions per unit of work. This implementation mode i~ re~rred to as l'conversational transaction3~ and requires that th st~te of the conversation be 6aved and restored ~or each transaction execution. Conversational transactions maintain the conver~ation state in working storage 10. At initialization, working storage 10 is re~reshed from a copy which wa~ 3aved at th t~e the transaction last terminated (for a given termlnal) D

Data import logic tran~orms an input data strPam 22 from a hardware-dependent repre~entation into the data elemen~s comprising working storage 10. Th~ data str~am 22 could originate from a (terminal) device or ~rom another transaction. In the case of devices, the application program loqic 12 for data ~tream 22 decompo~ition is coupled with, and r~lects, device characteri~kiGs~ In the çase of data receiv~d ~rom transactions, the appl~cation program logic 12 i~ coupled with the data reprs~entation syntax and ~emantics o~ the ~enderO

Data proces~ing logic 14 performs the computation and datia manipulation ~or the application. Information is read ~rom and wri~ten to system data base(s~ 18, da~a files, and/or other information systems. Application-dependent integxity checks are par~ormed. Queries are made of the Tl-13766 2 , .. :~. . . : .. . .. . .
, ,. , . , , , :; ~ . :

r,~ ~

in~mation systems an~ the responses placed in working storage.

Data export logic 16 trans~orms working storage 10 data elements into a hardware~dependent representation. The destination ~or the ou~put data stream 24 can eithsr be a device or a transaction. In ~he case of devices, the application program logic ~or da~a stream ~4 formatting is coupled with, and re~leck6, device characteristlc~. In the ca~e o~ data tran~mitted to transactions, the data representation syn~ax and seman~ic~ of the data ~trPam 24 must match the receiver's application logic.

Termination logic 16 includes clo~ing data ~et~ and committing any logical data ba~e transactions which occurred during this ~xecutlon insta~ce of the application. I~ this i~ a conver ational transaction, the current application state (work~ng storage) i~ saved.

Th~ interactive model provides applications with dedicated resources, including memory, daka bas~s~ files, and terminal. Implementation of conversational dlal~gs i5 ea~ler than with the transaction model 6ince the application state doe~ not have to be expllcltly ~aved/restored on every interaction with a terminal. Co~municatlons with other proce~or~ is achieved through "remote procedure call~"
(RPC). RPC~ ~re sometimes also used within the transaction model 9 or between interactive proce~r-ee and transactisns.
In any of these case6, an RPC requires that the calling ~rocadur~ (with all o~ it~ re~ources), the comm~nications re~ource, and the called procedure (with all of its resources) be dedicated during the time o~ the cal~.
Furthermore, the calling proc~dure's resources lsuch as the terminal~ can not, in general, be used by the called procedureO RPCs have the same characteristics as intQr tran~action data trans~ers, namely that the data Sl ~ r~ ~

repre~entation syntax and ~emantics of the data stream must be ~ynchronized bekween the client and ~erver ~ides of an RPC.

There are however, many ~ifficulties encountered with today's technolo~y. For example, application ~ource code is not portable. Much o~ the application logic i8 depend~nt upon a particular transaction proces~ing monitor, operating ~ystem, data base mana~emen~ system, proc ~80r type, terminal devices, and/or othex variationa in the softwar~
environment. ~ very high deyree o~ homogeneity between ~oftwaxe environmen~s i5 re~utred to minimize the co~t of porting appllcation~ ~rom one environment to anotherO
Multlple et o~ souroe code are required to support the variations in ~o~tware environment, with the attendant maintenance and function synchronization problems.

A~ a x~sult Or th~ above, programmers mu~t be trained to ge~exate ~ource code for each specific c,oPtware environm~nt.
Not only i8 thi~ a waste of training resourcee, but this amounts to high co~t~ in programmer tim~ ln generatlng ~ourca code to enabl~ an application to meet ~he pecu:Lar:ltias of each par~icular enviromlent, A~ ~ndl~ated abov~, us~r l~terfac~ control tablee ~e.g., screen formats) are p~ckaged separately from application program logic~ Thls re~ults in synchronization problem~ at execution time. In mQst ca~, a ~ynchro~lz~d update to both u~er inter~ace control table~ and application program logic can not be p~rformed in real time. In ord~r to avoid data int~grity problem~, application updates require that the application is taken o~line and all pending input for the tran~aGtion is ~lushed prior to installation.
Application logic ie, neverthel~ss, tightly coupled with specific ~evice char~cteristics, re~uiring application change~ to support new u~er int2rface technology.

"~ , ' ;. .' ''.~' ,', ' ' . ' "

'"~' ~' . ' ', ' ' . , ' ' ' .
~' ' ' ' ,' ' ' . ' ' ''' . ' ~lb ~

Conv~rsakional ~ransaction~ require ~xplicit application program logie to saYe/restore working Rtorage. The conv~rsati~n st~te is maintained with respect to (terminal) deYice, not a user. If a u~er changes terminals, he can not resume the conversation which he started at the original device. Any software modification~ to a conversational tranBactiOn which result~ in a red finition or re~tructuring of ~he elements in working ~torag~ can not be implemented in real-tlme. In ord~r to avoid datA
integrity probl~ms, application updat~s require that the application iB taken o~line and all saved working storage reinitlalized prior to installation.

Inter~tran~action com~unication~, including resource (e.g., transaction, t~rminal) sharing across distributed ~ystem6, i8 restricted to one instance o~ a single-image transaction proce6sing system, and also r~quire synchxonize~ in~alla~ion o~ communicating appllcation tran~action~i. A synchroniæed upda1e, acros multiple syetems, can no~ b~ ~or~orm~d in rea:L time. In or~er to iavold dat& int~grity problem~, application updates require khat all invol~ed tran~aGtlon~ bo tak~n of~line and all pending co~munications be ~lushed prior to installation.

Currently available techniqu~s ~or coopera~ive proces~ing r~quire d~dicated communication~ resources, dedi ated proce~se~, i~plamen~a~ion-speci~ic/complex progri~m inter~acas, and often a~y~metric logic between usQr and server. Yor these reasons, it is di~ficult to quickly implement cooperati~e proce~ing ~or small applications.
Furthermore, some of the performance/cost o~jectives as~oci~ted with a transaction model are compromised by excei~ive resource consumption associated with direct inter-application co~munication~

~ .~ . . . . . . . , : ~ - -:. ,~ . . i. , .. . . : . . : , .:

.". ~ -J ,v ~ r~ f~
Implementation of business ~pplica1:ions in interactive mode is not generally appropriate for high volum~.
applications due to the lack of ~Elexibility in the administration/control o~ computer resources, in additiorl to the inability to modify ac~ive, distributed applications in real time.

~MMARY OF T~ INVENTION

In view of the above problems associated with the related art, i~ i~ an objec~ of ~he pr~ent invantion to provide a syst~m and method of computer software architecture for enabling a plurality o~ computer~, and associated computer regources, some or all of which may be heterogenous in configura~ion, to cooperatively process applications, including applications built ~rom a single application souxce hase.

Another object of the present invention i~ to provide improvement in application programmer productivity by limlting program logic to the processing logic; speci~ically l~olating it ~rom data import and data export logic.
Because thls logic i~ built into the co~mon ex~cution code us~d by all applications, there is a significant reduction in need ~or specialized applicatlon logic ~or menus, help, and cooperati~a processing functions as well a~ message handling ~u~ctio~s. A~ a re6ul~, a proqram~er need only be trained for th~ si~gle uni~led system ex~cution and d~velopment environ~ent~. Fur~hermore, the programmer may ~uickly gen~rate applicatlons whlch can be distributed acro~ multiple heterogen00u~ aomputer ~y8tem8 without reguiring ~ourca code ch~ng~ and enabl~ ~odi~ication~ to an application to be implemented wlth one load ~odule, one documentat.ion ~et, and one data base blnd.

Yet another object o~ the present invention is to . . . , , , ~ ., , . , , . , . . .

~ 7 provide improvement in us~r productivity by ~urnishing uni~orm help a~d menu ~unctions bPtween applications, af~ording users with m~nu, help and glossary acc~ss to ~unctions from every application panel, and requiring us~rs to rememb~r fewer transaction cod~s.

A furkh~x ob~ect o~ the present invention i~ to provide lower system maintenance costs and improved system performance by enabling multiple functions to be accomplish~d in one reen~rant package, enabling reduction of system definition re~ourcas required by each application, providing re~ource sharing across multiple heterogeneous computer sy8tem8, enabling control of resource utilization, requiring manayemank of fewer transaCtiOnB and ~xtsrnal ~creens, enabliny us~rs to access applications on any heterogeneou~ system without being aware where the application is being run ~e.g., the system running the application is transpar~nt to the user), providing common applicat~on ~xecution environment f or a variety o~ platforms including main~rames, minicomputers, and workstations, a~
well a~ providing application scalabil:Lty to meet a user's pro~e6sing requirements.

'Y,at a ~urther objeck of the pre ent invention provides improved application guallty control and maintenance by proZviding co~mon applicati,on execution and development ~n~ironment for a variety of platforms, providing real~time I application upgrade~, r~ducing developmlent c~sts by enabling . d~velopment o~ appli~akion on low co,st platform for installation on di~ferent higher co t plat~orm~, accessing a~d maintaining ~pplication components in a ,synchronized fashio, enabling ~pplication~ ~o be tested as a large integrated application ~et before deployment, and simpli~ying deploym~nt o~ applications ~y reducing the number o~ load modules and system de~inltionæ required to install those load modules.

~, TI-13766 7 :,~ ' :, ', ' ': , ' ' ' '' ' . '., . ' . .' . , ,: .
''~,., ' "` ' ' . ' , ; ' ' . . ' ' ' ' . ' ' " ' ' . ' ~ ' : , ' . : ' :, , ', : . . , ' ' ~ ' ' ' ' ', ,' . . : . " : "' . ~' . ''. ,. ' ~ '' ' ' ' . ~

,J' ~ rJ ~
The~e obj ect~ are accomplished in a pre~erred e~bodiment o~ the present invention ~nown as Dis~ributed Applications Architecture ~hereinafter referr2d to as '7DAA"). The DAA
can ba installe~ on a variety o~ plat~orms including mainframe computers, minicomputers, and individual workstations. Once DAA is install~d, along with its required support su~y~tems, services and utilities, then DAA-generated applica~ion~ may be accessed from any of these platforms. The ~upport s~b~ystems may he cu~tomized from products readily available in the mar~et placeO

DAA works wi th a tran~action proce~sor via communication channels to the other host~ w~hin th~ nekwork- It al60 employs a map service. The map servic~ should provide an ed~tor to allow application progra~m~rs to create the maps ~or the application panel~, a compiler to generate map~ into a linkable form, and a linkable in~erpretor which translates the linkabl~ ~orm into the scrQen pres~ntation fo~mat ~or that platform.

Additionally, a se~n in Figur~ 2, in the preferred embodiment of the present invantion, the DAA employs a DBMS
13 (Data Base ~anagemen~ System) which use~ a standard form SAA SQL 20 to 3upport application code r)B~S unctions and to sav~ user/application pro~ile in~orma~ion. It should be noted that mor~ than one ~BM5 could b~ used ~or example, one to ~upport applic~tlon gunGtlon6 an~ on~ to save pr~file in~ormation. Furthermore while a D~MS not u~ing the ~tandard ~orm SA~ SQL could be u~ed, it should be realized that the emb~dded application DB~S code should be source compatible on the variou~ plat~orms.

Looking in mor~ detail at Figure 2, each application transa~tion consists of the In~o~mation Engineering Task tIET) 26, application program logic 3~ and working s~orage 10 .

- ' : ' ' ' ' '~ ', . ' : . .: ' .
' -' ~' ' . , .. ' : . ': ~ :,. , , , ' ' ' , ' : ' '':

r'~ r~

3~

The hardware ~pecific inpu~ data ~tream 22 con~ists of the information input to the application. In~ormation includ~d is: data, hardware type of the input device, and characteristlcs of the output e~pected.

Th~ IET 26 processes the input data stream 22 to prepare it for the applica~ion program logic 32. The s~tup de~omposes the data s~ream 22 ~y converting the characters înput to the applica~ion ~o it~ native data type for application program us~. The application proyram 32 t~
the IET 26 which data ~ts will need to be acce~sed. The IET 26 r~ceives routing information from the terminal d~vice characteristics and routing information table 30 via com~unication rollte 28 9 and 'open~' tho e data ~et~

The ~ain ~tsrage logic 10 p~rforms the co~putation and data ~anipulation ~or the application. ~pplication progra~
logic 32 pull~ in.formation from, and ~tore~ information on, data ba~es~ 18 in the ~y~tem u~ing a pre~elected ~ub~et of Structured Qu~ry ~a~guage (SQh~ commands 20 although other language~ could be e~ployed. ~hen the computation and manipulation are completed, tha IET 26 hegln~ its cl~anup.

I The IBT cleanup consi ts o~ two ~tQp3. Fir~t, composin~
I th~ data g~nerated ~rom th~ application 32 into a format set ~ by the programmer. The in~or~ation is ~ent out as the ¦ output d~ta ~tr~am 24. SQcond, 'clo~ing' data sets which . h~d be~n opened ~or use ~y th~ application.

~ All o~ th. application lo~ic, user inter~ace control ¦ table~, view de~lnitions, and other application-sp~cific ! table~ for one transaction ~eflnition are packaged in a ~ingle load module.

,` . ' ' ' . ' :' "' .' ': ' ,, " ,". ", ' ' ', '' ,'~ ', ' . ' . ' . , , ' '' ' ' . ' ~J ~ ~ ~ t,~

The DAA ~pplication load module, 5hOWn in Figure 3, include~ all the components nece~ary ~or a user to invoke a DA~ application through DAA ~rom a terminal on any other DAA
sy6tem. The components in this module control routing of information, aGcessing data base~ on di~ferent system~ if neces~ary, cleaning up data sets when the application is finished, and presenting the in~or~ation when compl te. The load module also include r~2rence3 to HE~P, INFOrmation, and GLOS~ary in~o~mation stored on the ~y6tem.

The DA~ Transaction Definition Table (TDT) 34 defines all the el~ment~ of a ~ load module 2nd i~ provided by tha D~.

The IET interface 2~ i3 a logic element al~o provided by the DAA. The IET interrace merge~ th~ in~ormation ~tored in th~ viewa 38 with the panel~ 40 da~igned by the proyrammer to form the application da~a ~tructur2.

The Terminal Mapping SyE~tem (TMS) 34 ia ano~her logic elemellt o~ ~hQ D~. ~rhe ~S 34 is prov:Lded by the DAA and taXes the daka stream input to the DA~ and convert3 i t into IBM 3270 ~ormat data ~treams.

VieWB 38 are de~3igned by the programmer to Aefine t~le type~ o~ variabls~3 used by 1:he appliG~tion. ~he vlew 38 tell~; the IET interface wha~ for~at the procedure 32 needs th~ data in . The IET interface 2 6 converts the input data stream to match that fc~rmat. After data is processed by the procedureE~ 32 al~o, IET 26 converts the in~ormation stored in the Vi~?iW5 38 to the ~ormat for the output data ~tream, or to the ~ormat 6pec:if ied ~or other proc:edure~ 3 2 . ~rhe vi~ws 38 allow data ~o pass locally b~tweQn procedures 32 on the system the user is logged onto and remotely to proc~dure~ on other DAA ~yste~s.

qq-13766 10 ~: ~ ..... . , , .......... . .. , . . - . : . , ;

., ,, . , . : . . . , :, ~ .

Panel~, or ~creen~ 40 for the application are builk from pxogramming d~finiti~n~ uaing a sçreen painter and a ~pecial compiler. Panels ~0 developed in this way are txan~errable across all sy~tems at the source code level.

Menu~ 42 are special creens used to guide the application user through ~he proc~dures ~or an application, are defined by th~ pro~rammer, and are expandable in source Once the applica~ion source code i~ complet~, all pro~rammer designed block~ ~hown in figure 3 ar~ built into one load module by ~h~ DAA software on the sy~t~m wher~ th~
application will reslde. To mov~ (or distxibute) an application, the sourGe cod~ ~or ~he proc~dure~ 32, views 38, and panel~ 40 are moved as a block to the n~w sy6tem.
Th~ load module i8 compiled u~ing the target ~y tem 1 8 compiler, link ed~tor, and bind proce~. No source code change~ are nece~ary.

No matter how complex the application, all application component~ o~ a load modu~e are automatically in synchronizakion and consequently can be installed in real-time. Applica~ion-indepen~en~ DAA logic and co~trol tabl~s are imple~ented as dyna~ically loadabl~ librarie~.
D~A upgrades are automatically reflected in applica~ion load ~odul~s, ensuring sy~chronization of DAA functions acros.
all applicatlon load ~odule~. Additionally, ~his make~ the appliaation eaeier to di~tribute, and require~ khe ~pplication user to reme~ber f~wer transactlon code~.

Applicatlon procedures contain no code relatsd to either data import or data ~xport. Application procedures are restricted to perform computation and data manipulation u~ing da~a elements defined in working storage and optionally an in~er~ace to some in~ormation system. An information ~y6tem 6upported by D~A i5 relational data base acce6e via a well defined su~e~ o~ Structured Query Language (SQ~) co~mands~ O~her information ~yskem6 could be employed by the applicatio~.

Data import/e~port ~unc~ions are completely isolated from any applica~ion procedure. All environment-dependent variations of import/export, including network prokocol, device characteristic~, ~ransaction proce~ ing monitor, operating sy~tem~, proces~or type~, etc~, are automatioally integrated with th~ application a~ load module bind tim~.
Import/export ~unctions are drivQ~ fro~ impl~mentor~de~ined views and u~er in~er~ace con~rol table~. U~er inter~ace control tables describe the characteriskic~ of the user inter~ace, and how elements o~ working 6torage map to/~rom the u~¢r inter~ace. "Import~i and "export" view~ descrlbe element~ oP workin~ storag~ which are to be communicaked bQtween tran~actions. ~Pro~ile" Yi2W~ are u~ed to de~cribe elem~nt of worklng ~korage which are t9 b~ ~ved/r~stored at initiation/terminat~on tim~ for each tran~action execution.

At axecution time, a view definition i~ u~ed to encod~
or de~ode an lnformation packet to/Prom working storage.
Each element o~ working stoxaga, which iB seleeted by ths view definltion, ie encoded i~to an identl~ier/value pair in the in~ormation packet. The ident~ier uniquely identifies, acro6~ all appli~tion VQrsiOnB of working ~torage, a particul~r element/ independe~t of the element's location or length in working e~orage. At any ~ime during the life cycle of an appllc~tion, a progra~mer may change the location and/or length of elements in working storage, rebuild a new ver~ion of the tha application load mGdule, and pro~uctionizQ the new load module. When a view is decoded from the in~ormation packet back to working stora~e~

'. ' ' ' , , ' ' ' . , , , ' ' . . ' ~ '. ' ',, . . . ". , ., . ' the element ~alue is stored in the location/length de~ined by the application at the time of ex~cution (i.e., not at the time of in~ormation packPt creation).

The~e characteri~tic of view manag~ment significantly r~duce the po ~ibility for data integrity problem~
introduced by modi~ying application load modul~ in real time. Th~ current s~ate (pro~ile) can be eucce~6fully re~tored to an application which modifi~d its working storage layout. Application load modules which communicate with each oth~r can b~ modi~i~d a~ynchronously, in real time, a~ro~ heterog~neous environments, including change~
to the impork/expor~ view and working storage layout.

To better under~tand the pre~ent invention and th~
relation~hip of i~ component part~ in the d~velopmen~
~nvironment, re~er now to Figure 5. ~lthough the component~
s~en thQrs will be dl~cu6eed in great detail later, a working under3tanding o~ their r~lation~hip with the hardwar~ in~olv~d i8 nece~sary.

A user may input data or invoke an application at terminal 58~ Terminal 58 directs such input to communl~ations proce~or 62 via com~unications line 60.
Communica~ion~ proc~660r 62 routa~ ~he inpug to central pro¢~ssing unit ~6 (CPU~ v~a hookup line 64. At this point the CPU 66 2ddres6e~ co~puter ~ mory 70 via bus 68~ Withln co~pute~ ~emory ra~ide~ the g~neral transaction de~inition tool 72 (GTD3, connected to transaction de~inition ~able 36 (~DT~. Th~ TDT cvzrhead 36 points to specific locations in me~ory 70 ~or map~ (panels) ~0, view~ 3~, and procedure logic 32. Application procedure logic in turn communicakes through disk inter~ace or data base management system 74, residing on operating sys~em 7~, to source object data se~s on disk 18 vi~ SAA SQL command~ 20.

'.' ' . ' ' ' ' ' , ~ ' ~ ' ' ' r~ ~

In the ~xecution environment o~ the pref~rxed embodimant of the pre6en~ invention, ~urning now to Figure 6, a uCPr invokes an application at ~erminal 58. Te~minal 58 directs the request along communication line 60 to communication processor 62. Processor 62 in ~urn forwards the invocation to CPU66 via hookup line 64. ~t this point the CPU 66 addreRses compu~er memory 70 via bus 68~ Within computer memory resides th~ transaction de~inition tabl~ 36 lTDT), the infor~a~ion ~ngineering tas~ 26 (IET3, and transaction proce~ing subsy~tem interface 78. TDT 36 points to 5peci~ic locations in memory 70 for maps (panel~) 40, view~
38, and procedure lo~ic 32. I~T 26 employ~ tran~action proc~ing sub~ystem in~r~ace 78, to int~rPace with out~lde ~y~tem~. In proc~3sing the application, it work~ with D~S
interface 74, which resides on operating ~ystem 76, to acc~ a data ba~e on di~k 18 via SQL commands 20. Likewide I~T ~6 maintain~ its ROLLFI~E 80 via ~Q~ commands 22 to ROLLFILæ databae~ manag2ment sy~tem 84.

Transaction and t~rminAl r~sourc~ are directly accessible ~rom only one (~ingle-imagej tr~n~action processing yste~. DAA imple~ents an in~orma~ion distribution ~exvice between ~ultiple transaction processing ~y~t~m~. Th~ distribution ~ervice provide~ for the di~tribution o~ information packets, with guaranteed delivery, a~ w~ll as th~ di~positioning of these information packets. Dl~po~itioning t~pically utilizes transaction proaes~ing sy~tem faciilitieA in order to forward the information packet to an application kransaction or (terminal) device. In~ormation packets d4itined for devices may be modified in order to conform with the device characteri~tics which ars present at time of dispositioning, thus accomo~ating dynamic changes ~o device configur~tion~.
Isolation o~ data import/export functions from application procedural logia enables appl~cations to transparently - . :, :: , . . : . .. - -.

:~ . , .~ , ,, . . : .
.: , ;, . :, . ,, ,: .:

utilize thi6 DA~ di~tribution service ~acility in order to share resources (eOg., transac~ions, terminals) acros~
di6tributed ~ys~ems in heterogeneous software environments.

More specifically, the Information Engine~ring Task (IET) is an executable D~A proaedure that receive~ control whenever an application program i~ executed and provides a nu~ber of devices to ~he application program which isslate it from the hardware and software environment in which the application runs. ~ communicate3 panels, view~, and information between the user, user profile~ application procedure and r2mote D~A applicatlon procedures. Thus the servicee it performs include panel input/output procss~ing, managing u~ar ~ocumen~ation requlrem~nts, providing menu navigation, and handling coopera~ive processing inter~aces for the application, a~ well a~ required DB~S setup, applica~ion ~ync~lronization and cleanup.

The IET uses a Tra~actio~ De~i~ition ~able (TDT, de~crib2d balow~, and compiled v~lsw ob~ects generaked automatically by Generate Transact:Lon Definition (&TD, de~crib~d b010w) from ~he Tran action Deflni~ion Flle (TDF, de~cxibed below) ~o aorrelate in~o~mat'ion to b~ comm~nlcated to the u er, u~er pro~ila, applicat.ion procedur~e and DAA
remote procedure~. Thi~ in~ormation i~ 8tor2~ in the tran6action view data area and iB th~ ma;or interface b~twe~n the application and the I T. The tranaaction view i8 inlti~lized from th~ input ~creen and pro~ile view when per~orming panel input~output proces~ing and initialization o~ the transaction vi~w ~rom the input/output/inter~ace ViQW~ and profile view6 when perfurming coop~rative proces~ing.

The isolation that the IET provides enables the application procedur~ to contain primarily application sp~cific logic. The languages tprimary ~nd DB~S) used in J~ ~ ~ 7 application procedure~; are written in languag~s which are implemented consis~ently acros~ all D~ pla~forms so as to ~n ure application portability.

Prior to having DAA, and speci~ically, the transaction driver program, IET, a programmer did not require a table of point:er~ to his maps and procPdures. Each l:ransaction would have uni~e program logic containing the nece sary decisions to explicitly call the proper proc~dures to proces~
appropria~e inpu~ from a uselr and to u~e various ecreen maps ~or output as requir d. Thi~ meant the programm~x wa~
required to pro~fide c:ode ts~ handle all the pos~ible dialog ~low~, and screen input/output, In DAA, the IET module provides the dialog flow manayem~nt and handles all the screen input/output includin h~lp documentation and glossary re~ua~t. Th~ programmer und~r D~ i~3 only required to han~le input and outpu~
variables from/to screen maps and remote procedure~.

Slnc~3 IET ~B a fixed progra~ln modulla that i~ com~on to all DAA tran~ac~ioTIs, it i~ not pos~ible for emb~ddsd loglc to call th~ appropria~e user procadur~ zmd to u~e it~ unique ~creen ma~?~. This E~roble~ requirz0 that all information U~14tl to drive th~ application screenE~ and procedur6~ be contained in a ~parat~ llnkabl~3 tab:L~a. Thit3 table must ha~rs su~fic~enk in~ormatis:n ~o allow IET to choo~ he appropriat~ E~areen maps, call appropriate procedurPI3 before and a~tQr ~creEall input~outy3u~, save and re6~0re appropriate program variables (vi~w~:~, restart a tran~action at the last known ~tat~ and provtds approprlate llnkage to re~note DAA
tra~ action procedures. ThiE; table is knowrl a~ the ~ran~action Definition Table (TDT) and i3 created by the DAA
development tool, ~i;TD, based on transaction definition in~ormation provl~ed by ~he developer, or applica~ion programmer, and qtored in the Transaction Deîinition File . " ., ' '' ' ' ~ , "' " , ' " ., ~ '''':

F~.

The TDT is a table of names, pointers, and control information required ~y ~he IET module at run time to properly commur~ica~e panels, views and information betw~en th~ u~er, link-edited procedure and remote D~A procadure~.
The TDT ia ~imply the anchor of information that allows IET
to contxol exeoution ~low. Ths TDT is constructed ~o that the developer' 5 procedure code i5 unawar~ o~ the TDT' 8 exi~tence and frees the developer from writing hi~ own code to correlate inpuk/output applica~ion pan~la, help panels, glos~ary panel~, as well as saving and restoring pertinent program variable~ (view~ across multiple executions of a tran~action for any given userO

The ~DT consi~t~ of a variety o~ information ~uch as application identlfication, vers1on number, last transactio~
build date, help documentation ~ile name, nu~ber of docu~entation lanugag~s supporked, a polnter to fir~t documentatlon languag~ table entry, and ~ SQL support procedure entry point addre~s fox such funct~ons as Conn~ct, Co~mit, and Rels~iase. Map and procedurs~ tables as well a6 menu and documen~ation languagt3 table en~ries also compri6e part s~ the TDT.

Eac~ o~ the map tablee ~or applis~ation, meinu~, help, in~o~mation and glo~a~y panel~ contain~3 such in~rma~ion as pan~l namQ, TMS ~creQn map pointer, intput/output procedure pointer~, nu~ber of a ~oaia~d menu entrie~, and pointer to ~ir~t 2~00iatad ~nu entry. ~ch o~ thQ procaduro table~
contai~ such data a~ procedure name, procedure entry-point addres~, intput/output/profile vi~w table pointer~, and SQL
DB u~e flag. Each of the menu table entriee contains such informatiQn as menu select code, panel entry pointer, panel procedure entry~poin~ address, and displayable m~nu de~cription string. Each of the documentation languag~

~able entrie~ co~ains uch 8peCi~ics a~ documentation languag~ name and documentation ~ile name.

The Tran~action De~initlon ~ile (TDF~ i~ a file o~
record3 used by GTD a~ the "blu~printl' ~or conatructing a DAA transaction~ ~his TDF i~ an integral part of GTD
because it conkains all th~ in~ormation nece sary to compile and link all the correct components of a given D~A
transaction. The programm~r simply use GTD's menus and screens to add and dele~e the appropriate components and GTD
files this infor~ation into the TDF.

Therefore, ~he content of the TDF is created and maintainPd by the developer using the GTD tool. The TDF is us~d by GTD to ag~ist ~he programmer in the edit of his procedure cod~, panel maps, ~nd menu~. Once these component~ have be~n edited, the TDF i~ used by GTD to comp:Ll~ and create variou~ object modules that are link-~dited along with the IET to produce a transaction load module .

The TDF consists of a variety of typeE; of recs~rds such a~ header, pan~l, m~nu, and procedureO The header typically contains a list o~ source, object, load and map librarie~
along with pertinent name~, ~uch a~ application and tran6action-view name~. Each panel i~3 ~ record containing panel name and inputjoutput processing procedure names.
Each menu screen i6 a record contalning menu name, menu panel name, input/output processing procedure names and displayable description ~ring. Each procedure de~inition i~ a record c~ntaining proc~dure n ~e, lnput/output/proile view ~iles name~, and language type.

~ he Generate ~ransaction De~inition (GTD) never requlres a programmer to build file~ containing instruction~ on compiling and linking the correct parts, because tha GTD

: ' . ' ' ~, ' ' ~ , ' ~' ' ' . ' ' " " ,' " ' r~ ,~

builds and main~ains the T~F. Fur~hermore, the GTD provides for development o~ applica~ions tha~ execute under control o~ the IET.

More speci~ically, GT~ is a menu driven user interface that is intended to be uniform acro~s all DAA platforms providing the application developer with structured application development such as dsfinition9 craation/2dit, constructlon, applica~lon tran~er fRature~ and various utilitie~ nece~6ary ~or d~velopment in an environment with multiple heterogeneous dev~lopment and ex~cution hosts.
Application programmQrs de~ine applicatio~ componen~ and their interrelationships by u~lng definit~on ~cr~en~ within GTD. They include procedure code, panel ~ape, menus, progxam data view~ and documentation. This in~ormation is stored in the ~DF and la~er used by ~TD when accesslng a~y o~ the ~omponents ~or modification or ~or DA~ application con~truction. rhe developer us~ GTD to edit the appl:Lcation eource compon~nt~ nd to construct the exeicutable applicatlon load modu1e.

During construction, GTD use~ the TDF and the application deSined program data Vil3W~ to creat~ ob~ect modul~s wh~ch are u~d by IET in order to per~rm it~
servtce~ ~or the application progra~m. Wheneveir a GTD
application i~ constructed, GTD ensur~s that all objects creiated are up to date with the ~ource ~iles so that the application will alway~ be ~ynchronized.

GTD provide~ for development of appl~cations that execute under control of t~e IET ~hrough the user interfaca, and performs background func~ions at each stage of thsi application development. These ~tages can be defined as de~inition, comp4sition, construction and deployment.
During definition ~TD require~ the user to define all of the componein~ of khe applica~ionl their phy6ical storage i,: -. ': .:: ' ', ' : ,.: -. .::, , . . : . . ...... . ..
':': .'. ..:, ~. .: .. ' ' ' ,,.-," ,, ','., ;,:

~ b, !
location, their in~errela~ionships, and any additional aktributes or in~orma~ion. Th~ ~e~inition information is stored in the TDF. During the compositlon phase GTD
provides the applica~ion developer with menu access to each of the components lis~ed in khe TDF and pxovides generators and sditors fsr each o~ thsse components.

During construction, GT~ retrieves the information in the TDF and generates the TDT and view module whi~h are used by the IET module at run time. GTD th~n compile~ each o~
the components lis~ed in the TDF using the appropriate compiler for each type o~ componenk in a prede~ined order by type. The~e ~ype include the TDT and view module~ GTD
generates, menus and panel maps and procedure code. GTD
provid~s the application developer with construction alternatives. Componen~s ~ay be con tructed conditionally or unconditionally ba~ed on date and ~ime informat:Lon whi h is updated each ti.m~ a s~urce component iB modified during the composition phase or when an output object i created or replaced during construction. When pe,r~orming conditional conBtruction ~TD check~ the dat~ and time on each source component and each output object. When the ~ource component ha~ a later date than the output objec~, ~TD reconstructs khe output object. Conditional and unconditional constructlon method approache~ ~nsure the ~ynchroniz~tion and con~i~tency Or the load module when con~tru~tion i~
per~ormed on all components in th TDF. To complete construction GTD binds all o~ the load modula components together into a load module using a linkage edi~or and installs the load module in the location referred to by the TDF.

During the deployment phase GTD provide6 the capability to trans~er all, or elected, application components from one machin~ to another. The application developer identifies the targe~ machine, th physical location on the ~,~: . . , . . . . , ,. . :. .... : , :: , : .~ . . , .: ,:
.:.. , . . . ,. .: . . : .:
i.: : . , , - , . , :. .

,1 q ~7 ~
target machine wh~re ~he TDF ~le could ~e loca~ed, and the compon~nt~ to ~ran~Per. This transi-~r proce~3 acce~ses the components listed in the TDF and trans~ers them to an appropriate loca~ion on the target mashine extrapolatad ~rom the target machine TDF file location. The transfPr is accomplished using an av~ilable file transfer communlcation6 program between the source and target machine~. A~ part of the trans~er proce~6 all ~extual data i~ translatPd to th target machine foxmat and the physical locations and name~
in the TDF are changed to conform to the target machine conventions.

The~e and other fea~ures and advantages of th~ invention will b~ apparen~ to ~ho~e skilled in the art ~rom th~
following detailed descriptiQn of a preferrsd embodiment, taken together with the accompanying drawings, in which:

D~8CRIPTI~N O~_TH~ DRAWING~
FIG. 1 i~ a block diagram depicting current program applicatlon development without the present invention;
FIG. 2 is a block diagram depicting program application dev~lopment according to an e~bodiment of the present invention;
FIG. 3 is a block diagram of a samplQ load modul~
according to the pr~ent invention;
FIG. 4 iB a graphic 1 repr6~entation of internal con~lguration of a transaction definition table (TDT), accordtng to the present inventlon;
FIG. 5 i6 a block diagram demonstrating ~he development environment according to the present invention;
FIG. 6 ii a block diagram depicting the execution en~ironment according to the present invention;
FIG. 7 iEi a gxaphical representation o~ application portability due to the implementation of the depicting cooperative processing;
FIG. 8 is a block diagram of a heterogeneou~ environment -: : : . , ; ; : ~ . : .

showing distribu~ed resource in~ercommunication~ support~d by the present invention;
FIG~ 9 is a block diagram o~ transaction consepts according ~o the pre~erred embodi.ment of the pr~se~t invention:
FIG. 10 is ~ block diagram depicting D~A procedur~
execution and profile view according to the present invention;
FI~. 11 is a block diagram depicting an user inter~ace ~cenario a~cording to ~he present invention;
FIG. 12 is a block diagram showing possible navigatio~
rout~ ~rom session to s2ssion, ~or a typical dialog according to the present invention;
FIG. 13 iB a block diagram showing pos ible navigation routes from transaction to ~ransac~ion, ~or a typical dialog according to the present in~entlon;
FIG. 14 is a block diagram showing possibl~ navigation rout~ ~rom panel tc panal, for a typical dialog according to the present inv~ntion;
FIG, 15 i6 a block diagram depicking an example of DAA
dialog flow, according to the prefe~rred embodiment of the present invention, combining consic~tent user inter~ace de~inltion3 with progra~mable dlalog ~.low commands;
FIG. 16 i~ a block diagram depi.cting remote procedure execut~on/data flow, accordin~ ~o ~he pre ent invention;
FIG. 17 i~ ~ block diagram showing the inter~
relatlonship batwe~n v~riou~ co~pon~nts used to implement di~tributed r~sourc~ control according to the pr ~erred e~bodiment of the pre~nt invention;
FIG. 18 is a block diagram demonstrating the logical ~low o~ control and da~ asRocated with the ~INK/RETURN
impl~m~ntation between transactlon& according to the pr~f~rred embodlment o~ the present invention;
FIGo 19 i~ a block diagram depicting the logical flow of control and data a~sociated with data interchange between terminals and transactions according to the preferred ~ :: .- .. . . :;. :.. ,; , ~ ., .,, :.. : . ;: . . . :

'` ; ! ;, ' ~ rJ~ ~

embodiment of the present invention;
FIGs. 20a-~ ar~ a flowchart detailing the functions per~ormed by the (:TD a~ the highest menu level, according to the preferred embodiment o~ the present im7ention:
FIG~ 21 is a flowchart depicting the procedure display procedure according to the pre~erred embodiment of` th~
pre~ent invention:
FIG~. 22a-b are a flowchart depicting the FE procedure which checks for an user inputted end indicator for GTD
panel function~ according to th~ preferred embodiment of the presPnt invention;
FIG6. 23a~c are a flowchart depicting the edit transaction parameters (ET) pros:edure according to th preferred embodim~rlt of ~he preserl~ inven~ion;
E'I&s~ 2~a-r are a flowchart d~picting the GTD gst TDF
(GTDT) procedure according ~o the preferred ~mbodiment of the pre~ent inventiorl;
FIGsO 25a-b are a flowchart depicting the ~TD read TDF
record (TDTGET) procedure according to the preferred embodlment of the present inYention:
FIGs. 26a-e are a flowchart depicting the generate tran~action view (GrVW) procedure ~ccs~rding to thQ preferred embodiment o~ the pre~ent invention;
FIG. 27 iB a flowchart d~picting the edit tran3action paramat~r~ (ETP) procedur~ accord.ing tu the preferr~d em~odim~nt ef the present inventlon;
~ IG~. 28a-~ are a flowchart deplcting the edit p~nel li~t (EP) proGedure according to the preferrad embodiment of the pr~ient i~vention;
F~G. 29 i~ a ~lowchart depicting the edit panel (EPE) pxoc~dure according to the preferred embodiment of the present invention;
FIGs. 3~a-~ are a ~lowchart depicting the edit procedure li~t (EC) procedure according to the prefexred embodiment o~
th~ pre~ent invention: -FIGo 31 is a flowchart depicting the add procedure u~er : ~ ' ' , . , ' ', :: ." ' , , . ' ' ' ' ' ' :' ' ~: ' ~ " .' . ' , ', ' " ', ' ' : ,, ;

~ g~

interface (ECA~ proc~dure according ~o the preferred embsdiment o~ th~ present invention;
FIGs. 32a-b are a ~lowchart depicting the chanye procedure entry (ECC) procedure according to the preferred embodiment of the present invention:
FIG. 33 is a flowchart depicting the edit filename (DO~EDIT) procedure according to the pr~ferred embodiment of the present inYention;
FIG~. 34a-b are a flowchart dapicting the edit procedur~
(ECE~ procedure according to th~ preferred embodlm nt of the present invention;
FIG6. 35a-c are a flowchart d~picting the generAte CQBOL
program (GCO~PROG) procedure according to the preferred e~bodiment o~ the pr~Fent inventlon:
FIGs~ 36a-c ar~ a flowGhart depicting the generate C
program (GCPROG7 procedure according to the preferre~
embodiment o~ th~ pre~n~ inven~ion:
FIGs. 37a-d aro a flowchart d~picting the adit menu 11st ~E~) proc~dure according to the preferred embodim~nt of the present invention;
FI&. 38 i~ a flowchart depicting the prepare menu display (EM5) procedure accordlng to the preferred e~bodiment of the present invention;
FIG. 39 is a ~lowahart depicting the edi~ menu li~t (EMX) procedurQ according to the pre~err~d e~bodlment of the present invention:
FIGs. 40a-~ are a flowchart depicting the sdit language li~t (EL) proc~dure according to the pre~erred embodiment of the present invention;
FIG. 41 [omitted3;
FI&s. 42a-d are a flowchart depicting the put TDF (PTDT) procadur~ accord~ng to the pre~exr~d ~mbodiment o~ th~
preBent inv~ntion;
FIGs~ 43a-b are a flowchart depicting the write TDF
record ~TDTPUT) procedure ac¢ording to th~ pre~erred embodiment o~ the present invention;

... . . .:.,, . . . ~ . : - .. : : , ,. ~- , ,: ., . . : .:

. . . , ....... . . . .,, . . . , . . , .. ~ . ~ . .

:. . ~.~ . : , ..
;- .: : : :, ~ . .. . .. , . . .: , ,.:

: : . , ; . . . . .. ... .

FIGs. 4~-b are a ~lowchart depicting the generate tran~action/view, COBOL/C program (GC) procedure according to the preferred embodiment of the present invention;
FIG. ~5 is a ~lowchart depicting the generate COB0 procedure u er interface (GCOBP) procedure according to the preferred ~bodiment of the present invention, FIG, 4~ is a flowchart depicting the g~nerate C
procedure user inter~ace (GCP) procedure according to the preferred embodiment of the present inYention:
FIGs. 47a-f are a flowchart depicting th~ generake map~ user interface (GM) procedure according to the prePerred embodiment of the pre~ent lnvention;
FIGs. ~8a-d are a flowch~rt d~picting the generate menu panels (GPM) procedur~ accor~ing to the preferred e~bodiment of the present invention;
FIG. ~9 i~ a flowchart depicting the generate skeleton panel u~er inkerPace (GSP) procedure according to the pre~erred embodiment of the pre~ent invantion;
FIG~. 50a-j are a flowchart depicting the compile tran~action defini~ion/views/panel~/procedure~ (CTREQ~
proGedure according ko the preferred embodiment of the pre~ent invention;
FI~. 51a-rr are a flowchart depicting the compil~
kransartion def inition ( CT) procedure according to the pre~errod embodim&nt of th~ preeant invention:
FIG~i. 52a-b are a ~lowchart d~pictlng ths add vlew na~e to tabl~ (TV~ procedure according to th~ pref~rr~d embodim~n~ o~ tha present invention;
FIG. 53 ~ a flowchart depicting the write buf~ier to file (WTS) pro~dur~ accordlng to the pre~erred ~mbodiment of the pr~ent invention;
FIGs. 54a~mm ar~ a flowchart depicting the compile ~iew (CV~ proced~re according to th~ preferr~d embod~ment o~ the pxesent invention;
FIG. 55 is a flowchart depicting the compile panels (CP) procedure according to the preferrQd embodiment of the :',, '' ' '' ~ ,'' ""'' '", . ':,; ' ' '.' . ' .'' ': :
., '- ' ' ' . , ' ' , ' ' ' ~ ~S ~ r~ ~

pre~ent invention;
FIGs. 56a-c are a flowchart depic~ing the lower level compil~ panels (CP0) procedure according to the preferrsd e~bodiment o~ the presenk invention:
FIG~ 57a-d are a flowchart depicting th~ compile (CC~
procedure according to the preerred embodiment of the pre~ent invention;
FIGs. 58a-j are a flowchart depicting the compile C
progr~m ~CC0) procedure according to the pre~err~d embodiment of ths pressnt invention;
FIG~. 59a-c are a flowchart depicting the ~ompile GOBOL
program (CCOB0) procedure according to the pre~erred embodiment of the present invention;
FIGs. 60a-b are a flowchart depicting the bind transaction (BT) procedure according to the preferred e~bodime~t o~ the present invention;
FIG. 61 i~ a flowchart depicting the file transfer pan~l~/proced~res/view~/documentation (FT) procedure according to the pre~erred embodiment of the pre~ent invention; and FIGs. 62a-bb ara a ~lowchart deplctlng the information engineering ta6k aspect o~ th~ pre~rred embodiment of the present invention.

TI~13766 26 ~ r, ~

D~AI~D DE~CRIP~XON 0~ A PR~RR~D ~MBODI~B~ -In the evolving world of distributed computing ~ystem~, it is nece sary tha~ the applications be upported with a strategy consi~ten~ with the enviro~ment in which the applications oparate. These distributed networks are compo~ed o~ sy~tem~ (compuker~) conne~ted wikh communications facilities of various type~ including wide area n tworks, local area networka, and bu architectures.
These ~ystema ~upport local data ba~e~ and di tributed data ba~e~ that allow synchronized maintenance of in~ormation between multipl2 computer sy~tem~.

In mo~t general ca~e, ~he present inv~ntlon provides the cap~bility to develop interrelated applications and put theae applications into ~ervice on multiple heterogeneous procee~or~ colmected with heterogeneou~ communication~
facilities ut:Llizing heterogeneoua data bases~ Currently the COBOL and C langua~a~ are being ~upport d. It should be under~tood how~ver, that other lan~uages could be used in applications involving the pre~ent inv~ntion. Furthermore, while par~icularly DBMS i~ the prima:ry d a~a base management sy~tem e~ploy~d in imple~en~ing ~ha presen~ invention, other data base management sy~em~ ~ueh as DL/l could al~o be used~ Lastly, lt is contemplated that the present invention $hould no~ be limited ~o the TSO, Unix and OS/~ environment plat~orm~ curr~ntly supporting the present in~ ntion.

The di~tln~ul~hing ~ature~ o~ a pre~erred embodi~ent o~
tha present lnv~ntion includ~ applicatlon portability, con~iGt~nt u ar interfa~, dynamic application change~, and cooperative proce~ing between het~rogeneous computer ar~hitectures. Application portablility means that an application written in one of the ~upported program~ing languag~s (a~g., .OBOL or "C"), along with all related copy ;",' " ~ ' ' , '., ' ' `' ' ` ~'; , ''.; ' . .` ' ~

~ t''~
~or include) files, user interfa~-e panel de~initions, documenta~lon, transac~ion defini~ion tables, views, etc., can ~e move~ and ins~alled, without ~ource-level modific~tion, on any supported targ~t platform.

"Dynamic application change" enables most application changes (including procedural, data base, or panel definition changes) to be made in real-tim~, without disruption of service or los~ of data integrity. End users p~rceive ins~alla~ion of application changes as subs~cond varianc~ in respon~e tim2, occuring only while ~he change i~ being installed. Indlvidual transactions of a distributed coopexa~ive proce~æing application are updated asynchronously, withou~ distupting continuity or integrity of data comm~mication~. Consistent user int~rface mean~
that a user, ~rsm any terminal in the network, ha~
transparent acces~ to ~11 transaction~ in the n~twork (~ubj2ct to security con~traints), that all tran~action~
have a con lsten~ form of ~lalog navigatlon~ and that the panel layou~, u6er lnt~ractlon wi~h panel element~, ~tc., i~
con~istent across all tr~n~action~ for any particular u~ex's ~erminal.

The cooperative proces~ing featllre of DA~ provides ~or da~a exchange b~tween transaction~ re~siding on h terogeneou~
pl~tform~, transparent to the application.

To m~et th~ ne~d for continuou~ operation~ and a well as implied dyna~ic change for ~pplications, ~ha preferred e~bodi~ent of the present in~entio~ ~odi~ies an application (including data ba~e ~nd panel pres~ntation) dynamically with, in most ca~es, only ~ubsecond interruption to service while ~he change is being implemented. Thi~ maint2nance capability i~ se~ment~d so that mos~ changes for an application can b~ modified in one system (computer) without re~uiring the change to be synchronized throughout the ,; : . .. . . . . ..
;~ : . . , . : . :

~3 S~ ' b~
istributed processirlg network. Certairlly some applications, due to distribu~ed all~ between ~y~tem~, will requir~
~ynchroniza~iorl of maintenallce on multiple sys tem~ :Eor certain type~ o:e application change~. However, the praferred embodiment of the present irlvention allow3 dynamic async:hronous change throughout a network.

The Distributed Applicakion Architecture (DA~) environment according to a pre~erred ~mbodiment o~ the present invs~ntion is comprised of a set of inter-connecked sy~t2ms, a~3 ~3hown in Figure 7, discus~3ed b210w each o~ which i~ uni~uely named and as3dre~;sahle by other ~ystems within the network . 5y6tem8 participate in the 0~ environment }: y allawing applicatiorls to use kheir resourc:e~ (2.g., termlrlals, trallsac~ions). Each ~ystem i~ a homogen~ous application processing environment which supports or simulate~ her a single~processor transaction proc~ssing syBtem or a multi-proc~sor aingle-imaye transaction pro~es~ g sys~.em (e-g- ~ IMS) -To illustrate this a~pect coopeEative proc2ssing betw~n heterogenou~ aystem~, r ~urn ~o Figure 7. Two intsrconn~ated ~y6tem~ are depict~d as an example only as more ~ys~em~ can ~re~uently be involved in any ~ransaction.
I nput invoking a transaction i~ received at logiral termin 1 130 and ~orward d to the D~A enviro~ment 132. Logical terminal 130 could be an I~ 3270 devic~, an int~lligent works~a~on win~ow~ a local t~rminal or a non-D~A process.
~he DAA ~nviron~nt 132 i~ a homogeneous application pxoce~ing ~nvironm~nt ~e.g~, a transaction processing ~ystem). DAA snvixonment 132 in~okes the required transaction. ~n application may r~quire a transaction 134 that only r~u~re~ ln~ormation ~ro~ loc~l databa~e 136. or, a tran~ac~ion 138 may r~qulre informa~ion fro~ both local database 136 and ~is~ribu~ed data~a~e 140. ~t ~h~ same time, terminal 1~0 may address DA~ environment 148 to invoke .. ~ , . . . . . .. . . ... .. .

'.,o ~ J
_ran~action 14~ which require~ inormation from local databa~e 14~ and di6tributed database 1400 It i~ po~sible with the present invention that transaction 144 (or 134, 138, 146~ could usa local da~aba~e 142, call another transaction (say 134, 138 or l~Ç) to re~ue~t information from local databa~ 136, and return the in~ormation to the DAA ~nvironment 148 to be properly formatted and return to terminal 150.

Looking now at Figure 8, a mor4 clear example of this cooperative processing across he~erogenou~ platforms is shown. ~ sume a data inpu~ strea~ 92 is received from a UNIX compu~er 86. This data ~ream 92 invoke~ application 94 to process procedure 96. Procedura 96 obtains informat1on from DBM5 100 via S~L reque~t~ 9~. As pro~edure 96 is proce~sin~, information is needed from DBMS which in turn need~ information ~rom DBMS 124 to ~omplete it~
proce~i~iing~ With khe pre~ent inventlon, thi~ inform~tion m~y now be obtained, whil~ remaining tran~parent to the user on th~ UNIX86.

To accomplish this, procedur~ 96 i~ re~urned to application 94 in the forffl o~ an output view ~not ~hown) r~questing a LINK ko, for example, I M Main~rame 88.
Application 94 ~usp~nd~ procedure 96 and ~itores relevant data ~rom proc~dure 96 in a pro~ile view (not hown) whlch is in turn ~tored i~ ROLLFILE lS)2. Then applicatlon 94 make~ a LINK regueYt via commun~Lcat~on line 104 to th~
main~rame 83. The ~ainfra~e 88 grant~ the request and directs the dat~ ~tream coming acros~i line 104 to application 10~. ~pplication 106 determines this data stream i~ looking ~or infor~ation ~rom DBMS 112.
Application 106 forward the data str~am to procedure 108 in th~ form of an input view (not shown). Procedure 10~
execu~e~ on the data ~itream, requesting information from DBM5 112 via SQL r~quest 110. While execu~ingl procedure TI-13766 30 :-~. .. ; .... ,. ..... . :.,., .,. ,,.. ,. : -,. ,:. : : " . :: . ;

'`,, . ,. ' . . ' '' ' ' ' . : ~ , ' .., , . , . ' ' , . ' ~ : . . . '~ , ' : -, .; :' ' ' ' : ' ' `' ' ''':: ' . : .' : ' . ' :: " ' , ,' "; ' , . ' ' ' y 3 , ~: .

108 determines it need~ some info~atlon ~rom DBMS 124 to complete its exeGu~ion~ Procedure 108 i~ returned to application 106 in the form of an output viPw (not shown), while rDlevant data i~ ~tored in a pro~ile vlew (not shown) in ROLLFIT~ 114. Application 106 then requests a ~INK with OS/2 works~a~ion 90 which is grantedD Appli~ation 118 accepts the incoming data ~tream and forwards it to procadure 120 in the form o~ an input YieW (not shown).
Proced~re 1~0 executes, obtaining informatlon from DBMS 124 via SQL reque~t 122. After completing execution, procedure 120 return~ to application 118 in the ~orm o~ an output ~iew (no~ shown)~ Application 118 makes ~ copy of this tran~action and places it in a profile view stored in ROLLFILE 126. Application 118 then makes a RETURN reque~t to mainframe 88. Upon the r~turn of data strea~ ~ia communication lin~ 116, application obtain~ the pro~ile view stored in ROLLFILE 114 and re~tarts procedure 103.
ProcQdure 108 complete~ ite execution, requesting additional in~ormation needed ~rom DB~S 112, if any, and returns to applicatlon 106. Application 106 make~ a record of the completed transaction and store~ it in a profile view (not ~hown) stored in RO~LFILE 114. Application 106 then mak2~ a RETURN reque~t to UNIX 8~ the data strea~ is returned ~ia communica~ion line 10~, appl.ication 94 o~tains the ~tored pro~ile view on thi~ transaction ~xo~ ROLLFILE 102 and re8t~rt8 procedure 96. Procedure 96 co~plete~ its execution, re~ua~t~ng addi~ional in~oxmation needed ~xom DBMS 100, if any, and returns to application 94.
Applica~ion 94 make~ a record of th~ comple~ed tran~action in th~ form of a profile view (not show~) and stores it in ROLLFILE 102. Application 94 then ~ormats the outgoing data ~tream 92 for the appropriate te~minal and sends it to the u~er.

DAA provide~ the servic~s reguired to share transaction and t~rm~nal re~ources across heteroge~eous ~ystems.

, . . ,. - .. : : : ~

.. .

:. , :, .
,:: ' , `:, . " ' . : . '' .

P~ , E~

2 ~
,ystem as contemplated by the p:resent inv~ntion i5 an applicatlon proces~ing environmen~ within a network, such a~
an IMS, CICS, UNIX~ OS2, or VMS processing environment, among others. Each sys~em wi~hin th~e DA~ environment has a name to uniquely identi~y that system, and the run kim~
directory at each sy tem maintains su~fi~ient information to support ~he routing of resource requests to the appropriate proc~ing ~y6tem within ~h~ DA~ network. Th~ feature o~ D~A
which supports routing of resource reque~ts i8 known as "Di~tributed ~esource Control"~

Theae sy~tems support distributed applications by allowing s~gmen~s o~ the~e applications to proca6s on any of the netwoxk-connected sy~tems. Th~e appllications are serYiced by a collection of named transactions (~yst~m-uniqu~ name~ that may be referenced by the syst~ms wlthin the network and the user~ of the n~twork. The6e tr~nsaction~ may accee~ data ba~se khat ar~ Xno~l to various portiona of the network and may be addres~ed to data bases on the local system or to data bases that are distributed on a ~ek of remote systems in the distributed data base enviro~ment.

ThQ us~r~ of the distributed e~pplication architecture disclo~d ~ the pr~snt invent~on are named (network unique na~e) work~tation op~r~tors, or pro~esse~ or machi~es that present them~lve~ s "usersl' to the network. A user within the pref~rred embodiment of th pre~ent application typically acc~sses an appllcation provided in the ~AA
network ~hrough a works~ation terminal. ~he user may invok~
variou~ fun~tions o~ ~he ne~work by entering data into the t~rminal by voice~ bar~od~, keyboard, mouse, data ~tream from a process, or other input device. Output is presented to users of the network via a terminal display; it is prPsented as a data stream to a process "user" within the ~ , E~
2 fs ,~

network.

A usar sign~ on to one of the system~ within the DAA
network using an Usex-ID (network uniqu~ name) and an identifying pa~word. This user idsnti~ication is employed within the D~A network ~o identify activity ~or ~ecurity and accounting purpose~, as well as ~or profile managemsnt to m~intain the status o~ prDcessing activity ~or th~ u er.

A given user may have multipls applications activ~- on multiple sy~tema ~t any one point in tims. Thi~ may bs viewed as the ~lectronic work desk for a user at a given system. The u ar may suepend processing of a giv~
application, either by signing off the network or by switching to an alternative application within his port~olio. At the suspension of execution o~ each transaction the control program will retain, within the prof~le data base (hereina~ter referred to as khe ROL~FILE) ~or that u~er on that syetem, th~ collection of data item~
(Pro~ile View, described ~urther bel.ow) that represent th~
status o~ that suspended application.

Similarly, more than on~ user may have multiple applications active o~ multiple system6 at any one point in tlme~ The xesults o~ each panel of an application is ~tored a~ it is completed in a profile view, which pro~ile view is uni~uely identifled by applicakion name and u~er identi~ication on a sy~tem. Although multiple users may be at di~ferent 5tage6 within a particular application, becausQ
of the pr~sen~ invention, each user is abl~ to restart his partiGular application at the ~tage la~t completPd by that particualr usar, regardless o~ the system the user is logged onto and regardless of what system the application reside~.

The architecture o~ the pre~erred e~bodiment o~ the pre~ent invention provides ~or a 'Di6play ActiYe' : - , ; : ,, . : . : . ~ . . , : .

r e~
r~ ~3 tran~action that allows ~he user to display the applicatlons that are acti~e for that particular user on the designated system~ Utilizing the 'Display Active' application display, the user may scroll thru the systems within the nekwork by striking ~he appropriate function key. ~rom this 'Display Active' application panel, the user may al80 restart a suspended applica~ion, delete an application from th~
pro~ile data base or may route the IDisplay Active' transaction to a designated new sy~tem.

According to the preferred em~odiment of the present invention~ applica~ione can run in any oP ~everal 6yBtem~
and the ussr may de~ire to int~rfac0 wlth application~
involvin~ multiple panels. Ther~ore, it i~ imperative that certaln attribute~ be displayed on the u~er int~rface panel to identi~y critical para~eter~ a~ociated with the particular u~c~r interaction, such a~: the u~er r~psn~ible ~or initiating the transaction, the ayste~ on which the curent application ie running, the application (tran action) that 1~ currently active ~or thi~ dl~play, ths pan~l with~n that appl~cakion that i8 curently being di~played, date and time o~ thi~ interaction, error zmd information ~es~age~ :
related to the interaction and standard promptlng i~ormatlon that reflect~ actions 1:he user may take ~rom this parti~ular panel~ The~e standard panel attr$butes are detailed below for example purposes only.

FUNCTION INTERNAL NAME ROW COL LENGTH

Txan~actio~ Name IEFl-TRAN 1 1 8 Pa~el Name I~Fl-PANEL 1 l0 8 Panel Title N~/Optional l l9 30 S~ste~ Name IEFl-SYSTEM l 58 Date/Time IEFl CURDT 1 62 18 U~er ID IEFl~USER 2 72 8 Me~ge ID . IEFl-MSGID 23 l 6 TI-l3766 34 r^~

Message Text IEFl-MSGTX 23 8 25 Func1:ion Key Prompts NA 24 1 <79 The format of the Function Key Prompts is 'Fnn-prompt' wher~
"nnl' i a on~ or two digit number idenkifying th~ function key nu~ber, and "promp~'l is v~riable length indicator of the associakion d function.

When UB~ ng ~L/l or other data basas, it is d~sirabl~, or eften even n8c~88ary, to have a collection of functions and sub-furction~ packaged as TR~NA and whlle another 5et 0 ~unctions ar~ packaged as TR~NB to minimize th~ number o~
data base~ a~ociated with a given tran~action. There~ore, according to ~he preferred e~bodiment of the present lnvention multiple function~ are packaged in e~ch transaction module. Packaging multiple functions within a ~ingle tran~action code (hereinafter re~err~d to a~ a '~trancod~'~) improve~ u~er frlendllness. Furth~rmore/ it also ~inimizes ~he num~ar o~ o~ects ~ha~ must be managed when in~talling an application in a naw sy~tem or when re deployins a new release of an application~ The size of any r~sulting transac~ion module i8 a de~ign considsratlon and must ~alance ~echnical and performance con~lderations with user fri~ndlines~ and ease o~ maint0nanc~.

A termlnal as conte~pla~ed by the present lnventio~ is a pre~ntation ~acillty, such a a video terminal screen, and an input meGhanism, norm~lly a ~eyboard. However, as noted previously, this input could he a program, voice, barcode, mouse, or other input as w~ll ae a ~eyboar~. Similarly, th~
display could be a pxogra~ a~ well as ~he more con~entional terminal dl~play. Each logical terminal ha~ a name that is unique within the DAA network.

The terminal is the primary interactive input/output ~acility for DAA applications according to the preferred , . , i, ~ , .. ~; . ............ .. . ~ ... - . . . , . ........ . - -.. , . ....................... i : ...... .; : . ~ " - . ..... ... .

, ~ . a~
rl ~

embodiment of ~he pre~ent invention. once the input has been prepared ~o the us~r~s ~atis~action, he may pr, BS ENTER
(or an equivalent) to invoke the transaction. This transaction in~ut ~tream will be passed to the appropriate system in the network. Once arriving at thQ appropriate sy~tem, it will be proc~s~ed according to the transaction code. Once the transastion has been invoked, the application or the Information Engineering Task (IET) runtime controller, will be responsible ~or int rpreting the input ~tream and in turn invoking the appropriate procedure.

Output genera~d by D~A tran~action~ wlll be pr~sented to the logical terminal, ~ormatt~d accordin~ to the interface and device characteristics associated with the termi~al (e~g., any neces~ary control s~quence~ associated with di~play devices will be included in the the data stream). ~he pri~ary hu~an interface to the D~A environment i~ through t~r~inal6 that present panel~ o~ information ~ro~
thQ application~ via transactions executing in th~ variou~
~y~tem~. Often, the terminal i~ a 24 x 80 vid~o screen with keyboard. However, a ~Iterminal~ could al~o bh a pro~ram (e.g., an interactive program such a~ a spread sheet package). Each logical ter~inal is lmiquely defined within each sy~tem.

An application as contemplated by th~ pr~sent invention i~ a coll~ction o~ transactions that perform a set of functions on behalf of the application. Each application ha~ a four charact~r name that is unique within each deploy~d runtim~ sy~tem.

~ transac~ion with D~A accordin~ to the pre~ent invention is a collection of resources (panels, r~ports, procedures, d~tabases, etc.) to be utilized in behalf of an application to p~rform various function~ ~or that application. Each transaction i6 uniquely idantifi~d within ,J' 1 ,~ 3 each runtime system into which is is deployPd. Addi.tionally, each transaction comprises a set of load modules or programs that perform ~he sp~cified functions in the appropriate environment for ~hat transaction. Each transaction has a primary program (load module) which may, in turn, .invoke sub-modules on behal~ of that tran action.

As shown in ~igure 9~ each DAA application transaction is composed of application procedures, panels, views, working storage, DA~ run-time ~unctions~ a Transaction De~inition Table (TDT), and other tables. As can be seen azcording to ~he preferred embodim~nt o~ the present invention, portion 152, containing th~ DAA runtime procedures and tables, is applicatlon independent. Portlon 15~, con~aining ~he TDT, proc~ur~ (input, refresh), panels (m~nu, application) and views (impor~, export, pro~ile3, remalns application depend nt. Procedure ha~e direct acce~ to working Btorage ~ but are co~pletely lsolated grom panel and views Sand consequently isolated ~rom the m2chanic~ o~ inter-transaction co~munication, devic~
com~unication, profile management, etc.).

Each transaction may per~orm multiple ~unctions in b~half o~ the application. These ~unctlo~s are repr~nted hy applicatio~ procedure~. ~ procedure as contemplat~d by th present inventlon is a collection of code that perform~
a parkicular set o~ ~unotiQn~ on behalf of a transaction~
Each proc~dure ha~ a na~e that i6 unique within the a~ociated transaction. An application procedure may be l~voked a~ a result of a panel being presented to khe transac~ion that con~ains this procedure. A procedure may also be invoked by a distributed application transferring a request for servic~ through a network reques~ (LINK) to the designated system/transaction thereby invoking the de~ignated tr~nsaction procedureO Upon completion o~
execution of a procedure, the procedure may stipulate that a ~ . . . . . . .

: '` ~: . . ' ` ' .` ~ ' ' panel i6 to be prep~red and presented back to the application user or it may designate that control is to be passed to anoth~r system/~ransac~ion/procedure with a remote r~quest or it may de~ignate tha~ control is to return to the calling system/transac~ion/procedure that invoked thi~
procedure.

A panel wi~hin DA~ according to the present invention is a defined format ~or information interchange with a logical terminal (e~g., an IBM 3279 display t2rminal). Each panel is uniquely identi~led within tha asaociated tran~action.
A~sociated wlth each pan~l is an INPUT procedure and REFRESH
procedure. The inpu~ procedure is invoked when tha csxresponding panel is received from a terminal. The optional refre~h procedure is executed upon the r~start of an application or ~rom a H~LP suspensio~ in order to refresh data to be presented on the panel prior to output display o the panel.

An input E~rocedure i3 an appllc:atlon program that is in~oked wh~n a panel is receivecl by a ~y~tem from a t~r~inal/proce~a. When an input palnel i8 received from a logical terminal, th~ input procedure associated with th~
pan~ invoked.

A refre8h procedure is an appllcation progra~ that i~
invok~d prior to d~splaying a panel that i~ requested fro~ a menu or i~ invoked upon re~tart of an application that has baen su~pended for HELP documentation presentation. The re~re~h proc dure i~ typically u~ed to retriev2 data ~rom data bases prior to diaplay on the panel. Th~ re~re~h proc2dur~ may also be invokPd when a panel i~ to be pre~nted a an initial us~r request from a menu. A refresh procedure may be associated with a menu ~election and/or a panel. If a refresh procedure i5 associated with a menu selection, this procedure will be invoked prior to the `J ~

display of the panel. If, howeve.r, a menu selection doe~
not e~plicitly hava a refresh procedure, then the refresh procedure on the panel specification will be inYokedO If neither the menu selection nor the panel specification speci~y a re~re~h procedure, ~hen the panel will be presented from the data in working storage, as populated from the profile view.

Working storage, sometimes also referred to as a tran~action view, contains all data items thak will be referenced by all panels, views, and procedures ~or this tran~ctlon. Working ~torage i~ pa~ed to each procedur~
within the ~ran6action ~or u6e in execu~ing the loglc o~
that procedure, Working storage con5i 6t5 of a f ixed section, which is u~ed to communicate betwean DAA run~time ~unctlon~ and application procedure~, and a variabls section~ which i~ entirely application-de~lned.

Within DAA, according to the pre~erred embodiment of the pre~ent invention, application proredure~ co~municat2 with each othar, and with outside re~ources, via "views". View~
are uised to help i~olate appllcatlon procedure~ from ths mechanias of in~er-ay6~em communications, device pr~entation manage~ent, help ~acilitiai, me~ue, and other D~A com~on erviae6. Thisi isiolation of the application logic from ~'service~ n~uresi that:
,- an applicat~on can be s~rviced, without programming change~, through c~ntinually evolving communication~, ,storage~ presentation, packaging, proce~sing, etc., technologies.

- an application can be imple~ented on a ~ariety o~
plat~orms and architectures, bas~d on c~st/perfor~ance measure~ents (not on miyration costs)..

- an application can be implemen~ed on a variety of Tq-13766 39 :i .: : . ' " : , . : , : : : . , .'. ~ "': ' , . ' ~ , ' : . ' ' :' . : ' ,', .', , ~: .

user environmen~s, including varianc:es in national language, human interace hardware, and user pre~erence, - an application can be altered in real time, including data interchange (view) re-de~initions, without disruption or loss o~ dataO

A vi~w within D~A a6 contemplated by the present invention i~ a de~ignated collPction of daka item~ that are utillzed by the appllcation, ~ view is a named coll~ction o~ ~uch d~a item~ and include~ the identi~icatlon and l~ngth oY t~e~e da~a i~e~ as th~y r~latQ to the partiGul~r tran~action. The primary t~pe~ o vi~w~ are pro~lla, import, and ~xportO ~ profila view id~n~i~ie~ all data item whi h are ~o be saved in the user' 3 pro~ile bekween executions of this tran~action. An import view dg~lnes all daka item~ to be presented to a called procQdure by a calling procedureO ~n export view de~ines all data item~ to be presented upon completion of the execution ~ a called procedure to th~ calling pro~.edure.

~ he pro~ view $B a sub0st o~ working storag~
sometime~ known a~ (kransaction view3 that is to be saved in the user~ pro~ for thi~ appli~ation. At the completion o~ thQ ~xscution of a procedure, th,e pro~ile view ~or that proc~durs i~ ~xtracted ~rom working storage and wxitten ~o th~ profil~ dat~ base. As this transaction is reinvoked by subseg~ent data entry or applic~tion restart, this profile view is r~ad frvm the pro~ile data base and used to repopulate wor~ing storage. The pro~ile view is i~tended to b~ a subse~ o~ wor~ing storage which de~ines the data requirements of the current user dialog state while minimizing the overhead a~sociated with maintaining user pro~iles.

The import, or input, view is a collec~ion of da~a items .. ., . : :....... . , . . . ............... - . . ....... . . .
:.. : . : , , , . . , . : : : . , that are pre~nted to a procedure when a procedure is LINR~d-to ~rom a calling system/transaction/proc~dure. When a procedure completes and indicates an Exit State o~ LINK, the DAA control program ~IET) will extract ~rom wor~ing storage the data items identified by the import view for the called procedure and package that with the control information neces~ary to speci~y the calling and called sy6tem/tran~action/procedure. This message ia routed to th~
de~ignaked ~ystem and transaction for execution. The import view, when received at the called system/transaction/
proradurs, i~ ue~d to populate wor~ing storage ~or the c lled tran~actlon.

The export, or output, view is a collection o~ data item~ repre~enting the re~ults o~ the execution of a called procedure. The e~poxt view i~ a ~ub~et o~ it~ms contained in woxklng 6torage at ~he completion of a procedu~e exQcution when the exit ~tate i8 Bet to RETURN. Thia export view i~ packag~d with inter~ace control lnformation into a me~sag~ to b~ routed back to the cal:ling 3y3tem/transaction.
~hQn ~his ~essage arrive3 a~ the de6ignated sy~tem/
transackion/procedure, the pro~.ile view ~or that ~yStem/tran8aCtl411/prOCQdUre i8 ret.rieved ~rom the profile data ba~e and u~ed ~o popu~ate working storage. Th~ e~por~
vi~w i~ then extracted from th~ me~sa~e ~ust recei~ed and used to populat~ (and overlay profile da~a in) working ~torage. The specified procedure is then restarted.

A transaction v12w iS a collection of data items to he used by the collection o~ procedures, p~nel~, and view~ that mak~ up a transactionO These data items may be thought o~
a~ COBOL Data D~initions or as C struckures, although other lanugages may be uqed, that specify each of these data item5. The transaction view is passed as a working storage area ~o each proced~re within the transaction ~or use in executing the logic of that procedur~.

: .. , . . . , .. -,: .

q~ -2 '~3 2 ., l ~

When the TDT is fir3t referenced, the GTD system will generate the "sy6kem required" portion of the transaction view and plac this in the associated SRCLIB (described later). The transaction view name i~ usually o~ the ~orm "tdtTVW". The application designer is then required to add any application-unique data items to this tran~action view.
Once specified, the transaction view is used as a data re~erence source ~or procedures, panels, and other views.

~ P~CA~O~ ~ORT~ pplication portability i~
achieved by ~uppor~lng, on all DA~ sy6tem platform~, and ~or evolving ~y~t~ environment~: iden~lcal application source program ; identi~al application deflnitions; and ident~cal application development environm nts.

Sourc2 pxogram portability, or ldentical application ~ourcs program~, for all ~uppor~ed plat~o~m~, is achieved by adherance to a selected set of industry-adopted standard~, combined wi~h a plat~or~-independen~ progra~ lnter~aris.

Examples of industry~adopted standards which arP usad to ai~sur~ ~ource program portability include~ n pr~gram compliance with dra~t propo~ed ANSI '~C" (X3Jll), including the defined ~unction library ~ICOBOL'' program complianc~
with ~SI X3.23 19~5 (Intermediate Level); and "SQL"
compliance with ~NSI X3~135-1986. Adherance to th~se ~tandard~ are checked on all plat~o~m~ having ANSI compliant compilers or pre compilers. Deviation from the standard, including non-portabl~ URe of syst~m-specl~ic function~
checked whenever ~aslblQO

Examples of areas in which induskry wide standards do not exist include: interface to a transaction proce~sing sy~tem; inter~ace to a presentation sy6tem; communicatlons betwe~n cooperative procesi~es; routing meSBage~ to I

.. . ,. . , . , - , . , ., . . . .. : . . ~
. : . . . , . : : ,;,. . : :

2~,t;,.~.

terminals, transactions, systems: user interface; pro~ile management; help and user do~umentation. These functions are provided by DAA, but are completely isolated from application loyic.

Furthermore, there i~ one interface between DAA and application procedure~. The application procedur is called, passing it the address o~ working storage.
Interaction between DAA run-time services and the application i~ via a fixed portion of working storage. The applicat~on u6es working storage to reque~t ~ervice~ ~uch a~
di~play a ~p~ci~ic panel or link to a proc~durQ. However, ths application does not ~peci~y daka requir ments, logical control ~equence, or any other mechanica o~ the ~ervice.
Parametera o~ DAA services are isolated ~rom the application logi~, making ~he application ~ource program ind~pendent of 3yetem-speci~ic implementation$.

Th~ runti~e environment for DA~ application~ provlde~
for the ma;or ~unctions to be supported by a run k~me driver (IET) and as60ciated run time aubroutines. An application (input~ procedure i8 invoXed as a result of input from a panel or input from a remo~e procedu:re call(i.e., LINK). In either caee, the st~uctura and cont~ent o~ working stora~e, a~ wall ~ the salling sequence its~,lfO is identlcal. It i~
tran~parent to th application whether input wa~ r~ceived ~rom a panel or another procedure (except that an optional RETURN ~ay be made to a ealling proc~dure~. These two X0rm6 o~ input are fur~h~r described in the ~ollowing paragr~phs.

When panel input is received from a terminal to a procedure, the u er's profile view is extracted from the ROLLFILE and placed in working storage. Working storage is presented to the procadure and the procedure i executed, which typica~ly perfo~ms application-dependent data ba~e query/upda~s, ~anipulative logic on data it~m~ in working . . ' ' . ' ~ . ' 1 ' ' . ' . ' . . ' ' . ' ' , ' ' ' ' . .
". ', ,. ' . i, . ','', '. ' ' ,." '' ~ ,,.,' '''; ' , ' . ': ' ' ' ' ,. ' .

' ' . , . ' '- ' " ' ,, . ' ' ',, ., " "' ,. ' , ' i ' . . ',' .', .

2 Q r ~

storag~ and/or da~a bases, and preparation of output data ~lements in working storage (which may be ~aved in the user'~ profil~ or displayed to the output terminal wh~n control is xeturned to IET). I~, for example, the designer o~ the applica~ion receiYes input, reads data from the data base, places that data in working storage, and rPturns contrvl to IET, the same panel will be displayed with th~
newly populated working storage data, X~ th~ loglc of the input procedure is such that it deter~lnes fro~ terminal input or u~er action request (e.g., a ~unction k~y) ~hat an alternatlve panel is ts be di~played, it may do ~o by ins~rting the new panel nam~ in th~ I~Fl-P~NEL fleld and returning control to the IET. IET
will pr~pare a panel for th~ input t~rminal consi~tent with the panel ~pecification. If the IEFl-PANEL ~ield i~ left blank, the master menu will be displayed.

The de~gner hae the option o~ lnt~rrogating the user action reque~t (a.g., runation key), located in worklng ~torage ole~ent IEFl FUNKEY, to d~termine ackion to bs taken by thi~ procedure in re~pon~e to a u~x ~ctlon r~gu~t ~rom the ter~inal. Not~, how~ver, that certain action reque~t~
ar~ ree~rved ~or u~e ln dialog action~ d~ined in th~
conslstent u~er inter~ace (and implemented by IE~).

An external procedure i~ a proc~dur~ which ls phy~ically located in a different transaction and possibly different ~ystem~ Th~ ~xternal procedure it~el~ i~ not included in the calli~g tran~action load module but a reference to this ~xternal procedure i~ mad~ to correlate the import and export views for this procedure.

A~ application procedure can use the LINK and RETURN
exit states to invoke ext~rnal procedures. Distri~uted Resource Control (DRC~ is used to route the regusst ~o the , ~ TI-13766 44 !

~j. .. .. . . , . . - . . .. ... . ,. -. ,; . ,., . . ~.. .. .. .. .. . . . .. . . . . .. .

.,. . .. . . . ( ., .. . . . ~ . :;

. ~ . ~ . . . . .

? ~ ~ r~ ,~ r~ ~
d2signated system/transaction. The proc~dure name, a~
specified, must be a w~ll defined procedure name within tha called system/transaction. If it is not well defined, then the menu ~or the called ~ransaction will be displayed to the user.

~ he invoked system/transaction/procedure operate~ in the same DA~ environment ae the parent transaction/proc~dure and has th~ ~am options (i.e., if a panel is to be displayed upon completion oX ~he execution o~ thiæ call~d procedure, the proc~dure may do ~o by entering a panel name in the IEFl-PANEL ~iald and returning control with tha IEFl-XSTATE
~ield blank t4 di~play thl6 panel to the r~queetlng u~er).

A called external procedure may return control to the calling procedure by ~ettlng the variable IEFl-XSTATE to RET~RN. In thie Ca6e, ~he IET control program will extr~ct data items from working ~tor~ge a~ ~peci~ied by the export vlew ~or thi6 called external procledure, package that with the intarface control block that initiated this call reque~t and ~ubmlt this output me~age to the calling ~yste~/transaction/procedure. Upon return to the calllng sy6tem/tran~action, the IET control program at that system will extract the pro~ile view for the calling proced~re from th2 profile data bas~ and u~e it to populate working ~torage of the calling tran~ackion, ~ollowed by a population (and con~equent ov~rlay~ o~ working storage ba6ed on the export vl~w r~ceived from the called ~xternal proc~dure. The calling procedur~ will be reinvoked for further proce~sing.

D~ profil~ management ~ a ~ervlce which i8 automatically pro~ided to all application procedure~
executing in the DAA environment. Profile management saves and restores an identified sub6et o~ working storag~, completely independent of application procedure logic.
Pro~ile m~nage~ent enabl s DAA transactions to have the ., . , : . , . . . . , ~ : i .. , . . , ,. :,." , .. ~: : ..

OEP~ ~

characteristics o~ conversa~ional transaction6 (exc~pt pro~iles are by user ins~ead of terminal~, without requiring application logic. Consequently, DAA procedures have some o~
the easeoof-programming ~eatures inherent with interactive-mode applications, while retaining the resource administration advantage~ inherant with transaction processing.

Ona side e~fect o~ 8 profile management is that working ~torags is Ret according to the de~inition of the user pro~ (and not ne~ee~arily th~ la~t executton of th~
procedur~). This encourag~ appllcation proc~dur~s to be coded ~or ~rial re-u~abili~y and/or re~ntrancy.

Application definit~on portabilityt both with respect to suppsrted platforms a~d evolving sy~tem environment~
achlev~d by u31ng table~ (a~ oppo~ed to yenerating code) wi~hin ~he ~pplication load modul~.

Tabl~ to de~crib~ the applisatlon requir~ment~ and de~inition6 are independen~ o~ the ~pecific implem~ntation en~lronment. For exampl~, panel table~ do not have any dsvice-r~lated in~ormation nor do import/export view~ ha~e any protocol sp~cifir information. Environmental dep~ndenciQ~, ~uch a texminal devices or inter-sy~tem communications protocol, are isolated ~rom the application definition. Con~equently, DAA support for change~ to the ~n~ironment, either through explicit application trans~r to another anvironm~nt, or through natural evolution of th~
current environ~ent, i8 achieved without impacting the applicatlon~

D~A provides a platform~independent int~rface to a ~tructur~d developm~n~ proc~ss, plus an automated mechanism for transPerring an entire application development environment between platforms.

: ' '' . ' ' '' E~

i~J ~

'IGenerate Transaction De~inition" ~GTD~ is an interactive ~ool used for semi~auto~ating the tr~nsaction development prsces~. GTD provid~s the dev~loper with a mechanism ~or specifica~ion o~ all transaction el~ments.
The us~r creat~ and edits ths Transactlon Definition Table ~TDT), which identi~ies the elements to b~ included in the tran~action and th~ relationship between the elem~nts. &TD
also provides the mechani~m ~or ~p~ci~ying parameters o~ DAA
service~, such a~ dialog interaotlon control, panPl layouk, profils mapping, lmport~export ~apping, etc.

~ TD proYide~ ~ ~'common u~er lnter~a~e'~ to ths developer, independent of the pl~torm being u~ed for d~velopment. The tool ha~ the ~ame panel~, and same op~ions, on all sy~t~s.

All a~p~ct~ of application dsv~lopment ar~ identlcal on ~11 plat~orms, including tran~action de~lnition, menu de~ini~ion, panel layouts, view defini~ion~, working ~torag~
de~inition, help and information docum2ntation, etc.
Variatlon~ in ~ naming conv~ntion~ compiler optlons, link option~, SQL pre-compile options, and other 6y~tem ~eakure~ are hidden from ~he developer. Variations in phy~ical characteristics of supported terminals/device6 are tran~par~nt to the developer. Variation in the tran~action proce~ing æy~tem, and associated interfaces, are hidd~n ~ro~ the deYeloper. Installation procedures are identical on all ~ystems.

In addition~ there is a function within GTD which provides for the automated transport o~ the entire ' development con~iguration, for a given application, ~rom one i system plat~o~m to another. These capabilities promote rapid dep~o~ment of applications across heterogeneous i platfor~.
~ TI~13766 47 ., : . , -- .

,, ~ . , . , ~ . , ! . . :: !

. .

.' ' ' ' ., ' . '`'.,., ' ' ' GTD i.s a s-~ructured developmen~ environment and ~n~orces structured construction o~ transactions, Since all components are known and controllecl by ~TD, it is feasible to automate the ~ransf~r o~ applications ~rom traditional ~albeit partially automated~ deYelopment methodology to full-cycle CASE tools such as Texas Instruments' IEF.

DYNA~IC APP~ICATION~o The primary attributes o~ DAA
transactions, according to the present invention, which contribute to the capability for dynamic application modiflcatlon areo pa~kaging all applicatlon-6peci~ic componentEl o~ a trarlsac~lon into BingI~ load module: and insulating transactions from the impact o~ view de~inition changeæ.

Additional:Ly, DAA ~ervices associated with application tran~actionfi can be modi~led dyna~ically and synchronously (~with respect to all application transactions) since: most DA~ service~ ar~ implamented a~ independant proce~es, communicating (in sy~tem-dependent implem~ntations) with DA~
run- ti~e ~unc~ion~ in the transaction; and the DAA run-tlme functions are dynamically loaded, independen~ of ths transaction's load module.

~ he~ c~pabllitle~ enabls continuous operation~ at all sy~t~6. It a~oids ~he prob:lems of synchronized in talla~ion, enabling main~enance on each syetem ~o be per~orm~d a~ynchronou~ly~ It also enables continual upgxade~ to DA~ ~ervice capability (e.g., ability to support new terminals/ devices: new u6er dialog~: new help/doc~mentation pre~entation features; etc.), transparent to applicatlon transactio~.

One or more application procedures are packaged together with a transa~ion ~efinition table, views, panels, and other resources to create a uniquely identified load module.
qI-13766 48 ;^ J

This load modu:Le~ in combirlatlorl with other attributPs such as scheduling prlority, is identified to the Transactlon Proce6sing Monitor via a "transaction identifi2r". This transaction identifier i~3 the ba~;is for scheduling work within D~. Th~ load modulla which i~3 associated with the tran~action identifier inc:lude~:

- Appl isation proced1lre~ .

- Set of re ources ko }::~ used in cs:n~unction with application procedurP3, suc:h as data set3 or data ba~esO

Transaction De~inikion Table. Thi6 table includes, among okher thing~

- A table oî all referenced procedures, both int~rnal and ~axternal.

E~or each re~erenced proc~dure, the import, export, and pro~ 3 vie.wE; a~;~ociated with th~t procedure~.

~ A tabl~ of all referenced pan~31e.

- ~or each re~erenced panel, the re~resh and input procedure~ asE~ociat~d with that pane.l.

- Working ~toragt~.

In ~ummary, 1:he load module contains all ~ppllcation-~p~cific: logic and d.ata. Since the load module is tr~ted as an indi~riE;ible unit by the transaction proc:es~ing sy~;tem~ modi~ica~ions of program logic, data base query, pan~ls, and/or any other components of the transaction will always be installed synchronously, thereby i ~nsuring 19;~ild module in~egri~y. ~osk non~ ystems, both tran~actiorl proc~s~ing sys~em~ and interac:tive sys~ems, Iq-13766 49 ::::: : : , , . . ' ' ~ '' ' ,:' , . :~ , :
, : . . ' ~ :: . .

require or allow user inter~ace contrt31 table l~e 3:hysically separate from load module~ (which inevitably lead~ to synchxonization pxoblems).

Speci~'ically not included in thP 1 oad modul~ are the DAA
run~time f'~ ctio~ (IET, etc., ) whis:h provide and/or intPrfaoe tG ~h~ YarioUs services provided by DAA.

IET, along with all lower level 58~iC~! functions associated with IET, i~ implem~nted out~;ide the load modula.
IET is isolated from applicatlon load module~ in order to reduce apEalication load module size, ~;ynchronize syatem~wid~
in~tallation, en~.~or~ ET upgrades into 11 applicakions, and perform I~T upgrad~ wlthout rebl~ad or oth~r modification to the a ?pllcation.

IET, along with all other I)AA run-time ~'tmctioll~, are i~plement~d aE~ a dynamic: link module, callabl~ ~'ro~ khe (DAA
provided~ ~Imain~ program whlc:h gain~ control ~'rom th~
tran~action pxoceseor.

Many DAA ~erviceE3 are implembnt2d as $~ade~aendent ~rocesse~; which utiliz~ sy te~-deperldent technique~ to com~unlc:ate wlth the run time function3 linked to application trarlBaCtionB. ~h~!~e ~ervices inslude docu~entation rstri~Yal system9 profila manage~ent/ and di~3tributed re~30urc:e control. ~he D~ ~ervices are imple~ented aE~ ~;erverE;: funct~ons within appllcation tran~act~ on6 are client~ .

DYNA~ VI~ r. Appli~:ation procedures communicat~ with each oth~3r, and with oute ide re60urce~, via 3 "view~", View~3 are used to help isolate application proced~lre~ from ~he mechanics o~ inter~ystem communic:ation , device presentation management, help facilities, menUi~3, and other D~A common ~ervices.

,.... . ,. .. . .. ~ ... .. . . . , . - , " " . ...... , . , , , . , - -, . . . ~

': . . - ............ - , `. , : ', : . j ~ ~ ' :

Following each execut:ion of a procedure, a subset of working storage is saved on disk. ~his sub~;et is a speci~ic "pro~ile'l view for the procedureO Th~ profile YieW i~3 us~d to re-populate working storage when panel input is complet~
(working storage is re-populated from both the panel input data and the prof ile) .

The relatis~nshipF between DAA application proc:edures, working storage, and profile views is ~hown in Figure 10.
Th2 portion Qf Figur~ 10 de~ignated 156 repr~sent~ th~t portion ;: f the executl on und~r IET control . Ths portion de~3ignated 15R repr3&entE3 the portlon o~ tha ex~cutiorl ~h t ~emains under s:~ontrol of the application.

Wherl a txanE~ctiorl haE; been re~tarted after b~ing E;u~;pended, a E~ystem accordiIIq to the preBant invention u~es ths user identification provided at logon~ and the application identi~ication of the desired application procedure~, to locate the pro~ile ~riew which has matchlng identi~lc~tion. I~ no pxofile view iB found, to match the giv~n identi~ica~ion, the ~y~t~m wil:L generate a new profile vie4w th~t bear~ ~he given identi~:Lcation. Once a profile vi~w bearlng ~ha given id~nti~ic~tion ha~ either been located or generated, the dialog manager thQn p~rform~ it~
proce~ing sequence until the transaction i~ suspended again or comple~ed.

T~e dialog manager (IET) proce~sing zeguence gor proftle views, panel view~, and working storage i~ ~ummarized a~
foll~ws:
- Read profil~ 160 and map to worklng storage 162.
- ~ea~ panel input 164 and map to working ~itorage 162.
~ Ex~cute procedure 166.
- ~ap working storage to pro~ile 1~.
- Map working storage 162 to panel 164.
TI~13766 51 ,~ . . . i . ~ . ; : . . :
:.~ . . . , , . , . .
, .. . . . . . . .. . . . . . . . . .

~3 ' ~ ~, .

.J ~r~ i ~J
- Display panel (not shown)~

Working storage is used direc~ly by the appllcation procedure~. ~x~ernal views are used for coordinating (asynchronous, queued) data interchange between procedures.

Viawe which are interchanged between pro~edure via LINK, ~ETURN~ or XFE~ or "profile" views which are stored on the u~er/~ession profil~ stack are "External view~'~. These VieWB have ~he proper~y o~ existing asynchroncusly to the li~e cycle o~ ~ran~action~ .g., the tran~action could be modi~ied while a view i~ in tran~lt between transaction ex~cution~, p~ibly with a di~erent de~inition ~or worXlng storage ) .

When data i~ $nterchanged between two tran~action~, or ev~n betw~Qn on~ ex~cu~ion instanc~ o~ a tran~act$on and anokhQr execu~ion ln~tance o~ the ~ame tran~actlon (e.g., "pxofile~' view~), a mapping occur6 ~e~w~en an external view and worki~g ~torage. ~he ~ollowin~ tran3~0rmatio~
con~idexa~ions apply ~o ~his mapping:
I

- The internal representation of data within working ¦~torage may not correspond to the internal repre~entation o~
the ~am~ da~a it~m in the ex~ernal ~iew. Either thQ format or lQngth may be dif~erent.

~- Data item~ may be added to or removed ~rom working :,~torage or an ex~ernal view.

- The nam1ng convention used by ite~ in working storage may not correspond to the naming convention used by the external view.
.~
f- The data conten~ of ~h~ ex~ernal view will change over ~im9. Not all transaction~ using the external view are i r - : . :, ' ~ , . ;. . ' ', . . : .: ~
'.~ , ' ~. ' , ' :' ,' ' ,: . ' : . ~ .
~: ' .
,:

6~ ~

updated (nor nacessarily have to be updated) to re~leck change~ in external view conten~. In any ~ase, ins~allation of ex~ernal views or working ~torage modifica~ions ~hould be po~sible, in real time, with no disruption o applicakion transactions or ~ata dis~ributions in progr~

- The quantity o~ data within a view may vary. A
repeating structure may occur a variable nu~bar o~ times.

External Views are implemented ccordlng to the ISO
pra~ntation pro~ocol 6tandard, which dePines both a "~ourca'l languag0 ~peci~ica~lon ~or dat~ structure~ a~ well a~ th~ run-time daka encoding algorithms, ~ o achieve ~he goal of da~a ln~erchanye ln an environm~nt whlch p~r~it5 real~time tran~actlon modi~iration, working s~orage i5 de~ined indep~nclently ~rom the exkernal view~ (import, e~port, pro~ile). A vlew con~ifit~ o~ a ~et o~ data elements, which can b~ "primitive"
item~ or "set6" o~ data elements. The recur~ive de~inition allowe arbltrarily complex ~ructur~

Each data element of a vlew i~ as igned an identi~ier ~which i3 always as~ociated with th~ ~ame element, ev0n i~
the el~ment changes relative po~ition within the ~tructur~
or ha~ a ch~nge of length)a Each daka element o~ working ~torage i~ a~signed an iden~ifier (which is alway~
as~ociat~d with th~ same elQment, even if the element change~ relative position within the structure or has a change o~ length). A projection tabl~ is constructed for each vlew which defines the mapping between identiier~ in a view and identifiers in working storage.

U~îng IS0-de~ined ASNn 1 encoding, including e~bedded id~nti~iers ~or each da~a ele~ent, views can be interchang~d across heterngeneous plat~orms. Furthermore, vi~w encoding , . , ., . , . . ., . . ~ . . . :; . .. ., ., . , - . . :.. ; . . . .
-~ t,) t 1/ ~

i~ independent of any structural change in working storarJe si~ce embedded identifiers are used for mapping (i.e., mapping is not dependent upon sequence of items in either working ~torage or view).

Consequently, data integrity of view exchange i5 maintained even wi~h change~ in relative order and/or removal or addition of items within the view.

CO~ T~N~ U~E~ E~FACBr A user inter~ace scenario which illustrate user interaction with a distributed ~A
~pplication iB 6hown in Fig 11. In thi3 example, a u~er 168 entered a panel on terminal 58 which wa~ a~sociated with System 2/Transaction 2/Proredure 2. Since the user' 5 terminal wa phy~ically located on System 1, Di6tributed ~e~our~e Control ~DRC) wa~ used to route the mes age (i.e., panQl input) to Sy~tem 2/Transactian 2/Procedure 2.
Application logic within Procedure 2 reque~ed a LINK to System 3/Tran~ackion 3~Procedure 3. DRC was u~ad to rou~e ths ~INK mes ay~ to Sy~tem 3/Tr~msactlon 3/Procedure 3.
~pplication logic wi~hin Procedure 3 reque6ted a panel to be di~played to the u~er. DRC was uslad to route the mes~age (l.e., panel output) to the terminal 58 on 5y6tem 1, for viewing by u3er 168.

Within this ~cenario, involving ~ultlple 6y~tem~ and transaction~, u6~r interface con~ist~ncy is es6sn~ial. The primary pUrpO~Q of a con~l~tent u~er lntarface within DAA iR
to have all computers, 8y8tem~ appllcations look the ~am~
to the user4 Panel ~ayout, panel element interaction, and overall dialog ~low arP. key aspects o~ u~er inter~ace c~n~istency. D~A enables and partially automate~ the specifioa~ion o~ consisten~, system- and devioe-independent pan~l layout~ (via GTD). ~ialog ~low is partially defined by the developer (menus, panel validity checks, documentation) and partially de~ined by DAA ¢onventions for .",. ~ . .. . ., , . . ,: ,. :: , . :

r~

dialog flow between applications.

Run~time user dialog navigation is implem~nted by IET, independent of application logic. Providing a con~istent u~er interface relies heavily upon profile management, w~ich maintain~ the transa~tion state and selected application data for each user/sess.ion.

The us~r and computer exchange reguests, creating a user-driven dialog which moves along one o~ the hierarchical paths providad ~y the application, Within the dialog, data and control is pas~ed from one proc~dure to another.
prosedure may be located on any system within the DAA
environment. The location of a procedure is transparent to both the application logic and the end user.

IE~ controls mosk o~ the user dialog, isolating the application procedure ~rom the majsr aspect~ o~ u~er interaGtion. This enables IET to implemen~ not only a consistent u6er int2rface acro!,6 all ter~inal~ and I plat~o~m~, but also to evolve the u~er int~rface toward~
deYeloping indu~try standard~ (indep~nd~nt of application logic)~ The following paraqraphs del3cribe an implementation of a conaist~nt user interface (controlled by IET and defined by GTD~

Although ~he I~T will be described in greater de~ail j laker, it u e6 a mapping servicl- to interpret any panel j input by mapping the input into variable~ which will be usad to build panels. It int~rfaces with a transaction processing ~ub~y~tem to obtain a next panel from a user and to present the output in a panel form with wh~ch the us~r may in~erac~. By using a table of in~tructionR containing pointers to ~ap~ ws, and appliction procedures, the IET
i~ instructed, via a translator for the table of instructions, as to which next panel to present based on the re~ults o~ the proces~ing of the pre.vious panel.

The IET manages dialog flow betw~en various users, which can be a variety of logical terminals by initializing the ~ields within a transaction vi~w for that tran~action.
After receiving a ~ormatted input data mesaage, the IET
reads the m2ssage header to d~ermine where the message is routPd for proper processing. 1~ the sy~tem.tran~actionOprocedure name found in the header doe~ not match that of th~ 19cal sy~tem, th~ IET ~orwards the me~eage packQt on to the appropriat~ ~y~t~m. If ther~
i~ a ~atch, how~ver, th~ IET yi01ds control o~ th~ di~log ~low to a map lnt~pr~tsr tha~ the IET call~d, APter th~
procQs~ing has co~pleted to the extent po3~ible, either due to applicatio~ command~, or procedurQ ~u~p~n~ion, or completion of khe proc~dur~, the IET bullds an output measage co~talning either an input view (~or cooperativs proces~ing on ano~her ~ye~Qm.~ran~ac~ion.procodure) or an output view (for returning a coopera~iYely prscessed procedure or returning a panel contalning kha proces~ed r~sult~ to a user). Either way, th~ IET then forward~ th~
m~age to the de~ired loyical terminal.

Panel~ are the primary unit of in~ormation interchange betwQ~n transactions and terminal~, A d 6cri~kion of the user dlalog which follows is wi~h respec~ to sequences of pan~l6. Within a panel; khere is in~ormation structured accord~ng to de~initions made in GTD. ~n parti~ular, there are fi~lds which di~play or r ceive formattPd data, ~h~
field~ have various attributes, such as color, rever~e vi.deo, etc. The panel i~ imported to DAA whenever an "action" is requested (e.g., an a~ion can be as~ociat~d with a ~unction key or an action bar pulldown menu item).
~h~ the panel is i~ported to DAA, D~ r~ceives data which has been ~ntered in en~ry ~ield~, th~ action requested, and the currently selected (e.~., cursored~ data item.

~ t;~ ~q ~

User int~ractlon with panels, prior to th~ action requ~3~t, are performed locally at ~he terminal (e.g., ~ursor movement, key entry to ~ields, et:c. ) . Thi~3 interaction is device-dependent, but is consis1:ent across all D~A
appli ations ( for each particular terminal j .

Panel to panel navigation is terminal~ deperldent. DAA
tran~action present panels to the te~mlnal ~ia a pan~l driver ~ref~rred ~o as rMS). TMS interprets panels prepared by GTD and ~upport~ color, extended attrlbute~, rev2r~e vid~ao, und~r~cor~, and oth~r characteris t:lc~3 . C2rtain texminal~3 that could r~c~iv~ thes~ panel pre~antation~ my not be capable o~ supporting th~ full ~unct~onal~ty of the panels aE; prepar~d by the de~igner. To support multiple levels of terminal c:apability but ~;till pro~vide maxim31m functionality Por the most c:apablQ terminal de~ic~ , TMS
u~e~ termina:L charact~ri~ic~ informa~ion provided by Dlstributed Resource Control (~RC~. Thare~ore/ the application de~igner can de~ign terM:Lnal pxe entations that ukiltze ~he ma~i~u~ funct1onali~y o~ ~ny terminal that would ukllize his application but, at thl~ ~a~e time, be as~ured that hi~ panel~ could be (dynamical:Ly) adapted to kerminal dQvic~ that have 1QS~r fUnCtiOna1itY~

At the same time the user and transaction are exchanging requ~ts involving the processing of in~ormation, the dialog, under control o~ the user, is moving along one of the paths provided by ~he application. The u~er "navigate6"
~, through th~ application using ~peci~ic actions ~ha~ are part i of th~ dialog. The~e dialog act~on~ donl~ neGe~sarily request the tran~action to process informatlon: they may I only cause movement through the dialog path.

j Dialog navigation within DAA is controlled at several lev~ls: sessions, transactions, and panels.

, ~ ~ : . , ~ , ` ', ! . ;

,~ ~ ' ' . ,', ' ' ~ ..

~ ~u ~t.~

The highzst lavel in the hierarchy o~ u6er interaction with DAA is the DAA "Display Applications" (DA) transaction.
The DA transac~ion iden~ifies active appli~ation on a system within the network ~or the designated user and may manage more than one ~ession for each us~r. When a user signs onto the network, the User-ID becomes known to the nekwork. By employlny the display active (D~) transactlon, a user is able to view the lis~ of applications in progress for the speci~ic User-I~. Through DA, the user may resume execution o~ an application or d~lete tha profila view for an appllctton ~ro~ the ROLLFILE.

Since DA iB a network-wide facility, the user may, through function key~ or by de~ignati~g an altar~ate sy~tem, transfer con~rol of ~he D~ transaction to an alternate 6ystem. Such transfer of control allows the user tD view a ll~t o~ applicat~on~ activa for that user on other sy~te~
in khe network.

In order to manag~ and control the number o~ active application~, the ~ystem may res~rict ~he number of active application~i and the amount of F~OLLFILE space allocated ~or each usQr ~ The~ param~ters may be ~et by def ault wh~n a new u~er sign~3i on to the syatem aIId can be modi:E~ ed via the U5:~c C ol;ation of th~ IE :: transaction ~descri~ed la~er) .

Each u~er ~ession has i~s individual pro~ile stack containing the c:urren~ s~at~a inf orma~ion ~or the corre~iponding hierarcl~ of transac~ions an~ panels. The DA
tran6~ction allowsi the user direct acce6~i to all of his activs~3 5e~8ion5 (includirlg tran6act:ion i on remote systems, if the se~sion ' s transaction thread leads to remote ~y~tema ) .

The pos~iible routes o~E naviga~ion and destinations ~rom ': . ' .: : , '~ '~ : ' , :: ~:'`: ''' . : ' , : ' ` :- : , : . ~ ': ' ' . ' . , ' ' ' ~' '; . ' , , : : . ` . : . ' ' ,'' ' ' ,, ':.:, . ' :': . : ' . ' . .

,l3 ~

J~.J.~
ses~ion to se~sion, for a typical dialog~ are shown in Figure 12. ~s can be seen, a user may request DAl (IETAAS) 170, which displays ~AA application, to start any session 172, may resume any suspended session 172, and may quit or susp2nd any session (curxent ox suspended).

U~ers can p~rform the ~ollowing actions with respect to s~ssio~s:

- 5USPEND the current ession. Th~ suspend action save~ th~ current ~tate o~ the se~6ion and dlsplaya tha ~A pan~l. It i~ possibl~ for the u~er to reeu~2 ~xecutlon of the session at a later ti~e (as an option from the DA panel), with the sa~e data (pro~ile~ as the time of susp~nsion.

- RESUME a suspended ~essisn (optlon on the DA panel).

- QUIT the current se~sion. TerminatQ~ the curr~nt se~ion, discard all pro~le in~ormatio~ a~30ciatad with th~ ses ion, and returns users immediately to the DA transaction. The DA transaction i~ logically the ~arthest point to which u~ers can return within D~A (i~e., the starting poi~t ~or DAA us~rs). In effect, quit is a fast-pakh exit to the highe~t le~el, logically bypassing the intermediate exit point~i. ~ny intermediate ~INXed transactions are exited.

QUIT a ~uspended se~sion (option on the DA panel)~

- CREATE a new ~e~sion.

The IET manage~ dialog flow for data input from a logical terminal ~or a suspended trnasacti~n that ha~ be~n re~tarted by. ini~lalizing the variables in the related TI~13766 59 ,,,, . ~ . .. .,. . ~ . ~ .

tran~action view. After receiving the data input from the stored profile view, i~ checks to slee if the input from the user is formatted. The IET reads the profile view and generates a new profile view based on selected portion~ of the format~ed da~a input. After converting the input from the input view and and profile view, the IET interfaces with a resident data hase management system to obtain the neca3sary views, maps, and procedures required to proces~
the input. The sys~em creates an ~utput view, populating iwth with selec~d portions of the proce~ed data and re~ults. The IET ma~e a pro~ile view o~ the current ~tate just complet d and replaces the previous view stored in the ROLLFIL~ with ~he naw profll~ view. The IET then tran mit~
the o~tput view, in the form o~ a me3~age beari.ng a head~x with rou~ing in~orma~ion to th~ appropri.ate logical terminalO

Transackion Navigation wlthin a ~ee~ion $~ based on a thread o~ ~IN~ed tran action~. ~ach transactlon has an ex~cution sta~Q which i~ retained on the pro~ data base.
The ~ r~t transaction within a threlad ls dete~mined by th~
user when h~ starts the ~esaion. Th~ creation o~ a new LINX
in the thread of ~ransactions is uncler program control. The sama transa~tlon can occur mor~ t~an on~ within a e~ion.
Th~ r~turn ~rom a 1 l nk can b~ per~orm~d by the program or can be short cirGuited by the user ~the Exit or Cancel action~).

The po~ible rou~e~ o~ navigation an~ ~e~in~tions rrom transaction ~o ~ransaction, for a typical dialog, are shown in Figure 13~ Th~ variou~ route~ depicted in Figure 13 e~pha iæe navigation about the thre~d o~ LINKed transactions. ~8 seen, DA display DAA applications 170 begin~ by linking to DAA application transaction 174 via tr~nsaction 174lS main menu. From this ~enu, vther panels can be invoked and this transaction (174) can be either canc~led or exited. The sther panel~ can be LINXed to the LINKed panel of DA~ applica~ion transactlon 176 or they can be exited to return to khe main menu. The LINRed panel in tran~action 176 may cancel transackion 176, at the user's request, or i~ may connect ~o the main menu of transaction 176. This main menu may in ~uxn invoXe other panel within tran~action 176, can canel transaction 176 to yet back to the other panels of transackion 174, and can exit tr~nsaction 176 to re~urn to the main m~nu o~ transaction 174. This pattern repeats for every tran~action added onto the LINK thread.

Within a transaction, th~re i~ a ~t of panel~. Tha navigatlon through a 6equence o~ panel~ i~ a function of th~
u~er interac~ion with ~ransac~ion procedure~. ~h~ pos~ible rvutes of naviga~ion and destination~ ~rom panel o panel, ~or a typlcal dlalog, are shown in Figur~ 14. The ~irs~
pa~Ql executed within a tran~actisn i~ either the main m~nu ox the panel re~ul~ing ~rom a ~INK~ proc~durQ execution.
Within ~igure 14, a closer loo~ at: thQ detail within an exampl~ current transac~ion 17~ i~ depiated. ~ain menu 178 i~ interconnected with panel~ 1~0, 1132. From main menu 17~, panel~ 180, 182 may be entered. The navigation po~sibilitie~ vary at panel~ 180, 182. From panel 180, ~or exa~ple, a transaation may proceed to ~nter panel 182, enter pansl 184, or cancel and return to ~ain menu 178. Panel 182 may enter panel 184 or cancel and r~aturn to main me~u 178.
Pan~l 184 ~y enter panel 186 or cancel and return to panal 180. Pan~l 18~ when comple~ed, may only cancel and return tv p~nel 180.

Th2 actiQns u er~ can per~orm wi~h re~pec~ to panels are-- Go back one step (~he Cancel action~ Thi~ results in a refresh o~ t~e panel which is next higher in the ,' i ., , ." . ".' . ', ', " ' . : : '' . . ' . ' . ' ' ' ' . ' ' " '' ' ' ' '.;. ' .. ' ' .', , ,' , '".' "' . ', :.. ', ' .

9~ .,i ~
f 3 hierarchy ( e ~ g ., the panel shown immediately prior ~to the current pan~ A Cancel i~sued :Erom the main menu terminates the tran~action.

- The "Exit " actiorl returns the u~er to the main menu for the current transac:tion. If the user is already in ~he m~in menu, and thi~ tran~action is LINKed, therl a return is made to the ~ain m nu Gf the previou6 appl 1 cation transaction . I ~ the u~er already in the main me~u, and this transactiQ~ i~ nst LINKed, th~r. exi~ to DA. Repeated axit reque~ts allow u~er~ to ~kQp back through th~ application tran~ction by txan~ation, utli~ taaly roturnlng th~
dialog to the highest level in the hierarchy (the DA
transaction~ ~

~ Re~r~E~h aotion. When u~er~ reque~t re~r~a~h, any data entered on the panel i~ ignored t and the re~resh proc~dure iY executed to generat~ the current statu~
o~ data to be di~played on the p~nel~ Example o~
ap1plication which might re~ii re "re~re~h" i~ a direc~ory list.

lp" actlon~ n u~er~ r~aue~t help~ a help panel i~ displayed ~o a~sist user~; to comple~e ~ha dialog.
Tha h~alp ac:tion triggers a help dialog, which is controlled en~irely by IE'r and is ~urth~r d~ac:rib~d in a subses~uenlt section.

- Proceed one step (the Enter actiorl).

When u~;~3r~; are f inished interacting with a panel, it is ~ubmittedi to ~he application with a specific: action requiest.
The action re~ie3t c:an :be either the enter action or other action which i~; not otherl,7ise de~ined as a dialog control func:tlon m~naged by IET. Examples of how action raqueste ' ': ', . ; ,",' ' ,' "` '. ' , ' ' ' . ' '' " ' ~ : ' ,' " ' ' '; ' .' ':~ ' " . ' ~;J ~ S~ r ~S

are generated include the use of function keys for non~
programmabls terminal~ or mouse ~election of action item~ in action bar pull downs on an intelligent work station.

The action requ~st results in the execution of the panPl's input proc~dure~ By convention, the input procedure has logic which results in a different panel being displayed, or the same panel with significant data contPnt ~hange~. The application co~trol~ the hi~rarchlcal level o~
the panPl from thQ "input" proc~dure. The input procedure c~n de~lara th~ rQlakiv~ hlerarchic~l level of khe next p~n~l dl3played, ~uch a~ l, o, 1, ox -2.

~ m~na lncrement current level by one. The pro~ile view associated with the input pro~-edure i pushed on the s~aion'a profila ~tack, ef~ectively ~aving the BtatQ of th~
panel aa ent~red ~y the user. The pro~ile view associated wikh ~he outpu~ procedura will be placed on th~ pro~
~tack a~t~r the vlew ~ua~ saved. Th.ls option i~ alway~ u~2d ~or th~ ~ransac~lon ~enu hierarchy.

0 ~ndicate~ th~ current level i~ not to b~ modir~d.
Next pan~l i8 di~played at ths sam~ l~vel o~ the hierarchy.
This is the d~fault for application panel~.

~ l d~a~ments ~he curr~nt level hy one. A profile view is popped of~ ~he ~es~ion's profile ~tack, recovering a panel and view a6 entered by the u~er. If there are ~o viewR on th~ stack for this transaction, then a RETURN is executed (with a completion cod~ of "cancel")0 This i~ th~ -enforced action taken on a "Cancel'l.

-2 removes all saved views which are on th~ profile stack for this transaction and forces execution of the main menu~

f, ' ~ ' .' ' . ' ' . . ' ' , . " ' , ', . . . ',: , ,, . . ' .' . . . ' ' ,' '., " . ,, . ',' . " ., , . . , ' ', ,, '', ,' . ' ` ' ":: ..' ,' ',, : . , . "' . .
,.; , . " ., ',.. . ',` ' , ~ ~, . , ,.- ', " , .,' .,.' ":, "', ,' ' , ' , ' ',, ., , , ,,',. - .. ,, . , . / ~, . . .

i: ' ' ," , ' ' ' ' ' , . ' ': ' .' " . ., ' ' ' ' ' '' . ' . .", ' ' ' ' ' ' . ~ ' .
, :' . ' ' ' . ' . I" ',., ' " .' ', " , " .'. ' ' ,, ': .. ., " ' ' , i' ' ' ' '' ' " "' . ''::' . ' ' i~ V ~

"Help" for an application can b~ invoked at any time.
Once invoked, the current st~te of the '7Primary Panel~l dialog is saved and a user dialog is initiated which is antirely under control of IET. When the user dialog i~
complete, control is r~turned to the state at which the "Primary Panel" dialog was interrupted.

Each data entry or selection ~ield on any panel can haYe an associated "help" panel. Additionally, the panel itself has a "help" panel. Invoking ~'help" from th~ primary panel result~ in ~leld level help, i~ available, otherw~se pa~el-lev~l h~lp (otherwi~e, help on the help ~y6tem). once within help, ther ig a de~ined set of hPlp actions (e.g., func~ion key6) which provide ad~itional in~ormation about applicakion keys, index to help documen~atlon, (glossary~
help on "selection"-~ype ~ields within the ~elp panel, etc.

Informakion displayed w~thin help panel~ are obtained ~rom a documen~ation ~yst~m. Ths ~ocumentatio~ BySt~m organize~ indexes docum~nt~ by report.generation.chapter.sec~ion.page. The ~ollowing convent~ons are used ~o as~ign document E.ection~ to help ~unctions:

- R~POR~.GENE~ATION. For a given comblnatlon o~
natlonal lanyuage and tranE.action, ~h~re iæ a single "repoxt.gen~ration" which include~ all application h~lp information. ~ lp functions ~ay al~o in~oke the g~neral DA~
h~lp in~ormation, which is located on report=~AAHELP
generatio~=(language code).

- SECTION. For panel help information~ the section nam~d "S00~' is reserved for extende~ help information (gen~ral inform~tion about the panel). A11 othar ~ctions are the n~me o~ a data entry "field" or a choice f'ield mnemonic app~aring on the panel.

i' ' ., ~. . 1 .'~" .1 '. ' . ' ' i .. , .: ' ' .' '~', ' ' , . ' , ' . " ' , . ., . , , ' . ' ' '. . . ~ . ' ' ` ' ' ' ~ ~ ~ " ~ rl ~

- C~PT~R. The chapter named lii;,LOSS~RY" i~ reserved f~r the followiny help functions:

- KEYS. This is a sPction which describes each key u5ii~
by the application and its function. The listing doe~ not havQ to indicate which keyE3 are val id in the current ~tat2 o~ the application.

- CONTENTS. This is a sectioIl which is ali50 a kable of content~ of help in~ormatlon, organ$zed by topic.

- HELP. (Only on DA~HELP~. Contai~s ~Help on Help~' inIorxnation .

The chapter named ~I~ESS~GE~ iB rQ~erved for help on ~rror mei3i~agei3 ( 1 . ~ ., detailed desrriptiQn o~ i~ach mei3~3agiEI
generated ~y t~e applic atlon procei~ur s) . ~he ~ec~ions wlthin the chapter correiapond to the mes~age identi~ier code .

All other chap~er~ are the same as panel nameE~ and Z con~ain in~ormation specif ic to panels . The help panel~
the~selvea are documerlted on D~}IELP~

Help i~ availabli at all times. A~railability of help information ~or elVQ:l~T application panel i~ validated, by 3 G~D, when the transaction is built.

Within the help ~ialog, ~very help pan01 (wi~h the `! exception of Ex~ended Help panels) providi~ ~unc~iorl key acce~e to Extended HelpO The title of hslp pan~1~ contain the word "~elp'3 and identi~y the pan~l or field to which it appl ies .

Th~ inYoc:ation o~ help is transparent to the application '''; ' ', ' ' ',. " ; ". : ,, ' ", ' ;.,', ' '~ ' ' ' ~ '' ' ' ' ' ' - ;, ''.. ' . , ., . ' ' ' , ,' ' ;' ,, .. , , . . ; , . . .' ' . ' ' .,,, ~ ' ' . '. "' . ': ' l ' ,. :

procedure and doe~ not interfere with the current dialog.
Data that user had entered before requesting h~lp i~ saved i~ the user' 5 pro~ile~

The types of help panels are-HELP. The Help action provides cont~xtual help about a~pecific field, a panel, or a~out the help facility. Field help is provided if ~he cursor is on an entry field or a menu choicQ ~iled. Panel help is pro~id~d ~known as "extended helpl') if th cur~or i6 not on an entry field nor a menu choice ~ield. Pancl help i~ also provided i~ ~leld help i~ not d~ined ~or the ~leld. Help ~acillty help i3 provided which ~E~P ~ regue~tad from a help panel. The help ~acility help 1~ also provided i~ the panel help i~ ~ot deI ined O

EXT~NDED HELPO When UB13r'~ r~que~t Ex~rENl~ED HE~P, ~ halp panel appear~ containing information abou~ the curren~ panel rather khan a particular slem6~nt on the parlel. I~he ~XTEND~D
HELP action option appears only in help parlel~.

HELP CONTENTS. When user~ rl~quest help contents, a table o~ co~tent~ appear~, organizsld by topic, o~ all the h~lp inormation in the application. The HELP CONT~NTS
action option appears only in help panels.

HELP I~DEX. When users request help index, an index of the help infQrmation appear~, The help index action option appear~ only in help panels. The HELP XNDEX i~ in the form of a menu oP options which provide the user acce s to the s~ctions of help.

KEYS HELP~ ~hen users re~uest key help, ~ t appears containing ~he names and ~un tions o~ all keys used by the application. The key6 help action optlon appear~ only in .,, . - , , . ............... , :. . . i :, -,.: . ,. , . , ~ ., .

2~i~.. .` u ~

help panels.

ENDING HELP. Uss3ræ end help by regu~sting Exit or by repeatedly requ~ting Cancel to back out of any help panel.

Whlle usere are navigating through ~e~sion~, tran~action6, and panels, information is r~tained in the pro~ile data ba e ~ The applicatis: n d~t~rmines how much infonnation iE~ actually r2tained ( i . e ., the proi~ile view) on the profile data bas~. The application al o determine3, within a tran~action, the hi,orar::hical relat~ on~hip between pan~ls within a dialog, and conssguentl y the flexlbility o~
th0 uaer to naYlga~e b~tweerl panel~; within a tran~aotion.

onc:e a panel is carlcelled, a transaction exited, or a se~sion ~it, th~ formakion i~ not available.
~lkernatlv~ly, th~ l'suspendl1 exi~ can be uE~ad to ~ave ~he aurrent ln~ormation/state o~ a ~3es~1 c\n, which en~bl~
reactiYation o~ the ~ess:i on, without data los~3, at any later tlme .
.
A con~i~tent u~r inter~ace imple~entation on DA~ i~
~ enabl~d ~rom definlkions made by 1:he application designer i u~i~g GT~. GTD pxovide~ the de~igner with option~ to ds~i~e ~ panel~ and l~plicltly de~ine dialogs. At ex~rution ti~e ths i dialog ~anagement f~nc~ion (IET, TMS, ~c.), which iR
3 isolated ~rom the application code, implements user-driven 1 navigatlon action~, en~uring a consistent u8~r inter~ace acro~s all D~A applicatio~

COOPE~A~IV~ PRCCE8~G. Explicit cooperative proces~ing ¦ between DAA application procedures is implemented via "LINK"/"RETURN". The mechanics of supporting LINK/RETURN, a~ well as ~upport of g~neralized terminal/transaction data int~rahange, i~ provided by Distribu~ed Resource Control service~ within DAA.

.,.:. . . ~ .. . . .

} ~ r1 Any DAA procedurQ can executa any other DAA proc~dure.
The mechanism for execu~ing a DAA procedure is the same whether it is packaged in the sam~ transaction or a different transac~ion, loca~ed on the ~ame or diffPrent sy~tem~ located on the same or architecturally different typ~ of proce~sor, or loc~ted on the same t~pe of tran~action proc~ing monitor or a diffçrent (DAA
supported~ transaction proces~ing monitor~

Tha 6y~tem re~uira~ that th~ develop~r ha~ dsfin d a : unique system.~ransac~ion.procedura name or both the called and the calling procsdure~0 ~hi~ enabl~ th~ sy~te~ to accurat~ly deliver any m~ssages be~ween variou~ machine~
After sa~iny a current tate of a calling procedure a3 a profile view, and ~torlng it in a pro~ile data ba~e, the IET
extract~ data items ~ro~ th~ calling tran~action view and pla~ them in an input view ~o be ~hlpped to th~ call~d procedure. The IET packayes the e dita item~, together with the unique called procedure 1 5 name and the uni~u~ calling i procedure's name and snds the packet to the called procedure. At the called procedure, th~ IET loads th~
~¦ called procedure 1 6 pro~ile ~iew and the input view receiv~d from the calling pro~edure. The called procedura execute~
, the reguested procedureO Th~ IET then extracts the data ¦ items Prom the called transackion vi~ew and places th~m in an output vlew to be returned to th~ calling ~rocedure. The i IE~ package. ~hese data items, together with the unique called procedure's name and the unique calling pxocedure's ~ name and return~ th~ packet to the calling procedure. The i IET at the calling procedure ex~rac~s the profile view stored in khe profile data ba~e and loads lt/ together with th~ returned output view into the calling procedure's tran~ctlon view. At this point th~ pxocedure is restarted for ~urther proces~ing.

.. ~ . , , . . . .; . . .

... , : . . . .. . .. , ,.: : .. .. ..
.,- ~ . . , . :
: :: :. .. : . , The specification for remote procedure execution is made as follows:

Application procedure in::ludes logic to s~t 'lexit state 1, - Dialog ~low speci:eication. A~ a function of l'exit state", de~ine a flow ~o a proc2dureO The flow can be a LINK, XFER, or SPAWN.

Thl~ ~tructuxed approach ~o pQcifica~ on Oæ procedure execution i~; intended to isolat~ the application logic a~
much as po~ ible ~ro~ the mechanics of dlalog flow.

There are situations in which it is nece6sary ~o ~leotiv~ly ~scecutQ a specific proc~d~ar~a on ons o~ many sy~tems. Th~ logic required to malce the det~r~lnation oî
which ~y~k~m s~ould be us d to ~xecut~ a procedur~ i5 application-depsndent. The appli~a~ion ha~ two ~y~tem variable~ which it can UBe to ~at the ~yste~/transaction ~or a procedure: NSYSTEM (next ~ystem) and NTRAN (n~xt tran~action).

Dials~g flow is controlled by co~mands which may originate from th~ appllca~io~ proceldure (ae~ exit ~tates~ or ~xola the Us~r. Us@r c:ommands are entered via action re~est~ (e,.g,, function keye, action bar-pull down rhoice 6election~, or conmand~3 en~cexed in ~he command araa). Mo~3t u~er commands are processed directly by IET, as de~in~d in t~he ~eotion on "consiætent user int2rface"0 The following commaxlds may originate ~rom the appllcation procedure:

T~i~ conmand save~; th~ currerlt s tate of the procedure ~ust c:ompleted on the profile stack and '` ' ' ' ' :''' ' " '"'-' , ' ,. ,' " :' ' ~xecutes an application procedure which may be in the same or a different transaction, located on the same or different system. The next procedure to be executed i5 specified in ~he working storagç data item 'INPROC''; the next transaction i5 in "NTRANi'; and the next system i~
in "NSYSTEM". The value o~ the sy~tem and transaction data items ars inkerpreted according to the rules ~or DRC (Distributed Resource Control). The nPxt proc~dure is passed in~ormation via an IMPORT view. The LINK
process is described more completely later.

RE~ hi~ command restores, from the user~æe~6ion profile, the previous state of th~ DAA
session thread, returning control to an applic~tion procedure which previou~ly requested a 19LINKllo The proc~dure to which control i~ being x~tur~d i~ pas~ed in~ormation via an export vi~w.

2FER. Thl~ command ~ran6~er~ con~rol to another application procedure. The ~pecification o~ procedure iB the sama a~ ~or LINK. Unlike ~INK, whlch re~ults in "stacking" the proflle view (and in~orm~tion/inpu~
views3, the XF~R co~mand re~ults in di~carding the entire ~tack prior to executing the pro~edure.
Con~guently, the new procedure i~ at the top o~ the stack~ XFER is similar in effeck to ar.
"Exit_applicat~on'~ ~ollowed by a LINK, with the additional fea~ur~ ~ha~ a vi~w 1~ communicated ~o the new procedure. A RE~URN ~rom th~ new prccedure result~
in xeturning control to the Session Manager.

(bl~k~ o This i~ the default exit state. It result in the display o~ the panel associatsd with the procedure.

,`" : " , ' ', ', . ' '.' '' ' ' . ' . . ' ' ' ' :. .' ' . j' , "' ~,, ' "' ', "' ' .,' ', ' .

J

~J

Figure 15 shows a model of DAA dialog ~low. The mod~1 combinez "consisten~ user interface" de~inltions with programmable dialog ~low co~ands, and is ~ explanatory, At exe~ution time, an application proc~dure set~ an exit state which is interpreted by IET as a dialog ~low request~
Ths dialog flow may ~peciy a LINK to a epecific: PROC:$DURE
(optionally quali~ied by transaction and system). The "to"
proc:edure of the ~low has a~so~iat~d with it an ext~rnal Import and Export view.

The r~lationships b~tween DA~ appli::ation proc:edure~, working storaS~6~, import view~, and ~xport vi0w~ ar~ ~hown in Figur2 16. Pro~sdure ~ 184 will be a part o~ the transacti on requesting procedure Z 196 to b~ executed uE~ing data from procedure Y 1 4~ The portion~ o~ Figu 16 de~ig~at~d 178, 1~2 ar~ und~r applicatioIl control, albeit possibly Reparate applicationE~. The middle port~ion, 180, i~
under IET (part o~ pref~3rred eml)odim~ t o~ the pre~ant inv~ntion, DAA) control.

Initially transaction Y ' s workln5~ ~torage 186 is mapped to procedur~ Z ' E~ import view 188 . The i~port view 188 i ~
than ~;ent to the IET in the ~'to" load module ~not spec:i~ically 6howrl~ contalning procedur. Z 196. IET, in this modul~; maps the import view 18~ into the transaction Z
working storage 194. ~ this point, procedure Z 196 is executed. Procedure Z 196 may call upon other proc~dur~3 and/or in~erac~iorls with o~her entitie~ ( such as the originating ~erminal~ b~fore requesting a ~ETURN. IET, in the 1 :7ad module~, m~p~ transaction Z ' ~ working ~torage 194 into procedure Z ' 5 export view 190 . Next, the export view 190 i~ sent to IET in the "from" load module (also not specl~ically shown)O IET, in this load module, then map~;
the Pxpor~ view 190 into transac~ion Y ' ~ working storag~
1860 Lastly/ procedur~ Y 184 is executed.

., .: . , ,; ,, : , . ., ~,. . : : .: . . .. :.

:.: . . ............. ,:: : . ......... : . : : : . .
,::: : . . . . - , : . .. ., . ,, , .,., " :: , . , : : : , . , .. : ; :; . : :

Y .~

J ~ ~ ~ J .~

Communica~lons between ~ransactions consist o~ messayes having th~ following information: transaction id~nti~ier, interfac~ control block; and a view~

The usual transac~ion identi~i~rs ar~

command - Thi~ data item indicates, generically, what type of message i~ being rec~ived. It may have one o~ the Xollowing Yalues:

-IETCONT. Indicates that this i~ a DA~ tran6action communication~ control function. This ~unctl on can not be enter~d manually, it can only be created ae a result o~ an application procedure ~or IET~ requeeting a LINK, XFER, ~ETURN, or SPAWN.

-~ESET Indicate~ that the 7'con~ist~t u~r inter~ace" RESET function i~ ~o be per~ormed ~or the indicated transaction. This c:ommand may be entered manual~y. ~ny data ~ollowing ~h~: command is ignored.

=QUIT Indicates that t:he "consistent~l user intQr~ace" QUIT ~unction is to be per~ormed for the indicat~d transaction. Thi~ e~s~mand may ba ent~r~d manually. ~ny da~a following the command is ignored.

~ ny other value for th~ co~and data item cau~ea a me~age inte~pretation to be attempted as if the message had originat~d from a terminalO

The int~rface control block is a (~ixed ~tructure, ~he sa~e for all DAA transac~ions. Within th~ interface control block, the parameter IETICC is ~or dlalog control and may as~me one of ~h~ following value~:

, . , : .: . . . . : ~ .. , .: .

, , . .. . .. , . :: ~: . :
.,~ , . . ~, . . .....
~: . : . . .. .. ,,, ,, , :

#&LIMK&~ LXNK co~mand.

#&RETN~# RETURN command.

#&XFER&# XF~R command.

The View contained in inter-transactional communication is an import view if the command is LINK, XFER, or SPAWN, or is an export view if the command is RETURN.

DI8TR~B~D ~EROU~CE CO~O~. DRC generallzes the concept of re~ourc~s and u~es an archltectur~ ~SNADS~ which de~inea u~ o~ de~ault~ and redlrecting to avoid th~
neces~ity of universal distribution. In genaral, the DRC
local data bases are ~or local use only and do not require any data exchange with other systems. The "learning"
function o~ ~he DRC ViPw Distribu~ion 5ervice ~view ~erv r) make~ ad~u6tments, as neces~ary, to re~erence~ o~ ext~rnal re~ources in ord~r to optimize use o~ the co~munication~
Sy8te2110 A DAA re~ource i~ an addr~ssabla entity which can orginate or receive in~ormation di~tribu~ione. Exampla~ of resource~ include t~rminals and transa~tion~.

Entitie~ may be defined for the purpo~e of normalizing resour~e dPfinitions. An example of this type of entity is DEVICE, w~ich is used to normalize ~he ~E~MINAL resource.
The ent~ty DEVICF. i~ deflned a~ a reiource, even thouyh it is not used as a distribution originator or receiv~r.

DAA addre~ses re60urc~ with a combination of ~ystem iden~i~ier and reisource identifier. The set o~ all system~
and reR~urce~ with~n systems is termi~d the DAÆ environ~ent.
~ach uni~ue instancie of a DA~ environmient has an identif~er (DAA_idj.
TI-13766~73 ; ~ - : .. . : . ": ~ . !` .
., , - , . . . . .
. ~ . . . . . .
~ ~ . ~ . .. ' ' ' . , ' ' . . " ' , , DAA resources are distributed acrQss a heterogenous mixture of sy~tems, ne~work services, terminal/devica type~, applications/ Operating Systems, transact1on management systems, and CPUs. The ~ollowing section describ~s how DAA
manages its resources within its environmen~.

A system is used to identify the location o~ resources.
A system ha~ the following characteri~tics: a homogeneous application processing environment, and an uniquely identi~i~d node within an SNA network.

In particular, a system has a ~ingle, uniquely identi~ied, transaction proc~ss$ng monitor ~e.g., I~S, Tuxedo~. The system may csnsist of multipls CPUs and/or operating syst:ems (if the transaction proces~ing monitor ~upport~ it). There may be more than one system on a CPU.
The system mus~ be uniquely identi~iable on the SNA network for a specific D~A environment.

Re~ource~ exist within the context o~ a ~ystem. Within a syskem, resources must be unigue'Ly identified (even if they are different types, such a~ t~ansactions and terminal~). Th~ re~ource txpe is an attribute o local re~ource~ (i.e., no~ part o~ the unlqu0 identifier/~ddrQs~
o~ the resource).

Resouroes ~e.g., terminal ~nd tr~nsac~ions) wi~hin DAA
arei addressed by the combination of system and resource~within-~ystem. I~ the system portion of the resourcE addres~ is specified, a di~tribution to the re60urcs u~es "dir~cted" routing. If th~ ~yste~ portion i8 not spe~i~ied, then the system is defaulted according to rules ~or "undireic~ed'l rou~ings.

Resource identifiers may be reused on other systems for ,, . . ,, ~ - , . , : . . . :

: . : : .: , . , .,. :: . ::., ., " :: . . ~ , . , . . ~: : . . . . . : .
.^ . . : : : : ~ . : : : . :
: ~ ;. . .: : : , . : : ~ . :

di~Prent resource instances, including differenk resourc2 types. For this re~son, it is recommended that directed routing (i.e., inclusion of syst:em_id) be used, where possible, for information distributions.

A transaction is the controlled use of a collection of resources to perform a business Application function. The integrity of resourc~s (e.g., data bases) are maintained per logical transaction. In DAA, a logical transact10n mu~t be contained within a single execution of a physical DAA
transac~lon on a ~ingle system.

Transaction~ can remotely ~xPcute oth0r transaction/procedures~ Data exchange with ths remot~ly executed tranæac~ion is defined via input~output views. A
transaction procedurç 6peci~ies remote procedure execution via a LINK co~mand, passing an INPUT viPw. When ths remot~
procedure is complete, it performs a RETURN co~mand, pa~si~g an OUTPUT Yiew back to the originating tranaaction.

Tran6action~ mus~ have a unique resource ldentlfiar within a ~ystem. The s~me transaction resourca id can be used for different purpo~es on a di~ferent system.
~herefore, it i~ recommended that referenc~s to transactions on xemote sy~t~s include the remota ystem identifier.

Transactions are resources which ~re tightly controlled and totally integrated into the DAA envixon~ent. Utilities (GTD) exi~t for automatiny the construction of transactions.
A runti~e ~nviro~ment envelop~ the applica~ion transaction, providing DAA services transparent to the application code.

~ terminal is a collection o~ re~ources which are used to interface to a user. A terminal normally consists of a VDU output device, and some combination o~
keyboard/program/voiceJbar code/mouse input. Other terminal :,; . - .. . . . . , : ,. , . ., - - :

.: . : . . - -. ,: . - . , ~

: ~ . . . . . - . . . .

~: E~

t.~J ~J~

configurations are possible.

Co~munications with a terminal i8 via 3270 data stream protocol, which supports a wide variety o~ output and input devices. Each device supported has a set o~ ~unctional characteristics which represent a subset of the total 3270 data stream protocol. In order to as~ure meaningful output to a given device, the 3270 data stream gPnerator (TMS) must know the generic device type of the termlna~.

Like tran6action~, a terminal ~u~t have a unique re~ource id~ntiflQr within a ~y~tem. A terminal resourc~
identiier can be re-used on a dif~erent ~ystem~ It ia reco~mended that remote terminal~ be ~dentified u~ing both system id and terminal id.

In order to normalize the de~lnition o~ TERMINAL
re~ourcea, an entity type DBVICE has been eatabll~hed which containa the devic~ attributes relat~d to a given ter~inal.
Th~ DEYICE - TER~INAL relatiQn~hip can be pictured a~.

Communication networks are not a (vi~ible~ component o~
D~Ao The mechanics o~ network operation i~ totally transparent to DAA application~. A multl-sy6t~m DAA
application may associate system identi~i~rs with remote transactions, but does not need to comprs~end the path between a local system a~d remote system. All t~rminal interface ~unctions ar~ ha~dled by TMS/IET (transparent to D~A application procedures), which comprehends terminal dev~ce typefi and system location.

Tha data exchange between SYSTEMs within a DAA
environment is implemented utilizing Syst~m Network Archltecture Distribution Services (SNADS).

The communications syst~m capabilities implemented ~: , . - .. , ,, ,, , : : ... :. , , '1:: :.. , ~ ,. . ., .- . :, . , .. :, : , :.

,, : . .: . . ,: . . - . :,,: : ; . ~ ., . .: ., . . : , : . . . ~: -. : , . .

withirl SNAD5 and other DRC components include~

(Dynamic) path determination and optimization.

Store and f orward queues at intermediake nodes .

(Automat~d) maintenance and diskribution o~ topology data bases.

Data exchange ba~ed on SYSTE~q identl~ier only ( i . ~ ., no knowledge re~uired o~ intermediate nodeE~).

Sel~-learning for routing to 3'new" y3tem8 and resource~ .

- Noti~ication to re~uestor if reque~t no1: completed.

'rhe DRC communication~ ~ystem does not require any ln~ormation ~ro~ ~he appli~atiorl other than ~y~te~ ld (which ie optional ~ and re~ource ~lem~rlt id .

The local data base maintenanc~ r~quirements are minimized through uqe of defaults and automated ~'learning'l.
3 ExtensiY~ administrative functions are a~railable to track data di~tribu~ions ~nd dispogition unserviced diitribution reques~

DAA will dynamically update xesource routing table~i to correct or re~olve "Destination ~ervice Un~ti" for any given i resvurce. Thl~ function i~ built into the DRC ~iew } Dis~ri~u~ion ServiceO

'I
:I The pre~erred embodiment of the inter~relationships , betwe~.n varioui components u~ed to implement DRC accordi~g to the pres~nk lnvention are shown in Figure 17. The portion of Fi~ure 17 designated 184 is located in transaction i I ~

:: , . , . ., . ;., , , , ~ . . . .
,.~: . . . , , .; i . , . ~ .. , " .... .. . . . . .. . .

procQ~lng addre3~ ~pace and that por~ion designated 186 resides in IEC address space. As can be sePn the DRC View Distrlbution Service~ (or view serv~r for ~hort) inter~ac~s hetween the defined SNADS protocol boundary and a DAA
transaction represented by IET.

Data exchange be~ween transactions is driven by LINK and RETURN commandi issued by DAA application transactions. The logical ~low of control and data associated with the LINK/RETURN implementation is shown in Figure 18. The following paragraph~ outline the rol ~ o~ di~trlbution betw~en application kr~n~a~tion origlnator 190 o~
orlgln~tlny ay~m 187 and appllc~tion transactlon recelYer 202 o~ receiviny system 188.

An applicatlon procedure within a tr n~action 190 initiatQ~ a data exchange with a remot~ transactlon 202 by i~sulng a LINK command and speci~ying an INPUT view (not ~hown) which is to be communicated to a remote SYSTEM/TRANSACTION 88. IET (ln the tran~actlon addre~
pace) save~ th~ INPU~ view (and, transparent to application, an INTERF~CE view) on the transaction P~OFI~E
data ba~e. The view on this PROFILE data base i~ refere~ced a~ a view r21ative ~o top o~ ack for a par~icular combination o~ USE~ and ~PPLICATION. IET initiateR th~
distribution of the vi~ws by passing the ~INK command to the View Servsr 194 (along wi~ the U~er and Application identi~iers ) ~

The VIEW server 194 accep~ the LINK command, along wi~h it~ par~meters, and processe~ the reque~t asynchronously to IET twh$ch exits). The VIEW ~erver 194 use~ the PROFILE DB
192 as the "queue" of data which is to be sent via SNADS.
SNADS operate~ as an intermediat~ system routing. In the profile VIEW ~not shown) is an identific~tion o~ de6tination system 1 8~ Based on th~ tra~egy de~in~d within SNADS 196, : ' ' ;"' '~ ~.',.: ', ' .
, ~ : .':', -tha distribution (view) is sent to the d~s~ination system 188. If the remote ~ransaction execution complstPs successfully, a returned OUTPUT VIEW will (eventually) be received. The V~EW server 194 receives the VIEW, puts the VIEW to the PROFILE DB 192, and queue~ the TRANSACTION to run und~r the local transaction proce~sing monltQr.

The VIEW size is restricted only by thQ VI~W size allowed o~ the PROFIT.~. DB 192 (2 gigabyte). The APPLI~ATION
i~ not required to block/de-block data exchanges having large byke counts. Furthermore, there is only one T~ANSACTION execution per logical data exchange.

The view ~erver 200 (on the des~ination system) receives the INPUT VIEW (also not shown) , puts it immediately on the RROFILE DB 198 , ~nd queue~ the TRANSACTION ~o r~m under the local transactlon proces~ing monitor. The TP Distributor ~e.rves a~ the inter~ace batwe0n DRCVDS 200 (view distribution service) and the Tran~action Proce sing Monitor. In the case o~ IMS, thi~ progr~m ~ a continuously running B~P. In ~h~ cas~ of a UNXX ~P, ~he ~P ~l~tributor is a function embedded in DRCV~S. I~ T ~ SACTION doe~ no exist, then a return OUrPUT view i8 con~tructed with suitable co~pletion codes and sent k,ack to the application 'tran~action originator 190.

Non~existent remote re~ources, and oth~r typ~s of di~tribu~ion errors, are repor~ed ~rom either ~he remo~e VIEW ~erver 200 or SN~S 196 . The local view ~erv~r 194 will rece~v~ these distribution exception~ and propogat~
them to th~ distribution originator 190 (i.e., a DAA
tiransaction). The results of completed remote transaction 202 may be returned, wh n view server 200 accepts a RETURN
command, along with its param~ters, and th~ whole previo~s process reverses. The OUTPUT VIEW travels back to SNADS 196 routed for system 137. View server 194 receives the VlEW, '.,, . ~:: - : ' ~ - ' ' ' , - : ~ :
.. :.............. - ~:, .
' ~ ' ' ' :" '', ' " ~ ' ' , ' put~ it ints the P~OFILE DB 192, and queues the TR~NSACTIOM
to run loca].ly.

All local terminals on a system are id~ntified aR
resources. Each t~minal has a specific set of devic~
characteris~ics. These device charact2ristics are required by TMS in order to properly construct 3270 data streams deskined for the te~minal. Unless th~ t~rminal is local, the device charactPri~tics are ~ot available through the local re-~ource directory. Support o~ remote terminals i~
further complicated by ~he inability o~ a tran~action proce~sing monitor to route data to terminals outside o~ it~
environment.

The logical ~low of control and data associated with data inter hange between ter~inal6 and tran~actions ar~
shown in Figure 19. A terminal fir~t conver6e~ with a DAA
transactio~ 20~ on ~he local y tem. I~ thi~ tran~actlon per~orms a LIN~, th0 terminal devire attribute~ are pas~ed to the remote ~ystem along with the u ~r-specifi~d INPU~
view~ When the remote transaction reque~t6 di6tribution of a 3270 data stream to th~ terminal, DA~ ma3t~r menu r~mote switah recognize6 that it i~ a non-lclcal t~rmi~al and i~ue~
a ~NK to ~he DAA pseu~o-transaction i'TERMIN~L" 210 (which i~ implemen~ed wlthin th~ ~P Di~tribu~or progxam3.

The TP Diatributor 210 receives the 3270 data stream (~
it~ INPUT view) and ~orward~ it through the local transact~on pxocessing monitor 212 to th~i terminal 216.
Daka entry from the terminal 216 i~ routed through the TP
Collector 218 twhich may require a JS~T T~AN on I~S). The TP Collector 218 pa~ses the 3270 data ~tream through (via RETURN) to the re~ote transaction. It is tran~parent to the DAA application whether the terminal 216 is local sr remote.

If th2 re~ote tran~action is~ua6 ~urther ~INRs, the ',;' :" ` ' ' ' " , . . . " '' ' ~ ' ' , ' ' ', ~ .: ' '; ' ,, ': ~ ' : ' ' . ' ~- ~
~ P~ ~, t, ~ ~ 3 terminal attxibutes are forwarded to the next (nested) DAA
transaction. ~ultiple R~TURN will ultim~tely RETURN to the terminal's owning system.

Part of the interface view associated with the LI~K
contains th~ TERMINAL id, the terminal's SYSTEM id, and the terminal~s generic device type. Thi~ information i~ u~ed in any LINKed transaction, and will be propogated to other LINKed transaction6. In DA~, only local transaction~ can be executed without a LINK. Local transaction~ obtain terminal charaat~ristlc~ directly from the lo~al resourca directory tS~ADS data ba~e).

TRANSACTION~ send data to term~nals via the YIEW ~erver.
~ tran~action generate~ ar~i~rary leng~h 3~70 da~a 6treams u8ing T~S (and GDD~ ha~e data stream~ are queued to the PROFILE data base. A rsque~t from th~ tran~action to the VIEW ~erver i.nltiatea the tran~fer of queued 3270 dat~
~kreamE~ to a TERMINAI.. If thQ texminal iB local, the data iiskr~am i~ inserted dire tly to the local trarl~action proces~ing monitor. In all o~h~r c:a~e~3, the ~u~u~d 3~70 d2~ta str~am is transmittad to a view ser~er at a remote sy~t~sm. The mechanism is identical to th~ proce~ $ng of I~PUT/OUTPUT view~;, but the INT~RFACE view i~ constructed aul:omatis:ally by the VIEW eerver and ~.ontaîns a pseudootrallsaction identiIier o~ '~TE~MINAL". The pselldo-~raniisaction "TER~qINAL" is implemented as a func:tion buil~ into thç~ view ~ r (it inserts the 3270 data stream to the local transaction proce sing monitor).

In the ca~ie of ur~solicited output to remote terminals, 3270 data streams must be created for a terminal with wlknown device attribu es. In this case, TMS generates a 3270 data stream for ~he most capa3~le device. Wherl the data stream is processed by the "TE~MINALI' kransac~icn, it is passed through a fil~r which strip~ or convert3 control , - , : :. : : . ~ . . . -. .
; . ... . , . . . . ;
. , . :
: ' .
.,: , .

2 d~,~," ,~

sequencss ~nown ~o be illsgal for the deviceO

DRCYDB - YIEW DI~TRIBUTION ~E~ICE~. DRCVDS is the Distributed Resource Con~rol View Distribution 5ervices, also referred to as the View server. The VIEW server combines the functions of pro~ile managemen~, distribution service~, and resource management (includin~ TP
monitor-centrolled tran~actions an~ terminals~ into a singlP
interface for DAA transactions (via IET). View distribution i8 implemen~ed by rombining the distribution services of SNADS with the view s~orage and xetrieval functions o~ tha pro~ile manag~ment data base.

The vl~w ~erver does not have it~ own data baBe; it use5 the SNADS data base ~or resource control information and the ~rofile manage~en~ da~a ba~e ~u~er and roll file~) for view ~toragQ and retrleval.

The view server acts a6 the in~er~c~ be~we~n application transact~on~ and the op~r~tions functlon~ Or SNADS. The view ~rver augmQnt~ SNAD5 b~ dynamlcally ~eding back "learned" in~ormatio~ about u~er~ (l.e., r~ourcQ~). Thi~ ~ee~back is in~ended to improve network re~ource utilization, performanc~, arld r~spon#e time3. This feedback featurs will be ~OB. e~fec~tive when Rufficiently detailed roUting tables are construct:~d at ~ach DSU~7.

The view ~rver di~patches distribution in~ormatlon to local re~ource~, The resource types curren~ly recognized by the dispatching function include device, terminal, and traneaction. Th~ lis~ of supported resources is easily extend~d, with the only software impact being the logic xequired to service a specific local-delivery queue. Each resource is genQrally associated with ~upport o~ a DA~
concep~ or capabili~y. As new concepts are added to DAA, the VIEW server will be extended with explicit support for r~

the ~ociated new resource ~roups.

Each re~ource is identified as b~ing local or non local.
Each local resourse has a local-delivery queue. The name of the local-delivery queue corresponds to the r~source type (and consequently to the dispatching logic used to service the local-delivery queue). The name of local-deliv~ry quQue must be explici~ly recognized by the view di~tribution service as a supported resource type.

Each local re~ource h~ a s~curity code. Thi~ code may b~ u~d by the re~ource-~peci~ic di~patchPr to disable di~tribution~ of ~ecur~ data to un~ecured r2~0urce~.

Re~ource ma~ have additional re ource type dependent attribut~sO These attributes are normally only used ~or local ~-es~urce~. When re~uire~ by remo~Q ~ransac~ions, the~e attribu~es are normally pas ed with the inter~ace view accompanying a LINK function (this is the ~echnique ~or di~tributing terminal/device attributes to a remote txan~action).

Transactions are dispatched by inserting the appropriate portion of the distributlon in~ormation unlts to the local ~ran~ac~ion procesæing moni~or ~.e.g., IMS, TUXED0). The concept o~ "local'l varie~ according to the transaction processing monitor. For IMS with ~5C llnks, "local" can be any global I~S transaction (note that thQre i9 a limi~ on da~a l~ng~h if ~ransaction is no~ local ~o I~S system3.

Terminals ar~ dispatched by inserting the appropriate portion of the diskribution in~ormation units to the local transaction processing monitor (e.g., IMS, TUXED0). The concept o~ "local" varies according to the transaction processing monitor. For I~S with MSC links, 'llocal" can be any global I~S lterm. A physical terminal may bei identified .,: .,~ . . ~ . ~ . - . :

~ g~
2 ~

as multiple logical terminal~, each (possibly) with dif~erent devic~ types and associated with dii~ferent host systems~ Each logical terminal can appear ts~ the user as a window at hi~ physical terminal.

Device i8 Zl resource type which doe~ not ~upport dispatching. ~evices are presenk as resources ~or the sole purpo~e o~ normalizing TERMINAL attributes~ Any ~tt~mpt to dispatch to a device will result in a distribution er:ror.

DEVICE re~ourc~ in~s~rmation characterlzes a deYlcQ type, includlng its generic device type name ~ devica attribute~
~upportedl and size o~ display. The DEYICE tabl2 1~
assummed to be identical acros~ the natwork (and infrequently cha~ged). The table i~ impleIRented as a resource table with local entrie~ only. The in~ rmation in the DEYICE table may be used to di6patch TERIIINAL
di~tribu~ion, in par~icular if a 3270 ~a~a s~ream Iilter is required becausl3 the originator did not ~ow the local terminal ~ s device attributes.

I

T~NSACTION DEF:[N:I:TION :E'IL:E~
Before considering the GTD in detail, one aspect of its input and storage, the use of a Transaction Definition File (TDF), should be considered further. Prior to the DAA o~
the present invention and its transaction generator program, GT~, a programmer was required to provide his own job decks to compile all the appropriate procedure~ and screen maps.
On a 370 mainframe this could consist of several JCL decks or TSO clists. On UNIX a programmer would have a make file containing ins~ructions on compiling and linking all the correck parts.

With GTD, a programmer never needs to build such files because GTD builds and maintains the TDF. This TDF is an integral part of GTD which contains all of the information necessary to compile and link all the correct components of a given DAA transaction. The programmer simply uses GTD's menus and screens to add and delete the appropriate components; GTD files this information into the TDF.

The TDF is a file of records used by GTD as the "blueprint" for constructing a DAA transaction. The content of the TDF is created and maintained by the application daveloper using the GTD tool. The TDF is used by GTD to assist the programmer in the ~dit of his procedure code, panel maps, and menus. Once these components have been edited, the TDF is used by GTD to compile and create various object module~ii that are link-edited, along with the IET, to produce a transaction load moduleO

The TDF consists of the following types of recordso header, first header extension, second header extension, panel, procedure, menu and language. Each TDF will have only one header, first h~ader extension and second header ,~ :
i i ,,:. , , i: ,. -., . . . , . - : , ,. , ., . , -. '. . . ~ ., . . . . ~

ex~ension, in that respective order. Each TDF will also contain at least one panel, proc~dure and menu record and they will be in no particular order. The presence of language records in a TDF is optional.

Each record is of variable length. Trailing fields in a record which do not have a value will not be stored. On platforms supporting variable length record constructs, the LLZZ field is not explicitly stored as data. On other platforms, the LLZZ field is stored as data to support variable leng~h record constructs.

Below is a field level summary with each record name given, followed by the length of that record and a brie~
description of the record.

HEAD13R:
LL2Z, 4, Length o~ record.
GTDHRTYP, 1, Record type. Value should be 'H'.
GTDHMEM, 8, TDT name.
GTDHMTYP, 1, TDT type. Value should be 'D'.
GTDHDR, 8, Documentation report: name.
GTDHDG, 8, Documentation generc~tion name.
G~'DAPPL, 4, Application name.
GTDRELN, 4, Release numb~r for application.
GTDLLIB, 46, Load library path.
GTDLMEM, 8, Load library member name.
GTDOLIB, 46, Object library path.
GTDOMEM, 8, Object library member name.
GTDSLIB, 46, Source library path.
GTDCMEM, 8, Transaction view name.

- GTDDLIB, 46, ~ata base libraxy path.
GTDDMEM, 8, Data base library membDr nameO
GTDNLIB, 46, Control library pa~h.
GTDNMEM, 8, Control library member nam~.
GTDLEOPT, 50, Linkage-editor options.
GTDGOF, l, GenPration option flag. Vall1es are 'Y' and ~N~o When value is 'Y', put "OPTIOM:" field on menu, help, info, glos, and panel.
GTDGLF, l, Generation look-ahead flag. Values are ty~
and ~N'. When value is 'Y', put "LOOKAHEAD:"
field on panel.

FIRST HEADER E~TEN8ION:
LLZZ, 4, Length of record.
GTDHEXl, 2, Record type. Value should be 'HX'.
GTDHEXlN, 2, ~xtention type. Value should be a binary l.
GTDCDSNl, 46, Extra copy/header library path.
GTDCDSN2, 45, ~xtra copy/header library path.
GTDCDSN3, 46, Extra copy/headex library path.
GTDC~SN4, 46, Extra copy/headex library path.
GTDXLIB, 46, Debugger symbols.

SECOND R~AD~R EXT~N~IONs ¦ LLZZ, ~, Length oE record.
GTDHEX2, 2, Record type. Valule should be 'HX'.
G~DHEX2N, 2, Extension type. Value should be a binary 2.
GTDLDSNl, 46, Extra load library path.
GTDLDSN2, 46, Extra load library path.
GTDLDSN3, 46, Ex~ra load library path.
GTDLDSN4, 46, Extra load library path.
GTDLDSN5, 46, Extra load library path.
~ GTDLDSN6, 46, Extra load library path.

P~NEh~ (one instance per panel entry) LLZZ, 4, Length of record.
STDETYP, 1, Record type. Value should be 'P'.
STDENAME, 8, Panel name.
STDESEL, 8, Unused.
STDEIPNM, 8, Input procedure name.
STDEOPNM, 8, Output procedure name.
STDEPVNM, 8, Unused.
STDEDESC, 32, Panel description.

PROCEDU~ (one instance per procedure entry) LLZZ, 4, Length of record.
STDETYP, 1, Record type. Value should be 'C'.
STDENAME, 8, Procedure name.
STDESEL, 8, Unused.
STDEIPNM, 8, Input view name.
STDEOPNM, 8, Output view name.
STDEPVNM, 8, Profile view name.
STDEDESC, 32, Procedure description.
STDERSV1, 4, Reserved space.
STDECCBM, 1, Unused.
STDECDB2, 1, Data base flag. Values are 'Y' and 'N'.
When value is 'Y', procedure has data base processsing.
STD~CXPD, 1, Debugger ~lag. Values are 'Y' and 'N'.
When value is 'Y', procedure will have debugger processing.
STDECTYP, 8, Procedure type. Valu~s are 'COB2', 'C', 'ALC', 'ENTRY', and 'EXTERN'. When value is 'COB2' the procedure is a COBOL procedure.
When value i5 t C ~, the procedure is a C
procedure. When value is 'ALC', the procedure is an assembler procedure. When value is 'ENTRY' the procedure is an entry point. When value is t EXTERN' the procedure is an external entry point.

~ . . . . , . .. . . , . I , . . . , . . , , . . , .. , . . . .. ~ . , , . ; .. . . . . .

:. . ~: ,. : . - . . . .. :

:, . - . . . , ., ., :
: ~:~ . - . ;. , .:'. ':

STDELOPT, 60, Language options.

ME~U: (one instance per menu entry) LLZZ, 4, Length of record.
STDETYP, 1, Record type. yalue should be ~E'.
STDENAME, 8, Menu name.
STDESEL, 8, Selection value for menu item.
STDEIPNM, 8, Panel name to invoke.
STDEOPNM, 8, Procedure name to invoke.
STD~PVNM, ~, Unused.
STDEDESC, 32, Menu item description. Value is used during display.

LANGUA~E: (one instance p r language entry) LLZZ, 4, Length of record.
STDETYP, 1, Record type. Value should be 'L'.
STDENAME, 8, Language name.
STDESEL, 8, Unused.
STDEIPNM, ~, Report name for documentation.
STDEOPNM, 8, Generation name for documentation.

I'I-13766 89 ... : .; . : , , . ~. . ., , ~ .. , ~EN~RAT~ T~A~8A~TION DEFINI~ION ~I~TD~.
According to the pre~erred embodiment o~ the present invention, khe Genera~ Tran~action De~inition (GTD) ~ystem is a s~mi au~omated facili~y ~or de~ining and managiny applications op~rating in a D~ envlronment. Th~ syst~m runs under TSO, UNIX and OS/2. GTD allows the d2signer to spPcify thosQ elements of a transaction t9 be included in the transaction load module, so the tran3action can be constructed and placed into operatlon within the D~
environment.

A GTD-generated ~ransac~ion in~ludes drive routines ~part o~ the IET module) that manag2 the coordin2tion o~
panel~, procedures, and views in th~ run-time P~ironment~
This ~et o~ routines int~rfaces with the Information Engineering Conkroller (IEC~ facilities installed in the run time e~virclnment to support exP-cution. ~TD supports the editing o~ th2 Tran~a~tion De~inition Tabl~ (TDTj. The TDT
contains the speci~ic relationships and the identification o~ the object~ to be managed by the transactionO

The de~igner sp~cifies the libraries or directorie~
where the generated ob~ec~s ar~ to b~ maintained~ identi~ies th~ ~pecific docum~n~ation reposi~o~y(ies) associated wi~h this transaction durlng it3 exectltion and ~peci~es the pan@ls, procedure~, an~ view~ to b~ inclu~ed within this transa~tion. MQnU ~n~ri~ assi t the u~er in the ~election o~ the runc~ions inclu~ed in thii ~ran~action.

The GTD syste~ is al80 adaptad to generate ~y~tem-providad panels; generate prototyp~ panels and procsdure~; compile TDTis, pan~ls, procedurec and view~;
bind the transaction load module; deploy homogen~ous transaction load modules; and deploy h~terogeneous transaction source.

':' ''., . ''' . . ,, : : ' :, :"' .

In the preferred embodiment, the GTD systPm interfaces with other utiliti~s such as CODESTAR and RINQ. CODESTAR, for example, supports data base BIND, panel editing and compilation, as well as source program editing and compilation. RINQ inserts the generated LOAD module alo~g with its data base references into the target system. It should be realiz~d that other comparable utilitles may be employed instead of those mentioned, and that these particular utilities are merely a matter of design choice.

To develop an application using the GTD system, the designer must allocate a set of libraries or directories to support the maintenance of the objects comprising the application. In a pre~erred embodiment of the present inven~ion, the following six libraries/directories support GTD-developed applications:

MAPLIB maintains TDTs and panels to b,e used by the application.

SRCLIB maintains source code, copy code, views, and macros to be used by the application.

OBJLIB maintai.ns intermediate object modules which result from assemblies and compiles of applicatlon objects. These objects can include ~DTs, views, and procedures.

LOADLIB maintains load modules for panels, procedures and the created program module containing the executable code for each transaction.

DBRMLI8 maintains DB2 Data ~ase Request Module (DBRM3 generated s a result of data base access calls in associated procedures (DB2 only).

:: .. , ., . . . , . :: : .; ~. ; : . .. . ~ . , i 3 t~

CNTLLIB maintains control information associated with DB2 applications (DB2 only).

It should be not~d that while slx libraries are disclosed, ln the preferred embodimPnt, more or less may be employed.
Additionally the names giv~n these libraries are a matter of design choice and the present invention should in no way be limited to these names and libraries.

Typically an application would be maintained in a set of libraries with data set name directory prefixes representing the application project. The last node would be the lihrary or directory names specified aboveO When a new TDT is being created, the designer must specify the MAPLIB containing this TDT and must supply a 1-4 character name for the TDT.

Upon initial use of a TDT name, the ~TD system will assum~ all o~ these other libraries/directories have names with the prefixes as specified ~or M~PLIB and will generate a TDT profile based on these assumptions~ The application designer is then abl~ to make adjustments to the library names in the TDT profileO Thes;e specifications will be maintained within the TDT. As the designer requires further maintenance action for this transaction, the library/directory names will be referenced and used for the requested function~.

~More speci~ically, the MAPLIB library/directory jmaintains information defining the TDTs which describe the transactions being developed, and maintains the panels (in source ~ormat~ to be used by the transactions. Each ~DT
within MAPLIB is assigned a 1-4 character name. In the pre~err2d ~mbodiment, cPrtain objects within the GTD
library/directory set are named by extending the TDT name by .;., . . ,, .. , ... ; . ~ , .......... '. .. ~.. ; ...... :-;- , :.. . ..
,, ,.. . . . ,. . . . . .
... , , . . ,., ". . ..

r~ J ); -J _i~ S J
up to four characters to define unique 8 character object nam~s.

The panels maintained within MAPLIB can be developed from "scratch7' usiny any map editor, such as the CO~ESTAR Map Editor, or may be generated by the GTD facility. The GTD
facility can generate the panels as system-provided panels (e.g., MENUs, HELP GLOSSARY and INFO panels), or as custom panels in skeleton form~ Furthermore~ panels may also he developed by copyin~ a panel similar to a desired panel, and editing the panel using a editor such as the CODESTAR
Editor.

The OBJLIBN library/directory is used by GTD as an intermediate storage for object code versions of various elements o~ the particular transaction being defined. These intermediate objects include the TDT, the view mPmber, and COBOL (or oth,er language of choice) procedures as they are compiled. This library/directory is normally transparent ko the user.

The LOADLI~ maintains the load module format objects as developed by the GTD system. In particular, it is the final repository for the load module representing the completed transaction. The load module is placed in this library/directory by the GTD `Bind Transaction' process.
Format objects are pl~ced in LOADLIB by a panel and procedur~ compiler ~such as the CODESTAR Panel and Procedure Compiler), by the &TD panel and procedure compiler, and also by the ~TD `Bind Transaction' process.

The SRC~IB retains the source information for a GTD
transaction and maintains the transaction, profile, input, and output views as source members. This source information can be COBOL, C, or Assembler source, COBOL copy code, Assembler macros, C header files, or source versions of the J. `'`~ ' ~
~ J~`l, ,,i';~
various views associated with thP transaction.

The DBRMLIB is a standard DB2 DBRM library. It is an operating system-partitioned data set used as an intermediate receiving library for the DB~Ms created by the DB2 pre-compiler. This library is required to support D~2 applications built with the GTD facility. A similar library would be needed to support other data base management architectures if a DB2 pre-compiler is not used.

Th~ CNTLLIB is a standard operating system library used to maintain control information, particularly in support of the DB2 bind process. The CNTLLIB defines the control structures of the DPRMS used for the DB2 ~ind process.

Table 1 lists the GTD Library Specifications for the S/370. It depicts the relative organization, r~cord formal, ~lock size, logical record length, moderate size and moderate number of directory blocks of the various libraries discussed above.

~` `' ' ` . . ` `' ' ' '` '.... ' ` . ,' :'. ` : . ` ' . '' . ' ~' ' ` .. I:

r . ~ ~

~, ~, , ., .J ~ ` ~J
TABLE 1. t;~irD I,IB~RY SPEt'IFICP.TlONæ FOR iS/370 ~________~_____ __~________+________+________+________~_____ LI B~RY
_______~______+_____--+--------------~-------- ----t------------------MAPLIB SRCLIB OBJLIB LOADLIB DBRMLIB CNTLLIB
_~_____+______~._____+_______+_______+________ Organization PO PO PO PC) PO PO

_~______.___________________~________________ Record Format V~i FB FB U FB FB
____ ________________________________________ Block Size6004 3120 400 19069 3120 400 ______,___ ___________________________________ Logical Record 400 80 80 256 80 80 Length------------- ~-------------~~-~~~~~~~~~~~~~~~

Moderate Size 15 120 30 60 15 5 ~3380) tracks) -----~----~-----------------------------------Moderate No.
of Directory 30 30 15 30 10 5 Blocks or~atio~ ~gineeri~g Controller ~ C~ ~upport. The I~iC is an addres~ space that interfaces with GTD-generated applic:ations t~ provide environmental control support for those applications. The IEC supports several critical functions for GTD applications, including: system name support (function 9), DAA environment definition (function 5), profile maniagement (function 7), documentation management (function 1). The function numbers for the preferred embodiment provided and referred to are strictly design choice and should in no way limit the scope of the .<.~ ,, ' ' , " ' :, ; , " ~ i, ", ,",, : ~, : .:;,:, " , .

r r present invention.

IEC system name support function enables transactions to dete~mine the name of the system on which th~ application is running. The system name is then used by the GTD
application for presenting output panels and determining whether a panel input to an application, adapted to run on multiple systems, is executing on the specified system.

If the transactions are not operating on the proper system, khe GTD runtime controller (IET~ uses the system name on the panel and the DAA environment definition, also known as the Distributed Resource Controller (D~C), to determine the system type and rollting specifications to route this transaction to the desired system. System name and type in~ormation (strictly design choice as to name of function, usually language dependent) is presented to the application vla the ~ollowing data items:

COBOL C
System Name IEF1-SYSTEM wsystem System Type IEFl-SYS'rYPE wsystype The IEC's DAA Environment Definition function specifies the environment in which GTD applications operate. It allows the user to define the characteristics of the devices included in the D~A network, to define the terminals allowed to interface with the systems within the DAA network, and to specify the systems included within the network.

A GTD application uses a function 5 request to extract data, ~uch a~ the following, from the IEC tables: device characteristics of the terminal from which an input response is received and device charac~eristics to which an output response is to be delivered~ At run time, these dynamically modifiable terminal characteristics are used to interpret an :: :: : , : . , : . . ~ . ~ : .

; . - ,. ,: , .. , :. . : :
: , . : , . .. . .. ..
,.: . . . ,: , : , , ` `' , ' :: '., : ', ,' ,: ~ ' ~ . . . . . .

r~
J _ ~ 3 incoming message from a terminal, determine the output device characteristics, and prepare an appropriate output stream.

The environment specification is extracted as the input message is received. The characteristics of the terminal at input time are determined from the IEC Table via a function 5 request. This same terminal characteristic set is used for preparation of th~ output message. This minimizes the overhead for each transaction. However, it does offer the possibility for terminal characteristics to change during the transaction execution. If the terminal characteristics change it could cause temporary anomalies, but not integrity problems~

The XEC profile management function supports the Profile Management Facility. Each transaction maintains a profile view in the IEC ROLLFILE as a scr~tch pad. The profile in~ormation is structured in the IEC address space (hereina~ter referred to as the "ROLLFILE" ) . The primary key is the user identification, while the secondary key is the application identificatlon (also known as a transaction code).

The profile information is maintained in a push-down stack within the IEC space as multiple views are created fox a given user/application. Information stored in the ROLLFILE includes: data extracted from the transaction view when a transaction procedurP is completed; any input message receiv4d by the HELP facility when a user activates the HELP
documentation; the interim HELP profile views as the application suspends execution between the viewing of pages in the HELP documentation; interface views for any appllcations invoked through distributed calls between systems.

" . . . . ,. . . , ... , ., . . . ............ .: . ., .. ,: , . .

r , ~
,.,.~
r~
Wh~n a ~ransaction procedure completes execution, the pro~ile view is extracted ~rom the transaction ~iew, and written to the profile address space in the IEC ROI,LFILE.
When a transaction input is rec~ived for a yiven user and a specified application, the profile view is extracted from the RO~FILE and is written to the transaction view. The profile view provides a transient scratch pad to save critical parameters between transaction executions for a given user/application on the specific system.

Each user may have multiple application profiles maintained within the ROLLFILE simultaneously. This collection of applications can be thought of as an electronic work desk for each given user. Each user may also have an electronic work disk active on multiple systems within the network simultaneously.

Profile management is also extended when an appli~ation invokes the H~P ~acilities. When this happens, the profile view and the input message received by the HELP facility when the user presses the Fl key are captured and saved in the R9LLFILE. The profile view and input message are restore~ when the user exits HELP. Furthermore, if the application suspends execution during the viewing of the pages within the HELP documentation, the interim HELP
profile is also maintained in the profile address space.

Profile space within the ROLLFILE is also used as a storag2 mechanism for maintaining the inter~ace views for applicakions invoked through distributed calls between systems. Th~se interface views are stored in the ROLLFILE
to return control to the appropriate system.transaction.procedure when a called application completes processing and prepares to return to the calling system.transaction.procedure. Each inter~ace ViQW stored as a Profile view within the ROLLFILE maintains an .: ~ : . :, ` , ~` ' , :" ' , .

~,~ .. 2 E ~ r ~ 9 i identification o~ the calling system.transaction.procedure and the called system.transactioJI.procedure. This interface view is stored both in the calling system ROLLFILE and the called system ROLLFILE. This thereby supports the return of control from a called procedure when a RETURN exit state is set, and supports the forward tracing of control is the user restarts a transaction suspended by the system, indicated as `EXTENDED DISTRIBUTED PROCESSING IN PROGRESS'.

GTD TR~ACTION PARAMETER~ WIT~ ~S. Applications built using the GTD facility that run under IMS are provided input parameters ~or accessing the transaction view (containing such data as panel information), the Input/output Program Control Block (IOPCB), alternate IOPCB, and the Program Status Blocks (PSBs~ for accessing DL/1 data bases. The IOPC~ contains information necessary for proper transaction processing, such as terminal and user identi~ication. Furthermore, the IOPCB must accompany every call back to the transaction processor.

To provide the transaction view as the first parameter, the other parameter in the normal IMS parameter list are offset by one position. The particular order of the addresses in the parameter list passed to the application are: the address of the trahsactiorl view, the address of the IOPCB, and lastly the address of the alternate IOPCB~

Other parameters in the list are ~he PSBs specified by the IM5 application according to the SYSGEN. These are also offset by one position. Furthermore, ~TD applications can only support 64 PSBs including the transaction view.

~ TD P~nel. A panel within the GTD application supports a presentation o~ information to the us~r, typically on a display screen such as the IBM 3270 video screen. The screen presents output data ~rom an application and accepts 2~
input data to that application. Each panel has a uniqu~ 8 character name within the ~T and the MAPLIB
dir~ctory/library. Each of these panels has an input and output procedure associated with it.

The input procedure, a mandatory procedure, is invoked whPn an input panel is received by a systPm from a input terminal or proce~s. When an input panel is rPceived, the panel name is placed in the TDT and the associated input procedure is giv~n control by the I2T runtime driver. This panel/input procedure relationship is specified using GTD.
The input procedure is also defined using GTDo The source code f~r the procedure may be edited by selecting E (-Edit), or any other specified designator, for the desired procedure.

The output procedure, on the other hand, is an optional procedure which may be invoked prior to displaying a panel requested from a menu, or may be invokPd upon the restart of an application suspended for HELP documentation presentation, in order to refresh data to be presented on the panel prior to actual output display of the particular panelO This panel/output procedure relationship is specified using GTD. As with the input procedure described above, the output pro~edure must al50 be defined using GTD and the source ~ode ~or the procedure may also be edited by indicating the E~=~dit) selection for the desired procedure.

The output procedure is typically used to retrieve data from data bases priox to actual display of the panel. For example, an inventory transaction may have a part number saved in th~ profile view, however, prior to display of a panel o~ information relative to this part number, data base calls m~y be required to complete the output panel.
!

.. : . , ., ,: , . , . , . ,, , ~ .. .... ~, ., ., . :. . : , 1-'`" . ~
-- ~st~ v The output procedure may execute during the restar-t process after any HELP sequence has ~ompleted (Fl=EXITHELP).
The output procedure may also be invoked when a panel is presented as an initial user request from a menu. An output procedure can be specified on the menu entry specification, or may be associated with the panel on the panel specification. If an output procedure is specified on a menu entry, this procedure will be invoked prior to the display of th~ panel. If the output procedure on the menu entry is left blank, the output procedure on the panel specification will be invokied. If bo~h are left blank, th~ panel will be presented from the data in the transaction view as populated from the profile view.

GTD M~ CON~Oh ~Y~EM. The Menu Control system for GTD
applications is analogous to ISPF menu functions. The system supports four levels o~ hierarchical menus, with each level supporting 1 to 16 entries. Each entry on a menu i5 characterized by an 8 character selectio~ code and a 32 character description to indicate the function offered by this selection codeO Generally, when a transaction is initiated, the Master Menu is presented to the user for an initial selection. At any time during the execution o~ a transaction, the uiser can press the F12 key, or entar an equal sign '=' in the select field on any menu panel to return to the Master m~nu. It should be noted that the Fl2 & "=" key~ are selected only as a matter of design choice and are not to be considered limitations of the invention~

The u~er can make a direct request to a function within the menu hierarchy by entering '7tran=select.select.
select.select': up to the four level specification capability of the GTD system. Shorter selections of l, 2 ~r 3 select codes are also ~cceptable.
TI-13766 lOl ;., ' ' '. ' ~ . . ' ' ' ' :' ' .. : '. .

r .~ , ~

When menu panels are created, entries are specified to indicate the select code, the descriptive line for the menu entry, the panel that can be presented, and the procedure th~t c~n be executed prior to presenting the panel itself.

~ E~P 8UPPO~T FO~ ~T~ APP~ICA~ION~ 2 When an application is developed using GTD, the TDT can specify a TIOLR
report.generation containing the transaction documentation.
The information in the TIOLR report.generation is structured so a chapter name can reference a panel name to provide multiple sections and pages of documentation associated with each transaction panelO

The documentation is presented to the usedr of the application at run time by pressing thP F1 key. The key causes the control program to collect the information on the user screen and store it in the ROLLFILE as a HELP view.
The control program preserves the profile view for the transaction and presents the HELP documentation for that transaction to the user through a HELP panel. The panel name for this HELP documentation is tdH~LP.

The user can return to the execution of the application after completing review of HELP documentation by pressing F1. The control program then proceeds to restore the profile view in the transaction view, execute the output procedure associated with the panel (if thee is one), redisplay the panel suspended for the HELP present~tion, and repopulate the screen with data items on screen data items on scre n at the point the HELP request was made.

While in the HELP presentation, a user can request a definition of a word in text by placing the cursor on the word of interest and pressing the F2 key. F2 invokes the Glos~ary fun~tion. If the word h~s been defined by the application designer in the GLOSS~RY, the definition will be presented on the screen. After viewing the definition, the J

: ,:
., : .

'.'i' ' ~ ' ' ' ' '' ' ~. ' ; ' '' ` ' ' ' ' ' . ' . ' ' , . ' . ,' ', ~;

s~
7,i~ 7, , ;er can press the F3 key to return to the HELP
documentation, and in turn press Fl to exit from HELP and return to thP suspended application panel.

GL5~8~ARY SUPPORg~ FOR GTD ~PPLICATIONS. The Glossary function allows the application designer to deine a set of words in the designated TIOLR report.yeneration so the user can interactively select the definition of a word they do not understand. Glossary words are specified in the TIOLR
chapter ~'report.generation,GLOSSARY". Words within the Glossary can be one to eight characters long. Each word is specified as a section within the Glossary chapter. Each word des~ription may be up to several pages long.

once a word has been selected from the Glossary, function keys allow the user to scroll through the possible multiple pages of documentation ~or that word. To find other words in the Glossary the user can either use function keys to scroll to next or prior words within Glossary, or enter a parkicular word in the entry field. If a word is specifi d by either method, and is not found in the Glossary, the next word in alphabetical order will be shown.

Word definitions can be selected from the Glossary from the HELP panel, INFO panel, or GLOS panel by placing the cursor on the word o~ interest and pressing F2. Once the user has compl~ted a review of the Glossary, he can press F3 'to return to the prior panelO

II~O~a~ION ~PPORT FO~ GTD APPLICA$IONS. The GTD
run~ime system (IET~ supports the presentation of tutorial do~umentation from the documentation report.generation for a GTD transaction. The user can select tutorial documentation from the Master Menu by specifying a menu select code and ~description, the tdt INFO panel, and the IETOINFO procedure.
JlThis procedure and panel activates the information display .:
iTI-13766 103 ' . , : . . .' : , :;: ', :~. ', . :.;:, ;, . !. ' ., ' . ".
. :, ... ;~ , ;. . ~ . , . ' ,. , ' , ,~ .. .'.. , .. ':, i, , ' ' . , ' ' ' .. . ' : ' ' ' ~ nction from the report.generation.chapter where the chapter is specified by the first eight characters of the description field on the menu entry.

Haviny selected an INFO presentation, the user can scroll forward or backward within this information by pressing F5 and F6, respectively, for forward and backward page scrolling or be entering the desired section and p~ge names on the tdtINFO panel. The user can exit the IMFO
function by pressing F3 or F12 to return to the Master Menu.

G~D OPTION FIE~D. The GTD system supports an Option field on the panels~ The option field allows the user to specify functions keys. This is especially useful when the user is using a terminal that does not have function keys.
The op~ion field can be placed on the panels by specifying the variable name, IEFl_OPTION(woption), as a three character input/output ield. The option field can be automatically specified as the panels are created.

The user can enter an F (uper or lower case) followed by one or two decimal digits (1 to 24) in the option field.
This is equalent to pressing the corresponding function key.
IE the user enters an option field and also presses a function key, the function key will take precedence. If an entry is not in the preceeding form, the entry is ignored by the IET and passed to the procedure.

GTD ~OO~a~EAD FIELD. This field is an optional field that can be placed on a panel to allow the user to designate a next fun¢tion to be perfor~ed. This 64 byte field is processed according to the application designer's specificat~on. In the preferred embodiment of the pr~sent invention, the field is associated with function key F12.
I If a lookahead field is on the screen, or the first i character of the lookahsad field is not blank, or F12 is -.:. : :: .: :,: . : ,, ., , . - i .
: . . ~ : ~ , . :. - : : .- .

~essed, the menu action normally associa~ed with F~2 is ignored. The specification of F12 is passed to the application through the IEFl_FUNKEY (wfunkey~ variable. The applic~tion recognizes the user wishes to execute the specific LOOKAHEAD function as indicated by the IEF1-LOOK~HEAD~wlookahead) field.

~ DI~IN~ A GTD ~ AC~ION DEFINITON. The anchor element of a GTD application is the TDT. The TDT is a member of a MAPLIB library/dir2ctory that contains the specification for a transaction. Each TDT entry is a named member, one to four characters longO The name may be extended up to four characters to create unique object names in support of the applicationO

A CO~OL procedure within a GT~ application is a standard structured CO~OL member. The application designsr can use any of the basic COBOL functions, and reference other programs and procedures, using standard languaye facilities of the environment where the transaction is intended to run. The COBOL procedure is intended to be a COBOL II structured COBOL member with minimal references to other facilities so the application can be portable to any of several environm2nts.

When a procedure is entered ~ith panel input, the transaction view will be populated with the profile view.
The panel data will be superimposed on the profile view~
When a procQdur~ is entered with a LINK request, the transaction view is cleared (to zero) and the input view populate~ the transaction view.

Tn invoke an external procedure, use the LINK and RETURN ~acilities of the DAA. To execute a LINK to other procedures in the DAA, the user may specify a new system, transaction~ and procedure in the respective fields .

, , ; , ~ ~ . . ~, .; . . . .... . . .. . .. .. ... .... ... . . . . ... . . . .

.. ~; . . ... . . .... . ... .. . - ., . -., .. ,. ,.. . , . .. : :-. .. . .

~ _ d ~

IE~1-NSYSTEM, IEFl-NTRAN, IEF1-NPROC respectively) and enter the word LINK in the IEFl-XSTATE field.

If the logic of the application indicates a called procedure has completed execution and is to return to the calling procedure, the designer may enter RETURN in the IEF1-XSTATE field to return control to the calling transaction~procedure.

~ DIT ~TD APPLICA~ION VI~W~. Profile, inpllt, and output views ar~ maintained in ~he SRCLIB for each transaction within an applica~ion. These views are maintained as standard source members. The only information included on each line within this source member is the name of the data item to be included in that view. These YieWS are correlated at compile time with the transaction view associated with the TDT. The further information necessary to develop the object ~orm of the view is derived from the tra~saction view.

Th~ views, a~ managed by the IET runtime monitor have characteristics validated at runtime to veri~y the data associated with the view is consistent with the curent version of that view as manayed by the executing transaction. These crosschecks are made using inherent param~ters, including numb~r of data items and total length of th data items in a view. Each profile, input, or output view has a v~rsion modifier to allow the designer to change the input, output, or profile views for a given transaction.procedureO The version identifier is specified by ~VER-line in the source member for the corresponding view. `line~ represents a four character alpha/numeric version identificaticn. As the designer specified a change to a view, he should also change the ver~ion number so the runtime validation of this version ID can detect incon~istancies in views as they are processed at runtime.

: ,.. :: , : : - . ,, - : : ::... , .: ., . . ::

:...... ., ,.. :,. , : ,: I , . . : :.
.. . , . . , ,. , . : , . .. . . ~ . :. . , : : . : ~:
., A ~ ' ~ . . . . .. . . ..

. . . ', ~ ' ' ' . . . , ' ' S J ~

lis version is necessary because changes for a transaction in one system may not occur precisely synchronous with changes in other systems within the network.

This source-identified version number is transcribed into the object and load modules versions by the view compile process of the GTD application builder. When a view image is created at runtime, this version ID is further transcribed into the runtime view image. As that view image i5 received by a called program, or extracted by the runtime controller at application restart, the version of the view imag~ is valida~ed against th~ version for the view de~inition. This improves the probability the information will be passed consis~en~ly be~ween procedures in this DAA.

CO~PILI~G G~D ~ . GTD vi~w are compiled using GTD
to generate the object version of the views. This process builds a multi-view object module that maintains a representation of each input, output, and profile view referenced wi~hin a transaction. This compilation process extracts the transaction view ~rom the S~CLIB (normally `SRCLIB(tdtTVW') and parses this member to interpret data type, location, and length of each of the da~a elements within the transaction view. The view compiler then extracts each of the input, output, and pro~ile views from the SRCLIB and generat~s an object section for each view.
The object section includes a header identifying the view name, length, and version number. For each data element the object section generates an entry identifying that data element relative to the transaction view. Each section is gi~en the name of the view. The object module created is given the name tdtVIEW. This object module, as created, is included with the transaction load module during the transaction bind step.
TI~--13766 107 '~;` . ' . ' ": .. ' .. " ', .. , ., . ' . ~ " ;' ~ ' . ' . , ., ' . . , ' . . . ' . ,' " ' ,, "' ... ' This yields a view model for each input, output, and profile view for a given transaction. This includes the views for the procedures included within this transaction, and the inpt and output view specifications for each of the procedures (EXTERN procedures) called by this transaction.
The called procedure input and output views are defined in the TDT with GTD with a TYPE=EXTERN for the procedure.

CO~PILI~ GTD P~EL~. views are compiled using GTD The view compilation process is a mass view compile process~
All view~ associated with this TDT are compiled and placed in the object member tdtVIEW.

The desiyner can request the mass panel compile. A
conditional compile compiles panels changed in MAPLIB or if ~he transaction view has changed in SRCLIB since the last panel compileO ~he GTD system uses the modified date in MAP~IB and SRCLIB and the compiled date in the LO~DLIB to make this dete~mination. ~n unconditional compile compiles all panels in the transaction. The system references the TDT member in the M~PLIB to identify all of the panels (including menu panels) to be used by this transaction, and to initiate individual map compiles generating the load modules (LOADLI~ describing these panels for the run time interfac~. This i~ a lengthy step in the process. The designer will get a RETURN code for each panel in the TDT as they are compiled.

~ E~B~T~G ~ ~TD ~AN8ACTION~ To reduce the cost of the development cycl~ while retaining full integrity of the regeneration proce~s, an intelligent regeneration process is used. This proce~s maintains, with appropriate libraries, a last cha~ge date for each of the significant objects defined by the TDT. To ~ully support this pro~ess, the GTD editor notes when a panel is gen~rated or a view is edited. The CODESTAR editor id~ntifies when a change is made to a panel.
Th~ CODESTAR compiler identi~ies when a panel i5 compiled.

: ~ . ~ . . , : ,.

s 3 .~e linkage editor identifies when a procedure is linked.
The source editor identifies when a source change is made to a procedure.

The conditional regeneration begins by inspecting objects within the TDT to determine if a source change has been made requiring a regeneration or recompilation of any of these objects. The transaction view is the anchor object within this collection of items. If the transaction view has been edi~ed, all panels, procedures, and views must be recompiled. If the transaction view has not been changed, only those objects modified since the last generation need to be recompiled. The regeneration process inspects the last edit date for a source module and the last link-edit date ~or the load module. If the last link-edit date is after th~ last source edit date, the compile is not required for that modul~. Similarly, if there has be~n no editing of a panel or the transaction view since the last compile and link edit of khe panel, a recompile of the panel is not necessary.

NOTE: Since the object module time stamp maintains minute resolution, it is necessary for full integrity to recompile objects with link edit time equal to source edit time. This may, on occasion, cause panels and procedures to be recompiled wh~n no change has been made. If source edit and compile are both complete~ in the same minute, the next conditional regeneration will perform another compile.

~ G~TI~ ~ GTD TR~N~ACTION. Once a GTD transaction has been developed and installed into the runtime environment~ the user can invok~ that transaction by logging on to the system that supports this transaction. The user can enter `R system name' or RTGxxx followed by the tra~saction code and press ENTER to run IMS transactions.
I~ the user wi~hes to select a particular sub-function from TI-13766 lO9 ~ '., ' '` ~' , ' ' ' ". ", "; ' ` " ~ ' ,. ' '' ' .. `` ' ' , , ' ' I ., ` ~ ' ' ' ., " ',. ' . , f ~ ~JI l~v' ;J ~
~e menu hiPrarchy within the transaction, he can i~mediately transfer to a sub~function within the transaction by entering ~=select.select.select' specification. Once the transaction receives control, it will prasent the appropriate panel to the user. The trans~ction may have executed some procedure, or, depending on the applica~cion design, may only present an initial panel for further selection by the user. The user can enter data into the indicated panel and press ENTER to execute the indicated input procedure for this panel.

The user can press F1 for HELP documentation associated with the given panel. This documentation will be extracted for the TIOLR report.generation.chapter specified by the application designer. If the designer has not prepared the TIOLR report.gen~ration information, the user can get a `Documentation Open Error' error condition. If the particular chapter ~panel name) has not been specified for the HELP documentation for a particular panel the user will get a `Documen~ation Not Found' error condition. Ik is the designer's responsibility to develop and maintain the supporting documentation.

Once HELP has been invoked, the user can select glossary functions (press F2, or can press F1 to return to ~he interrupted panel~

Pressing F12 at any time returns the user to the transaction Master Menu. If the application designer has specified furth~r actions with function key specification, the u~er can press the appropriate function key to request the indicated action. It is the application designer's responsibility to correlate function key descriptions on the function key line, normally line 24, with the panel input pror-~dure 77 logic" to support these indicated function key act~ons.

,, , ' , . . , . ~, , .: , . , ' ' '. . , . . . ' , ~ . ' ' .: ~ ' ! . ' When a GTD transaction terminates execution, the profile view is sav~d by the profile data base for the user/appli~ation on that system. The transaction can be resumed by entering the transaction code from a clear screen (or a directed routing of the form `R system tran') This restores the profile view, executes the panel output procedure (if any) and presents the current panel.
Alternately the user can enter `tran-' to retain profile view and present transaction master menu; `tran=RESET or tran /RESET' to clear profile view and present transaction master menu; or `tran=QUIT or tran /QUIT' to delete application from userls profile space on this system and display the `Display Active' panel.

E~IT ~AT~a DAA procedure have a completion condition specified by the Exit State variable. This exit state is set by the application, or by the system, by placing a code in an eight character variable called IEF1-XSTATE/wxstate.
The application uses the Exit State variable to indicate an action to be taken upon completion of the transaction. If this variable is not modified by the transaction the Exit State will be blank. A blank exit state causes the designated panel (IEFl-PANEL/wpanel) to be formatted and presented to the user at the input terminal (IEFl-TERM/wt~rm3.

~ he application may specify the alternate exit states listed in table 2.

f'J !i"' ,/, ~ ~ ff' ~

TABLE 2~ GTD Exit State Exit St,ate Action blank Display Panel=IEFl~PANEL/wpanel LINK Trainsfers control to IEF1-NSYSTEM/wnsystem, IEFl-NTRAN/wntran, IEFl-NPROC/nproc RETURN ~eturrls control to calling system transaction procedure RESET Clears profile view and displays master menu QUI~ Deletes application from profile data base and presents `Display Active' panel.

LIN~ ATB. A LINK Exit State specifies the application procedure is reqjuesking a transfer of cantrol to th~ system.transacition.prociedure ais designate by IEFl-NSYST~'l (wnsysteim), IEF1-NTRAN~wntran), and IEFl~NPR~C(wnproc). The trainsaction name specified in IEFl-NTRAN'5wntran) must be a network d~ofined transaction code. If th~i IEF1-NSYSTEkl'i(wnsyst2m) name is blank, it is ~ assumed the re~gue~t is to a transaction in the current i system or routed as specified by the locial directory (DRC).
~ If the IEFl-NPROC(wnproc) name is blank, a null input view ¦ : will be prepared and the master menu for the indicated transaction will be presented to the user of the application.
;
, When control is to be passed to a procedure using a ¦ LINX ~xit S~ate, the input v.iew for that called ;! transaction.proc~2idure is prepared by the sy~tem. Thie system r~ -s ~' xtracts the designated data items from the transaction view, packages these in a LINK message with an interface view indicating the calling and called system.transaction.procedure.

R~T~RN ~X~T ~TAT~. A RETURN Exit State causes control to be returned ~o the calliny application. If a RETURN exit state is specified and the current procedure has not been LINKed to another system.transaction.procedure, an error message is specified in the IE~l-MESG(wmsg) field.

When a RETURN is executed from a transaction.procedure, the output view for the called transaction.procedujre is packaged in a RETURN message with the interface view that invoked the request. The RETURN m~ssage i5 routed to the calling system.transaction.procedure.

When the calling transaction.procedure is reinvoked at the calling syst~m, the profile view for the calling transaction.procedure is restored in the transaction view.
The output view from the called procedure is stored in the transaction view and the calling procedure restarted.

RE8~T E~IT ~A~. A R~SET Exit State the profile view for this application/user on this system is cleared and the mastQr menu for this transaction is presented. This condition can be initiated directly by the terminal user be entering `tran-RESET' or `tran /RESET'.

Q~ T 8TAT~ . A QUIT Exit State removes the application from the ROLLFILE for this user on this system ~nd the `Display Active' application panel is presented.
This condition can be initiated directly by the terminal user by entering `tran=QUIT' or `tran /QUIT'.

, , ~ , .. . . .

~t ~ r,~
FIJNCTION REY BIJPPO~T IN GTI) APPLIC~ TIONi~. The application desiginer can specify function key action for GTD
generated applications by including logic within the input procedure to interrogate the function key flled. The function key filed is made available as a GTD system provide parameter IEF1-FUNKEY(wfunkey). This is a COMP-3 COBOL
variable ~short C variable) with a value in the range of 0 through 24, that represents the function key pressed. The IET monitor tha~ controls the execution of the GTD run time module will interpret function keys 1, 11, and 12 and take the predefined system actions of `F1' HELP documentation presentation; `Fll' Display ~ctive applications presentation for the current user on the current system (transfers control from the curren~ transaction to a system provide transaction (TRAN=DA) to display ~he list of the active applications for this user on this system); and `F12' Master Menu pxesentation.

The appli~ation designer must include the appropriate logic within the application to specify alternative function key actions. A function key value of zero implies the ENTER
key was pressed to invoke this transaction. If non-zero, th~ user can invoke the logic the application designer set up ~or the function key pressed.

Example - Invoking alternate panel will place alternate panel in I~F1 P~NEL(wpanel) field; GOB~CK statement issued to retur~ control to alternate paneli or alternate p~nel presented to user.

Example - Invoked alternate transaction - Alternate system.transaction.procedure placed in IEFl-NSYSTEM (wnsystem), IEFl-NTRAN(wntran), IEF1-NPROC (wnproc) fields - LINK placed in IEF1-XSTATE~wxstate) fields ',' , . ' . . ; , . ' ' ' , ' ' ', . . ' ~9 ~ ~

GOBACK statement issued to transfer control to alternate transaction - Input parameters prepared as specified by input view for called procedure.

The user can request the next or prior obje~t from the one portrayed on t~e panel be extracted from the data bas~
and its attributes presen~ed for vi~w. This is a typical function for Fs (next) and F6 (prior) keys within a referenced ta~le or data base~ I~ is the designer's responsibility to iden~ify the next or prior object in the data base read the appropriate attributes from the data base and issue the GOB~CK statement to have the information presented on the panel.

~ D APP~I~ATXON PROCEDURE STRUCTURE. The GTD system primarily supports COBO~ and C applications. The GTD system will support As~embly Language Code (ALC) implementation, but these implementations require manual correlation of information not required in COBOL and C environments. For example, in the ALC environment, a DSECT must be maintained that is byte level compatible with the COBOL or C
transaction view generated for view and panel references.

The ALC programmer must adhere to sertain conventions fox procedure de~initions. While this has not proven to be a significant problem, it is more complex than the COBOL
environme~t.

~ he COBOL and C environment for GTD provided applications provide for the major function~ to be supported by the IET runtime driver and the associated runtime ubroutines~ Therefore, the application development process is significantly simplified for procedures in this COBOL/C
~nvironment~ When a procedure receives control from the IET
runtim2 driver it can be invoked in two ways:

~. . , .: ' " . . . ' , .. ', I ., ,' ~ .. . .

1. Input from a panel.
2. Input from a calling procedure.

I~P~T FROM A PANEL. In general, when input is received from a terminal to a procedure, the profile view is extracted from the ROLLFILE and placed in the transaction view~ That transaction view is presented to the procedure.
The procedure executes the logic indicative of that particular input procedure:

- reading records from data bases - preforming logic on the data items that extracted this input and the data items from the data bases - preparing output data elements that can be saved in the pro~ile view upon completion of the procedure execution or displayed to the output terminal.

The same panel input will be displayed with the updated data if the application designer sets up the ~ollowing procedure-- receive input - read data from the data base - place data base data .in the transaction view - return control (GOBACK or return) If the input proc~dure logic determines from the terminal input or function key an al-ternate panel is to be displayed, it can insert the new panel name in the IEF1-PANEL~wpanal~ field and execute the &OBACK (return) statement. This returns control to the IET controller and prepar~s a panel ~or the input terminal consistent with the panel specification. I~ the IEF1-PANEL(wpanel field is left blank, the M~STER MENUwill be displayed~

iJ
The function key field, IEF1-FUNCXEY (wfunkey~, can be lnterr~gated to determine if a function key has been pressadO The application designer determines the action to be taken according to the key pressed. The function keys listed below are reser~ed for 5TD developed applications.
Any other keys can be set up by the application designer.

INP~ FRO~ A C~ G PROC~DU~. A proc~dur~ can call other procedures, sub-programs, and sub-routines, as desired to execute particular functions for that procedure.
External procedure calls, both external to this transaction and this system, can be invoked with the LINK and RETU~N
Exit States for a procedure.

The transaction name in the IEFl-NTRAN(wtran) field must b~ a defined transaction within the network. The transaction name can be routed based on the transaction routing specifica~ions for the calling system to another system within the network. The procedure name must be a well defined procedure name within the called transaction.
If it is not defined, the MENU for the called transaction will be displayed to the user.

Having invoked the called system.transaction.procedure, that proc~dure can operate in the same environment, with the same options, as the parent transaction.procedure. For example, to display a panel upon completion of this called procedure ex~cution, the application designer can enter a panel name in the IEF1-PANFL(wpanel) field and return control with the I~F~-XSTATE(wxstate) field blank. This displays the panel to the requesting user~

"' ~ ' , , . ' , . , ' ' ' ' , ", , ' , ' ' . ' ' ''' ' ' ', ~ ; ' .' ' ~ " . . ' ' ' ' ' ~ ' '. ' ' ' ' , ' " ' . " '"'", ' ' ' ', '' ' . ' '; , .' ";''. ' , ' ' ' ' '.' ~'' ' . ' ' ' . ' . .

;,, ~
A called procedure can return control to the calling procedure by issuing the GO~ACX (return) statement with the varia~le IEFl-XST~TF.(wxstate) set to RETURN. Upon issuing the RETURN, the IET control program will:

- extract data items from the called transaction view as specified in the output vi~w for this called procedure - package the data items with the interfa~e view that initiated the call request - submit the output messages to the calling system.transaction.procedure.

Upon return to the calliny system.transaction, the IET
control program will: ~
- extract the profile view for the procedure from the profile data base - load the profile view into the tran~action view for the calling transaction - load the output view as received from the called procedure on top of the transaction view.

The calling procedure will be reinvoked (at the top) for further processing as indicated by the application designer.

G~D_~tern~l_Pro~ure. An external procedure ~EXTERN~
is a tr~nsaction procedure called by a transaction through the LI~K exit state. In this case, the procedure is nok included in the calling transaction load module. A
reference to this external procedure is made to correlate the input and output views for this procedure. An external procedure does not have a profile Vi2W. The profile view is maintained as null throughout the definition of the TDT.

When the TDT is prepared, the external reference will be noted by speci~ying the procedure type as EXTERN. The TDT
will no~ create a re~erence for this extern 1 procedure.

The external procedure will not be includ~d in the load module. The input and output views for this procedure, since they are requirPd when a LINK is exPcutRd to the external procedure (or a ~ETUR~ is perform~d)~ are included within the tdtVIEW module created at view compile time.

GTD ~for~tt0~ Uto To allow initial entry to the system to give more specific directioning to the application, the application desiyner can develop applications that process input to the transaction processing system from an unformatted input screen. While the data is usually presented ~rom an unformatted input screen. While the data is usually presented from a formatted data screen, being able to support clear screen inputs can savP interactions with the application.

In some cases, the unformatted input is processed by the IET command processor. Thes~ inputs are characterized by a clear screen input with a transaction code followed by a space (or multiple spaces) and an equ 1 sign followed by a series of selection options separated by periods. For example: ~IECCTRM.B'. This approach is satisfactory for gaining access to a system at a particular functionality level.

It is also desirable for application unique functionality to be presented to GTD developed applications.
For exampl~ an HRN transaction where the user wishes to input the transaction cod~ HRN and an employ~e name as a single action to get a response presenting information regarding that particular employee.

These types of unformatted input applications can be ~ ~upported by the GTD system by allowing the application I desig~er to specify an UNFORMAT ~GTD option 102 panel, de~ining the UNFORMAT panel to the ~TD application, and in TI-13766 ll9 !

'' ' , ' ;: ' ' , ' ' ,. S
''' . ' ~ '; . ., , :. "' ' ,' ' ,' ' :" , ' . ' ' ~ . . ' ' ,; . ' ' ' ' ' '~ ' , ' ' ': , ' , ' .. . . . .

~ i 2 ~ 2 J _G ~ ~
turn associatiny with the UNFO:R~AT panel a procedure to proces~ the un~ormatted input.

The structurP o~ the UNFORMAT panel is very basic. I~
requires - field 1 (normally row 1 column 1), transaction code, typically 8 characters, IEF1-TRAN(wtran~

- field 2 ~normally row 1, column lO), panel nam~ field - panel name specified as UNFORMAT, typically eight characters, IEF~-PANEL(wpanel~

- third field (normally column~ 18l application designer speci~ied length~, character input fiPld - unformatted, in~ormation following trzlnsaction code from ~mformatted screen placed in field with first non blank character in left most position.

Th~ application is responsi.ble for interpreting the input data stream accordi.ng to any user rules de~irabl~. In turn, thf~ application typically presents a formatted output: panel characterizing the desired user action. This parsing and panel pre~entation is completed by the i~put procedure as~ociated with the UNFO~MAT panel by GTD.
~ .
Sinc~ the structure of the UNFORMAT panel is uniform from sne application to another, the application de~igner can craate a new UNFORMAT panel for his library by copying ~ an ~xisting UNFOR~AT panelO For generality, the application `¦ de~igner may desire to have the data .input through the 3 I~Fl-OUTPUT (woutpuk) field since this is a user-available ~ield in the GTD transaction view, 32 bytes in length, and l , j TI-13766 120 :j ,~

should be sufficient for most application requirements of this type.

The UNFORM~T panel must be named U~FO~MAT. Therefore, the panel is unique within the library/directory set for a given application. It is preferred the application designer use a variable name for the input data field in the system supplied section of the transaction view, since it will be invariant across applications managed within the same family of GTD libraries/dirPctories.

GTD Applic~tio~ Pa~el Pre~ent~tio~. Transactions developed by the GTD system present panels to the terminal through a panel driver. This presentation server interprets TMS panels prep~red by CODESTAR or' by the GTD system which may support color, extended attributes, reverse video underscsre, and other characteristics. Certain terminals receiving these panel presentations may not be capable of supporting multiple levels of terminal capability, but the panel presentation server still provides maximum functionality ~or the mo~t capable terminal devices. The Transaction Mapping S2rvic8 (TMS) module interrogates the IEC terminal and device tables IEC function 5) to determine the terminal capability where a panel is to be presPnted.
The application designer can design terminal presentations using the maximum functionality of any terminal that would us~ this application. At the same time, these pan~l presentations can be ~dapted to t~rminal devices with less~r functionality~

Applications within the network can have the capability sp~ci~ied for each terminal name recorded in th~ IEC
Terminal Table with a referenc~ to the appropriate device characteristic. The IEC terminal controller can dynamically modi~y (~IEC=TR~.C'3 the characteristics of any terminal within the network at any sr all of the systems within the , . . .

' b ~ R r~

network. This adapts maximum functionality of an application to the functionality of th~ target terminal.

G~D Dosument~tio~ Report D~Pinition - Lanauia~e o f Pre~renes. GTD applications documentation i5 stored on TIOLR for the transaction user to access in one of the following ways:

- Press Fl for HELP
Press F2 for GLOSSARY
- Select INFO from menu The documentation can be made available in multiple languages. The language of the documentation display~d depends on what the user has selected as his first and second language of preference ~LP). The selections are made using the ITSS "Language of Preference" transaction, TSSLP.

The selection criteria of the report.generation (based upon language~ is:

l. The report.generation declared for the primary LP if a report was defined for that LP.

2. The report.gen ration declared for the secondary LP
if a report was defined for that LP.

3. The report.generation declared for ENGLISH if a report was defined for ENGLISH.

4. The report.~eneration defined as the default.

¦ These r~ports must be defined on the system executing ¦ the transaction.

' '. ,': ' , ,:

-H~hP Doau~e~tagion. The organization of the HELP
report.- generation is as follows:

rpt.gen.panel.SOO.paye Where: rpt = report name de~ined by LP
gen = generati~n name defined by LP
panel = panel name for which HELP is provided SOO = constant section name page = arbitrary page name(s) G~O~ARY DOC~TA~ION. The organization o~ the GLOSS~R~ repor~.generation is as follows:

rpt.gen.GLOSSARY.word.page Where: rpt = report name defined by LP
gen = gPneration name defined by LP
GLOSSARY = constant chapte:r name word - word being defined page - arbitrary page name(s) IN~O DOC~N~N~A~ION. Selection of GTD System Documentation presents a ~ubmenu with the following options:

1~ G~neral Description 2. Technical Description S~lection of one of these options presents the text stor~d in the T report listed below. ~he glossary informatisn ~or INFO is stored in the same report as for HELP.

General Description rptOgen.GENERAL.sec.page Technical Description rptOgen.TECHNCL.sec.page '.... , . ' ' ,' - ~' ., ~ , ` ' `' , ': ' ; r3 ~ ~

here: rpt = report name defin~d by LP
gen = generation name defined by LP
chp = first 8 characters of menu description sec - arbitrary section name(s) page = arbitrary page name(s) .

f9 p~ r~

GTD MENIJ HIERARCHY

The major functions of th~ GTD user inter~ace are characterized in the top 2 levels o~ menu options. The GTD
user is an application programmer or developer. The user interface menu~ and the functions they support are generic and can be implemented on any suitable platorm to provide a consistent application development snvironment on each platform. Figure 20 i5 a flowchart detailing the functions performed at the highest m nu level according t~ the pre~erred embodimen~ o~ the present invention. Th menu options provided to the user at the top level include the following functions.

1. EDIT TRANSACTION DEFINXTION
2. ~ENERATE TRANSACTION VIEW/SOURCE PROGRAM
3. GENERATE PANELS
4~ CONPILE TRANSACTION DEF/VIEWS/PANELS/PROCEDURES

5. FILE TRANSFER PANELS/PROCEDU:RES/VIEWS/DOC~MENTATION

6. EXIT

Menu item 1, EDIT T~ANSACTION DEFINITION, provides functions whic~ allow the applica~ion developer to characterize the application by providing functions to define and modi~y the application parameters and component parts. Figure 23 is a flowchart of this Edit Transaction (hereinafter referred to as 'IET procedure'7) describing these ~unctions further.

Menu item 2, GENERATE TRANSACTION VIEW/SOURCE PROGRAM, ~hereinafter referred to as "GC procedure") provides ~unctions which allow the application developer to generate the source ~iles for the transaction view (the application : ~: . . . , . : , .
; ~ , , ~ ~ : :

~ ~3~

data area) and programs. The transaction view and source programs are constructed so as to be compatible with the IET. Thus the required IET application interfaces are built into the data areas in the tranCiaction vi~w and into the program linkage for the application procedure. Figure 44 depicts a flowchart of the pre~erred embodiment of the GC
procedure, detailing these functions further.

Menu item 3, GENERATE PANELS, (hereinafter referred to as "GM procedure") provides numerous functions to allow the application developer to generate the system-provided panels, customized for his application and base panels for procedure dialog flow with the user. The GTD generates panels to be compatible with the IET. These generated panels have the fields required by the IET to perform its panel and menu dialog flow management. In addition, GTD
generates menus which also support the IET user interface functions by providing consistent and well-defined common user inter~ace functions. For the convenience of the developer these fu~ctions can also be performed by edit requests on the transaction view, procedure, and panels as provided by user interfaces included under menu item 1.
However the developer may not need or wish to customize all the system-provided menus, information, glossary, and help screens thereby making menu item 3 functions useful. Figure 47 depicts a flowchart of the preferred embodiment of GM
procedure detailing these ~unctions further.

~ ~ Menu item 4, COMPILE TRANSACTION DEF/VIEWS/PANELS/
PROCEDURES, (hereinaft~r referred to as "CTR~Q procedure") provid s the developer with the construction tools neccessary to build a DAA application. Of utmost importance are the capabilities to generate the TDT and view tables required to characterize the applica~ion to the IET. Menu item 4 guarantees that applications built with GTD are constructed with consisten~ compile and linX editor options '" -f~ ~
2 ~ J i.7 ~ 3 ~or the DAA platform and ensure internal consistency within the application ~hrough the use of conditional and unconditional compilation options and the capabilities to compile and link all components in one process TION, into one load module. Figure 50 depicts a flowchart of the preferred e~bodiment of the CTREQ procedurei detailing these functions ~urther.

Menu item 5, FILE TRANSFER PANELS/PROCEDURES/VIEWS/
DOCUMENTATI~N (hereina~ter referred to as "FT procedure") provides a utility to transfer all or part of the application source frsm one DAA machine to another. Menu item 6, EXIT, provides the user a clean exit from the GTD
program. Figure 61 depicts a flowchart of the preferred embodiment of the YT procedure, detailing these functions further.

Before considering each of these menus in detail, the GTD transaction view will be discussed. The GTD transaction view is a work area unique to GTD and should not be confused with the application transaction view, which is manipulated as a data file by GTD. This work area is used extensively throughout GTD as a place to: save the TDF header ~all types) record fields, keep user inputs, and organize data for panel display. Length information for the name, pathname, userid, system identifier, object module external symbolic names da~a are limit~d by the maximum length supported ~y ~he most restrictive platform in the DAA
system. Specific information concsrning the transaction viewj or work area, variables used by the preferr~d embodiment of GTD can be found in Appendix A~

Looking now at Figure 20, depicting thP top or first level GTD Main Menu User Interface Pracedure, GTD intializes a work area, W (Block 5200), and sets the IEFl_TRAN variable in the work area to "GTD" (Block 5210). The date and time . . .. , . . . , . .,, .. , . ~ .. ... , . ,, . , , ., .. . . . . . " . ~ ~ I

are obtained and formatted for display and saved in the wor~
area variables ZDATE and ZTIME (Block 5220). GTD gets the USERID ~rom the system (Block 5250), and sets the IEF1-USER
variable in the work area (Block 5260) to that USERID. The ZUSER variable in the work area (Block 5370) is set to the value in the IEFl-USER variable.

A GTD user parameter file is opened for READ ONLY
(Block 5400). The GTD user parameter file contains the information necessary for the system to present to the u~er some previously initialized fields from prior GTD sessions.
This is done as a convenience ~or the user. The work area fields saved in the parameter file include: gtdmlib, gtdmmem, srcsid, srclid, srctdt, srcuid, tgtsid, tgtlid, tgtuid, tgtsw. In Figure 20, the program tries to open the file (Block 5440~. If unsuccessful (Block 5450), there is no user information stored, ~nd the program jumps to Block 5710. If the open is successful, the GTD user parameter file is read into a buffer (~lock 5460) and the file is closed (Block 5470).

The work area variables are intialized with the parameter file variables, and the program proceeds to Block 5710, where it loads system-dependent environment information that applies to all users on the platform as well as informa~ion that is configurable by the user. The eN~ironmen~ information that applies to all users on the platform incIudes~ compi~ler option, C compiler name, DAA
system ob~ect/load library pathnames, DBMS software object/load library pa~hnames, DBMS copy source pathnames, DB~S ~pre-compiler pathname. This information i5 obtained from environment variables defined for all users. Other system-dependent environment information that is hard coded into ~the program includes the specific names of all utilities, the ~pecific options required by those utilities, the names of system, DAA and DBMS libraries. The : : :

~ ~ ''' ' system-dependent utilities include: C compiler, DBMS
pre-compiler, DBMS to DBMS languagP translator, COBOL
compiler, Linkage editor, editor, show file, copy, move, kill task utility, panel compiler, panel screen formatter (interpretor), panel editor, COBOL data map generator (compiler), COBOL to C translator.

It should be remembered that while the preferrPd embodiment depicts COBOL and C, the scope of the invention should not bei limited in any way to these two language~.
Additionally, an alternative to using the environment variables is to have a system environment information file which would have the above information, and possibly other in~ormation that is currently hard coded in the program stored in ~he file. This file can be loaded by GTD from a prede~ined location each time it is invoked, in much the same way as it loads environment variables in the preferred embodiment o~ the present invention.

Other environment information, which is configurable by the user, is also stored in environment variables. The configurable environmental information includes: DBMS source translator usage flag (indicating that an additional DBMS
code transla~ion step is required) and DAA test system library/object pathnames (the existence of which implies that the test pathnames should be used instead of the DAA
production syi~tem library pathnames). Alternatively, this information could also be loaded from a GTD user configuration file when GTD is invoked.

After obtaining the system dependent: configuration information, the procedure opens an output file unique to the user's userid (Block 6120~. The standard screen output and error output are then redire~ted to this file to be included in the screen information presented to the user (Block 6160). The output from the called utilities is then .

r~ ~

automatically writtPn to the output file, and not to the display device~ leaving GTD in control of the display device input/output. The output file remains open throughout the execution except when it is periodically rewound to purge existing data in the file~ The output file can be displayed by GTD when errors from the utilities need to be examined by the application ~eveloper. An alternative implementation is to pro~ide an output file for the utilities called from GTD
and instruct the utilities, when called, to send their output to the indicatad file. At Block 6180, the GTD
initializes the user~s terminal device to allow panel input and output. -~

Block 6260 displays a GTD panel. When the display procedure is complete, GTP calls the ~E procedure (Figure 22, beginning at Block 48130) to see whether the user has indicated he is finished using this procedure (Block 6300).
If a user end is indicated, the program jumps to Block 6560.
If nok, the program checks to see whether the user requested the edit transaction definition menu option, GTDSEL=l (Block 6350). The GTDSEL variable represents user input, typically a menu selection, from the panel. When GTDSEL equals 1, the edit transaction definition procedure (ET, Figure 23, starting at Block 102390) is called. When the ET procedure is complete, the program returns to Block 6260, to see if the user requires any other menu options from this panel.

If GTDSE~ does not equal 1 at Block 6390, the procedure ---checks to see if GTDSE~ equals 2, meaning the user requested the generate procedure or transaction view menu option.
When GT~SEL equals 2, the generate procedure or transaction view procedure (GC, Figure 44, beginning at Block 6900~ is called. When the GC procedure is complete, the program return~ to Block 6260, to see if the user requires any other procedures from this panel.
TI-1376~ 130 ..' .

., , . ; .' ', !, . . '., ! . , . ' j; ,; ~ . ' 2 ~

If GTDSEL does not equal 2 at Block 6430, the program checks to see if GTDSEL equals 3, meaning the user requested the generate panel menu option. When GTDSEL equals 3, the generate panel procedure (GM Figure 47, beginning at Block 9030) is called. When the GM procedure is complete, the program returns ~o Block 62~0, to see if the user requires any other procedures from this panel.

If ÇTDSEL does not equal 3 at Block 6470, the program checks to see if GT~SEL equals 4, indicating the user requested the compile/bind application menu option. When GTDSEL equals 4, the compile/bind application procedure (CTREQ Figure 50, starting at Block 164~0) is called. When the GM procedure is complete, the program returns to Block 6260, to see if the user requires any other options from this panel.

If GTDSEL does not equal 4 at Block 6510, the program checks to see if GTDSEL equals 5, indicating the user requested the transfer procedure/panels/views/documentation menu option. When GTDSEL equals 5, the file transfer procedu~e ~FT Figure 61, starting at Block 115640) is called. When the FT procedure is complete, or if GTDSEL does not equal 5, the program returns to Block 6260 to see if the user requires any other procedur~s from this panel.
.
When the user requests an end, the procedure creates a parameter file over the existing parameter file (block 6560~, to save transaction view variables from this GTD
session so they are available to the user during the next GTD session. The program checks to see if the parameter file was succes~Pully created ~Block 6570). If it was not, the program jumps to Block 6820 and ends the program. If the create was successful, the buffer is initialized with the parameter values from the work area (Block 6590), the buf~er is written to the parameter file (Block 6790), and ~he d i,7 ~L t ~

parameter file is closed ~Block 6800). Block 6820 exits the program.

GTD DI8Ph~Y ~N~L PROCED~R~. Looking now at Figure 21, detailing th~ preferred embodiment of the GTD display panel procedure ~or displaying a panel to the user and th~n waiting for input from the user~ It uses a panel interpr~tor to perform the panel device input to and output ~rom the GTD transaction view fields which correspond to the display panel fields. It also maintains the current date and time for panel display, maintains the GTD value in the transaction field and clears the message field once the panel has been displayedO

The procedurs obtains the new date/time and formats the panel date/time fields (Block 47370). The transactlon code is set to "GTD" (Block 47420) and the panel interpretor is called to generate the screen output (Block 47430). GT~MSG
i~ claared to blanks (Block 47440~ and the pa~el map interpretor is called to obtain user panel input (block 47480). The procedure then checks to see if the transaction code is still l'GTD" (Block 47490. If it is not, the procedure returns t~ Block 47420; i~ it is, the program exits the display panel procedure7 Gq!D FlINC~ION BND C1115CI~ER F~ l?RC~EDURl:: Looking now at Figure3 22a-~, the flowchart depic~ing ~he preferred embodimen~ of ~he GTD pro~edure to check for an end indicator. ~hi~ FE procedure indicates that the us~r wants to exit from a particular panel function. On receipt of an end indica~ion, the usual program function is to complete processing and terminate the current function. From the main menu, an end indication means that the user wis~es to terminate the program. The user indicates an end indication in a nu~ber of ways. One way to terminate th~ program is to type an exit command in the GTDSEL user input field on the :-::

~ J B ~ ~

panel. This field is included on all GTD panels to support user exit co~mands (as well as other function defined commands). ~nother way is for the user to input an end or exit ~unction key. In the current implementation of the present invention, this is function key 3, but any function key could be used. A function key input number is defined to correspond to the ief_funXey field in the work area or GTD transaction view.

Starting with Figure 22a, the FE procedure begins with Decision Block 48150 checking if the end function key was pressed. If the function key was not pressed, the procedure jumps to Decision Block 48200. If the function key was pressed, the procedure sets the function key field equal to zero, (Block 48160), and sets the select field to blank (Block 48170). At Block 48180, an end is indicated with a flag return code=l and the program exits the procedure.

Decision Block 48200 checks if there is an 'x', or other preselected character, in the select field GTDSEL='x' or 'X'. If there is an 'x' or 'X;, then the function key field is set to zero and (Block 48210). The select field is set to blank (~lock 48220). At Block 48230, an end is indicated with a flag return code=l and the program exits the procedure. --At decision Block 48300, the program checks if there is an 'end~ in the select field GTDSEL='end' or 'END'. If not, then go to block 48400. If so, the program sets the function key field to zero (Block 48310) and sets the select field to blank (Block 48320). At Block 48330, an end is indicatPd with a flag return code=l and the program exits the procedure.
:
Block 48400 determines no end has been indicated and -sets a flag ~qual to zero with a flag return code-0. The ff~,~

~ ~, program ends procedure FE at (Block 48410).

: . .
. :

TI-13766 ~ 134 :~

7 ~

Moving now to Figure 23, at Block 102390, the ET
procedure provides the interfaces necessary to define, edit and perform maintenance on application components, their characterization and their relationships. This information is stored in the TDF f il4 . A copy of the TDF headers is saved in the GTD workarea (or GTD transaction view) in memory for program use, to be later stored in the TDF file.
The format of khe da~a portion of the headers is the same as the format of the TDF headers. The TDF component entries are also saved in a memory data structure for program use, to be later stored in the TDf file. The data structure used to store the TDF component entries is an array named the STDE or STDE table. The format of each STDE element is the same as the largest TDF component.

One of the major functions of the ET procedure is to define the application and maintain the application characteristic information in the TD~ file in a consistent and structured manner. The application characteristic information includes application user dialog/session interface, and the application cooperative processing interface. GTD provides the app]Lication developer a structured method to quantify and ~dit this information in terms which can be saved in the T~F and used to construc$
the application load module. Included in th~ load module is a subset of the TDF and other information quantified in tables which are used by the IET during application execution. Information which is used to quantify the application dialog/sassion interface include panels, the input and output procedures which support those panels, and the application profile view. Information which is used to quantify the application cooperative processing interface includes external and internal procedures as well as the input and output data views for those procedures. When the application is first being defined and no TDF exists, a set :, r~ . I~
2 ~ ir 1 ~

of default definition~ are specifi~ed which define default names, locations of programs, panels and other items, as well as default definitions of system provide procedures, panels and menus. These default definitions are extrapolated using a defined set of conventions from the name of the TDF
file and path names provided by the user. Th2se default definitions comprise a minimal essential subset of application parameters stored in the TDF header. In addition certain default component ~efinitions are also set up. These component definitions arP for panels, procedures, and menu entries provided to support the IET menu, help, information, and glossary manayement functions. These components are stored as panel, procedure, and menu records in the TDF file whenever a function within the ET procedure is performed.

The information in the TDF file allows GTD to locate each component of the application. According to the preferred e~bodiment of the present invention, the conventions used ~re as follows. The TDF and all panel and menu source (maps) are stored in a map library or directory.
The path name of this library or directory i5 provided by the user and is kept in the GTDMLIB field of the GTD work area. It is not stored in the TDF. The TDF name is also provided by the user and stored in the GTDMMiEM field of the GTD work area and in the GTDHMEM field of the TDF . The user-provided map library path name and TDF name are combined using machine-dapendent file naming conventions and DAA conventions to yield the T~F file name. In the same way the GTD determines the file names of the transaction view source, the procedure source, panel and menu source, the ~view source, the TDT source, the TDT objects, the YieW
objects, the panel and map objects, the procedure objects, and the load module. In the UNIX implementation of the preferred embodiment of the invention, the files are located using the listed path name, file name and exten~ion conventions. Specific information regarding these files is ., , ~a /~ f' 2 ~ ~i r ~ i ~
located in Appendix Bo Other DAA application files exist or are used temporarily by GTD but their usage is generally hidden from the application developer. In som cases, specifically with objects, the GTD file location conventions ars different because of restrictions in compiler file output capabilities. In UNIX objects are created in the source (GTDSLIB) directory; on a mainframe, objects are created in the object (GTDOLIB) library. These slight differences in GTD implementation do not affect the portability of the application or affect the GTD development environment as seen by the application developer.

Another function of the second level ET procedure is the provision of an interface for selecting and identifying component (panels, procedures, views, and maps) source for editing or modification. Each of the second level procedures of the ET procedure will now be considered.
Discussion of any other procedures called during execution of a sepcific second level procedure will follow discussion o~ the particular second level procedure.

EDI~ TRAN PARAN~T~R~ This third level procedure provides a display panel which includes information from the TDF header, the TDF first extension header, and the TDF
second extension header. The user can change the information on this display panel as appropriate and have it saved into the TDY. Figures 23a-c depict the flowchart of the preferred embodiment of the ETP procedure, detailing these function~ further.

This procedure provides a way for the application designer to define the basic parameters o~ the transaction.
The de~igner must specify the name of the TDT and the MAPLIB
that contains it. If this is the first reference to the TDT

.

L r~
within the MAPLIB, the system will assume the libraries/directories are to be SRCLIB, OBJLIB, LOADLIB, DBRMLIB, CNTLLIB, and MAPLIB; the transaction view is to be formed by extending ~he ~DT name with the suffix TVW
(tdtTVW); and the documentation indicates the TDT name is the report name while EOO is the generation name ~tdt.EOO).

Any of these default specifications can be changed by the application designer. Once library/directory names have been specified, they should remain unchanged throu~hout the life of the transaction definition. The documentation reportOgeneration can be changed at any time~ This allows a convenient way to release new application documentation.

The GTD edit transaction definition (hereinafter referred to as "ET procedure") begins at Block 102420 by performing the procedure ts display a panel (Figure 21, Block 47300), electing to display the GTDET panel~ This panel contains a list of the third level procedure selections. Block 102440 performs the FE procedure (Figure 22, ~lock 48130) to check for user input end indications.
I~ an end is indicated, the program jumps to Block 102850 and exits the ET procedure. If an e!nd is not indicated at Block 102480, the procedure per~or~s the loadJcreate TDF
procedure known as GTDT procedur~ (Figure 24, Block 44960~
and checXs to see if th~ load/create was succ~ssful (Block 102485). If the load/create was successfull the procedure jumps to Block 102550. If not, the procedure sets the number of entries in the STDE table to -1 to indicate no ST~E table (Block 102490) and clears the user select field (Block 1025~0)~

Dacision Block 102550 checks to see if there is an edit transaction parameters reguest, GTDSEL = 1. If there is, the edit transaction parameters procedure (Figure 27, Block 102~30) is performed and the procedure jumps to Block 102810. If there is not an edit transaction parameter request, the procedure checks to see if there is an edit panel list request, GTDSEL = 2 (Block 102590). If there is, the edit panel list procedure (Figure 28, Block 103190) is performed and the procedure then returns to Block 1028100 If there is not an edit panel list request, the procedure checks to see if there is an edit procedure list request, GT~SEL = 3 (Block 102630). If there is, the edit procedure list procedure (Figure 30, Block 106610) is per~ormed and the procedure continues at Block 102810. If there is no edit procedure list request, the procedure checks to see if there is an edit menu hierarchy request, GTDSEL = 4 (Block 10~670). If there is, the edit menu hierarchy procedure (Figure 37, Block 110280) is per~ormed and the procedure jumps to Block 102810.

If there is no edit menu hierarchy request, the procedure checks to see if there is an edit language list request, GTDSEL = 5 (Block 102710~. If there is, the edit language list procedure (Figure 40, Block 113070) is performed and the procedure continues at Block 102810. If there is no edit language list requesl:, the procedure checks to see if there is an edit transaction view request, GTDSEL
= 6 (Block 102750). If there i5, the ~ully qualified name o~
the transaction view file is built and the edit procedure (Figure 33, Block 43860) is called to bid an editor. Once : the edit is complete, or if there was no edit transaction view requestr the procedur~ proceeds to Block 1028l0.

At ~his point, the procedure wrikes out the TDF file and then (Block 102815) checks to see if the write is :successful. If lt is not, the procedure sets the error m~ssage field, GTDMSG to equal "TDT WRITE FAILED" and moves to Block 102420. If the write is successful, the procedure returns to Block 102420, to await another display of the :

':' F'l. , 7a - 2 ~ i ~J ~ 7 ~

GTDET panel.

G~D G~T TDF: GTD~ PROCE~UR2. According to Figures 24a-r which depict the preferred embodiment of this procedure, the GTDT procedure loads a TDF file into memory.
The header records are stored in appropriate areas in the transaction view and the panel, proc~dure, language, and menu entry component records are stored in the STDE table.
If no TDF file exists, then the memory areas are initialized with default TDF file values. The format of the TDF file records, and consequently the format of the transaction view header record work areas, as well as the STDE table entries are documented in the TDF documentation.

The GTD GET transaction definition file (TDF) procedure begins by clearing the S~DE table entries to blank ~Block 45000) and building a TDF file pathname (Block 45030) using the MAPLIB pathname (gtdmlib), the TDT name (gtdmmem), and the suffix ".tdt~. The pro~edure constructs default component names for the system panels and default application profile view and stores them in the variables listed: main menu, variable gtdhme!nu; information menu, variable gkdhimnu; information panel, variable gtdhinfo;
help panel, variable gtdhhelp: glossary panel, variable gtdhglos; and profile viaw, variable gtdhpvw (Block 45250).
It should be recalled that these names have been selected as a matter of choice and should not in any way limit ~he s~ope of the present invention. The default component names are con6tructed by using the TDT name as stored in gtdmmem and appending a suffix which differentiates the various components ~e.g.,MENU for the main menu, IMNU for the information menu, etc.

At 810ck 45410, the TDF file is opened for read only and the STDE entry table count, nent, is initialized to zero -~

~--?2~
2 ~ J 'J ~ r6~ ~

(Block 45420). Block 45430 checks to see if the op?Pn wassuccessful. If it was not successful, the procedure proceeds to Block 45440 to build the initialization data for the TDF file in the STDE table and in the header record ~ields of the GTD transaction view. If the open was successful, the TDF file is loaded into the header record fields of the transaction view and the TDF component records are loaded into the STDE table. At Bloc~ 45~32~ the procedure performs the get record from TDF file (TDTGET) procedure (Figure 25, Block 16140). The record obtained at this point is the TDF header record. Block 45434 checks to see if TDT~ET was successful. If it was, the procedure jumps to Block 46430 to validate the header record read. If TDTGET was not successful, the procedure moves to Block 45440. Blocks 45440 through 46410 build the initialization data for the TDF in the STDE table and in the header record ~ields of the GTD transaction view and then constructs the application transaction view.

In Block 45440 the procedure sets the work area fields in the GTD transaction view containing the TDF header fields to blanks. The TDF header fields are then initialized to the default values (Block 45450) listed below: gtdhrtyp = 'H';
gtdhmtyp = 'D'; gtdhmem = gtdmmem; gtdllib ~ gtdmlib with last t~ken (~APLIB portion) removed, "LOADLIB"; gtdlmem =
gtdmmem "PROG"; gtdslib = gtdmlib with last token (MAPLIB
portion) removed, "5RChIB"; gtdolib = gtdmlib with last token (MAPLIB portion) remove~, "OBJLI~"; gtddlib = gtdmlib with last token (~APLIB portion) removed, 'IDBRMLIB''; gtdnlib = gtdmlib with last token (MAPLIB portion~ removed, "CNTLLIB"; gtdhdr = gtdmmem; gtdhdg = "E00"; gtdcmem =
gtdmmem, "TVW"; gtdappl = gtdmmem; and gtdreln = 1l0000l~

The work area fields in the GTD transaction view containing the TDF first extension header fields is set to blanks (Block 45730) and then initialized to default values :'' ~ .: .. '';, ~ ,, ' , . ' . "; , ' ' ?, " ! , ; ' , ",, .

' ' 2~j?.~

(Block 45740) listed below: gtdhexl = "HX" and gtdhexln = 1 in BIG_ENDI~N format. Byte order in which integer data is stored is different on different machines. The BIG_ENDIAN
format refers to the storage of bytes ~rom the high to lowsst order in a left to right direction. This order is used as a convention for integer data stored in data sets to be trans~erred between machines such as the integer data in the source TDF and MAPs. Other conventions could be used such as LITTLE_ENDIAN.

The work area fields in the GTD transaction view rontaining the TDF second extension header ~ields is set to blanks (~lock 45800) and then initialized to default values (Block 45810) listed below: gtdhex2 - "HX" and gtdhex2n = 2 in BIG_EN~IAN format. A TDF component entry is constructed in the GTD transaction view workarea ~or the glossary panel with the following values: gtdename - gtdhglos, gtdeipnm =
'~IETIGL0S", and gtdeopnm = "IETOGLOS'I (Block 45870). The panel sntry is put into the ST~E table (Block 45910) using th~ process described below.

An attempt is made to add the new panel entry to the STDE table for later storage in the TDF. The attempt will fail if the panel name provided is b:Lank, if the STDE table i~ full, or if the panel name provided already ex~sts in the table. I~ the no error is detected, ths panel entry is inserted in the STDE table in ascending panel sequence.
Speci~ically, the new panel is inserted before the first panel name which has a larger alphabetic comparison value or at the end of the table. The STDE entry count, nent, is incremented (Block 45910). ~-~

A TDF component entry is constructed in the GTD
transac~ion view workarea for the help panel with the following values: gtdename = gtdhhelp, gtdeipnm "IETIHELPI', and gtdeopnm = "IETOHELP" (Block 459203. The :'i, ,, ! '; ' '; ~ .' .' i ' ~ ! ., ' ~ 1~.
2 ~ 7 ~
i:
pan~l entry is put into the STDE table (Block 45950) using the process described in Block 45910.

Next, a TDF component entry is constructed in the GTD
transaction view workarea for the information pianel with the following vilues gtdename = gtdhinfo, gtdeipnm "IETIINFo", and gtdeopnm = "IETOINFO" (Block 45960). The panel entry is put into the STDE table (Block 45990) using the process described in Block 45910.

Then, a TDF component entry is constructed in the GTD
transaction view workarea for the glossary input procedure with the following values: gtdename = IETIGLOS, gtdepvnm =
"IETGPVW", and gtdectyp = "~NTRYi' (Block 46000~. The procedure entry is put into the STDE table (Block 45990) using the process described below.

An attempt is made to add the new procedure entry to the STDE table ~or later storage in the TDF. The attempt will fail if the procedure name provided is blank, if the STDE table is full, or if the procedure name provided already exists in the table. If no error is detected, the procedure entry is inserted in the srrDE table in ascending procedure sequence as described above with regard to panel seguence. The STDE entry count, nent) is incremented (Block 45990)-: A TDF component entry is constructed in the GTD
transaction vi~w workarea for the glossary output procedure with the following values: gtdename = IETIGLOS (Block 46050~. The procedure entry is put into the STDE table (Block 46060) using the process described in Block 45990.

Next, a TDF component entry is constructed in the GTDtran~action view workarea for the information input procedure with the following values: gtdename = IETIINFO, ,;.

.

, ~
~ ~ 2 ~ ~ r~ 1) and gtdepvnm = "IETIPVW", (Block 46070). The procedure entry is put into the STDE table (Block 46090~ using the process described in Block 45990.

Then a TDF component entry is constructed in the GTD
transaction view workarea for the information output procedure with the following values: gtdename = IETOINFO
(Block 46100). The procedure entry is put into the STDE
table (Block ~6110) using the process d~scribed in Block 45990.

Subsequently, a TDF component entry is co~structed in the GTD transaction view workarea for the help input procedure with the following values: gtdename = IETIHELP, and gtdepvnm = "IETHP~W", (Block 46120). The procedure entry is put into the STDE table (Block 46140) using the process descrîbed in Block 45990.

Then a TDF component entry is constructed in the GTD
transaction view workarea for the help output procedure with the following values: gtdename = IETOHELP (Block 46150).
~he procedure entry is put into the srr~E table (Block 46160) using the process described in Block 45990.

Next a TDF component entry is constructed in the GTD
transaction view work area for the main menu input procedure with the ~ollowing values: gtdename = IETIMENU, and gtdepvnm -. = gtdhpvw (Block 46170). The procedure entry is put into :~: the~ST~E table (Block 46190) using the process described in ~ Block 45990.
: : :
At Block 46200, a TDF component entry is ronstructed in ~:the GTD transaction view work area for the main menu output procedure with the ~ollowing values: gtdename = IETOMENUi.
The procedure entry is put into the S~DE table (Block 46210) :using the process described in Block 45990.

f~ ~
2~2~

Then a TDF csmponent en~ry is constructed in the GTD
transaction view work area for the display input procedure with the following values: gtdename = IETDISPL (Block 46220). The procedure entry is put into the STDE table (Block 46630) using the process described in Block 45990.

Finally, a TDF component entry is constructed in the GTD transaction view workarea for the main menu system documentation menu entry with the following values: gtdename = gtdhmenu, gtdedesc = "SYSTEM DOCUMENTATION", gtdesel =
"0", gtdipnm = gtdhimnu, gtdeopnm = ~'GTD" (Block 46240).
The menu entry is put into the STDE table procedure (Block 46290) using the process described below.

An attempt is made to add the new menu entry to the STDE table ~or later storage in the TDF. The attempt will ~ail if the menu name provided is blank, if the STDE table is full, if the name provided already exists in the table (~or any other type of component, STDETYP not - E, named in an STDENAME ~ield) or if the menu entry select field STDESEL
already exists for the menu name!. If the no error is detected the menu entry is inserted in the STDE table in :~
ascending menu seguence as discussed previously for procedure sequence. The STDE entry count, nent, is încremented (Block 46290).
~:
A TDF component entry is constructed in the GTD
: transaction view workarea for the information menu general description menu entry with the following values- gtdename =
gtdhimnu, gtdedesc = "GENERAL DESCRIPTION", gtdesel = "1", ~gteipnm - gtdhin~o,~gtdeopnm = I'IETINFO" (Block 46300). The menu entry is put into the STDE table procedure (block :~
46350) using the process described in Block 46290.

~Next, a T~F component entxy is constructed in the GTD :~
:~ TI-13766 145 ~.

~\ :~
7 ~

transaction view workarea for the information menu technical description menu entry with the following values: gtdedesc =
"SYSTEM DOCUMENTATION", and gtdesel = "2" (block 46360).
The menu entry is pu~ into the STDE table procedure (Block 46380) using using the process described in Block 462900 At Block 46390, the procedure then generates the transaction view using procedure gtvw (Figure 26, Block 8200), sets the message field, gtdmsg, to blanks (Block 46400), and exits the procedure with no errors (Block 46410) .

In Block 46~30 the header record is moved from the buffer area into the TDF header area in the GTD transaction view. Block 46440 checks to see i~ the TDF record (gtdhrtyp=h) and TD~ types (gtdhmtyp=D) are acceptable. If the records are acceptable, the procedure jumps to Block 46490. If not, the procedure sets the error message field, gtdmsg, equal to "INVALID TDT FORMAT'D (Block 46450~, closes the TDF file (Block 46460) and exits the procedure with an error (Block 46~70) .

At Block 46490, the procedure gets the first header extension record from the T~F file using the TDTGET
proc~dure (Figure 2~, BlocX 16140~. The first header extension record is moved from the buffer area into the corresponding TDF header workarea in the GTD transaction vie.w (block 46500).

The procedure then gets the second header extension record ~rom ~he TDF file ~Block 46510), again using the TDTGET proc~dure. The ~econd header extension record is moved ~rom the buffer area into the TDF header workarea in th2 GTD transaction view (Block 46520), and index "e" is pointed to the beginning of the STDE table [Block 46530), the m~mory copy of the TDF entry records.

2~23 ~ ~0 Blocks 46540 through 46650 initialize the STDE table from the componen~ records in the TDF. Whenever information is needed by G~D which is recorded in the TDF component records, GTD retrieves the information from the STDE table.
Any modification of the application component definitions is performed on the entries in the STD~ table. The STDE table entries ar~ later stored by GTD after the modification has completed. Since all TDF information is maintain4d in memory during execution, the TDF can be written in its entirety, thereby simplifying TDF file input and output.

Specifically, the procedure gets a record from the TDF
file (Block 46540) using the TDTGET procedure (Figure 25, Block 16140), and then checks to see if the TDTGET was successful (Block 46542). If it was successful, the procedure moves the entry record into the S~DE table at location e in the STDE table (block 46620); increments e to point to the next entry in the STDE table (block 46630);
increments the STDE entry count, nent (block 46640); and returns to Block 46540. I~ it WZ15 not successful, the procedure jumps to Block 46660. I~ the TDTGET procedure was successful, the procedure checks to see if the buffer is blank (Block 46543).
.
I~ the buffer is not blank, the procedure ch~cks to see if the STDE table is full (Block 46560). If it is not full, the procedure jumps to Block 46620. If the STDE table it is full, the procedure sets the error message field, gtdmsg, :-:
equal to i'STDE TABLE FULL"(Block 46570), closes the TDF file (Block 46580), and exits the procedure with an error (Block ::
46590).
.. .:
If the buffer is blank, the procedure continues to Block 4~620 where the procedure closes the TDF file, generates the transaction view (Block 46670) using procedure TI-13766 147 .-.~:

a . ~
7 ~

GTVW (Figur~ 26, Block 8200), set~ the message field, gtdmsg, to blanks (Bloc~ 46690), and exits procedure GTDT.

R~AD ~DF ~ECORD: TDTGET PROCED~R~. Accordin~ to Figures 25a-b, which depect a flowchart of the preferred embodiment of the present invention, the GTD TDF input procedure hegins by setting the buffer to blanks (Block 16180) and reading the 4 byte header from the transaction definition file ~TDF). Decision Block 16190 checks to see i~ the read was successful. If it was not successful, the error me6sage, GTDMS~, is set equal to "MAPLIB READ ERRORI' (Block 16200) and the procedure is exited with an error (Block 16210). If the read was successful, the record len~th is set to equal the length in the ~irst two bytes of the header in BIG_ENDIAN ~ormat (Block 16260). The bu~fer length is set to equal the record length minus the 4 byte h~ader (Block 16280). The TDF is read to fill the buffer to the length indicated in buf~er length (Block 16320) and the procedure checks to see if the read was successful (BlocX
16325). If it was not successful, 1:he error message out, 5TDMSG, is set equal to 'IMAPLIB REAI) ERROR" (Block 16330) and the procedure is exited with an error (Block 16340). I~
the read was successful the program exits procedure TDTGET
(Block 16360).

GENERA!I!E: TRA~AC~ION VI~ GTVW PROCEDUR~: .
Considering now Figures 26a-e, which depict a ~lowchart of the preferred embodiment ~f the present invention, the GTD
tran~ction view procedure blanks the buffer area (Block 8260) and puts the SRCLIB path name from gtdslib into the transaction view file name, variable GTDCMEM, (Block 8280) using GTDSLIB. Then the procedure checks to see if GTDCMEM=blank (Block 8300). If GTC~EM is blank, the program sets the error mes~age field, GTDMSG, to "INVALID TRAN VIEW
NAMEI' (Block 8310), and exits the procedure with an error . .

~ ;~
~ ~ 2 J ~

(Block 8320). If GTDCMEM is not blank, a completed transaction COBOL view name is built using the current machine standard conventions (Block 8340). GTD is written on each platform to comprehend the conventions required by the operating system. Once the transaction view name is built, the program checks to see if th~ transaction view file already exists (Block 8390). If the transaction view does exist, the error message field, GTDMSG is set to "TRAN
VIEW(cpy) EXISTS" (Block 8400) and the program exits the procedure with an error.

If the transaction view file does not exist, the procedure attempts to create a transaction view file (Block 8440). If the create is not successful, the program sets the error messag2 field, GTDMSG, to "TRAN VIEW(cpy~ create FAILED" (Block 8450) and exits the procedure with an error (Block 8460). If the create was successful, an index is initialized to point to the first line of the skeleton program ~Block ~490). This line is checked to see if it is the last line of the skeleton program (Block 8500). If it is, the procedure jumps to Block 8620. If it is not, this line is copied into the output buffer (Block 8530), and terminated (Block 8660).

The output buffer is then written to the transactior~
view file (Block 8560~, and the procedure checks to see if the write was successful (Bloclc 8565). If the write was successful, the procedure increments the index to point to the: next line of the ~keleton transaction view record, and moves back to Block 8500. If the write was not successful, the error message f ield GTDMSG is set tol' TVW . cpy WRITE
ERROR" (Block $570).
,.
: At Block 8620, the procedure closes the transaction view ~ile and builds a completed transaction C view file name using t~e current machine standard conventions (Block .': ' -:; ' 8640). Once the transaction view name is built, the program checks to see if the transaction view file already exists (Block 8710). If the transaction view exists, the error message field, GTDM5G is set to "TRAN VIEW(h3 EXISTS" (Block 8720) and the program exits the procedure with an error (Block 8730).

I~ the transaction view file does not exist, the procedure attempts to create a transaction view file (Block 8760). If th~ create is not success~ul, the program sets the error message field, GTDMSG, to "TRAN VIEW(h) create FAILED" (Block 8770) and exits the procedure with an error (Block 8780). If the create was siuccessful, an index is initialized to point to the firsit line of the skel~ton progra~ ~Block 8810). This line is checked to see if it is the last line of the skeleton program (Block 8820). If it is, the procedure jumps to Block ~940, closes the transaction view file, and exits procedure GTVW (~lock 8950). If it is not, this line is c:opied into the output buffer ~Block 8850) 1 and terminated (Block 8870).

The output buffer is written t:o the transaction view file (Block 8880) r and the procedure checks to se~ if the write was successful ~Block 8885)o If the write was successful, the procedure increments the index to point to the next line of the skeleton transaction view rec~rd, and returns to Block 8820. If the write was not successful, the error message field GTDMSG is set to "TVW.h WRITE ERROR"
(Block 8890~, the transiac~ion view file is closed (Block 8940), and the program exits the procedure (Block 8950).
: , : ~DIT ~R~BAC~IO~ PA~AM$TBR~: ~T~ PROCED~R~. Considering --Figure 27 which shows a flowchart of the preferred embodiemnt of the procedure, the -GTD edit transaction parameters procedure accepts user input in the the GTD
transiaction view ~ields on the panel that corresponding with , r~ .
r~ 3 the TDF header, the TDF first header extension t and the TDF
second header extension. ThP user information defined on the screen is eventually stored in the TDF f ile. When the TDF
is first defined, GTD defines a sufficient number of default values to de~ine a working TDF. These values can be customized by the u~er for special situation~. Validation is performed and incorrect input is corrected.

Procedure ETP begins by performing the procedure to display a panel (Figure 21, Block 47300) electing to display the GTDETD panel (B1GCk 102980). This panel contains the TDF header fields described above. The procedure translates :
the user input fields GTDLMEM, GTDHDR, and GTDHDG into uppercase (Block 102990) and checks to see if the release number, GTDR~LN, field is valid (Block 103020). If GTDRELN
is invalid, the procedure replaces any illegal characters with default character " " (blank), and proceeds to Block 103070. If GTDREhN is valid, the procedure continues to Block 103070, where the FE procedure (Figure 22, Block 48130) is performed to check for user input end indications.
If an end is not indicated (Block 103080), the procedure returns to Block 102980. If an end is indicated ~he program exits procedure ETP.

' ' , .

,:
: :
:: ::

,: ' ,.:

.3 ~ DIT PAN~ LI~. This procedure is a third level procedure which provides a display panel which includes information from the TDF panel record type. This informatisn characterizes a panel entry definition and is displayed on ~he panel in a list. Since more panel entries may be defined than may be displayed at one time, facilities are provided to allow navigation through the panel list.
Function~ are also provided for adding new panel de~initions, modifying current panel de~initions, deleting current panel definitions, displaying current definitions, and editing the panel map.

This procedures presen~s the application designer with a list of the panels within the TDT. Each panel entry can include an input procedure and an output procedure. The designer can add, change, delete, or edit en~ries within this list. System-provided entries (e.g., MEMU, HELP, GLOS, and INFO support) cannot be changed.

To delete an entry from the panel list, a 'D' is entered in the select field.

To add an entry to the panel list, an 'A' is entered in the select field. The user completes the 'ADD PANEL' screen by providing a panel name, an inpu~ procedure, and an output pxocedure (optional~. When the 'ADD PANEL' pan~l is completed, this entry will be inserted into the TDT and the updated pan~l list presented.
:
To change an entry to the panel list, a 'C' is entered in the select field. The user makes changes as necessary to the 'CHANGE PANEL' panel. When the 'CHANGE PANEL' p~nel is completed, these changes will be inserted into the TDT and the updat~d panel list presented.

2 ~1 ~ r~ () To edit an entry in the panel list, an 'E~ is entered in the select field for the desired panel. This pres~nts the panel for Edit with the CODEST~R editor. If the panel does not exist when an Edit i5 requested, a default panel will be generated and presented for edit.

Figures 2~a-f depict the flowchart of the preferred embodiment of the EP procedure, d~tailing these functions further.

The GTD edit panel list (EP) procedure begins by scanning the selec~ ~ield for the locate command input by the user. The locate name is ~aved in the dname field of the transaction view~ This locate name is us~d as the initial panel sntry to be displayed in the edit list. If there is no locate command, dname is set to blank (Block 103240). The following display area ~ariables are blanked tBlock 103260):
select, variable gtdsela; name, variable dnamea; input proc, variable dipnm; and output proc~ variable dopnm. The return code, RC, and number of panels, NP, are initialized (block 103330) and the panel table, TP, is blanked (Block 103360).
The STDE table is scanned, adding the! menu and panel entry names to the TP, counting the number o~ entries added ~o the tablej and saving this number in the TP. The TP contains a unique list of panel and menu names sorted in ascending order. The index for the number o~ panels in the panel table, i, and the index for the soreen edit list, j, are initialized to zero ~Block 103570).
,. .
~: . .
Blocks 103580 through 103725 constitute a process by which the initial panel list item to be dispIayed on the scre~n is located in the panel list table. Then the initial panel name and as many subsequent panels names as will fit on the display panel are placed in panel list display fields with~ the corresponding panel characterization information from the STDE table for each panel ~ntry displayed. The ~02~7~

process is finished when all panel names up to the end of the list or all panels names which will fit on th~i screen and their characterization data, have been placed in the display field~.

Decision Block 103580 checks to see if i is greater than or equal to the number of panels in the panel table.
I~ i is greater than the number of panels in NP, the procedure jumps to Block 103750. If not, the procedure checks to see if j is greater than or equal to the number of procedure entries (16) which will fit on a scr en (Block 103590). If j is greater than or equal to 16, the procedure jumps to ~lock 103750. If not, the procedure checks to see if the current panel in the panel ~able is greater than or equal to the next panel, dname, requested by the uier (Block 103595). If the current panel name is not greater or equal to the next panel name, the procedure jumps to Block 103720.
If thei current panel name is greater or equal to the next panel name, the jth item in the edit list is initialized to the following values: panel name, variable dnamea = TP at index i; input procedure, Yariable IETIMENU; and output procedure, varia~le IETIO~ENU (Block ~3610)~

The procedure scans the STDE table entries for a panel entry with tha current panel name, STDETYP=P and TP(i)=STDENAME (Block 103640)o Decision Block 103650 checks to sse if the search was successful. If it was, the procedure initializes the jth item in the edit list to the following values: input procedure, dipnm(j) = STDEIPNM:
output procedure, dopnm(J) = STDEOPNM (Block 103660) and increments j (Block 103700). If the search was not successfull the procedure just increments j (Block 103700).
Block 103720 increments ind x i and then returns to Block 103580.

:Blocks 103775 through 10403S constitute a process by .

which ea h user request for each panel list item is examinedO If an add, delete, change, or edit request is identified, then the appropriate task is performed. Th~
process is complete after the requests have been identi~ied and performed for each panel in the list.

J is initialized to zero (Block 103770) and the procedure checks to see if j is greater than or equal to the number of procedurP entries (16) which will fit on a screen (Block 103775~. If ~ is greater or equal to 16, the procedure jumps to Block 104040. If no~, the procedure checks to s~ i~ there is an add panel r quest, GTDSELA =
'a' or 'A' (Block 103810).

If there is an add request, a panel is displayed requesting the panel characterization information as described in the panel record type of the TDF. The input values are validated. This typically involves translating the panel name, input and output procedures, and option flag to upper case and ensuring that the option flag value is either "~" or "N" (yes or no). The option flag value d~termines if the panel should be generated with or without an option ~i~ld. After the input values are validated, an attempt is made to add the new panel entry to the STDE table for later storage in the TDF using the process described in Figure 24, Block 45910. Once the panel is added, the procedure jumps to Block 104030. If there is ns add requ-st, the procadure checks to 5e8 if a cha~ge panel request GT~SELA - 'c' or 'C' (Block 103860).

~ If there is a:change request, the change request panel name is verified. A change request can not be performed if the panel is a system~defined panel, or if the panel is not :defined in the STDE table. By not permitting changes in definition to system-defined panels, GTD ensures that the IET will operate on these panels as intended. If the panel ~ TI-13766 155 ,r~ ,r ~, is not a system panel and is listed in thP STDE table, then the values in the STDE panel entry are copied into the work area fields which correspond to a STDE entry, and a panel is displayed requesting changes for the panel characterization information. The input values are validated in similar fashion to the as add panel request of ~Block 103810), and moved back into the ST~E entry to complete the change. The only change the user is not permitted to perform with this implementation is a change to the panel name, although this change could easily be per~ormed by deleting the old ST~E entry and adding the n2w STDE entry. Once tAe panel is changed, the procedure continues to Block 104030.
If there is no change request, the procedure ~hecks to see if there is an delete panel request, gtdsela = 'd' or 'D' (Block 103910~.

If there is a delete request, the delete request panel name is verified. A delete request can not be perfo~med if the panel i5 a sys~em-defined panel, or if the panel is not defined in the STDE table. By not permitting deletions for system-defined panels, GTD ensures that the IET will operate as intended. If the panel is not 21 system panel, ~nd is listed in the STDE table, then the panel is simply deleted by overwriting the delet~d entry with the later ~ntries in the STDE table. The STDE entry count, nent, is decremented.
once the panel is deleted, the procedure proceeds to Block 104030.

I~ there is no delete request, the procedure checks to s~e if there is an edit panel request, gtdsela = e' or 'E' (Block 103960). If th~re is an edit reguest, the edit panel ~Fiyure~ 29, Block 10541~) procedure is performed, and the procedure proceeds to Block 104030. 1~ t~er~ is no edit request, ~he procedure increments j (~lock 104030~ and returns to Block 103775.
; Block 104040 performs the FE procedure (Figure 22, . .
: .

~ a ~ 3 Block 48130~ to check for us~r input ,end indications~ If an end is not indicated (Block 104045), the procedure returns to Block 103240. If an end is indicated, the program exits procedure EP.

BDI~ PANEL: EP~ 2ROCED~RB. Looking now at Figure 29, which shows a flowshart of the preferred embodiment of this procedure, the ~TD e~it panel procedure begins by searching for the edit panel name in the STDE table (Block 105460). If the search is not success~ul, the program returns ~rom the procedure without an error. If the search is successful, the procedure saves the panel name in variable GTDPMEM
(Block 105550), builds a panel map file name (Block 105560), and checks to see if the ~ile exists ~Block 1057S0). I~ the file does not exist, the procedure generat~s a skeleton panel and goes to Block 105730.

Panels, or map sour~e records, are g~nerated in the ~ormat required by the map services employed. Specifically, the definition of each map record is built in a buffer using hard-coded specifications for each type of panel being generated (menu, glossary, informati.on, help, or skeleton panels), and then written out to a map file. Specifications written into the map sourc~ include field names, field types, field row and column information, ~ield lengths, field attxibutes and literal data. All these speciifications are hard coded for each type of panel and are written out to the file in the most convenient manner. The details o~ the logic to gen~rate the maps in the format required by the map services employed are map service dependent and will not be discussed herein.
.
Skeleton panels are created with the following fields def ined in the IE~TVW and required by th~ IET:

r~ . æ

c IEFl-TRAN, IEFl-PANEL, IEFl-SYSTEM, IEFl-CU~ROW, IEFl-CURCOL, IEFl-FUNKEY, IEFl-CURDT, IEFl-MSGID, IEFl-MSGTX, IEFl-MSGTX, IEFl~MSGAE, IEFl-USER, IEFl-OPTION
(optionally generated when gtdgof = Y), IEFl-LOOKAHEAD
(optionally generated when gtdglf = Y) If the file does exist, the procedure continues to Block 105790. The procedure builds the panel edit parameters a~d file names (Block 105790), and invokes the map editor (Block 106210). Block 106~30 checks to see i~
the map edit is successful. If the map edit i5 successful, the program exits procedure ~PE. If the map edit is not successful, the procedure sets the error message field, gtdmsg, equal to ~PANEL EDIT FAILED" (Block 106240), and exits the procedure with an error.

EDIT PROC~D~R~ ~I8~. This procedure is another third level procedure which provides a display panel which includes inforimation from the TDF procedure record type.
This in~ormation characterizes a procledure entry definition and is displayed on the panel in a list. Since more procedure entriss may be defined than may be displayed at one time, facilities are provide to allow navigation through the pro~edure list. Functions are also provided for adding new procedure definitions, modifying current procedure definition~, deleting current procedure definitions, displaying current definitions, and editing the pro~edure :map. System-provided entries cannot be changed. ~:

~ o add an entry to the procedure list, an 'A' is entered in the select field for a procedure. The user completes the 'ADD PROCEDURE' panel by providing a procedure -name, a procedure description, a name of profile view asso~iated with procedure, a name of input view associated with procedure, and a name of output view associated with r~ ,S~
~ 'J~
procedure (if any).

The procedures can be identified as one of several types:

COB2 COBOL procedure. Will be processed by the COBOL II compiler using GTD options 4.5, 4.6, 4.8, and 4.9.

C C procedure. Will be processed by C compiler using GTD options 4.5, 4.6, 4.8 and 4.9.

AL~ Assembly language procedure.

EXTERN External procedure. Procedure is candidate to be LINKed-to by a procedure within this transaction.
.

ENTRY Procedure contained within another procedure in the transaction.

As other languages are employe~, additional types of prscedure6 may be identified.

A procedure can be designated as a relational data base (DB~ procedurs and be processed by the appropriate pre processor during the compile options. When the 'ADD
PROCEDURE' panel is completed, the entry will be added, and :the :updated procedure lis~ presentedO

To~delete an ~entry from the procedure list, a 'D' is entered in the s~lect ~iPld.
:
: : .
~ To change an entry to ~he procedure li~t, a 'C' is : entered in the select field. The user makes change~ as :: : `
: ~neeessary to the 'CXANGE PROCE RE'~panel. When the 'CHANGE
; TI-13766 159 : ::

''''"" '' 1''; ~ "` '''''''''''1''' ' 2 ~ r3 ~3 PROCEDURE~ panel is completed, the changes will be inserted into the TDT and the updated panel list presented.

To edit an entry in the procedure lis~, enter 'E' in the select field for the desired procedure. If a COB2 or C
procedure does not exist when it is requested for edit, a default procedure will be prepared and presented.

Figures 30a-f depict the flowchart of the preferred embodiment of the EC procedure detailing the~e functions further.

The GTD edit procedure list procedure begins by scanniny the select field for the locate command input by the userO The locate name is saved in the dname field of the transaction view. This locate name is used as the initial procedure entry to be displayed in the edit list. If there is no locate command, dname is set to blank ~Block 106680).
The following display area variables are blanked (Block 106690): select, variable gtdsela; name, variable dnamea;
input view, variable ~ipnm; output view, variable dopnm;
pro~ile view, variable dpvnm; procedure ~ype, variable gtdcty; rdbms flag, variable gtddb2: and debug flag, variable gtdxpd. The index for the screen edit list, j, is initialized to zero, and the pointer, e, i~i initialized to point~to the beginning of the STDE table ~ 91Ocks 106815 through 106935 constitute a process by which th~ initial procedure list item to be displayed on the screen is located in the STDE table. Then th~ initial procedure name, and as many subsequent procedures namesi as ;will fit on the display procedure, are placed in procedure list;~display fields with the corresponding procedure ch~racteri~ation information from the STDE table ~or each ~procedure entry displayed. The process is finished when all procedure names up to the end o~ the list, or all procedures .~ '' 2 ~ 3 names which will fit on the screen, and their characterization data have been placed in the display fields.

Decision Block 106815 checks to see if e points beyond the end of ~he STDE table. If so, the procedure jumps to Block 106940. If not, ths procedure checks to see if j is greater than or equal to the number of procedure entries (16~ which will fit on a screen (Block 106830). If j is greater than or equal to 16, the procedure jumps to Block 106940. I~ not, the proceidure checks to see if the current procedure, STDETYPE=C, in the STDE table has a procedure name, ST~ENAM~, greater ~han or equal to the next procedure name, dname, requested by the user (Block ~06835). If the current procedure name is not gr~ater or egual to the next procedure name, the procedure continues to Block 106930. If the current procedure name is greater or equal to the next procedure name, the jth item in the edit list is initialized to the following values: name, variable dnamea = ST~ENAME;
i~put view, variable dipnm = STDEIPNM; output view, variable dopnm = STDEOPNM pro~ile view, variable dpvnm - STDEPVNM:
procedure type, variable gtdcty = STDECTYP; rdbms flag, variable gtddb2 = 5TDECDB2: and debug ~lag, ~ariable gtdxpd = STDECXP~ (Block 106840). J is incrlemented (Block 106910), e is incremPnted ~o point ~o ~he next STDE entry, and the procedure returns to Block 106815.

Block 106g40 performs the procedure to display a panel :(Figure 21, Block 47300) electing to display the GTDEC
panel.

~ locks 106955 through 107140 constitute a process through which each user request for each procedure list item is examined. If an add, delete, change, or edit reque~t i~
: identified, then the appropriate ta~ is performed. The : ~process is complete after the requests have been identified .
: TI-13766 161 .

f~ ;~

and perfoxmed for each procedure in the list.

J is initialized to zero (Block 106950j and the procedure checks to see if j is greater than or equal to the number of procedure entries (16) which will ~it on a screen (Block 106955). If j is greater or equal to 16, the procedure jumps to Block 107210. If not, the procedure checks to see if there is an add procedure request, gtdsela - 'a' or 'A' (Block 106990). If there is an add request, the add procedure (Figure 31, Block 107330~ is performed on the displayed procedure identified by index j (Block 107020) and the program proceeds to Block 107200. If there is no add request, the procedure checks to see if a change procedure request gtdsela = 'c' or 'C' (Block 107040). If there is a change request, the change procedure (Figure 32, Block 1084703 is performed on the displayed procedure identified by index j (Block 107070~ and the procedure proceeds to Blsck 107200. If ~here is no change request, the procedure checks to see if there is an de:lete procedure request, gtdsela = 'd' or 'D' (Block 107090).

If there is a delete reques~, the de:Leke request procedure name is verified. A delete request can not be performed i~
the pro~edure is a system-defined procedure, or if the procedure is not defined in the STDE table. If the procedure is not a system procedure, and is listed in the STDE table then the procadure is deleted by overwriting the deleted entry with the later entries in the STDE table. The 5TDE
entry count, nent, is decremented. Once the procedure entry is deleted, ~Block 107120) the program proceeds to Block 107200. If there is no delete request, ~he procedure checks to see if there is an edit procedure request, gtdsela = 'e' or 'E ~Block 107140). If there is an edit request, the edit procedure (Figure 34, Block lU9440) is performed on the displayed procedure identified by index j and the procedure jumps to Block 107200. If there is no edit request, the 3 ~ ~
procedure increments j (Block 107200), and returns to Block 106955.

Block 107210 performs the FE procedure (Figure 22, Blo~k 48130) to check for user input end indications. If an end is not indicated (Block 107215), the procedure returns to Block 106680. If an end is indicated, the program exits procedure EC.

ADD P~OC13D~ IJ8E~ I~TERFACE: ECA PROCEDU~
Considering now Figure 31, which depicts the preferred embodiment of this procedure according to the present invention, the GTD add procedure user interface procedure begins by blanking the work area field corresponding to the STDE entry fields (Block 107330). The procedure performs the procedure to display a panel (Figure 21, Block 47300) electing to display the GTDAC panel (Block 107440) requesting the user to define the procedure characterization information as described in the procedure record typ2 of the TDF.

The procedure entry fields are validated (Block 107450). The validation includes tra:nslating the procedure name, input, ou~pu~ and profile view~s, and procedure type, ~data base procedure flag, and debug flag into upper case.
he profile view nam~, data base procedure fla~, and debug flag are:blanked out when a procedure is de~ined to have a ;type o~ EXTERN. The data base flag and debug flag are blanked out:when a proceduré is defined to have a type of :ENTRY.~ A11 ~ields, data base procedure flag a~d debug ~lag, which have a required value of~:either "Y" ox "~", are redefined to have a val~e o~ "N~ the value defined by the user is not "Y". The procedure language typ is de~ined to be C if the language defined by by the u er is not COB2 ALC, :or C.
: TI-13766 163 :

2~a~

Block 107460 performs the FE procedure (Figure 22, Block 48130) to check for user input end indicationsO If an end is not indicated (Block 107470~, th~ procedure returns to Block 1074~0. If an end i5 indicated, the procedure is added to the STDE table (Block 107510) for later storage in the TDF~

An attempt is made to add the procedure entry to the ST~E. The attempt will fail if the procedure name provided is blank, if the STDE table is full or if the procedure name provided already exists in the table. If no error is detected, the procedure entry i5 inserted in the STDE table in ascending procedur2 sequence as described earlier. The STDE entry count, n,ent, is incremented. Once the procedure is added, the program exits procedure ECA (Block 107520).

An attempt is made to add the procedure entry to the STDE. using the process describ~d in Figure 24~ Block 46040.
once the procedure is added, the program exits procedure ECA
(Block 107520).

CE~ P~OCEDURE ENTRY: ~CC PROCED~ Looking now at Figures 32a-b j which show the preferr~d embodiment of the procedure, a flowchart of the ECC procedure provides the capabili~y to change the procedure characterization information as stored in the TDF and to edit the user input, output and profile view files.

The GTD change procedure entry procedure begins with Dacision Block 108490 checking if the input procedure name i~ a system procedure. System procedure~ include IETIHELP, IETOHEL,P, IETIINFO, IETOINFO, IETIGLO~, and IETOGLOS. If it is a~ system procedure name, then the GTD returns from procedure ECC with no error. If not, procedure ECC searches .

.:
.-~2~
the STDE table for the input procedure name tBlock 108670).Decision Block 108730 checks to see if the input procedure was found. If not, the GTD returns from procedure ECC with no error. If the procedure is ~ound, the STDE entry is copied into the corresponding work area fields (Block 108760).

Block 108780 displays the change procedure entry definition screen panel (GTDCC) procedure display (Figure 21, Block 47300) containing th~ TDF procedure characterization in~orma~ion for modification. Block 108790 validates the procedure entry fields using the proce~s described in Figure 31, Block 107450. Blocks 108800 through 108820 handle the user request for editing of the procedure view files. A view file contains a list o~ all the transaction view variable ~amPs which the user determines are required for input, output, o~ profile view processing by the IET. Decision Block 108800 checks if the edit input view was requested. If so, construct the fully qualified input view name is constructed and the input view edited using procedure do-edit (Figure 32, Block 43860). The procedure then continues to Decision Block 108810 to check if an edit output view was requested. If so, the fully qualified output view name is constructed and ~he output view edited u ing procedure do-edit (Figure 32, Block 43860). The procedure advances to Decision Block 108820 to check if the edit pro~ile view was requested. I~ so, the fully qualified profile view name is constructed ~nd the profile view edited using procedure do-edit.

At Block 108830, th~ FE procedure (Figure 22, Block 48130) is executed to check for user end indications.
~ecision Block 108B40 then check~ if end is indicated. If not, the procedure returns ~o Block 1087~0. If end is indicated, then the program con~inues to Block 108870 where the STDE work area fields are copied back into the ST~E
~ TI-13766 165 .

~ ~ ~ 3 7 ~
entry, and the program exits procedurle ECC (Block 108890).

Gq'D E:DIT FILE~ DIT PROS EDIJRE:: Continu.ing now to Figure 33, which shows a flowchart of the preferred embodiment of this procedure according to the present invention, this do-edit procedure takes a fully qualified file name as input for editing.

The GTD edit filename procedure begins by building editor parameters (Block 44120) and then invoking the editor for the procedure (Block 44240~. The edit parameters vary according to the editor being used. Generally all that would be required is the name of the editor (either unqualified or ~ully qualified), and the fully gualified name of the file to invoke the editor. This depends on the operating ~ystem platform and the editor being used. The name of the editor being used is stored as part of the en~ironment information loaded at the beginning of the program and may vary. Decision Bloc:k 44310 checks i~ the edit was success~ul. If it was, the! procedure do-edit i5 ended (Block 44880). If the edit was not successful, the error message field is set to GTDMSG= PROCEDURE EDIT FAILED
(Blork 44320). The procedure then returns with the error mes~age (Block 44330). , ~ TD ~DIT: EC~ PROC~DUR~. Looking now at Figures 34a-b, which depict a flowchart:of the preferred embodiment of this proceidure, the GTD edit procedure begins by searching for the requested edit procedure name in the STDE table. Block 109530 checks :to see if the search was successful. If it was not, the program exits:the procedure without error. If the search was successful, the procedure checks to see if the~ procedure language is COBOL. If it is not a COBOL
progxam, the procedure proceeds to Block 109750. If it is a : -: TI-13766 166 ~;

~ a r~ ~
2 ~

COBOL program, the procedure builds a COBOL procedure file name (Block 109580), and veri~ies the procedure file exists (Block 109670). I~ the file exists (Block 109675~, the procedure jumps to Block 109750. If not, the procedure saves the procedure name in gtdpmem (Block 109680), and generates (Block 1096~0) a skeleton program using the GCOBPROG procedure (Figure 35, Block 7400). The program then jumps to Block 109900, to do the edit.

Block 109750 checks to see if the procedure is in C
language. If it is not, the procedure continues at Block 109930. If it is in C, the procedure builds a procedure file name (Block 10g760), and verifies the procedure file exists (Block 109850). If the file exi~sts (Block 109855), the procedure proceeds to Block 109860. If not, the procedure saves the procedure name in gtdpmem (Block 109860~, and at Block 109870 generates a skeleton program using the GCPROG procedure (Figure 36, Block 114950).

Block 109900 performs the do-exit editor procedure (Figure 33, Block 43860) on the procedure file, and the program exits the procedure (Block 109930).

GE~RA~I!E COBOL PROGRI~N: GCOBPROG PROCE~DlJRE~ .
Considering next Figures 35a-c, which depict the preferred embodiment o~ ~his procedure, the GTD generate COBOL program procedure begins by putting the COBOL procedure path name from~ gtdslib into the COBOL procedure file name (Block 7460). Then the procedure checks to see if the COBOL
procedure name is undefined, gtdpmem is blank ~Block 7490).
If gtdpmem is blank, the program exits the procedure with an error. If gtdpmem is not ~lank, a fully qualified COBOL
procedure name file is built using the machine standard conventions (Block 7520). Once the COBOL procedure name is built, the proyram checks to see if the procedure already q'I-13766 167 ~ , El~
2 ~ 2 ;} ~ 7 ~

exists (Block 7580). If the procedure does exist, the error message field, GTDMSG is set to "COBOL PROGRAM EXISTS"
(Block 7590), and thP program exits the procedure with an error. If the procedure does not exist, an attempt is made to create the COBOL procedure file (block 7630). If the create is not successful, the program exits the procedure with an error. If the create was succ~ssful, an index is initialized to point to the first line of the skeleton progr~m.

Decision Block 7670 checks for the end of the skeleton program initializa~ion data (block 7670). If it is at the end of the initializa~ion data, the procedure closes the COBOL procedure file (Block 7910) and exits procedure GCO~PROB (block 7920). If it is not at the end, this line is copied into the output buffer (Block 7700).

At this polnt the buffer contents are examined tD
locate the ~keleton COBOL procedure lines which need customizing for the application. In thle preferred embodiment o~ the present invention, the progra~m id, the transaction view copy file, and the first section name are customized.

Th~ line moved into the output buffer i~ checked to see if it is line 003000 of the skeleton program (Block 7710).
1~ it is line 003000, the program id, assumed to be defined on this line, is set ~o the procedure name and the procedure moves on to Block 7B400 If it is not line 0003000, the procedure:checXs to see if the line moved into the output buffer is line:o01200 of the skeleton program ~BIock 7740).
If so,~ the:copy statement is set to the transaction vi~w name~and the procedure:proceeds to Block 7840. If it is not line 091200, the procedure checks to see if the line moYed into the output buffer is line 001800 of the skeleton progr~m (Block 7770). If it is, the section header is set to contain the procedure name and the procedure continues to , :, ., ... . , . , .. ,, .,, . . , .. . . ... .. ... . . . ... .. . . , . . , , ~ . ~ . . .. . .... ... . .. . .

rJl ~

Block 7840. If it is not line 001800, execution continues with Block 7840 where the procedure terminates the line in the output buffer by placing a new line character at the end of the line. This line termination is a UNIX convention.
Other terminal conventions may be used, such as filling a line with line spaces (a main frame).

The output buffer is then written to thP COBOL
procedure file (Block 7850), and the procedure checks to see if ~he write was successful (Block 7855). If 50, the procedure increments the index to point to the next line of the skeleton program and returns to Block 7670. If the write was not successful, the error message field GTDMSG is set to "COBO~ PROGRAM WRITE ERROR" (Block 7860~, the COBOL
procedure file is closed (Block 7910). The program then exits the procedure (Block 7920).

GTD GENER~E C PROGRA~: ~CPRO~ PROCEDURE: Looking now at Figures 36a-c, which show the preferred embodiment of this procedure according to the present invention, the GTD
generate C program procedure begins by putti~g the C
procedure pathname, gtdslib, into the C procedure ~ile name (Block 115010). Decision Block 115040 checks t~ see if the C procedure name is undefined, gtdpmem is blank. If bla~k, the procedure is exited with error. If not blank, the procedure name is validated by converting to uppercase. I~
valid, a fully qualified C procedure file name is built with procedure name gtdpmem and current machine standard naming convPn~ions (Block 115180). Decision block 115130 chacks if the C procedure file exists. If not, the procedure continues to Block 115180. If the C prbcedure file exists, the procedure sets the error message field GTDMSG equal to "C PROGRAM EXISTS" (Block 115140) and exits the procedure file (Block 1151501-Tq-13766 169 r^^~
r~ ~

Block 115180 creates the C procedure file. Decision Block 115190 checks whether the create was success~ul. If not, the proyram exi~s the procedure with error. If the create was suc~ess~ul, the index is initialized to point to the first skeleton program line initialization data (Block 11521~).
Decision Block 115220 checks ~or the end of the skel2ton program initialization data. If the end o~ the initialization data is found, the procedure jumps to Block 115490. If the end of the initialization data is not found, then the pro~edure copies the line of skeleton program into the output buffer (~lock 115250). Decision Block 115270 checks if the line of skeleton C program in the buffer contains the transaction view include statement. If so, the transaction view name is cu~tomized to refer to the application C transaction view ~ile name. I~ not, Decision Block 1153~0 checks whether the line o~ skeleton C program contains the procedure name for the skeleton C program. I~
so, then the procedure name is customized to re~er to the application C procedure name. If it does not contain the procedure name, then execution continues with Block 115410 by terminating the line in ~he buffe!r. The program writes -the buf~er to the C procedure file (Block 115430) and checks i~ the write was successful (Bloc:k 115435). I~ write is successful, the program incr~ment~ ~he index to point to the next ~ skeleton procedure line (Block 115470) and then return to 81Ock 115220. If the write is not successful, the procedure sets the error message field GTDMSG=3'C PROGRAM
WRITE ERROR" (block 115440). The program then closes the C
procedure file (Block 115490) and ends procedure GCPROG - -~Block 115500~.

DIT MB~ ~I8T. This procedure is another third level procedure which provides a display panel which includes nformation from the TDF menu record type. This information characterizes a menu entry definition and is displayed on :: .
, 2 ~

the panel in a list. Since more menu entries may be defined than may be displayed at one time, facilities are provided to allow some navigation through the menu list. Functions are also provided ~or adding new menu definitions, modifying current menu definitions, deleting current menu definitions, and displaying current definitions.

ÇTD optio~ 1.4 presents the application designer with the 'EDIT MENU' panel. The designer can edit entries within th~ four level hierarchy of menus supported by the GTD
systemO Upon initial request, the Master Menu for the transaction will r~quire appropriate select codes, descrip~ions, a panel to be presented when a selection is made, and a procedure to be invoked when an entry is selected (optional).

To add an entry to the menu, an 'A' is entered in any select field. This presents an 'ADD MENU ENTRY' panel, allowing addition of a select code, a description, a panel to be presented when selection i~ made, or a procedure to be invoked when e~try is selected (optional1. When the 'ADD
ME~ ENTRY 9 panel is completed, th~ entry is added, and the EDIT MENU panel will be presented.

To delete an entry from the menu, a 'D' is entered in the selec~ field.

~ o change an entry to the menu, a 9 C / iS entered in the select field. ~he user make~ changes as necessary to the 'CHANGE MENU ENT~Y' panel which allows changes to the description, panel name, or output procedure name. When the 'C~ANGE~NæNU ENTRY' panel is completed, the changes will be incorporated, and ~he EDIT MENU panel presented.
.
~:
The GTD system supports four levels of menusO To select a lower level menu to be edited, enter a selection ~ TI-13766 171 r~
~ ~ 3 ~ 7~

sequence in the form S(select.select.select~ in the command line of the ~EDIT MENU' panel. ~his specifies the menu within the hierarchy the designer wants to edit. This is a cumulative process. The designer must define the Master Menu first and indicate an entry on the Master Menu is intended to reference a sub-menu by specifying an entry selection code, description field, and panel name that will be the name of this sub-menu, leaving the output procedure name blank. This continues (repeats) for up to four levels.

Figures 37a-d depict the flowchart of the preferred embodiment of the EM procedure detailing these functions further. --The GTD edit menu hierarchy procedure begins (Block 110320) by copying the last menu hierarchy select reguest into the workarea select field, w.gtdsel. Block 11330 blanks the menu names and selects codes for each level of the hierarchy, then Block 110430 validates and parses the -~
selection request (if any) into select codes for each level in the hierarchy. The format of a selection request i5 S(xl.x2.x3); the "S(" or "s(" is searched for as th beginnin~ of the request. If the keyword is ~ound, then each x value is located and assigned to a hierarchy ~election ccde. 5xl is assigned to hierar~hy level 1, x2 is assigned to hierarchy level 2, and x3 is assigned to hierarchy level 3). If no hierarchy level is requested then its value is left blank, indicating no request ~peci~ied for that levelr If the display request is not for the first level o~ the hierarchy (Block 110490), the program proceeds to Block 110580. If it is, Block 110500 prepares the menu display workareas with the first level menu entries, procedure EMS ~Figure 38, Block 111240) and gets the next level menu name. Block 110510 displays the first level of the hierarchy edit list and saves the next hierarchy salection request panel in GTDEM0 (displays an edit list for f~ ~ ~
i~ J~
2 ~ ~ ~v I r~

information in the first level of the hierarchy). This process involves getting the new date/time and formatting the scr~en date/time fields. The panel interpretor is called to generate the screen output. ~TDMS~ is set to blanks and the panel map interpretor is caliDd to obtain user panel input. After input i5 obtained, the user select field is saved (Block 110510).

Block 110520 executes the edit menu list, procPdure EMX
(Figure 39, Block 111640). Block 110530 checks ~or a user end indication, procedure FE (Figure 22, Block 48130). If the end is indicated (Block 110535) the program exits the procedure (Block 110890). If not, the program returns to Block 110320 and continues processingO

If the display request was not for the first level of the hierarchy (Block llO~so), Block 110580 determines if the request is ~or the second level of the hierarchy. If not, th~ program jump~ to Block 110680~ I~ it is, Block 110590 prepares the menu disp~ay wor~axeas with the first level requested menu entries, procedure EMS and gets the nex~
level menu name. Block 110600 prepares the second level menu display workareas with the second level requested menu entries, procedure EMS and gets the next level menu nam~.
Block 110610 displays the second level hierarchy edit list and saves the next hierarchy selection request on panel GTDEMl (displays an edit list for the second level menu as well as selection and description information on the previous level~ a described in Block 110510. Block 110620 execu~s the edit menu list, procedure EM5. Block 110630 checks fvr a user end indication, procedure FE. If the end is indicated (Block 1106323 the program exits the procedure (Block 110890). If not, the program returns to Block 110320 and continues processing.
.
If the display request was not ~or the second level of ,:

r^~

~2~ 7~
the hierarchy (Block 110580), Block 110580 determines if the request is ~or the third level of the hierarchy. If not, the program jumps to Block 110790. If it is, Block 110690 prepares the first level menu display workareas with the first level requested menu entries, procedure EMS and gets the next level menu name. Block 110700 prepares the second level menu display and workareas with the second requested menu entries, procedure EMS and gets the next level menu name. Block 110710 prepares the third level menu display workareas with the third level request menu entries, procedure E~S and gets the next level menu name. Block 110720 displays the third level hierarchy edit list and saves the next hierarchy selection request panel in GTDEM2 (displays an edit list for the third level menu as well as selection and descriptive information on the previous 2 level menus) using the process described in Block 110510.
Block 110730 executes the edit menu list, procedure EMX.
Block 110740 checks for a user end indication, procedure FE.
If the end is indicated (Block 110745) the program exits the procedure (Block 110890). If not, the program returns to Block 110320 and continues processing.

If the display request was not l-~or the third level of the hierarchy (block 1106~0), Block 110790 prepares the fir~t level menu display work are~ with the first level reque~t~d menu entries, procedure EMS and gets th next level menu name. Block 110800 prepares the second level menu display and workareas with the second requested menu entries, procedure EMS and gets the next level menu name.
Block 110810 prepares the menu third level display workareas with the third level request menu entries, procedure EMS and gets the next level menu name. Block 110820 prepares the forth level menu display work areas with the fourth level request menu entries, procedure EMS and gets the next level menu name. Block 110830 displays the fourth level hierarchy edi~ list and saves the next hierarchy selection request on r~
2 a ~ 7 ~
panel GTDEM3 (display and edit list for fourth level with selection and description information for the previous 3 levels) uiiing the process described in Block 110510.

In thei currently supported menu hierarchy, only four levels are supported, but more levels could be supported by extending the logic preisented here to cover more levels.
Since the sidit menu list display panel actually displays description and select information ~rom previous levels in the hierarchy, new panels could be designed to display more levels and thieireby extend the current logic and data areia usa~e. Alternati~ely, logic could be added after handling the fourth menu hierarchy to display the previous 3 levels selected and describe information for menu hierarchy levels greater than 4.

Block 110850 checks for a user end indication, procedure FE (Figure 22, Block 48130). If thei end is indicated (Block 110855) the program exits the procedure ~Block 110890)~ If not, the program returns to Block 110320 and continues pracessing.

GTD P~PAR2 NE~ DI~PL~Y: ~M~ P~OC~D~B. Figure 38 depi ts a flowchart o~ the pre~exred embodiment of this procedure, according to the present invention. The GTD
prepar~ menu display procedure initializes the display areas for the description, output panel, and output procedure for each menu en~ry in ~he curren~ menu. It takes as input ~he : name:of the current menu to be displayed, the workarea in which to place the select/description information, and the next menu select code. The EMS procedure outputs the initialized workareas for the current menu and the ~enu name :corresponding to the next menu select code.

The EMS procedur4 begins by blznking out the menu : TI-13766 175 2 ~ rl ~

display areas dnamea, dopnm, and dipnm in the workarea description (Block 111320~, then initializing j to zero and the pointer e to point to the beginning of the STDE table (Block 111400). Decision Block 111405 checks if e i5 pointing beyond the end of the STDE table. If so, the program exits the procedure (Block 111560). If e is not pointing beyond the end of the STDE table, the next Decision Block 111420 checks if the entry will fit on the screen, that is, if indPx j is greater than or equal to the number of menu entries that will fit on the screen (163. If so, the program exi~s the procedure (Block 111560). If not, Decision Block 111425 checks if the STDE entry is a menu entry (STDETYP=E) and if the STDE menu entry name STDENAME
is equal to the input menu name, menu. If not, the program exits the procedure (Block 111560). If so, the program initializes the jth item in the edit list and sets thP
following parameters: panel name is set to dnamea-STDEIPNM;
output procedure name is set to dopnm=STDEOPNM: description is set to STDESEL, ~ - ~, including the portion of STDEDESC
that will ~it in the field, (Block 111430). The next step increments index j for the panel edit list (Block 111500).
Then, decision block 111510 checks if the select code of the menu entry is equal to the next select code input value. If the menu entry is equal to the next sele~t code input value, then the procedure initializes the next menu name to the menu entry panel name, STDEIPNM (Block 111510). Otherwise, the program increments pointer e to point to the next STDE
entry (Block 111550~ and returns to Decision Block 111405 to check if e is pointing beyond end of STDE table. If so, the program exits the procedure (Block 111560). I~ not, at Block 111405, the program returns to Block 111420 and continues proces6ing. -~
'- ', GTD ~DIT NEN~ LIST: ~M~ ~ROCE~E. Figure 39 depicts a flowchart of the preferred embodim~nt of this procedure ~ .

~3 ~
~ ~ 2-- ~ r~ ~

wherein, the EMX procedure processes the user add, delete, and change menu entry request operations for the menu entry edit list display~d.

The GTD edit menu list procedure begins (Block 111670~
by initializing index j to zero and setting pointer e to t~le beginning of the STD~ table. At Block 11680, the procedure then d~t~rmines whether the e pointer has moved beyond the end of the STDE table. If so, the program jumps to 810ck 1117sO. If the e pointer has not moved beyond the end of the STDE table, the procedure determines (Block 11690) whether the entry is a menu entry (STDETYP = E) and if the menu entry name is equal to the input menu name (STDENAME =
menu~. If not, the procedure continues at Block 1117c~iO, to examine the next entry in the STD~ table. If it is, the procedure determines whether the command for the jth menu entry on panel is a change command (Block 111700).

If it is a change request, the values in the ST~E menu entry are copied into the work area fields which correspond to a STDE entry and a menu is displzlyed requesting changes for the menu characterization information. The input values are validated by translating the ou1put panel and output procedure, gtdeipnm and gtdeopnm, to upper case, and then moved back into the STDE entry to complet~ the change. The only change the user is not permitt~d to perform with this implementation is any change to the menu name: although/
this change could easily be performed by deleting the old STDE entry and adding the new STD~ entry.

If it is not a change command, the program determines if the~ommand for the jth menu entry on the panel is a delete command (Block 111730~. If it is, the procedure deletes the menu entry in the STDE table by overwriting the daleted entry with the later entries in the STDE table. The STDE entry co~nt, nent, is decremented and e is modified to :

point to the previous STDE entry.

If not, the procedure increments index j for panel edit list ~Block 111760), then moves the e pointer to the next STDE entry (Block 111780), and returns to Block 111680 to continue processing.

Block 111790 initializes the panel menu entry counter and sets index j to zero. The procedure then determines if the panel menu entry counter, j, is greater than or equal to the number of menu entries which will fit on the screen (14) (Block 111795). If the ~ounter has reached the maximum, the program exits the procedure (Block 1118503. If the counter has not reached the maximum, the program determines if the command for the jth menu entry on panel is an add request (Block 111800). If it is, the work area fields which correspond to a STDE entry are cleared, the menu name initialized, and a panel is displayed requesting new menu entry characterization information from the user. The user input values are validated by translating the output panel and output procedure names, gtdeipnm and gtdeopnm, to upper case and then the menl1 entry is added using the process described in Figure 33, Block 46290. If not, the procedure clears the menu entry command code (Block 111830), increments index j for panel edit list (Block 111840), and re~urns to Block 111795 to continue processing.

~ DIT ~AN~aG~ LI~T. This procedure is another third level procedure which provides a display panel which lncludes information from the TDF language record type.
This information characterize~ a language entry definition and is displayed on the panel in a list. Since more language entries may ~e defined than may be displayed at one time, facilities are provided to al~ow navigation through the language list. Functions are also provided for adding ~ æ,~
2~:'3~ ~

new language definitions, modifying current language definitions, deleting current language definitions, and displaying current definitions.

When the user requests ~ELP documentation, GLOSsary support, or INFOrmation, the Language of Preference field determines the appropriate documentation to present to the user. If the documentation does not exist in the user's language of preference, English documentation will be presented, if available.

The GTD system supports applications that use HELP, GLOS, and INFO documentation to describe the ~unctionality of the application. This documentation is maintained as part of the TDT. As the TDT is initially built, the designer can specify the report and generation to designate the documentation location. This feature can be extended to support multiple languages through the Edit Lanuage Lisit facility. The Edit Language list ~acility allows the designer to edit a list of languages and the associated report.generation for the documenta~ion. The application designer can then provide documentation in the user's language of preference.

GTD 1.5 presents the designer with a list of languages specifled for this TDT~ Each language entry includes a report and generation specification to identify where the documentation resides for that language. The designer can add, change, or delete entries within this language list, by entering 'A', ~C~, or ~D~ respectively, and modifying the entries as necessary.
~: , Figures 40a-f depict the flow chart of the preferrad embodiment of ~he EL procedura, detailing these functions further.
.

.
~ a~
2 ~

The GTD edit langua~e list procedure begins by scanning the select field for the locate command input by the user.
The locate name is saved in the dname fi~ld of the transaction view. This locate name is used as the initi~il language entry to be displayed in the edit list. If there is no locate command, dname is set to blank (Block 113100).
The following display area variables are blanked (Block 113110): select, variable gtdsela; name, variable dnamea;
report, variable dipnm; and generation, variable dopnm.
Index, j, and pointer E are initialized to th beginning of the STDE table (Bloc~ 113180).

Blocks 113185 through 113260 constitute a process by which the initial language list item to be displayed on the screen i5 located in the STDE table. Then the initial language name, and as many subsequent languages names as will fit on ~he display, are placed in language list display fields with the corresponding language characterization in~ormation from the STDE table for each language entry displayed. The process is finished when all language names up to the end of the list, or all languages names which will fit on the screen, and their characterization data have been placed in the display fields.

Decision Block 113185 checks to see if e is pointin~
past the end of the STDE table~ If it is, the procedure jumps to Block 113270. If not, the procedure checks to see if j is greater than or equal to the number of language entries (16) which will fit on a screen (Block 113200~. If j is greater than or equal to 16, the procedure jumps to Block 113270. If not, the procedure checks to see if the current language (STD~TYP=L) is an STDE table language name, STDENAM~, greater than or equal to the next language name, dname, requested by the user (Block 113205). If the current language name is not greater or equal to the request language name' the procedure jumps to block 113~0. If the ~ Ea~

current language name is greater or equal to the next language name, the jth item in the edit list is initialized to the ~ollowing values: name, variable dnamea = STDEN~ME;
report, variable dipnm = STDEIPNM, and generation, variable dopnm = STDEOPNM (Block 113210). The procedure increments index j (Block 113240), increments pointer e to point to the next STDE entry (Block 113260), and then returns to Block 113185, to continue processing.

Block 113270 performs the procedure to display a panel (Figure 21, Block 47300~, electing to di~play the GTDEC
panel.

Blo~ks 113285 through 113475 constitute a process by which each user xequest for each language list item is examined. If an add, delete, or change, reque~t i5 identified then the appropriate task is performed. The process is complete after the requests have been identi~ied and performed for each language entry in the list.

J is initialized to zero (block 1132B0) and the procedure checks to see if j is yreater than or equal to the number of language entries (16) which will fit on a screen (Block 113285). If j is grPater or e~ual to 16, the procedure proceeds to Block 113480. If not, the procedure checks to see i~ there is an add language request, gtdsela e 'a' or 'A' (Block 113310). -If there is an add request, a language is displayed requestin~ the language characterization information as described in the language record type of the TDF. The input values are validated. This typically invol~es translating the language, documentation report, and documentation generation names to upper case. After the input values are validated an attempt is made to add the new language entry .

2 ~ 3 to the STDE table for later storage in the TDF. The attempt will fail if the language name provided is blank, if the STDE table is full, or if the language name provided alreiady exists in the table. If the no error is detected the language entry is inserted in the STDE table ascending language sequence. The STDE entry count, nent, is incremented. Once the language is added, the procedure jumps to Block 113470. If there is no add request, the procedure checks to see if a change language request gtdsela = 'c' or 'C' (~lock 113360).

If there is a change request, the change request language name is verified. A change request can not be performed if the language is not defined in the STDE table.
If the language is listed in the STDE table, the values in the STDE language entry are then copied into the workarea fields which correspond to a STDE entry and a language is displayed requesting changes for the language characterization information. The input values are validated as described for an add language request (Block 113310) and moved back into the STDE entry to complete the change. The only change the user is not permitted to perform with t~is implementation is a change to the language name. Once the language is changed the procedure proceeds to ~lock 113470.
I~ there is no change request, the pr~cedure checks to see if there is an delete language request:, gtdsela = 'd' or 'D' (Block 113410).

If there is a delete request, the delete request language name is verified. A delete request can not be performed if the languaqe is not defined in the STDE table.
If the language is listed in the STDE table, then the language is deleted by overwriting the deleted entry with the later entries in the STDE table. The STDE entry count, nent, is decremented. Once the language is deleted the procedure moves to Block 113470. If there i5 no delete ~ ~ 2 ;~

request, the procedure increments j (Block 113470) and returns to Block 113285.

Block 104040 per~orms the FE procedure (Figure 22, Block 48130) to check for user input end indications. If an end is not indicated (Block 113485), the procedure jumps back to block 113100. If an end is indicated the program exits procedure EL.

P~T TDF- ~TDT P~OCEDURE: Looking now at Figures 42a-d, which depict a flowchart of the preferred embodiment o~ this procedure according to the present invention, the Put TDF
procedure begins by determining (Block 45790) if an STDE is created (number of entries, nent, i5 less than zero). I~
not, the program returns from the procedure with an error.
I~ an STDE is created, the program opens a TDF file for output (Block 46820). If the TDF file open is not suc~essful, the program returns from the procedure with an error. If it is successful, the program (BlocX 46850) copi~s the TDF header from the transaction view work area into the output buffer and at Block 46860 writes the TDF
header r~cord to the TDF file using TDrPVT procedure (Figure 43, Block 15440). Next the TDF first header extension record fields are copied ~rom the transaction view workarea into th~ buffer iBlock ~46870)~, and at Block 46880, the TDT
:header: re~ord is written to the TDF file using the TDTPUT
procedure. Next the TDF second extension header record fields;:are copied from the transaction view workarea into the buffer (Block 4~8~0), and at Block 46g00, the TDT header record: is written to the TDF file again usinq the TDTPUT
procedure.

: Block 4694:0 moves pointer e to. the beginning of the STDE table. If the pointer (Block ~6945) is past the end of ~the STDE table, the program~ continues at Block 47010. If r not, Block 46950 copies ~he STDE entry at e into the buffer and Block 46960 writes the TDF record to the TDF file using the TDTPUT procedure. Decision Block 46365 determines if the write is successful. If so, the program proceeds to Block 47000 where pointer e is incremented to the next STD~ entry in the table and the program procaeds to Block 46945. If not, the error message field is set, GTDMSG= "TDT WRITE
E~ROR'I (Block 46970~, and the program jumps to Block 47010 which blanks the output bu~fer, and Block 47020 writes the TDT record to the TDF file using the TDTPUT procedure. The TDF file is then closed (Block 47090) and the procedure is exited ~Block 47040).

WRIT~ ~D~ RECORD: ~DTP~ PROC~D~R~i. Moving now to Figures 43a-b, which show a flowchart of the preferred embodiment for this procedur~, according to the present invention, the GTD write TDF record procedure begins by setting the buffer length to equal the length of the position of last non-blank character in the buffer (Block 15480). The record length is set equal to the length of the bu~fer plu5 the 4 byte header (Block 15530). The first two bytes o~ the header are set equal to the buffer length in BIG ENDIAN format (Block 15570). The second 2 bytes o~ the header are set to zeros (Block 15590) and the 4 byte header is written to the transaction definition file (TDFl. :
Decision Block 15605 checks to see if the write was successful~ If it was not success~ul, ths error message out, G~DMSG, is ~et equal ko "MAPLIB WRITE ER~OR" (Block 15610) and the procedure is exited with an error (Block I5620~o If the write was successful, the procedure checks to see:if the bu~fer length i~ equal to zeros (Block 15640).
If the buffer length is zeros, the program exits the procedure without an error. If not, the ~uffer is written -.:

.. ... .. .. . . .. . . . .. . ... .. . ... .. . .. .. . . . .. .. . . . . .

~ - a~
2 ~
.
to the TDF (Block 15670). The procedure checks to see if the write was successful (Block 15675), and i~ it was, exits procedure TDTPU~ at 810ck 15710. If the write was not success~ul, the procedure siets the error message out, GTDMSG, ko "MAPLIB WRITE ERROR'i (Block 156~iO) and exits the procedure with an error (Block 15690).

ED~T TRAN~ACTIO~ ~IE~. This third level procedurs provides a capability to edit the application transaction view. A default transaction view is genera~ed at the time default TDF entries are defined. This default transaction view consists of a workarea definition which includes only the system-required I~TTVW struct~ire variable~, typically ~ith a C "incluæiet' or COBOL "copy" statem nt. The application dependent variables are de~ined following the IETTVW variables.

:-.
,. .

- . .

~-- f ~
2~3~
GENERATE T~;AC~ION VIEW/;0URCJ3 PROGRAJI. The next major area of the GTD involves the Generate Transaction View/Source program which provides ~unction to allow the application developer to generate the source files for the transaction view (the application data area) and programs.
The transaction view and source programs are constructed so as to be compatible with the IET. This builds the required IET application interfaces into the data areas in the transaction view and into the program linkage for the application procedure.

GENERA~ING G~ ~RAN~C~ION YIB~B. Transaction views ar~ the basis for procedures, panels and views to reference data items~ The application designer must define the structure o~ the transaction view. A required portion o~
the transaction view is used by the system to re~erence system data items. These system variables include userid using transaction, system where transaction is running, current date, current time, function key pressed when transaction was invoked, and other kley parameters.

The system generates a starter transaction view upon the first save of the TDT. The GC procedure presents the application designer with a transaction view generation screenO This screen allows the designer to specify the MAPhIB in which the TDT member is maintained, and the name of the TDT member. The format of the system-defined transaction view is described in Appendix C.

Figures 44-46 depict flowcharts of the preferred embodiments of various aspects of this program.
-The GC procedure defined at Figure 44, Block 6900provides the interfaces neccessary to generate a transaction ~,.

n~ , ~
r~ a view, C procedure, or COBOL procedure. Specifically, the source is g nerated to be compatible with the IET. The transaction view generated stores the data fields required by the IET in a portion o~ the application transaction view, known as the IET transacaction view, named IETTVW. The programs generated have the appropriate program entry points and program linkage defined so that the IET can call the generated application procedure and receive control back when the procedure terminates. The application program must be generated to be a callable procedure with one data area to be used as input. This data ar~a is the transaction view. The application program must use the procedure name as the entry point and must return control back to its caller when program processing is complete. Generating a skeleton transaction view and application procedures, GTD facilitates the generation of applications which are compatible with the IET, thereby ensuring the IET will operate on these panels as intended.

The technique used to generate the transaction view, C
procedure and COBOL procedures is basically the same. An initialized data structure is defined in the GTD program which contains the standard definition~ Each data structure record is moved into a buffer, customized i~ neccessary, and then written to the source file. This process continues until the end of the data structure is located.

Other techniques for accomplishing the present invention could involve obtaining the standard definition from other sources such as a GTD system configuration file.
Also, the process could be extended through the use of a CASE product such as Texas Instruments' IEF, which would allow the application developer to build a specification of the application procedure with the CASE product,and then a compl te, or more fully defined, procedure may then be generated using the same CASE product. The requirements for -' "

2~'f"~f~
IET interfaces and data areas would be comprehended in the application procedure specifications.

Below are listed the third level menu options under th~e second level menu G~fNERATE TRANSACTION VIEfW/SOURCE PROGRAM.
In addition to selecting a m~nu option to per~orm, the user is also rff~uired to provide 2 additional pieces of information: the name of the TDF file (gtdmmem), and the library or pathname under which the TDF file may be accessed (gtdmlib). These 2 pieces of information are required to perform any of the menu functions. Input fields for these values are included on each of the second level hierarchy menues.

2. GENEfRATE TRANSACTION VIEW/SOURCE PROGRAM
2.1 GENERATE TRANSACTION VIEW
2.2 GE~'E~ATE SKELEifiTON COBOL PROGRAM
2.3 GENERATE SKEifiLEfTON C PROGRAM
2.4 EXIT

Menu option 2.1, GENERATE TRA~ISACTION VIEW, provides a capability to generate the application transaction view.
This def'ault transaction view consists of a workarea definition which includes only the system required IETTVW' structurfffi varîables, typically with a C "include" or COBOL
"copy" statement. The application dependent variables arffff defined a~ter the IErTVW variables. The flow chart of the GTVW' procedure starting with Figure 26, Block 820D details i ~ this functions further. The GTVW procedure has been expflained in detail earlier, therefore such discussion will ~ not be repreated here.

; Menu option 2.2, GENERATE SKEifiLEfTON COBOL PROGR~Mff!
provides a capability to generate an application COBOL
skeleton program. The flow chart of the GCOBP procedure (Figure 45) starting with Block 7230) details this , ~ f~ ~ ~ f ~f~ ~ s;j~ $; -~ r~ v3 ~ 7 ~

capability further.

Menu option 2.3, GENERATE SKELETON C PROGRAM, provides a capability to generate an application C skeleton program.
The flow chart of the GCP procedure (Figure 46, starting with Block 8000) details this capability ~urther.

~ TD GEN~R~TB TRAN~ACTION/VIE~, CO~OL/C PRO~RA~: GC
PROCEDURE. Looking first at Figures 44a-b, which depict the preferred embodiment of this procedure, the second level GTD
generate transaction/view, COBOL/C program procedure begins by performing the procedure (Figure 21, Block 47300; to display a GTDGC panel ~Block 6940). When the procedure is completed, the FE procedure (Figure 22, Block 48130) checks to see if the user has indicated he is finished using this procedure (Block 6950). If a user end is indicated, the program jumps to Blo~k 7150 and exits procedure GC. If not, the program (Block 6980) performs the load/create transaction definition file (TDF) GTDT procedure (Figure 24, Block 44960).

When the GTDT procedure is completed, the program cheaks to see i~ variable GTDSEL=1 (Block 7000). The GTDSEL
variable represents user input, typically a menu selection, from the panel. When GTDSELF1, the user accesses the create transaction view GTYW procedure (Figure 26, Block 82003.
Whon~the GT~W procedure is complete, the program returns to Block~ 6940 to see i~ the user requires any other procedures from~this panel~.

If~GTDSEL does ~ not equal 1, the program checks to see GTDSEL=2 (Block 7050). When GTDSEL=2, the user accesses the generate COBOL sk~leton program GCOBP procedure (Figure 45, Block 7230). When the GCOBP procedure is complete, the program returns to~Block 6940 to ~ee if the user requires ~' ~` 2 ~

any other procedures from this panel. I~ GTDSEL does not equal 2, the program checks to see if GTDSEL=3 (Block 71003.
When GTDSEL=3, the user accesses the generate C skeleton proyram GCP procedure (Figure 46, Block 8000~. When the GCP
procedure is complete, or if GTDSEL does not equal 3, the program returns to Block 6940 to see if the user requires any other procedures from this panel.

GEN~RAT~ COBO~ PROCEDU~ U8ER INT~RFACE: GCOBP
PROC~D~R~. Looking now at Figur2 45, which shows a preferred embodiment of this procedure, the GTD generate COBOL procedure user interface procedure begins by performing the procedure (Figure 21, Block 47300) to display a GTDGCP panel (Block 7230). ~When the procedure is completed, the FE procedure (Figure 22, Block 48130) checks for user end indications (Block 7260). If a user end is not indicated, the program returns to Block 7260. If a user end is indicated, the program (Block 7310~ performs the generate COBO~ GCOBPROG procedure (Figure 35, Block 7400). The GCOBPROG procedure generates a skeleton COBOL program, that can be edited by the user to meet his specific needs. When the procedure is completed, the program exits procedu~e GCOBP (Block 7320).

G~AT~ C PROCEDUR~ R INT~RFACE: ~CP PROCED~RE.
Continuing to Figure 46, which show~ a preferred embodiment o~ this procedure, the GTD generate C procedure user interface procedure begins at Block 8030 by performing the procedure (Figure 21, Block 473003 to display a GTDGCP
panel. When the procedure is completed, the FE procedure (Figure 22, Block 48130) checks for user end indications (Block 8040). If a user end is not indicated, the program returns to Block 8030. If a user end is indicated, the program at Block 8080 performs the generate C GCPPROG

.

.
OE3. , ~ "p r~

:; procedure (Figure 36, Block 114950). The GCPPROG procedure generates a skeleton C program, that can be edited by the user to mPet his specific needs. When the procedure is completed, the program exits procedure GCP (Block 8090).

: . .:

. .
. : : : ~ : . .

:
~ : : TI-13766 191 2 ~3 ~
GENERATB PAN~ PRO&RAM.
The next major area of the GTD involves the Generate Panels program which provides functions to allow the application developer to generate customized system-provided panels for his application and provides base panels for procedure dialog flow with the user. These panels are generated to be compatible with the IET, and have the fileds required by the IET to perform its panel and menu dialog flow management.

The GM procedure defined at Figure 47, Block 9030 provides the interfaces neccessary to generate menu panels and the system- defined GLOS, INFO and HELP panels. These panels have all the fields pre-defined in standard locations to allow the IET to provide the application with dialog management, menu navigation, glossary, information, and help functions. The standard location provide the application user with a common application interface for all DAA
applications. The application developer has the option of customizing the look of the panel generated, but should not delete fields required by the IET.

The application designer can generate the syst~m-provided panels and skeleton panels to be customized for the application using the generate panels procedures.
The designer is presented with a selection panel to generate the syst~m-provided panels for this application. Normally, the designer would specify Option 1 which generates the panels to perform standard MENU, GLOSary, HELP, and INFOrmation functions for the GTD application being developed. The designer can elect to generate a sub-set of thes panels by entering other options.

To generate a skeleton panel (MAP) the application ~esigner must speci~y the MAPLIB and panel name to be .
:' generated to the skeleton panel. The panel name must be unique within that library. For inclusion in a TDT, the panel must be included with the panel list. Once the data -is entered on the skeleton panel, the panel is generated.
The method used to generate the panels is to generatP
the map source records in the format required by the map services employed. Specifically the definition of each map record is built in a buffer using hard coded specifications for each type of panel being generated (menu, glossary, information, help, or skeleton panels) and thPn written out to map file. Specifications written into the map source include field names, field types, field row and column information, field le~gths, field attributes and literal data. All these specifications are hard coded for each type of panel and are written out ~to ths file in the most convenient manner.

Alternative embodiments o~ this aspect of the GM
program would be to copy the panel source from a location speci~ied in a GTD system configuration file and then plug in the particular customized in~ormation required (e.g., the panel name; for menu entries, the ~;election and description information). -~

Below are listed the third level menl~ options under the second level menu GENERATE PANELS. In addition to selecting a menu option to perform, the user is also required to --provide 2 additional pieces of information: the name of the TDF file ~gtdmmem), and the library or pathname under which the TDF file may be accessed (gtdmlib). These 2 pieces of information are required to perform any of the menu functions. Input fields for these values are included on -each of the second level hi2rarchy menues.

3. GENERATE PANELS
3.1 GENERATE MENUS(ALL),HELP,INFO, AND GLOS PANELS

..

r - ~

3 . 2 GENERi~TE MENU PANELS 2 ~ 7 3 . 3 GENERATE HELP PANEL
3 ~ 4 GENERATE INFO PANEL
3 . 5 GENERATE GLOS PANEL
3 . 6 GENERATE SKELETON PANEL
3 . 7 EXIT

Menu option 3.1, GENERATE MENUS (ALL) ,HELP, INFO, AND
GLOS P~NELS, provides a capability to generate panel source for all menus and the system provided help, information, and glossary panels. The menu option lines are constructed from menu entries stored in the TDF.
All requested panels are generated in turn.

Menu option 3 . 2, GENERATE MENUS provides a capability to generate panel source for all menus. The menu option lines are constructed from menu entries stored in the TDF.

Menu option 3.2, GENERATE HELP PANEL provides a capability to generate panel source for the system-provide HELP panel.

Menu option 3.3, GENERATE INFO PANEL provides a capability to generate panel source for the system-provide INFO panel.

~ enu option 3.4, GENERATE &LOS PANEL provides a capability to generate panel source for the system-provide GLOS panel.

The flow chart of the GPM procedure (Figure 48, starting with Block 9600) details these menu option capabilities further.

Menu option 3.5, GENERATE SKELETON PANEL provides a capability to generate a user panel skeleton source file.
: . .

', The generated panel skeleton panel provides a starting point from which the application developer can work when composing the application panel s . The flow chart of the GSP procedure (Figure 49 starting with Block 12540~ details this capability further.

~ EN~R~T~ MAP~ ~ER INTERFACZ: G~ P%OCED~E. Starting with Figures 47a-~, which depict a pre~erred embodiment of this procedure according to the present invention, the GTD
generate maps user interface procedure begins at Block 9070 by performing the load/create transaction definition file GTDT procedure tFigure 24, Block 44960). When the GTDT
procedure is completed, control is returned to Block 9090 which performs the display procedure (Figure 21, Block 47300), electing to display a GTDGM panel (Block 9090).
Procedure FE (Figure 22, Block 48130) then checks for user end indications (Block 9100). If a user end is indicated, the program jumps to Block 9520 and exits procedure GM. If a user end is not indicated, the program saves the generate option flag (GTDGOF) value (Block 9130), and the generate lookahead flag (GTDGLF~ value (Block ~140). Procadure GTDT
(Figure 24, Block 44960) then loads and creates the TDF
(Block 9150). The generate option flag value (Block 9160) and generate lookahead flag (Block 9170) are restored to the GTD transactio~ view, and the flaqs are validated by :translating the values to upper case and then changing their values to "N" if ~he values contained are not 'iY" (Block 9180). When the ~lags have been validated, procedure PTDT
writes~a new TDF from the information in the GTD transaction view.

Decision Block 9200 checks to see i~ the user input opt~ion code o~f GTDSEL=l, which is a request for all panels to be creatd. I~ not, the program jumps to Block 9270. If G~SEL~equals 1, the GPM procedure (Figure 48, Block 9600) :.

~ 2 ~3 ~
generates the menu panels (Block 9210), followed by all the system-defined panels.

The HELP panel is created at Block 9220 with the following ~ields defined in the IETTVW and required by the IETo IEFl-TRAN, IEFl-PANEL, IEFl-SYSTEM, IEFl-CURROW, IEFl-CURCOL, IEFl-FUNKEY, IEFl-CURDT, IEFl-MSGID, IEFl-MSGTX, IEFl-MSGTX, IEFl-MSGAE, IEFl-USER, IEFl-HELPPNL, IEEl-OPTION (optionally generated when gtdgof = Y), IEFl-TEXT(01) thru IEFl-TEXT(21).

The INFOrmation panel is created at Block 9230 with the following fields defined in the IETTVW and required by the IET: IEFl-TRAN, IEFl PANEL, IEFl-SYSTEM, IEFl~CURROW, IEFl-CURCOLI IEFl-TUNKEY, IEFl-CURDT, IEFl-MSGID~
IEFl-MSGTX, lEFl-MSGTX, IEFl-MSGAE, IEFl-USER, IEFl-INFOCHP, IEFl-INFOSEC, IEFl INFOPAG, IEFl-OPTION (optionally generated when gtdgof = Y), IEFl-TEXT(01) thru IEFl-TEXT(21).

The GLOSsary panel is created at Block 9240 with the following fields defined in the IE'TTVW and required by the IET: IEFl-TRAN, IEFl-PANEL, IEFl-SYSTEM, IEFl-CURROW, IEYl-CURCOL, IEFl-FUNKEY, IEFl--CURDT, IEFl-MSGID, IEFl-MSGTX, IEFl-MSGTX, IEFl-MSGAE, IEFl-USER, IEFl-GLOSSEC, IEFl-OPTION (optionally generated when gtdgof = Y), IEF:l-TEXT(01) thru IEFl-TEX~(21).
.

When all the panels have been generated, GTDMSG is set equal to PANEL GEN COMPLETE, and the message is output to the user ~Block 9250).

: Decision Block 9270 checks to see if the user has input ::
an cp~ion code of GTDSEL=2, a request for only the menu : panels to b~ created. If not, the program proceeds to Block 9310. If GTDSEL equals 2, the GPM procedure (Figure 48, :

~ 3 Block 9600) generates the menu panels (Block 9280). When the procedure is complete, GTDMSG is set equal to "PANEL GEN
COMPLETE", and the message is output to the user (Block -9290).

Decision Block 9310 checks to see if the user has input an option code of GTDSE~=3, a request for only the help panels to be created. If not, the program continues to Block 9350. At Block 9320, if GTDSEL equals 3, the help panel is generated as described for Block 9220. When the help panel has been generated, GTDMSG is set equal to "PANEL GEN
COMPLETE", and the message is output to the user (Block 9330)~

Decision Block 9350 checks to see if the user has input an option code of GTDSEL=4, a request for only the information panels to be created. If not, the program jumps to Block 9390. At Block 9360, if GTDSEL equals 4, the informaton panel is generated as discussed Block 9230. When the information panel has been generated GTDMSG is set equal to "PANEL GEN COMPLETE", and the message is output to the user (Block 9370).

Decision Block 9390 checks to see if the user has input an option code of GTDSEL-5, a request for only the glossary panels to be created. If not, the program proceeds to Block -9430. At Block 9400, if GTDSEL equals 5, the glossary panel is generated as described for Block 9240. When the glossary pan~l has been generated, GTDMSG is set equal to "PANEL GEN
~O~PLET~", and the message is output to the user (Block 9410)-:
Decision Block 9430 checks to see if the usex has input an option code of GTDSEL=6, a request to generate a skeleton panel. If not, the program continues to Block 9480. If GTDS~L equa1s 6, procedure GSP (Fisure 49, Block 12540) ' :.

"".;,.i',i;,",-i, ~"~ ; ,;",~ ,,"",-, ";,;,,, ;,, ~ B~
,~ ,ff~
~ ~3~ 7~
generates the skeleton panel (Block 9440~. When the procedure i5 complete, GTDMSG is set equal to "PANEL GEN
COMPLET~", and the messaye is output to the user (Block 9450).

Procedure FE (Figure 22, Block 48130) then checks for user end indications (Block 9480). If a user end is indici~ted, the program moves to Block 9520 and exits procedure GM. If a user end is not indicated, the program returns to Block 9090 to continue processing.

G~NERA~E MEN~ PANEL~: GP~ PROCED~RE. Moving now to Figures 48a-d, which depict the preferred embodiment of this procedure according to the pre~ent invention, the GTD
generate menu panels procedure begins at Block 9680 by setting the number of entries in the menu count index to zero and blan~ing the menu names in the menu table tBlock 9700). The procedure initializes a pointer to the beginning o~ the STDE table (~lock 9740). Decision Block 9745 checks to see if the end of the STDE table has been reached (Block 9745). If it has, the procedure -,jumps to Block 9940. If not, the procedure checks if the current STDE table entry is a menu entry, STDETYPE=E. If the entry is not a menu entry, the procedure proceeds to Block 9885. If the entry is a menu, the menu name is added to the menu table (Block 9760).
The menu name table is built in a sorted manner and contains only unique menu names. The new menu name is loaded into the location ~ound (block 9850) and the menu count is incremented (Block 9860). Block 9885 increments the STDE
pointer to point to the next STDE table entry and the procedure returns to ~lock 9745~

When the end of the STDE table has been reached, the index is initialized to the beginning of the menu table (Block 9940) and checked to see if it .is still less than the menu count (Block 9945). If not, the program exits procedure GPM (Block g9iB0). If the index is still less than the menu count, GTDPMEM is set to th~ menu name (Block 9950), and the individual menu panel is created.

Th~ menu entry field containing the selection values STDESEL and menu selection description STDEDESC are placed on the screen in a list as constants together on the same line with a list of the menu entries constituting the menu options.

The menus are created with the following fields defined in the IETTVW and required by the IET: IEFl-TRAN, IEFl-PANEL, IEF1-SYSTEM, IEF1-CURROW, IEF1-CURCOL, IEFl-FUNKEY, IEF1-CURDT, IEF1-MSGID, IEFl-MSGTX, IEFl-MSGTX, IEFl-MSGAE, IEF1-USiER, IEFl-COMMAND, IEFl-GDATE, IEFl-GTIME, IEF1-APPL, IEFl-TDTID, IEFl-RELN, IEFl-OPTION (optionally generated when gtdgof = Y), IEFl-LOOKAHEAD (optionally generated when gtdglf = Y~.

When the menu has been created, the index is incremented, and the program returns to Block 3945.

G~N~Ra~B S~ELE~ON P~NEL U~ER D ~ERFACE: GSP PROCEDURE.
Considering n~xt Figure 49, which depicts the preferred embodiment of this procedure, the GTD generate skeleton panel user interface procedure begins at Block 12570 by p~rforming the procedure (Figure 21, Blo~k 47300) to display a GTDGP panel.

At Block 12580, the generate option and lookahead flag fields are validated by translating the values to upper case and then changing their values to ~'N" if the valueis contained are not "Y". When the flags have been validated, procedure FE (Figure 22, Block 48130) checkisi for user end indications (Block 12590). If a user end is not indicated, TI-13766 l99 :

the program returns to Block 17570. If a user end is indicated, the program (Block 12530) generates the skeleton panel. Skeleton panels are created with the following fields defined in the IETTVW and required by the IET: IEFl-TRAN, IEF1-PANEL, IEFl-SYSTEM, IEFl-CURROW, IEF1-CURCOL, IEF1-FUNKEY, I~Fl-CURDT, IEF1-MSGID, IEF1-MSGTX, IEF1-MSGTX, IEFl-MSGAE, IEFl-USER, IEFl-OPTION (optionally generated when gtdgof = Y), IEF1-LOOKAHEAD (optionally generated when gtdglf - Y) The generated panel may then be edited by an appropriate map editor and customized to meet speci~ic application n~eds. After the skeleton panel is generated, the program exits procedure GSP (Block 12640).

2 ~ ~ ~ E . ~

CO~PI~E TRAN~ACTION D~F/VIEWS/PAN~L8/PROCEDURES~

The next major area of the GTD involves the Compile Transaction Definition, View~, Panels and Procedur~s program which provides the application developer with the construction tools necessary to build a DAA application, particularly the TDT and view tables required to characterize the application to the IET. When the TDT edit has been completed, the designer can request an object module be created for the TDT using the CTREQ procedure.
This presents a panel allowing the designer to specify the TDT member to be compiled. The CTREQ procedure ensures that applications built with GTD are constructed with consistent compile and link-editor options for the DAA platform.

Furthermore, the CTRE~ procedure defined Figure 50 at Block 16440 provides the user interfaces neccessary to construct an applicatio~ load module and install it in an execu~able load module library or directory. The application is built with the neccessary TDT and view tables required by IET. The information in these tables are checked for consistency and completeness before the table objects are built.

If the edit specifications for a selected transaction are consistent (all panels and procedures referenced in TDT
member are d~fined as entries in TDT) the compilation will create the appropriatè object module. The object module bui}ds the tables that interrelate the panels, procedures, menu ~entries, and views within the TDT suitable for controlling execution of this transaction at run time.

If errors exist in this process (for example, panel is refere~ced on menu and panel is not defined to menu hierarchy or as a discrete panel specification) these error 2 ~ ~ ~ i 7 0 conditions will be noted for the designer to correct.

In addition to providing the user interfaces for compiling/constructing the tables required by IET, the CTREQ
procedure includes user interfaces for compiling the application panels and procedures as well as building the load module. The menu options provided construct each type of component as a group, either conditionally or unconditionally. By treating each type of component as a group, the program helps to ensure synchronization within a component type.

Other menu options provided construct the entire application in a sequence which ensures synchronization between all components of the app~ication. When one of is selected, the entire application is constructed in the following seq~lence by type: the TDT, the views, the panals, the procedures, the application load module. This construction sequence comprehends the data dependencies between different types of application objects.

The conditional construct:ion options ensure sychronization by checking modification dates of both the source module and the transaction view source and comparing those dates with modification dates on compile objects.
Source modules which h~ve been modified later than their corresponding object module requiire reconstruction, Each object ~odule with an earlier modify date than the transaction v~ew will also require reconstruction. The conditional construction piermits a shorter (but still synchronized) construction process when only a few changes have been made to the application. The unconditional construckion forces reconstruction of all objects.

Below are listed the third level menu options under the second level menu COMPILE TRANSACTION DEF/VIEW/PANELS/

.

. .

f~- ~

PROCEDURES. In addition to selecting a menu option to perform, the user is also required to provide 2 additional pieces of information: the nam2 of the TDF file (gtdmmem), and the library or pathname under which the TDF file may be accessed (gtdmlib). These 2 pieces o~ information are required to perform any of the menu functions. Input fields for these values are included on each of the second level hierarchy menus.

4. COMPILE TRANSACTION DEF/VIEWS/P~NiELS/PROCEDURES
4.1 COMPILE TRANSACTION DEFINITION
4.2 COMPILE VIEWS
4.3 COMPILE PANELS- CONDITIONAL
4.4 COMPILE PANELS--UNCONDITIONAL
4.5 COMPILE PROCEDURES- CONDITIONAL
4.6 CO~PITE PROCEDURES--UNCONDITIONAL
4.7 BIND TRANSACTION :-4.8 COMPIL~/8IND ALL ELEMENTS--CONDITIONAL
4.9 COMPILEi/BIND ALL ELEMENTS--UNCONDITIONAL
4~10 EXIT

Menu option 4.~, COMPILE TRANSACTION DEFINITION
provides the capability to generate and compil0 application description/control tables into linkable objects which can be used by the IET when performing dialog management, obtaining profile information, performing cooperative processing, and interfacing with the application. The ~lowchart of the CT procedure Figure 51, starting with Block 1745~0) details these capabilities further.

Nenu option 4.2, COMPILE VIEWS provides the capability to: ganerate and compil~ view tables into linkable objects `
: : which can be used by the IE~ when saving~r~storing application profile information and when obtal~ingjretrieving input/output in~ormation during ~: cooperative processing. The flowchart of the CV procedure :

.

~r,~r}~
(Figure 54, starting with Block 25870) details this capability further.

Menu option 4.3, COMPILE PANELS--CONDITIONAL and Menu option 4.4, COMPILE PANELS--UNCONDITIONAL provide the capability to compile all application panels either conditionally (Menu option 4.3) or unconditionally (Menu option 4.4). A flag is set indicating the conditional state for the compilation, then a procedure is invoked to manage the compilation of all the application panels. The flowchart of the CP procedure (Figure 55, starting with Block 31540) details this capability further.

Menu option 4.5, COMPILE PROCEDURES--CONDITIONAL and Menu option 4.6, COMPILE PROCEDURES--UNCONDITIONAL provide the capability to compile all application procedures either conditionally (Menu option 4.5) or unconditionally (Menu option 4.5). A flag is set indicating the conditional state for the compilation, then a procedure is invoked to manage the compilation of all the application procedures. The flowchart of the CC procedure (Figure 57, starting with Block 33340) details this capability further.

~ enu option 4.7, BIND TRANSACTION provides the capability to link all application objects, as well as any required system objects, into a single load module and install it in a library or directory for executahle modules.
The flowchart of the BT procedure (Figure 60, starting with Bloc~ 40110) details this capability further.

Menu option 4.8, COMPILE/BIND ALL ELE~ENTS--CONDITIONAL
Menu option 4.9, COMPILE/BIND ALL ELEMENTS--UNCONDITIONAL
provide the capability to compile all application components either conditionally (Menu option 4.8) or unconditionally (Menu option 4.9). A flag is set indicating the conditional state ~or the compilation then all the compile procedures TI-13766 204 :
.

r I r~ ~

are invoked in turn to manage the compilation of the application componen~s.

CO~PILL/BIND: CTREQ P~OC~DURE. Starting with Figures 50a-j, which depict a prPferred embodiment of this procedure according to the present invention, the GTD compile/bind procedure begins at Block 16500 by performing the procedure to display a panel (Figure 21, Block 47300) electing to display the GTDCT panel. This panel is a menu of all the construction processes a~ailable. Block 16510 performs the FE procedure (Figure 22, Block 48130~ to check for user input end indications. At Block 16520, if an end is indicated, the procedure proceeds to exit the program at Block 17370. ~f an end is not indicated, at Block 16540 the - procedure performs the load/create TD~ (Figure 24, Block 44960) GTDT procedure. The temporary working directory is initialized from gtdslib (Block 16550). Block 16580 then obtains the transaction view modify date/time and saves it in gtvwtim~. This is later used when evaluating conditional compilation cases.

Decision Block 16590 checks to see if there is a compile TDT xequest, GTDSEL = 1. If not, the program jumps to Block 16630 to continu~ identifying the user request. If GTDSEL eguals 1, the compile TDT (Figure 51, Block 17450) CT
procedure is per~ormed (Block 16600). The compile status is checked (Block 16610). The program then returns to Block 16500 to redisplay the menu.

Decision Block 16630 checks to see if there is a compile view~ request, GTDSELF2. If not, the program procee~s to Block 16680 to continue identifying the user request. If GTDSEL equals 2, the unconditional compile flag is set/ gtdcflag = U (Block 166~0). The compile views ~ ~ (Figure 54, Block 25870) CV procedure is performed (Block : ~ :

~b æ~
2 ~
16650). Block 16655 then checks the compile views status after which the program returns to Block 16500 to redisplay the menu.

Decision Block 16680 checks to see if there is a conditional compile panels request, GTDSEL = 3. If not, the program proceeds to Block 16730 to continue identifying the user request. If GTDSEL equals 3, the conditional compile flag is set, gtdcflag = C (Block 16690). The compile panels (Figure 55, Block 31540) CP procedure is performed (Block 16700). The program then returns to Block 16500 to redisplay the menuO

Decision Block 16730 checks to see if there is an unconditional compile panels request, GTDSEL = 4. If not, the program moves to Block 16780 to continue identifying the user request. If GTDSEL equal~ 4, an unconditional compile flag is set, gtdflag = u (Block 16740). The compile panels (Figure 55, Block 31540) CP procedure is performed (Block 16700~. The program then returns to Block 16500, to redisplay the menu.

Decision Block 16780 checks to see if ~here is a conditional compile procedures request, GTDSEL = 5. If not, the~ the procedure jumps to Block 16830 to continue identifying the user request. If GTDSEL equals 5, the conditional compile flag is set, gtdflag = c (Block 16790).
The compile procedures (Figure 57, Block 33340) CC procedure is performed (Block 16800). The program then returns to Block 16500 to redisplay the menu. ~
. .
~ Decision Block 16830 checks to see if there is an unconditional compile procedure request, GTDSEL = 6. If not, the program moYes to Block 16880 to continue identifying the user request. If GTDSEL equals 6, the unconditional compile flag is set, gtdcflag = U (Block 168403. The compile :~
:.

,r~- "~
- ~ ~ 2 ~
procedure (Figure 57, Block 33340) CC procedure is performed (Block 16850)o The program then returns to Block 16500 to redisplay the menu.

Decision Block 16880 checks to see if there is a bind transaction request, GTDSEL = 7. If not, the program jumps to Block 16930 to c,ntinue identifying the user request. If GTDSEL equals 7, the conditional compile flag is set, gtdcflag = C (Block 168gO). The bind transaction (Figure 60, Block 40110) BT procedure is performed tBlock 16850). The program then returns to Block 16500 to redisplay the menu.

Decision Block 16930 checks to see if there is a conditional compile/bind all request, GTDSEL=8. If not, the program jumps to Block 17060 to continue identi~ying the user request. If GTDSEL equals 8, the conditional compile flag i~ set, gtdcflag - C, (Block 16940). The compile TDT
~Figure 51, Block 17450) CT procedure is performed (Block 16950). The status of the compile is th~n checked (Block 16960). I~ the TDT compile was not successful, the program returns to Block 16500 to redisplay the menu. If the TDT
compile was successful, the compile views (Figure 54, Block CV 25870) procedure is performed (Block 16970). The status of the views compile is then checke!d (Block 16975). If the views compile was not successful the program returns to Block 16500 to redisplay the menu.

If th~ views compile was successful the status messages are displayed but no input is accepted from the user (Block ~6980). The compile panels (Figure 55, Block 31540) CP
procedure is performed (Block 16990). Again the status messages are displayed but no input is accepted from the user (Block 17000). The compile procedures (Figure 57, Block 33340) CC procedure is performed (Block 17010). The status of~the c~mpile is checked (Block 17015). If the compile was not successful, the program returns to Block 16500 to ~'`,. . ~la redisplay the menu panel. If the compile wa~ successful, the status messages are displayedr but still no input is accepted from the user (Block 17020). The bind transaction (Figure 60, Block 401103 BT procedure is performed, and the procedure returns to Block 16500 to redisplay the menu panel.

Decision Block 17060 checks to see if there is an unconditional compile/bind all request GTDSEL = 9. If not, the program returns to Block 16500 to redisplay the menu panel. If there is, the unconditional compile flag is set, gtdcflag - U (Block 17160). The compile TDT (Figure 57, Block 17450) CT procedure is then performed (Block 17170).
The TDT compile status is then checked (Block 17175). If the TDT compile was not successful, the program returns to Block 16500 to redisplay the menu panel. If the TDT compile was successful th~ status messages are displayed but no input is ac¢epted from the user (Block 17180). Next, the compile ~iews (Figure 54, Block 25870) CV procedure is then performed (Block 17190). The status of the views compile is then checked (Block 17195~. If the compile was not successful, the program returns to Block 16500 to redisplay the menu panel. If the compile was successful, the status messages are displayed but no input is accepted from the user (Block 17200). The compile panels (Figure 55~ Block 31540) CP procedure is then perfor~ed (Block 17210). The status messages are displayed but again no input is accepted from the user (Block 17220). The compile procedures (Figure 57, Block 33340) CC procedure is then performed (Block 17230). The status of the compile procedures is then chec~ed~(Block I7235j. If the status of the compile was not ~successful, the program returns to Block 16500 to redisplay the~:menu panel. If the compile was successful, the status meisag~ are disp7ayed but still no input is accepted from ~the: user (~lock 17240). Finally, the bind transaction ~(FLgure 60, Block 40110) BT procedure is performed (Block r ~

17250) and the program returns to Block 16500 to redisplay the menu panel.

-, ~: : :

.
~ .
: :

~ 7ab 7 ~
COMPILE TRAN,'BAiCiTION D~FINITIOfN: CT PROC~DUR~

Looking next at Figures 51a-rr, which depict a flowchart of the preferred embodiment of this prc,cedur~
according to the present invention, the CT procedure is responsible for building the transaction definition table, TDT object module. This procedure must produce a standard object module that is to be link-edited with IET, application panel maps and procedures to produce an executable transaction. The TDT consists of various separate tables with inter-related pointers that allows IET at execution time to control the dialog between the user and the application code using the application defined maps and menus. In addition to the dialog, IET handles all panel input/output for the application and facilitating the communications from one transaction to a remote transaction via the DAA link and return facility.

In summary, the following table types are constructed by GTD through the CT procedure: TDT anchor block ~consists mainly of pointers to other TDT tables);
transaction panel entries table, q'PETAB, with one TPE per panel; transaction code entries table, TCETAB, with one TCE
per ref~erenced ~xecutable procedure entry point; transaction menu entries table, TMETAB, with one TME per menu panel;
transaction language en~ries table, TLETAB, with one TLE per language supported; and the data base sync table referencing SQL data base support routine entry points.

Building this TDT objPct module can be accomplished different ways. On UNIX, the CT procedure, as flowcharted here, builds a C language source file that is later compiled by the C compiler to produce a link-editable object module.
On MVS a CT version exists that constructs 370 linkable object modules directly, without the aid of a C compiler.
~' TI-13766 210 ~

S s :~ S :IiS: h . ~ .,cc': ~

r~ ~
2~
The CT procedure involves building and compiling the TDT. The TDT is built in the following manner. First the STDE table is inspected to ensure that all the definitions are complete and consistent by determining if any panels or procedures have bPen left undefined (i.e., without a source file). Then all panels, menus, procedures, languages, and views are counted and a table built containing the names for each type of component. once all the components are accounted for, a source procedure is built containing source language statements which define the customized TDT
information. In the case of the current implementation for UNIX, this isource file is built as a C source file. The TDT
source generation proceeds by generating a standard source prefix, external name definitions for the panels, views, procedures; generating the TDT, TPETAB, TCETAB, TMETAB, TLETAB, and DB synchronization function address table; and then generating a standard source suffix. The standard source prefix contains files, function prototypes, and external definitions common to all TDT source. The standard source suf~ix contains a small procedure, DLITCBL, that is called by the transaction sub-system main module upon execution of the transaction. DLITCBL, in turn, calls IET, passing the address of the TDT and any input/output control block passed by the transaction sub-system main module. Once the TDT source file is built, it is compiled using a standard compiler. In the case of ~n UNIX implementation, a C compiler is used.
.

The first section of the CT procedure (Blocks 17450-17850) det~rmines if there are any undefined panels (i.e., menu panel references with no corresponding panel defined30 It begins by clearing the output file information and rewinding to the beginning of the file (Block 17580).
The display area, DNAMEA is blanked out (Block 17630) and the counter for undefined panels is set to zero (Block 17660). Pointer e is s~t to the first STDE table component f~
3 ~ r~

name (Block 17670~. Decision Block 17675 checks to see if pointer ~ is past the end of the STDE table. If so, the procedure jumps to Block 17830. If not, Decision Eilock 17680 checks to s~e if the component type, STDETYP, of the component indicated by e is equal to 'E', indicating a menu entry definition. If not, the procedure proceeds to Block 178~5. If e equals E, the procedure searches the STDE table looking for a component where component name, STDENAME, is equal to the panel name referenced by the current menu entry, STDEIPN~, for the menu component indicated by e (Block 17700). If searGh is successful, the procedure advances to Block 17815.

The panel name, STDEIPNM, is copied to the current position in the display area, ~DNAMEA, indicated by the number of undefined panels in Block 17770, and the number of undefined p~nels is incremented by one (Eilock 17780). In Decision Block 1~790, if the number of undefined panels is greater than the maximum number for the error display screen, then the procedure moves to Block 17830. Otherwise, it increments e to the next component (Block 17815) and returns to ~ilock 17675.

Decision Block 17830 checks t:o see i~ the number of undefined panels i9 greater than zero. If not, the procedure moves to Block 17920~ Ii. the number is greater than zero, BlocX 17840 performsi the procedure to display a GTDCTEl panel ~Figure 21 , Block 47300), and the CT
procedure exits with the error return code set to 4 ~Block 17850).
, , The next section of the CT procedure verifies (Blocks 17920-18480) each panel's procedures. The rule is that every panel must have an input procedure and the name given must match the nama o~ a defined procedure. The panel output pro edure is optional, but if present, must match a defined , .. .
.

' . ', 1 ;, - ; : . ' . , , ; . ' : , ' . ;' f~ ~
~2~7~
procedure. In addition, menu entries may optionally specify a procedure name and, if present, lt must be the name of a defined procedure.

This section of the CT procedure begins at Block 17920 by blanking out the display area, DNAMEA, and setting the counter for undefined procedures, j, to zero (Block 17950).
The pointer, e, is set to the first STDE table component name (Block 17960).

Decision Block 17965 checks to see if e is pointing past end of the STDE table. If so, the procedure advances to Block 18460~ Next, Decision Block 17970 checks to see if the component type, STDETYP, of the component indicated by e is equal to "p", (indicating a pan~l entry definition). If e does not ecrual ~Ipll ~ the procedure continues at Block liB270.

In Block 17990, the program searches the STDE table looking for a procedure entry where STDETYP equals "C" (for component) and where component name, S~DENAME, equals the input procedure name referenced by t:he current panel entry, STDElPNMi for the panel component indicated by e. If the search is successful, the proceclure continues to Block 18110.

At this point, if no procedure name was found for ~he input proc~dure name specified, the procedure namel STDEIPNM, is copied to the current position in the display area, DNA~EA, indicated by the number of undefined procedures, j (Block 18060). The number of undefined --procedures is then incremented (Block 18070). In Decision Block 18080, if the number of undefined procedures is greater than the maximum number for the error display screen, the procedure then jumps to Block 18460.

: ' ~ 2 ~ 1 7 d Decision Block 18110 checks to see if the output procedure name, STDEOPNM, for panel entry, e, is not defined (i.e., contains blanks). If so, the procedure advances to Block 18270.

In Block 18115, the STDE table is searched for a procedure entry where STDETYP equals l'C", and where the component name, STDENAME, equals the output procedure name referenced by the current panel entry, STDEOPNM, for the panel component indicated by e. I~' the search is successful, the procedure continues to Block 18270.
.::
At this point, if no procedure name was found for the output procedure name specified. The procedure name, STDEOPNM, is copied to ~he current position in the display area, DN~MEA, indicated by the number of unde~ined procedures, j (Block 18220). The number of undef'ined procedures i~ then incrementPd (Block 18230). In Decision Block 18240, if the number of undefined procedures is greater than the maximum number for the error display screen, then the procedure jumps to Block 18460.

Decision Block 18270 checks t:o see if the component type, STDETYP, of the component inclicated by e is equal to an 'E' ~'indicating a menu entry def'inition). If not, the procedure advances to Block 18450.

Decision Block 18290 check to see if the output procedure name, STDEOPNM, for menu entry, e, is not defined ~i.e., contains blanks). If so, the procedure jumps to Block 18450.

In Block 18300, the STDE table is searched for a procedure entry, 5TDETYP, that equals the output procedure referenced by the current panel entry, STDEO~NM, for the panel component indicated by e. If the search is .
; ~ ~ TI-13766 214 ~: .

, ' ' . , ' i; ,: ' ., `, ' , . ' ` . ' . .: .. : ' ;i ' ;
, . .. , ~ . ~` . , ' ."`: . :i !: . i i ~L 2~
2 ~
successful, the procedure continues at Block 18450.

At this point, if no procedure name was found for the menu procedure name specified, the procedure namP, STDEO~, is copied to the current position in the display area, DNAMEA, indicated by the number of undefined procedures, j (Bloc~ 18400). Th~ number of undefined procedures is then incremented (Block 18410). In decision block 18420, if the number of undefined procedures is greater than the maximum number for the error display screen, the procedure jumps to Block 18460. Otherwise the procedure increments e to the next component (Block 18450), and returns to Block 17965.

Decision Block 18460 checks to see if the number of unde~ined procedures is greater than zero. If not, the procedure continues at Block 18570. If so, Block 18470 performs the procedure to display a GTDCTE2 panel (Figure 21, Block 47300), and the CT procedur~ exits with an error return code set to 4 (Block 18480).

During Blocks 18570-18980, a pass is made through the STDE table to count panel5, menus, procedures and views. In addition, if a panel or menu is found, it's name is stored alphabetically in a master table, TP, and duplicates are ignored. If a procedure is founcl marked as a relational data base process, a global flag, dbtype, is set to true.
And lastly, each defined view name ~or a given procedure is added to the master table, TV.
;

This section begins by zeroinq out each counter: NP for panels, N~ for procedures, NL ~or languages, NV for views, and NM menu components or entries in STDE table. The DBMS
proc~dure found flag is initialized to zero (Block 18630), the~ panel tabl~, TP is blanked (Block 18660), and the pointer, e, is set to the first STDE table component name .

:: :

i: : , ', . i .~ . ' :': ,~. ,, . " . , , ,r~, ~
2 ~
(Block 18700).

Decision Block 18705 then checks to see if e is pointiny past the end of the STDE table. If so, the procedure jumps to Block 19040. Otherwise, Decision Block 18710 checks to see if the component type, STDETYP, of the component indicated by e is equal to "P" (panel) or "E" (menu). If e is not equal to either, the procedure proceeds to Block 18850.

Block 18720 finds the panel table location in which to place the name, STDENAME. The table is built in an ascending sorted manner. In Decision Block 18770, if the name, STDENAMiE, is already contained at the location found, the procedure jumps to Block ~8850. Otherwise, it moves panel table entries over to make room for the ~ew name (Block 18780), and put the new entry, STDENAME, in the panel table at the location found (Block 18810). Then the panel count, NP, is incremented, (Block 18820).

Decision Block 18850 checks to see if the component type, STDETYP, of the component indicated by e is equal to a 'C' (indicating a procedure entry definition). If it is not, the procedure continues at Block 189960, where the procedure counter, NC is incremented (Block 18860). In Decision Block 18880, if the procedure has STDECDB2 equal to 'Y' (to u~e the application DB~S~, then procedure sets DBTYPE ei~ual to '1', indicatiny an application that uses DBM5 has been found (Block 18900).

.
Block 18920 addc a view n~me to the table (Figure 52, Block 251~0) by using the TVA procedure for the current procedure entry input view name STDEIPNM (Block 18920).
Decision Block 18925 checks to see i~: the view was successfully added to view table. I~ not, the program exits the CT procedurs with an error return code.

, . .

r .
2 ~ f~J ~31 7 The CT procedure executes the add view name to table (Figure 52, Block 25170) TVA procedure for the current procedure entry output view name STDEOPNM (Block 18930).
Decision Block 18935 then checks to see if the view was successfully added to view table. If not, the program exits the CT procedure with an error return code.

The CT procedure then executes the add view name to table (Figure 52, Block 25170) TVA procedure again, this time for the ~urrent procedure entry profile view name STDEPVNM (Block 18940)o Decision Block 189~5 checks to see if the view was successfully added to view table. If not, the program exits the CT procedure with an error return code.

Decision Block 18960 checks to see if the component type, ST~FTYP, of the component indicated by e i5 equal to an 'L' (indicating a language entry ~e~inition). If so, the language counter, NL, is incremented. Decision Block 18970 checks then to see if the component type, STD~TYP, of the component indicated by e is equal to an "E" (indicating a menu entry definition). If so, the menu counter, NE, is incrementedO At Block 18980, the procedure increments pointer e to the next STDE table compsnent entry and then jumps to Block 18705.

~ he next CT procedure section (Blocks 19040-19230), opens the output file for the TDT "C" source statements that are to be compiled later into the TDT object module. The file name is consi~t with the user-specified source library name, plus the TDT name, plus the extension of ".c".
Finally the source prefix is written to the beginning of the file. This prefix consists of the C statement necessary to .

compile the table, such as "includes" and "extern"
statements.
TI-1376Ç 217 ,, . .. . , . .. / ", .. ~ .. ............. ... ..... .. ... .. ..... . . . .

f ~`
~ ~ 2 ~
.

Specifically, Block 19040 builds the TDT C source name with pathname: gtdslib, filename: gtdmmem, UNIX extension:
Oc.~ and opens the TDT C source file for create and write only options (Block 19100). In Decision Block 19101, if the open is unsu~cessful, the program exits the CT procedure with an error return code.

~ lock 19150 sets the index to the beginning of the TDT
prefix initialization data. Decision Block 19160 checks to see if this is the last line of prefix initialization data.
If so, the procedure moves to Block 19130.

At Block 19190, the line of TDT prefix is copied into the output buffer, and the line in-the buffer is terminated by placing a new line character after the data (Block 19210). In Block 19220, the write buffer TDT source file WTS procedure (Figure 53, Block 25500) is performed. At this point~ the procedure increments the index (Block 19230) and jumps ~o Block 19160.

The next CT procedure porti.on (Blocks 19300 through 19730) generates the C extern definitions for the panels, views, and tables. Since each of these items is actually defined in another object module, the CT procedure must declare the names of these items to be external so that references to them by pointers in the to-be-generatsd TDT
c~an he resolved at link edit time~

: This section begins by zeroing out the index, i, at Block 19300. In Decision Block 19305, if index, i, is equal to the number of panels, TP, then the procedure jumps to Block 19460.

Block 19310 initializes buffer TDTBUF to blanks, and builds a C language external entry in the buffer as an ::
; TI-13766 218 : :.
," - -` ,. . , . . ,, ,; , r ~ , ?~,~
.,~ ~
"extern char", panel name from table at index loc i, ~3;~2(Block 19320). The line in the buffer is terminated by placing a new line character after the data (Block 19370).
In Block 19380, the write buffer TDT source file WTS
procedure (Figure S3, Block 25500). The procedure then increments the index, i, in Block 19390, and proceeds to Block 19135.

In Block 19460, index, i, is initialized to zero.
Decision Block 19465 checks to see if index, i, is equal to the number of views. If so, the procedure jumps to Block 196~0. Otherwise, the buffer, TDTBUF, is set to blanks (Block 19470~, and a C language external view entry is built in th~ buffer as "extern struct VMOH", view name from table, TV, at index loc i, Il[] ;l~ (Block 1?~480).

The line in the buffer is terminated by placing a new line character after the data (Block 19530), and the procedure performs (Block 19540) a write buffer TDT source file WTS procedure (Figure 53, Block 25500). The index, i, is incremented (Block 19550), and the procedure returns to block 19465.

Block~ 19620 throug?h 19730 generate EXTERN entries for procedures. The pointer, e, is set to the first STDE table component name ~lock 19620), and then the procedure checks to see if e points past the end of the STDE table component name table. If so, the procedure jumps to Block 19800.
I~ not, the procedure next checks to see if the component indicated by ~ is a language ~STDETYP = C) entry type, with an~external procedure type (STDECTYP = EXTERN). If not, the procedure continuee at Block 19730. If it is, the procedure initializes the buffer, TDTBIF, to blanks (Block 19640).

The C language external procedure entry is built in the bu~fer as "extern int", with the procedure name from the .

-:

r~
~2~7~3 STDE table (STDENAME) at index location i, "()" (Block 19650). The line in the buffer is terminated by placing a new line character after the data ~Block 19700) and the procedure performs (Block 19710) the write buffer TDT source file WTS procedure (Figure 53, Block 25500). (Block 19730 increments e to the next STDE table component entry, and the procedure thsn returns to Block 19625.

Block~ 19800 through 20740 generate the TDT overhead structure ~ource statements. This consists of the C
statement necessary to build the TDT table portion shown in Figure 62, as TDT fields labeled TDTID through TDTATLE. As show in the Figure, a large portion this table is made up of pointers to other tables and table entries. Examination of the TDT documentation section will help in understanding the logic required to build this overhead structure.

Pointers throughout the CT procedure, are constructed in C ~ource as a pointer to a given tabla name subscripted by the index o~ the entry needed. For example, field TDTAMENU is a pointer to the panel entry, TPE, whose namP, TPENAME, is equal to application-generated menu name.
Assuming that this entry is the 5th entry, subscript 4 in C.
The C statement for such a ~efinition would be "&TPETAB~
43". So in ~ach case, the entry's subscript is located and then the statement is generated as in the example.

This section starts at Block 19800 by initializing the large buffer to blanks. The buffer C language TDT table struature de~inition header is built in the buffer as "struct ~DT IETTDT={0 (Block 19810). The C source to initialize ihe TDTID is built in the buffer using the value of gtdmmem (Block 19830). ThP C source to initialize the TDTRELN is built in the buffer using the value of gtdreln ~Block 19870). T~e C source to initialize the TDTGTIME is built in the buffer using the current clock time recorded as .:
~ TI-13766 220 - ~

:: :

' ' , '. ., ! ~ ' ~ . : ; , ,; ` . ' .'i;, ,, '; j ' ' . . ' r-- ~

seconds since 70/01/01 (Block 19960).

The C ~ource to initialize the TDTGDATE is built in the buffer usiny a zero. Because the date is implied in TDTGTIME, another implementation could record data and time information using both fields in TDT with different encoded values (Block 20010).

The C source to initialize the TDTDREP is built in the buffer using the value of the report name contained in ytdhdr ~Block 20030).

The C source to initialize the TDTDGEN is built in the bu~fer using the value of the generation name contained in gtdhdg (Block 20060~. The index number of the panel table entry which has the same value as gtdhmenu is then identified (Block 20090).

The C source to initialize the TDTAMENU is built in the buffer using the index number identi~ied. This is stored as the pointer to nth entry in TPETAB identified by the index number, the TPE number of TDTAMENU (Block 201003.

The index number of the panel table entry which has the value the same as gtdhhelp is then identified (Block 20170).
At Block 20180, the C ~ource to initialize the TDTAHELP is built in the buffer using the index number identified. This is stored as the pointer to nth entry in TPETAB identified by the index number, the TPE number of TDTAHELP.

The index number of the panel table entry which has the value the same as gtdhinfo is next identified (~lock 20250), and the C source to initialize the TDTAINF0 is built in the buffer using the index number identified. This is stored as ;the pointer to nth entry in TPETAB identified by the index number, the TPE number of TDTAINF0 (Block 20260).
: ':

f ~
~ ~` 2 ~ ~ r~ ~ r~ ~

The index number of the panel tablf~- entry which has the value the same as gtdhglos is identified (Block 20320) and the C source to initialize the TDTAGLOS is built in the buffer using the index number identified. This is stored as the pointer to nth entry in TPETAB identified by the index number, the TPE number of TDTAGLOS (Block 20330).

The C source to initialize the T3TNTPE is built in the buffer using the value of NP as the number of panels (number of TPEs).

The C source to initialize the TDTATPE is built in the buffer and stored as the pointer to the first entry in TPETAB, the transaction panel entry table (Block 20460).
,:
The C source to initialize the TDTNTCE is built in the bu~fer using the value of NC as the number of procedures (nl1mber o~ TCEs) (Block 20490).

The C source to initialize the TDTATPE is built in the buf~er and stored as the pointer to the firs~ entry in TCETAB, the transa~tion procedure entry table (~lock 20540)~

The C source to initialize the TDTAPPL is built in the buffer using the value of GTAPPL, the application name ~Block 205703.

The C source to initialize the TDTNTLE is built in the buffer using the value of NL as the number of language : .
entries (number of TLEs) ~Block 20610). ~
. -Blof-k 20660 checks to see if the number of language : entri~s is greater than zero (Block 20660). If it is, the C
source:to initialize the TDTATLE is built in the buffer and stored as khe pointer to the first entry in TLETAB.
.
~ ~ TI-13766 222 ~ J~

herwise, the C s~urce to initialize the TDTATLE is built in the buffer and stored as zero, or a NULL pointer reference, indicating ~hat there is no language table, TLETAB.

The C language TDT table structure definition, IETTDT
structure termination data is built in Block 20720. The procedure then performs the write large buffer TDT source file WTS procedure (Figure 53, Block 25500) to complete this section.

~ he next CT section, comprising Blocks 20800 through 21900, generates the panel table, TPETAB. TPETAB is a table o~ entriei, TPE. The structure for the TPETAB source file is tv defined TPETAB as an array of structure type TPETAB, with a max occurrence equal to the number of panel entries.
Pointers in these entries are created the same way as they were for the TDT overhead, see the discussion above. There will be one entry built for each panel defined.

This section begins by initializing the large buffer to blanks (Block 20800). Block 20810 then builds the source statement to dealare ~PE~AB as an array of structures of type TPE with an occurrence of the value NP. The buffer is then written to file at block 20840.

Next block 20860 prepare to build all the panel entxies by initializing index, i, to zero. Bli~ck 20865 check~i for the end of the panel definitions by determining whether i is equal to NP. If it is, control is passed to Block 21920. Otherwise, the large buffer is initialized to blanks (Block 20870), and the C language TDT structure array element prefix is built (Block 20880).

The C source to initialize the T~ENAME is built in the buffer using the value of the element in the panel name :

able indicated by the index (TP at index location i~ (Block 2091~).

The C source to initialize the TPEAMAP is built in the buffer using the value of the element in th~ panel name table indicated by the index (TP at index location i) (Block 20910), and is stored as a pointer.

Block 21000 locates the STDE table entry with the name, STDENAME, the same as panel name table entry indicated by index, TP at index location i, and sets the pointer e to indicate this element. Block 21030 then checks to see if the STD~ table element indicated by e is a menu entry. If it is, the menu input procedure is saved as "IETIMENU" in the variable procname. If not, the input procedure name, STDEIPNM, of the STDE table element indicated by e, is saved and placed in the variable procname.

Block 21070 locates the STDE table procedure entry (STDETYP = procname~ The number of procedures encountered in the STDE table before the desired procedure is located are counted and j is initialized with this count.

Block 21150 che ks to see if the procname is hlank. If it is, the C source to initialiæe thle TPEAITCE is built in the buffer llsing zero or null as the pointer value. If not, the C source to initialize the TPE~ITCE is built in the bu~fer and stored as a pointer to the ~irst entry in TCETAB, the Transaction Procedure Entry table, indexed by j, the count of procedures encountered in the STDE table before the procedure procname was located.

~ Block 21240 checks to see if the STDE table element indicated by e is a menu entry. If it is, the procedure saves the menu input procedure as "IETOMENU" in the variable rocname. If not, the procedure saves the output procedure name, STDEOPNM, of the STDE table element indicated by e, and places it in the variable procname. The procedure then locates the STDE table procedure entry (STDETYP = C) with the name (STDEN~ME) the same as the value of procname. The number o~ procedures encountered in STDE table before procedure is located is counted and j initialized with this count.

Block 21360 checks again to see if the procname is blank. If it is, the C source to initialize the TPEAOTCE is built in the buffer using zero or null as the pointer value.
If not, the C source to initialize the TPEAOTCE is built in th~ buffer and stored as a pointer to the first entry in TCETAB, the Tran~action Procedure ~ntry table, indexed by the count, j, o~ procedures encountered in the STDE table before the procedure procname was located.

The ~ source to initialiæe TPERSVD1 to zeros is built in the bu~er (Block 21450). This is currently unused. It is here to allow room ~or expansion and enhancements.

The C source to initialize OPCHTA to zeros is built in the bu~fer (Block 21490). This is also currently unused.
It is here to allow room for expansioll and enhancements.

Block 21520 locates the STDE table first entry with the name, ST~ENA~E~ the same as the panel name table entry -~
indicated by th~ indexj TP, at index location, i. Poin~er, 8, iS set to indirate this element. The number of menu entries encountered in the STDE table before the desired panel is located are counted and j initialized with this count.

~ Block 21570 checks to see if the STDE table entry i5 a menu, STDETYP = 'E'. I~ not, the proc~dure jumps to Block ' ,~ f~
2~3~
:l740. If it is, Block 21580, locates subsequent entries in the ST~E table with name, STDENAME, the same as panel name table entry indicated by TP at location i. The pointer is set to indicate the number of subsequent entries found in the rest of table, and initializes k with count. ..

The C source to initialize TPENTME is built in the buffer using the value of k as the number o~ menu entries which are related for the current menu panel (Block 21620).

The C source to initialize TPEATME is built in the buffer and stored as a pointer to the menu entry in TMETAB, indexed by j (Block 21680), after which the procedure jumps to Block 21840. This is the first menu entry related to the -:
current menu panel.

The C sources to initialize TPENTME (Block 21740) and TPEATME (Block 21790) to zeros are built in the buff~r. The procedure builds the C language TD~ structure array element suffix (Block 21840) and performs (Block 21890) the write bu~fer TDT source file W~S procedure (Figure 53, Block 25500). Index i is incremented (Block 21900) and the procedure jumps to Block 208i65.

The procsdure initializes the large buffer to blanks (Block:21920), and then builds the C language TPETAB table structur~e array de~inition suffix in the buffer (Block 21930)~. The procedure then performs (Block 21940~ the write ; ~ bu~fer TDT source file WTS procedure (Figure 53, Block 255:0~

; :` Blocks 22010 through 22720 generate the TCETAB in a very: similar manner ~o the way the TPETAB wasi built. There will:be one entry generated for each procedure defined. This section begins by initializing the .large buffer to blanks ` : (Block 22010).

~: :
: ~ :

r~
~ 3~ 7 0 The C language TCETAB table structure array is built in the buffer using the value of NC as the number of procedures (TCE) stucture elements in the TCETAB table (Block 22020).
The procedure performs (Block 22050) the write buffer TDT source file WTS procedure (Figure 53, Block 25500) and then initializes the pointer to the first STDE table component name (Block 22080). (Block 22085 checks to see if e points past the end of the STDE component table. If so, the procedure jumps to Block 22700. Otherwise, Block 22090 checks to ~ee if the component type of the component indicated by e is a procedure, STDETYP = C, entry definition. If it is not, the procedure jumps to block 22670.

The procedure initialize~ the large buffer to blanks (Block 22100), and then builds the C language TDT structure array element pre~ix (Block 22110).

The C source to initialize TCENAME is built using the value of STDENAME in the STDE table name table entry indicated by index e (Block 22140). (Block 22180 checks to see i~ the procedure component procedure type indicates a procedu~e that belongs to another application transaction proqram, STDEÇTYP = "EXTERN". If it does, the procedure builds the C source to initialize TPEAPROC to zeros or null value. If notl the procedure builds the C ssurce in the bu~fer to initialize TPEAPROC, using the value of STVENAME
in the STDE table name table entry indicated by index, e, and stores it as a pointer.

Bloc~ 22280 checks if the procedure component input view is not defined, STDEIPNM = blanks. If it is not defined, the procedure builds the C source in the buffer to initialize TCEAIVW to zeros or null value. If it is, the procedure builds the C source to initialize TCEAIVW using ~'~ . a~

llue of STDEIPNM in the ST~E table name table entry indicated by the index, e, and stores it as a pointer.

Block 22360 checks if the procedure component output view is not defined, STDEOPNM = blanks. If it is not defined, the procedure builds the C source in the buffer to initialize TCEAOVW to zeros or null value. If it is, the procedure builds the C source to initialize TCEAOVW using value of STDEOPNM in the STDE table name table entry indicated by the index, e, and stores it as a pointer.

Block 22440 checks if the procedure component profile view is not defined, STDEPVNM = blanks. If it is not defined, the procedure builds the C source in the buffer to initialize TCEAPVW to zeros or null valueO If it is defined, the procedure builds the C source to initialize TCEAPVW using value of STDEPVNM in the STDE table name table entry indicated by th~ index, e, and stores it as a pointer.

Block 22520 checks if the procedure component is a DBMS
type procedure, STDECDB2 = Y. If it is a DBMS type, the procedure builds the C source in the buffer to initialize TCEDBTYP to 1, flagging it as a database procedure. If it is not, the procedure builds the C source to initialiæe TCEDBTYP to æeros, flagging it as a non-database procedure.
The procedure builds the C language TDT structure array element suffix tBlock 22610) and performs (Block 22650) the write buffer TDT source file WTS procedure (Figure 53, Block 25500). Pointer e is incremented (Block 22670), after which the procedure returns to Block 22085.

At this point, the CT procedure creates source to build the menu table, TMETAB. Here too, there will be one sntry per menu. The procedure initializes the large buffer to blanks (Block 22700) and builds a C language, TMETAB, table structure array definition suffix in the buffer (Block : ~ : ' :~ :
-.

,, . , . . ! . . . , ': ', . . :~ ': . , '.' ' ' ' ' ' 7 ~
2710). At Block 22710 the procedure then performs the write buffer TDT source file WTS procedure (Figure 53, Block 25500).

Blocks 22790 through 23420 generate the TMETAB. This section begins at Block 22790 by initializing the large buffer to blanks. The C language TMETAB table structure array is then built in the buffer using the value of NE as the number of procedure (TME) stucture elements in the TMETAB table (Block 22800). The procedure performs (Block 22830) the WTS procedure (Figure 53, Block 25500~ and then initializes the pointer, e, to the first STDE table component name. (Block 20865 checks to see if e points past the end of STDE table component table. If it is, the procedure jumps to Block 23400. Otherwise, the procedure tBlock 22870) checks to see if the component type of the component indicate by e is a menu entry definition ~STDETYP = E).

Block 22890 builds a C language TDT structure array element pre~ix. The C source to initialize TMESEL is built using the value of STDENAME in the STDE table name table entry indicated by index, e (Block 22920). (Block 22180 locates the panel name in the panel table with the same name as the menu output panel indicated by pointer e. Index j is initialized with the number of panels encountered in the panel table before the desired panel is located.
.
8}ock 23000 checks if the procedure component profile view i~ not defined, STDEIPNM = blanks. If it is not definedj th~ procedure builds the C source in the buffer to initialize TPEATPE to zeros or null value. If it is definedj the procedure builds the C source to initialize .
TPEA~PE~using the j as an index into the panel table, TPETAB
and stores it as a pointer to the jth entry ln TPETAB
identified by the valu~ of j and the TPE number of the :, 2~2~ 3 ~
rDEIPNM panel.

Block 23100 locates the STDE tabl2 procedure entry, STDETYP = 'C', with tAe name, STDENAME, th~ same as the valua of the menu output procedure name, STDEOPNM, in the menu entry in the STDE table indicated by pointer e. Index j is initialized with the number of procedure encountered in the STDE table before the procedure is located.

Block 23170 checks if the procedure menu output procedure is not defined, STDEOPNM = blanks. If it is not defined, th~ procedure builds the C source in the buf~er to initialize TPEATCE to zeros or null value. If it is defined, the procedure builds the C source to initialize TPEATCE using the j as an index into~the panel table, TCETAB
and stores it as a pointer to the jth entry in TCETAB
identified by the value of j and the TCE number of the STDEOPNM panel.

The procedure builds the C source to initialize TMEDESC
using the value of STDEDESC in the STDE table name table entry as indicated by the index, e.

Block 23300 builds the C language TDT structure array element 6u~fix and performs (Block 2:3350) the WTS procedure (Figure 53, Block 25500). Pointer e is incremented (Block 23380) after which the procedure retur~s to Block 22085.

The large buffer is initialized to blanks (Block 234001, a C language TMETAB table structure array definition su~ix is built in the buffer (Block 23410), ~nd the procedu~e performs (Block 23420) the WTS procedure (Figure 53, Block 25500).

The next portion of the CT procedure (Blocks 23490 through 23870) generates the transaction language ~ TI-13766 230 ~3. l ~
f~ ~
7 ~
ble,TLETAB. As noted by the flow chart, no transaction language entries will be built if none are defin~d. (Block 23490 checks to ~ee if the number of language entries, NL, are greater than zero. If they are not, the procedure advance to block 23950. If they are, the procedure initializes the large buffer to blanks (Block 23550).

Block 23510 builds the C language TMETAB structure array definition using ne as the number of procedure (TME) sturcture elements in the TMETAB table. The procedure performs the WTS pro~edure (Figure 53, Block 25500) and pointer e is incremented to the first STDE table component name (Block 233B0).

Block 23575 checks to see if e ~oints past the end of the STDE table componenk table. If it does J the procedure jump~ to block 23850. If it does not, the procedure checks to see if the component type (STDETYP3 of the component indicated by e is a language entry definition. If not, the procedure jumps to block 23830. If it is, the procedure initializes large buffer to blanks (Block 23590) and builds a C language TDT structure array element prefix (BlocX 23600).

Block 23630 builds the C source in the buffer to initialize TLENAME using the language name in the STDE table name table entry indicated by index, e.

Block 23670 builds the C source in the buffer to initiali~ TLEDREP using the documentation report file name, the~value of STDEIPNM in th STDE table name table entry indicated by index, e.

Block 23671 builds the C source in the buffer to initialize TLEDGEN using the documentation generation name, the value o~ STDEOPNM in the STDE table name table entry : TI-13766 231 dicated by index, e.

The procedure initializes the large buffer to blanks (Block 23850), builds the C languag~i TLETAB table structure array definition suffix (Block 23860), and performs (Block 23870) the WTS procedur~ (Figure 53, Block 25500).

The next section of the CT procedure (Blocks 23950 through 242230) generates the DB synchronization function address table. This table is used only if a procedure has been declared to be a DB user. However, although the table exists, the procedure pointer generated will be 0, so that the link editor will not try to link in the DB
routines.

This section of the procedure begins at Block 23960 by initializing the large buffer to blanks and builds the C language DB synchronization function address table structure de~inition (Block 23960).

Block 23980 checks to see if the application contains any procedures with STDECDB2 flagged (flag set to dbtype =
1). If not, the procedure jumps to block 24100. If STDECDB2 wa~ flagged, the procedure builds the C source to initialize the connect using the IETCONN function addre~s. IETCONN
p~rforms a DBMS login or connect function within IET. The procedure then builds the C source in the buffer to initialize the commit using the IETCOMM function address (Biock 24050). IETCOMM performs a DBMS commit function within IET.
:
The~ procedure builds the C source in the buffer to initialize the release using ~he IETREL function address (Block ~24055) and~ then proceeds to block 24210. IETREL
~performs~ a DBMS release or logout function within IET.

' : : ~. .

~ 2 3 ~ 7 ~) .
The proce~ure builds the C source in the buffer ~o initialize the connect using zeros or null pointer value in Block 24100. At Block 24130 the procedure builds the C
source in the buffer to initialize the commit using zeros or null pointer value, and then builds the C source in the buffer to initialize the release using ~eros or null pointer value in Block 24160.

The procedure builds the C language DB synchronization structure initialization suffix (Block 24210), and performs tBlock 24230) the WTS procedure (Figure 53, Block 25500).

The next portion of CT procedure Blocks 24250 through 24500 generates the TDT source suffix and closes the source ~ile. This section of the procedure begins at Block 24260 by setting the index to the beginning o~ the TDT suf f ix initialization data. The procedure checks to see if the index points to the last line of the s~fix initialization data in Block 24270. I~ so, the procedure ~umps to block 24440. If not, the procedure copies the line of TDT suffix into the output bu~fer (Block 24300) and terminates the line in the buffer by placing a new l:ine character after the data (Block 24320).

Block 24330 p rforms the WTS p:rocedure: (:Figure 53, Block 25500) and saves the return code. T~e index is incremented and the procedure returns to block 24350.
, .
~ Block ~4440 checks to see if the return code is good. -~:
::~: If it is, the procedure proceeds to Block 24500 and closes the TD~ source file. If not, the error message out, gtdmsg, :~
is:set ~ equal to "TDT SOURCE WRITE ~RROR" (Block 24460) and -:
~` the program exits the CT procedure with an error.
~ .:
he last portion of the CT procedure (Blocks 24560 through 25070) compiles the TDT. This section of the : : TI-13766 233 -, .. :
,:

2 ~
^ocedure begins at Block 24560 by setting up the compile parameter values. The compile parameters are copied to the list Block 24790)~ For UNIX implementation, the original directory is saved (Block 24890) and the directory where the TDT source is located is changed (Block 24900)~

(Block 24910 next calls the C compiler with the paramet~r list and saves the return code. For a UNIX
implementation, the procedure changes back to the original directory (Block 24920)o Block 24950 checks to see if the return code indicates the call to tihe C compiler failed. If it did not, the program advances to Block 25000~ If it did fail, the error message out, gtdmsg, is set equal to "TDT cc spawnvp failed, errno = rc7' (Block 24950) and the progxam exits the CT procedure with i~n error (Block 24970).

Block 25000 checks to s~e if the return code indicates the C compiler terminated with error conditions. If it did not, the program jumps to block 25070. If it did terminate with an error, the GTD output file is shown to the user with the compiler error messages.
Block 249~0 sets the error message out, gtdmsg, equal to "TDT COMPILE FAILED" and the program exits the CT
procedure with an error (Block 25030).

Block 25070 sets the message out, gtdmsg, to "TDT
COMPILE COMPLETE", and the program exits procedure CT.

, ; ~ :
--..

.
:

r, . b~
~ 7 GTD ADD VIEW NAME 'ro Tl~B~ rVA PRC)CEDURE. Looking now at Figures 52a-b, which depict the preferred embodiment of this procedure according to the present invention, the GTD
add view name to table procedure adds an input view name to the view table in ascending sequence and updatec a view kable count, and begins with the Decision Block 25210 to chsck if the input view name is blank. If blank, the program exits the procedure with no error. If the input view name is not blank, Decision Block 25220 checks if the input view name is zero. If so, the program exits the TVA procedure with no error. If not, Decision Block 25250 chacks if the number o~ views exceed the maximum view table size. If yes, the program sets the error message field, GTDMSG--VIEW T~BLE
FULL (Block 25260) and exits the TVA procedure with an error (block 25270).

If the number of views do not exceed the maximum view table size, a view table location is found fsr the view table name (Block 25350~. The view table is built in an ascending sorted manner. Decision Block 25355 checks for the input view name, vname, to see i~ it was found at the view table location. If found, the program exits the TVA
procedure (Block 25420~. If input view name, vname, is not -found at the table location, the procedure moves the table entries ov~r to make room for the new name (block 25360) and then proceed~ to Bloc~ 2S390. -'.
Block 25390 step puts the name, vname, in the table at the location that was ~ound, and then increments the view count NV ~Block 25400). When this is completed, the program exits the TVA procedure (Block 25420).

:
GTD ~ITB B~FFER TO FILE: W~S PROCED~. Briefly considering Figure 53, which depicts the preferre~ -:'' r ~ , ~
~ i~

embodiment of this procedure, the GTD write buffer to ~ile procedure begins at Block 25530 by writing the data buffer to file. Decision Block 25550 then checks if the write was successful. If not, the error message field is set GTDMSG=TDT SOURCE WRITE ERROR (Block 25560), and the program exits the WTS procedure with an error (Block 25570).
Otherwise, the program exits the WTS procedure at Block 25420. 25420~.

:: ' .:

:' ~'1 /
~ r~

G~D CO~PILB VI~W: CV PROCEDUR~. Considering now Figures 54a-mm, which depict the preferrPd embodiment of this procedure according to th~ present invention, this process involves verifying the view compile is required, as well as building and compiling the views. The verifying process is done in the following manner. First, the name of the view object module is built and the modify date and time is collected. Next, list of all the views is built from the T~F. Then, the modify date~ of user view files and the transaction view file are checked against the date of the view object module. The build and compile process is required if any of the user view files or the transaction view file has an equal or later date than the view object module, or if an unconditional compile is requested by the user.

During the build view process the C transaction view file (.h)is regenerated from the COBOL transaction view file to maintain consistent transac~ion views between COBOL and C
language procedures.

VMOH and VMOF tables are constructed for each user view. Help, glossary, and information profile views are constructed with VMOH and VMOF tables and written out to the -view C source file. For each user view, the view fields are read into a tabla, and the VMOH and VMOF tables are constructed and written out to the view C source file. If the cons~ruction i~ successful, the view source file is closed and the view is compiled.

Starting at Block 25870/ the GTD compile view CV
procedure rewinds the GTD output file and saves the maximum view length in ~h~ variable g~dmvwl (Block 26120). -~
~: "
Blocks 26170 through 26285 set the fully qualified ;:

, , ~ , ,, ,, ~ . , . . . ,, " .,, ", . .. .. . . .... . .. - ... .. ..... .

r . g~
~3~ 7~
pathname of the view object module and obtain the object module modification da~e and time. The fully qualified view object module file pathname is built using the map library pathnam~: gtdmlib, the TDT name: gtdmmem, and the suffix VIEW.o (Block 26170).

In Block 26280 the existence of the view object module is checked and the file description information is obtained.
Block 26285 checks if the view objec~ module exists. If so, the view object module modify date/time is ~itored in otim and the program continues executing with Block 26380. If not, otime is set ~o zero and the program continues executing with Block 26380.

The next portion of the CV procedure, (Blocks 26380 through 26465) builds a list of views from information contained in the STDE table. First the number of views is set to æero, NV = 1 (Block 26465), and the pointer, e, is initialized to the beginning of the STDE table. Decision Block 26405 checks to seP if e points beyond the end of the STDE table. If so, the procedure jump~, to Block 26510. If not, the procedure checks to see if the current entry in the STDE table is a procedure entry, STDETYP = C (Block 26410).

If the STDE table entry is not a procedure entry (Block 26410), the program continuei executing at Block 26460. If the STDE table entry is a procsdure entry, then TVA
proce~ure (Figure 52, Block 25170) is performed to add the input vi~w name STDEIPNM to the view table (Block 26420).
If the input view is not successfully added, the CV
procedure is exited with an error (Block 26425). Otherwise, the procedure adds the output view name S~DEOPNM to the view ~able by performing the TVA procedure (Block 26430).

If the output view is not successfully added, the CV
procedure is exited with an error (Block 2643~). If the . .

~ ~ 3 output view is successfully addsd, the TVA procedure is performed to add the profile view name STDEPVNM to the view table (Block 26440). If the profile view is not successfully added, the CV procedure is exited with an error (Block 2644S). If the profile view is successfully added to the view table, e is set to point to the next STDE entry in the STDE table (Blsck 26460), and the procedure returns to Block 26405.

The se tion of the CV procedure represented by Blocks 26510 through 26590 determines whether the view compile is required in order to maintain program source/object consistency. This involves checking the unconditional compile flag and then checking the modify dat~/times of all view source (including the transaction view modify date and time) against the modify date/time of the view object as stor~d in otime. Decision Block 26510 checks to see if an unconditional compile is requested by the application developer, gtdcflag = U (Block 26510). If 50~ the view compile is required, compile is set to 1 (Block 26510), and execution continues with Block 26550. If not, the view compi.le requirement has not yet been fully determined, compile is set to 0 (Block 26510), and execution continues with Block 26550. Blosk 26550 sets view table index, IV, to zero.

: Decision Block 2655S checks to see if the view table index is less than the number of views in the view table, IV
~ NV. At Block 26555 if the view table index is less than the number of view~ in the Yiew table, execution continues with;~ Block 26560 which sets t~e current modify date/time variable to zero, mtime. Otherwise, the program proceeds to Block 26920. Block 26560 sets the current modify date/time variable to æero, mtime.
.
Decision Block 26570 checks if the current view : TI-13766 239 . ' '.

~5~7~
id~ntified by index IV in the view table is the glossary profile view IE~GPVW. If so, at Block 26270 th~ modify date/time is set to negativs one (-1) indicating that no conditional compile file check is required later and execution proceeds with Block 26580. If not, execution continues wîth Block 26580 which checks if the current view identified by index IV in the view table is the help profile view I~THPVW. If so, the msdify date/time is set to negativ~ one (-1) indicating that no conditional compile file check is required later. Execution proceeds with Block 26590.

Decision Block 26590 checks if the current view identified by index, IV, in the view table is the information profile ~iew IETIPVW. If so, the modify d~te/time is set to negative one (-1) indicating that no conditional compile file check is required l~ter. Executi~n of the CV procedure then continues with Block 26600.

At Block 26600, if a file check i~l not required (mtime not - 0~, the program jumps to Block 26~00. If a file check is required (mtime = 0), the ~ully qualified user view file name is built using pathname: gtdslib, current table view name, and suf f ix It . Vll ( Block 26610~.

Block 26680 checks the exi~tence of the user view file and obtains the file description information~ If the view user file exists (Block 26685), the view user file modify date/time is stored in mtime (Block 26700), and the program proceeds to Block 26~5D. I~ the view file does not exist, an error has occurred and the program advances to ~lock 26720. Block 26720 saves the current view table name indicated hy IV into gtdvmem and performs the procedure to display a panel (Figure 21, Block 47300), electing to display the GTDCVE3 compile view error panel (Block 26760).
Block 26760 performs the FE procedure ~Figure 22, Block r- ~
V ~, ~2~

48130) to check for user input end indications. If an end is indicated (Block 26785), thP program exits the CV
procedure with an errsr (Block 26830). Otherwise, the program returns to Block 26760.

In Decision Block 26850 a check i5 made to see if the user view file modify date/time is less than the transaction view modi~y date/time, mtime < tvwtim~. If so, the transaction view ~ modify date/time is saved in mtime (Block 26850) and execution continues with Block 26860. If not, the larger of the transaction view date/time and usPr view ~ile da~e/time, mtime, is compared to the ob~ect module modify date/time, otime. If mtime is greater than or equal to otime, then a view source has been modified and a view compile is reguired. The procedure at Block 26860 sets the compile ~lag to one and continues execution with BlOck 26900. If mtime is less than otime, the procedure increments the view table index IV (Block 26900) and retirms to Block 26555 to check date/time validation on the remaining views in the Vi2W table.

Deci~ion Block 26920, checks to see if a view compile is required either by the application developer ~gtdcflag =
U) or by the date/time validation process (compile = 1). If a view compile is required (Block 26920), the procedure advances to Block 27020 to start the view compile process.
If a view compile is not required, the GTD message field gtdmsg is set to "VIEW CO~PILE NOT REQUIRED" (Block 26930), and the CV pro~edure is exited with no errors indicated (Block 26940).
, .
: ; Blocks 27020 through 27160 set up an internal table of transaction view field informatio~. This process is essentially a compiler for the transaction view COBOL source -: which encodes the field displacement, type and length :~.
information output from the compile, and places that .,,..,.. ,...,, . .,. ".,,~,, ...,~,. ..

information into an internal table. The internal table contains for each field: the ~ield displacement relative to the beginning of the transaction view, the field type, the field length, and the field occurrence multiple. This informa$ion is used when creating the VMOF table entries and as input to the COBOL/C translation utility which translates the COBOL transaction view into a C version of the same transaction view. Another translation utility may be employed which does not use the internal table as input. The method of the pref~rred embodiment used here, is efficient because it does not require any duplication of effort between generating the field offset, length, etc.
information and generating the C version of the transaction view. The two views are required to result in the same memory usage and allocation for each language version of the transactiQn view.

Block 27020 builds the fully qualified pathname of the COBOL transaction view and then calls the internal compiler utility to generate a memory table of the transaction view ~ield attributes discussed above. This memory table is accessed through a pointer cpytable. Decision Block 27125 checks to see if the utility was successful. If so, the prosram proceeds to Block 27260 to cont~;nue with the compile view process. If the utility was not successful, an error occurred, so the GTD error message field gtdmsg is set to "TVW OPEN ERROR" (Block 27150) and the CV procedure is exited with an error (Block 27160).

Blocks 27260 and 27360 invoke the COBOL to C translator to generate the C transaction view from the COBOL
transaction view. This techniqu~ ensures data consistency and integrity of the transaction view interpretation between the IET and the applica~ion program as well as for applications which have both C and COBOL procedures within one load module. Block 27260 builds the fully qualified pathname of the C transaction view and then calls the COBOL
to C translator (Block 27360).

Blocks 27460 through 27630 open the view source module to bP generated and place constant prefix information into the source module? Every line of prefix source is copied to a ~uffer and then the buf~er is written using WTS procedure (Figure 53l Block 25500).

Block 27460 builds the file pathname of the view module to be generated using the SRCLIB pathnam~ GTDSLIB, the transaction view name, and the standard suffix "VIEW.cl'.
Block 27510 then attempts to create the view module with that constructed path. Decision Block 27515 tests for a successful create and if so, execution proceeds to Block 27550. If the create file was not successful, the CV
procedure is exited with an error.

Block 27550 sets an index to the beginning of the prefix source and then proceeds to Decision Block 27555 which tests for the last line of the c view prefix source.
If found, execution proceeds ko Block 27700. If the last line of the prefix source has not been reached, that 11ne of c view source is copied to an ou~put buffer ~Block 27590) and the line is terminated in the buffer (Block 27610). The buffer~is then written to the c view source file (Block 27620) Usinq the WTS procedure ~nd the prefix source index is incremented (Block 27630).

Block 27700 initialize~ the index (IV) to the ~irst name in the view table and Decision Block 27705 then determines if the index is less than the number of view table entries. If the index is greater than the number of ~iew table e~tries, control is passed to Block 30660.

f the index points to a valid view $able entry, blocks ~' - ~ - - - ; . .. . ..

r r~ ~ d~i~

27710 through 28190 initialize multiple field names and values for that view. Block 27710 saves the view name (from the view table, indexed by IV), to a memory area.

Specifically, Block 27720 sets the view header length.
The procedure then initializes the number of fields to indicate no fields counted in the user view files (Block 27770) and initializes the v~rsion with the value (0100) of the default version (Block 27780).

Decision block 27840 tests ~or whether the view name (from the view table) is equal to the HELP PROFILE VIEW and, if not, execution continues at Block 27990. If so, control passes to Block 27850 which initializes' the number of fields in the HELP PROFIL~ VI~W to 4. Block 27860 then initializes the field table to blanks, and Blocks 27890 through 27920 then save field name~ "IEF1-HELPPNL," 'IIEFl-HELPCHP,'' "IEF1-HELPSEC," and "IEF1-HELPPAG'7 as the firs~ through fourth ~ields in the field table respectively, beginning at index 0.

Decision Block 27990 tests for the view name (from the view table, indexed by IV) equal to the glossary view and, if not found, passes control to Block 28120. If found, control passes to Block 2i8000 which initializes the number of fields in the HELP GLOSSARY VIEW to three. Block 28010 then~ initializes ~he field table to blanks. Blocks 28040 ~through 28060 then save the field names "IEF1-GLOSPNL, 1l i'IEFl-GLOSCHP," and "IEF1 GLOSSEC" as the first through third fields in the field table beginning at index 0~ -Decision Block 28120 then tests for the view name (from : the view table at index IV) equal to the INFORMATION PROFILE
VIEW and, if not found, passes control to block 28270. lf fou~d,~ Block 28130 initializes the number of fields in the help information view ~o three and Block 28140 ini~ializes " .:
.

r~ , ~
~ ~ 2 the field table to blanks. Blocks 28170 through 28190 then save the field names "IEFl-INFOCHP," "IEFl-INFOSEC," and "IEFl-INFOPAG" as the first through third fields in the field table beginning at index 0.

Decision Block 28270 tests for the number of fields still negative and, if none are found, passes control to Block 28750. If any are found, control passes to Block 28280 which builds the user view file name using the gtdslib pathname from SRCLIB, the table view name as indexedl and the suffix ".v".

Block 283~0 then opens the user fils using this pathname for read only and Block 28350 initializes the r.umber of fields to zero. Block ~8360 then reads a lin~ from the view file and places that line in the buffer. Decision Block 28360 tests for a successful read. If not successful, control passes to Block 28610. Otherwise, control passes to Decision Block 28364 whi~h tests whether the number of fields in the field table is less than the maximum table len~th and if not, passes control to Block 28610. If so, control pa~ses to Decision Block 28390 which tests ~or the read buffer (Block 28360) beginning wi~h a blank, or asterik, or binary zero, or new line and, if found, continues execution at Block 28630. If not found, Decicion Block 28400 looks for the read buffer beginning with a period. If not ~ound, control passes to Block 28520. If found, Block 28460 translates ~he buffer data ~o upper case.
Decision iBlock 28470 tests for the buffer containing a keyword for version information and, if not found, passes control to Block 28630. If found, Block 28480 extracts version data from the buffer and places that data in the version variable. Block 28520 moves the field name to the ~ield~table at the index location of the field count. Block 28610 then increments the field count. The procedure then returns to Block 28360 to read the next line from the view : TI-13766 245 :

r , ~
,~ r~

file.

Block 28640 ~loses the user view file. Decision Block 28750 tests for whether the number of fields is non-zero and, if so, generates a reference to VMO~ and passes control to Block 28760. If the number of fields is zero, control passes to block 288~0. Block 28760 builds C source in the buffer to generat~ a reference to VMOF, to resolve VMOF
references embedded in VMO~ using the value of the view table index in the ~MOF table name.

Block 28830 builds C source in the buffer to define VMOH structure, using the value of the viPw table name at the current index as the VNOH table name. Block 28870 builds C ~ourre in the buffer to initialize VMOHAPPL, u~ing the value of the ~TD name. Block 28920 builds C source in the buffer to initialize VMOHVIEW using the value of the view table name at the current index. Block 28980 builds C
source in the buffer to initializ~ VMOHTM~ to zerss. Block 29010 builds C source in the buffer to initiali~e VMOHDTE to zeros. Block 29040 builds C source in the buffer to initialize VMOHVER using the value of the version variable (the d~fault or user specified ver~.ion id). Block 29080 builds C source in the buffer to initialize VMOHFMT to 1.
Block 29120 builds C source in buffer to initialize VMHORSVO
to zero. Block 29160 builds C source in the buffer to initialize VMiOHNE using the value of the number of fields in the view.

.
Decision BlocX 23230 tests ~or the number of fields in the view greater than zero and, if none, builds C s~urce in the buffer to initialize VMOHAE to zeros and then passes ontrol tG Block 29320. I~ the number of fields in the view is greater than zero, C source is built in the buffer to initialize VMOHAE using the value of the view table index number~to generate the VMOF table name and is stored as a r . ~
.,~ ~
~a~3~7~
pointer to the first element in the corresponding VMOF array table.

Block 29320 builds C source in the buffer for VMOH
structure definition initialization suffix. Block 29340 writes the buffer to the TDT source file using WTS procedure and saves the return code. Decision Block 29420 tests for the numbex of fields greater than zero and, if there are none, passes control to Block 30570.

If the number of fields is greater than zero, Block 29430 initializes a large buffer to blanks. Block 29440 builds in ~ha~ bu~fer C source language for a VMOF ta~l~
structure array de~inition using the number of fields as the number of VMOF structure elements in the table. The values of the view table index number i5 used to generate VMOF
table names as VMOFnnnn where nnn~ contains the index value.
Block 29490 writes the buffer TDT source file using the WTS
procedure. Block 29510 initializes an index to point to the fir~t name in the field table.

Decision Block 29515 tests whether the table index is less than the number o~ field table entries and, if not, passes control to Block 30390. If so, Block 29530 saves the table file name at the index location in gtdaname, Block 29540 initializes variables fldd, fldl, fldt, and fldn to zeros, and Block 29550 finds the index value gtdaname in khe internal transaction view field table.

Decision Block 29630 tests for whether the search was successful and, if so, passes control to block ~9640. If not, control pass~s to Block 29780. Blocks 29640 through 29670 save the field displacement, field length, field type, ~and ~ield zero occurrence found in the inter~al table into fldd, fldl, fldt, and fldn, respectively.

:
: .

~ ~ 3 Decision Block 29680 tests whether the field has zero multiple occurrences and, if so, increments the view length by the field length. Otherwise, the view length is incremented by the field length multiplied by the number of ~ield multiple occurrences. Execution continues with Block 29910.

Block 29780 performs a procedure display (Figure 21, Block 47300) of the GTDCVE2 panel view error display panel.
Block 29800 checks for user end indication and performs khe FE procedure (Figure 22, Block 48130~, If an ~nd was indicated, execution continues with Block 29850 where the program exits the cV procedure with an error (Block 29850).
If not, co~trol is passed to Block 29780.

Block 29910 initializes a large buffer to blanks.
Block 29920 builds C source in that buffer for a comment identifying the field name using gtdaname. Block 29960 builds C source for a TDT structure array element prefix.
Blocks 30000 through 30210 build C source in the buffer to initialize VMOFRlED using the value of fldd ~field displacement in thc work area), to initialize VMOFRlEL using the value of fldl (field length in the work area), to ini~ialize VMOFRlEN using the value of fldn (field number of occurrences~ in the work area), to initialize VMOFRlET uising the ~value of fldt (field element data type3, and to initiallze VMOFRSV2 to æeros, respectively.

Block 30300 builds C source for the TDT structure array element suf~ix. Block 30305 writes the buffer TDT source : : :
: ~ile usin~ the WTS procedure. Block 30310 increments the index i. The program then returns to Block 29515.

Decision Block 30390 tests whether the view is too long (gtdcvwl greater than RFVXML)~and, BIock 30420 performs the procedure display o~ GTDCVEl panel (view error display TI-1~766 248 :. .

`~ ~ 2 -~ ~ 7 ~ :
panel). I~ so, Block 30440 tests for a user Pnd indication (FE procedure, Figure 22, Block 481303. If the view is not too long, control passes to Block 30520.

Decision Block 30~45 tests the result of Block 30440 and if an ~nd was indicated, passes control to Block 30490.
Otherwise, control is passed to Block 30480 which forwards control to Block 30420.

Decision Block 30490 exits the CV procedure with an error indication. Block 30520 builds C source in the buffer for the VMOF structure array definition initialization suf~ix. Block 30540 writes the buffer TD~ source file using the WTS procedure and saves the return code. Block 30570 increments the view table index and passes control to Block 27705.

Decision Block 30660 tests whether the return code from the last write is good and, if so, passes control to Block 30730. If not, control is passed to B].ock 30680 which sets an error message gtdmsg = "TDT SOURCE W~ITE E~ROR"~ At Block 30690, the program exits from the CV procedure with an error.

~ lock 30730 closes the view C source file. Block 30740 releases memory used by the internal transaction ~iew table.
Block 3081~ sets up compile parameter values. Block 30990 copies the compile parameters to a list~ Block 31080 saves the original directory and Block 31090 changes to the directory in which the view source is located (UNIX
implementation only)~ Bloak 31100 calls t~e C compil~r with the parameter list built above ~Block 30990) and saves the return code.

.
Decision Block 31130 tests whether the compiler return code indicates the compller ~erminated~with an error and, if ~.

r~ ~

so, passes control to Block 31150. If not, execution continues at Block 31200. Block 31150 shows the GTD output file to the user with the compiler error message. Block 31160 sets the error message ~or output gtdmsg = "VIEW
COMPILE ~AILED". The program exits the CV procedure with an error (Block 31170).

Block 31200 sets the message for output gtdmsg = "VIEW
COMPILE COMPLETE". Block 31210 ends the CV procedure.

':
:

:
:~ ."'' ,...

f~ ~

'D COMPIL~ PAN~L~: CP PROCEDURE 2 ~ 7 Looking next at Figure 55, which depicts the preferred embodiment of this procedure according to the present invention, the compile panels procedure initiates a compile process for each panel in the application. It first builds a list of all the panels in the application from the menus and panel names listed in the STDE table and then initiates the compile process for each panel in the listO

The CP procedure begins at Block 31540 by building the panel name table from the STDE panel and menu entries, and counting the number of panel names, NP (Block 31670). Then, the i index is initializ~d to the beginning of the panel name t~ble (Block 31870).

Decision Block 31875 checks if i is less than or equal to the number of panels in the panel table, NP. If so, the procedure sets the mesgage field to GTDMSG="PANEL COMPILE
complete" (Block 31950) and the program exits the CP
procedure (Block 31960). If i is greater than NP, the procedure moves the panel name into GTDPMEM in the work area (Block 31880). Block 31890 next performs the compile the panel procedure CPO ~Figure 56, Block 32030), Decision Block 31895 checks if the compile was successful. If it was, and is incremented (Block 31930), and execution proceeds to Decision Block 31875. If compile was not successful, the get error message field is set to GTDMSG-"PANEL COMPILE
FAILED" (Block 31900~. The proc dure returns with the error (Block 31910), increments i (810ck 31930), and returns to ~Decision Block 31875.
.

CO~PI~E ~ANE~: CPO P~OCED~RE

Looki~g now at Figure 56a-c, which depict the preferred '-'.

.

ff~ . e~

, nbodiment of the GTD compile panel procedure, the CPo ~ 7 procedure begins by building the fully qualified file pathname of the panel source module (Block 32150). The file statistics on the panel source are obtained ~Block 32220~
and the modify date and time are saved in mtime (Block 32230). The transaction view modify date and time are then compared to the panel source date and time. If the transaction view modify date/time is greater than the panel source date/time, the transaction view modify date/time is saved in mtime (~31Ock 32240) and execution continues with Block 32260. If not, execution continues with Block 32260.

The fully qualified pathname of the panel object module is then built (Block 32260). The file statistics on the panel object module are obtained (Block 32373). Decision Block 32375 checks to see if the file statistics were obtained successfully.

If the statistics were obtained successfully, the object modify date and time are saved in otime. Otherwise, otime is initialized to zeros (Block 32375~. The source and object modify times are then compared (Block 32420). If the source modi~y time is great~r than the object modify time (mtime > otime) the program jumps to Block 32440.

If thP source modify time is not greater than the object modify time, the program checks to see if this is a :~
conditional compile (gtdcflag = C) ~Block 32425). If so, the CP0 procedure ends and returns with no error (Block 32425). If this is not a conditional compile, compiler :
~parameters are built (Block 32440). The panel compiler is then called to produce the object file (Block 33070). The compil:e status is checked (Block 33180~. If the compile was successful, the CP0 procedure ends (Block 33180).
: : Otherwise, the gtdmsg is :se~ to "COMPILE FAILED" (Block :-33230). The error messages are displayed, but no input is :' ' .
-~

, æ.
~` j~
2 ~ ~ 3 1~ Q
~cepted from the user (Block 33240). The procedure then returns with an error status (Block 33325).

COMPIhE: CC PROC~DURE

Moving now to Figures 57a-d, which depict the preferred embodiment of the CC procedure, the compile procedure initiates a compile process for each procedure in the application. It examines each procedure in the STDE table and calls the appropriate compiler for the procedure. In the current implementation only C and COBOL compilers are supported, however, any language may be used which can produce linkable object code.

The CC procedure begins by initializing E to point to the b~ginning of the STDE table (Block 33380). Decision block 33420 cheaks to see if E points past the end of STDE
table. If it does, the program jumps to Block 33600 and sets the message field, GTDMSG to "PROCEDURE COMPILE
COMPLETE'I at which time the program exits the CC procedure (Block 33610). If E does not point past the end of STDE
table, the STDE entry is checked to see if it is a procedure entry, STDETYP = C (Block 33425). If the STDE table entry is no~ a procedure, execution continues at Block 33520. If the STDE table entry is a procedure, the procedure language is checked to see if the proceduxe is written in the C
language, STDECTYP a C~ (Block 33426). If the procedure language of the STDE entry is not the C language then the program jumps to Block 335200 If the procedure language of the~ STDE entry :ls the C language, Block 33430 calls the compile C procedure: CC0 ~Figure 58, Block 33690~.
:
Decision Blo~k 33435 determines if the compile is successful. If the compile is successful, the program jumps to Bloc~ 33520. If not, GET error message filed, GTDMSGF is -~3 ~

' !t to "PROCEDURE COMPILE FAILED" (Block 33440) and the 2 program returns from the CC0 procedure with an error (Block 33450)-Decision Block 33520 determines if the STDE procedure entry is a COBOL procedure, STDECTYP = COBOL (Block 33520).
If the procedure language is COBOL, at Block 33530 the program calls compile C procedure, CCOB0 ~Figure 59, Block 36270). If not, the program jumps to Block 33580. Decision Block 33535 determines if the compile is successful. If the compile is successful, the program jumps to Block 33580. If the compile is not successful, error message field, GTDMSG
is set to "PROCEDURE COMPILæ FAILS" (Block 33540) and the program returns from the CCOB0 procedure with an error (Block 33550).

Block 33580 increments E to the next STDE table entry and returns to Block 33420 to examine the next STDE table entry.

CO~PI~E C PROGRAM: CC0 PROCED~RE

Looking now at Figures 58a-j, which ~epict the preferred embodiment of the CC0 procedure, this procedure invokes the compiler (or compilers~ necessary to build an output object for the C procedure. It first determines if a compile is nacessary for the current procedure. It is necessary i~ the compile is an unconditional compile, or if it is a conditional compile and the transaction view source or procedure source modi~?y date/time is larger than the object module date tim?P. If the compile is necessary, then the compile proceeds as ~ollows. First a DBMS compile is performed, if the procedure is flagged as a DBMS procedure in the STDE table. Then the compile is performed, followed by any required cleanup to get rid of temporary files.

~ TI-13766 254 : .:
" .

202~3 r The CC0 procedurP starts execution by rewinding the GTD
output file (Block 33780), and building the fully qualified C source module file name (Block 33820~. It then obtains the file statistics on the procedure source file (Block 33890) and saves the modi~ied date/time in mtime (Block 33900).

The Decision Block 33910 determines if the transaction view modify date/time, stored in tvwtime, i5 greater than the procedure date time stored in mtime (Block 33910). If this is true, the transaction view modify data/time is saved in mtime (Block 33910).

If the transaction view modi~y date/time stored in tvwtim~ is not greater than the procedure dat /time stored in mtime, then execution continues with Block 33930. In Block 33930, a C object module pathname for the output object is built, and file C object module statistics on procedure object module are obtained (Block 34040).

Decision Block 34045 determines if the statistics were obtained success~ully, and if they were, the modify date/time in otime is saved. If they were not obtained successfully, otime is initialized to zeros. Decision Block 34090 determines: i~ source modify time is greater than ob~ect:modify time. If true, the procedure jumps to Block 34110. ~Decision Block 34095 determines if gtdcflag equals 'C', i~dicating ~ conditional compile. If this is true, the procedure return~ with no errors.

Decision ~lock 34110 checks to see if the procedure is a DBNS type procedure (STDECDB2 = Y). If it is not, the program:jumps to Block 35170 to compile the C procedure. If the:procedure is a DBMS type, the program sets up the data sets~required for the DBMS pre-compiler and then invokes the : : ~

:: ~ ,.

~ . a ~ ~ 2 ~ ~ r7 ~
~MS pre-compiler. Block 34140 copies the C source file to a temporary file for precompiling, and builds the C DBMS
pre-compiler parameters (Block 35170). It then calls the C
DBMS pre-compiler (Block 35030).

Decision Block 35060 determines if the pre-compile was successful. If the pre-compile was successful; the program jumps to Block 34110. Otherwise, the user is shown the pre compiler GTD output file containing the error messages from the pre-compiler (Block 35070) and the error message ~ield, gtdmsg, is set up to contain the name of the failed procedure, STDENAME, together with the "PRECOMPILE FAILED"
message (Block 35080). The error messages are displayed, but no input is accepted from th~ user (Block 35090). The procedure then returns with an error (Block 35100).

In Block 35170, the program builds C compiler parameters for the compile procedure, saves the current directory pathname (Block 35600), changes to directory gtdslib (Block 35610), calls the C compiler (Block 35620) and after the C
compiler has completed, changes back to the original directory (Block 35630).

Decision Block 35670 checks to see if the C compile was successful. If it was, the program jumps to Block 35740.
If the C compile was not successful the GTD output jumps to Block 35740. If the C compile was not successful the GTD
output file containing the compiler error messages is shown to the user (Block 35680) and the error message gtdmsg field ~et up to contain the name of the failed procedure, STDENAME, together with the "COMPILE FAILED" message (Block 35690). The error message~ are ~isplayed, but no lnput is accepte~ from the user (Blocik 35700). The procedure returns with an error (Block 35710).
.
Decision Block 35740 checks to see if the procedure is a ''.'' ,r/ ~
~MS type procedure. If it is not, the program jumps to Block 36600. If the procedure i5 a DBMS type procedure, the program moves the compiler output object file named with a temporary name to the correct name (Block 35780), removes the DBMS temporary files (Block 36240) and sets up the message field, gtdmsg, to contain the name of the compiled procedure, STDENAME, together with the COMPILE COMPLETE"
message (Block 36600). The status messages are displayed, but no input is accepted from the user (Block 36610), and the program exits the CC0 procedure (Block 36630).

CO~PI~ CO~O~ P~O~RA~: CCOB0 PROC~DURE

Moving now to Figures 59a-c, which depict the preferred embodiment of the CCOB0 procedure aspect of the present inventions, this procedure invokes the compiler (or compilers) necessary to build an output object far the C
procedure. It first determines if a compile is necessary for the current procedure. It is necessary if the compile is an unconditional compile, or i~ it is a conditional compile and the transaction view source or procedure source modify date/time is larger than the object module date time.
If the compile is necessary, then the compile proceeds as follows. First a DBMS compile is performed, if the procedure is flagged as a DB~S procedure in the STDE table.
Then the compile is performed, followed by any required cleanup to get rid of temporary files.

~ The compil~ ~OBOL program procedure begins (Block 36810) by rewinding~the GTD output file to the beginning. Block 36850 builds a fully qualified file pathname of the COBOL
source module. Block 36920 gets the file statistics on the procedure source. Block 36930 saves modified date/time in field~m~ime. Block ~9640 determines if the transaction view modified date/time is greater than the procedure date/time.

: ~t is, the program saves the transaction view modified date/time in mtime. Blo~k 36960 then builds the fully qualified pathname of the COBOL object module.

Block 37070 gets the file st~tistics on the procedure object modulie. Decision Block 37075 determines if the file statistics were ob~ained successfully. If they were, the program saves the modified date/time in otime and jumps to Block 37120. If the statistics were not obtained successfully, the program initializes otime to zeros and continues execution with Block 37120.

Block 371~0 determines if t~e source file modify date/time is yreater than the object file modify date/time.
If the source file modify date/time ,is not greater than the -object modify date/time, then the program returns from the CCOB0 procedureO If the source file modify date/time is greater than the object modify date/time, then execution continues with Block 37150.

Decision Block 37150 determines if the procedure is a DBMS type procedure. If it is not, the program jumps to Block 38650. If the procedure is a ~BMS type procedure, Block 37190 determines if the environment configuration information indicat~s that a machine-dependent DBMS
translation is re~uired. If so, the program translates COBOL standard DBMS source to machine dependent DBMS source placing it into a temporary file, and execution continues with Block 38150. If not, the program copies the COBOL
; souxce file to a temporary file for a standard DBMS
pre-compile.

Block 38150 builds the COBOL DBMS pre-compile paramet rs, and Block 38630 calls the COBOL DBMS
pr~-compiler. Decision Block 38650 determines if the pre-complle was successful. If it is, the program jumps to :, :
-:

".,'',''".''' " '. "'~ ''"'' ,' .' ' '' ' ' , / '' ' '' '" ' '' '' ' ', ,'''' '' ,' '','' ' "" ' ' ' ' ' ' ,'" ' ' ' ~' '':' , oe?~ ~

Lock 38730. If not, the pre-compile error output in the 2 0~ ~ 7 GTD output file (Block 38660) is displayed, the error message filed, GTDMSG, is set up to contain the name of the failed procedure, STDENA~E, together with the "PRECOMPILE
FAILED" messaqe (Block 38670) and the error messages are displayed, but no input is accepted from the user (Block 38680). The procedure returns with an error (Block 38690).

If the pre-compile is successful, the program (Block 38730~ builds the compiler parameters for the compile, (Block, 39320) saves the current directory, (Block 39330) changes to directory gtdslib, (Block 39340) calls the COBOL
compiler, and (Block 39350~ changes back to the original directory.

Decision Block 39450 determines if the compile was successful. If so, it jumps to Block 3g530. If not, the program shows the compiler error output in GTD output file (Block 39460), sets the error message field to contain the name o~ thei failed procedure, STDEN~ME, together with the "COMPILEi FAI~ED" message (Block 39470). The error messages are displayed, but no input is accepted from the user (Block 39480), and (Block 39490) returns from the procedure with an error.

If the compile is successful, the program determines ~Block 39530) if the procedure is a DB~iS type procedure. If not, the program jumps to Block 39930. If the procedure is a DBMS type procedure, the program removes the DBMS
temporary ~iles.
, Block 39930 removQs other temporary files. Block 40030 sets the status messags field to contain the name of the compiled procedure, STDENAME< together with the "COMPILE
COMPL~TE" message (Block 40030). The status messages are displayed, but no input is accepted from the user (~lock r~ ~ ~
7 ~
0040). The program exits the CCOB0 procedure (Block 40050) BIND T~AN~AC~ON, BT PROCEDURE

The final step in preparation of a GTD transaction is the BIND process for the TDT member. This process extracts all GTD system-provided runtime members necessary to execute the transaction along with each of the designer-specified procedures, panels and views creating the appropriate load module.

Consid~r now Figures 60a-b, which depict the preferred embodiment of the BT procedure aspect according to the present invention. The bind transaction procedure builds the application load module and installs it in an executable -directory or library. It may also perform a data base bind if required by the DBMS used. In the implementation documented here this was not necessary; however, on the mainframe a DBMS bind must be performed before the load module can access the DBMS successfully. The load module is built with a linkage editor. This utility resolves all unresolved references made to DAA, application, or system libraries. Library references can either be dynamically loaded at execution time or linked in with the load module.
It is preferred to have library modules dynamically loaded at execution time.

The~BT proc~dure begins by rewinding the GTD output file (Block 4Q260), sets up the link editor parameter values and application input file with lin~ editsr files to ~e included in~the link editor procedure (Block 40580) identifies the DBMS procedure typesj if any, and procedure language types (Block 41790~, se~s up names of language, DBMS (if any), DAA
system, operating system libraries and object files to be , ~ 3 ncluded in the link (Block 42060).

The appropriate linkage editor to use is determined tBlock 42790).

The parameter list is built from the setup values (Block 42840).

The link ~ditor is called with the g~nerated parameter list and the link editor return code is saved (Block 43020).

The linkage editor output module is opened for read only (Block 43070) and the module size is initialized (Block 4308~).

Decision Block 43090 checks to see if opening the linkage editor output module was successful. If the open was not successful, the program jumps to Block 43160. If the open is successful, the module size is determined (Block 431003 and the linkage editor output module is closed (Block 43110).

Decision Block 43160 checks to see if the linkage editor return code is good. If not, the program proceeds to Block 43170. If the return code is good, the linkage editor output module is checXed to see if its size is greater than zero (81Ock 43165~. If the module is greater than zero, the program ~jumps to Block 43460. I~ not, the output file containin~ the linka~e editor error messages is displayed (Block 43170), the error message field, GTDMSG is set to "BIND FAILED" (Block 43180), and the program returns with an error (Block 43190).
~ :
The program rewinds the GTD output file (Block 43460) and calls the task termination utility to stop the currently :
executing application module (Block 43500). This is due to : ~ TI-13766 261 :
: : :

~ 3~

~ operating system restriction on UNIX which prevents a currently executing load module from being overwritten by a new copy. This does not apply to the mainframe implementation. A way to get around the problem is to kill the task and then replace the load module.

If the stop is successful, the program advances to Block 43650, removes the original load module (Block 43650), renames the temporary file to the original name (Block 436080), sets the error message field, GTDMSG to "BIND
COMPLETE" (Block 43760), and the program exits the BT
pro~edure (Block 43770).

I~ the stop is not successful, the program shows the user the output file containing the linkage editor error -messages (Block 43170) sets the error message field, GTDMSG, to "STOP TRAN FAILED~ (Block 43550) and returns from the BT
prvcedure with an error (Block 43560).

',,.
,"
::
':
.

: ~ -~: TI-13766 262 "
.'`~

FIL~ TRaN~FE~ pANELsfpRoc~D~REs/vIEwR/DocuME~ATIo~

The last area of the GTD involve the File Transfer Panels, Procedure, Views, Documentation Procedure which providas the interfaces neccessary to file transfer all or part o~ the application source from one DAA machine to another.

The file transfer file is built by passing a list of all data sets for transfer to an archive utility, which is supported on both platforms, to archive the application files into one large file. This archive file is then shipped to the destination system using standard data transfer channels between ~he 2 systems. This data transfer should have a capability to bit an unarchive utility, once the file is shipped, to unarchive the file into its componen~ files into appropria~e corresponding file locations on the destination machine.

The ~ile transfer menu option needs only to present panels to the user permitting the selection of required componen~s for transfer to the destination environment. It may then modify a copy of the TDF to comply with the target machine naming conventions. Other application source components are independent of the naming conventions on the different platforms due to the capabilities provided by the IET.

Specifically, the GTD file transfer procedure begins at Block 115640 by building a parameter list for the file trans~er user interface utility including USERID, MAPLIB, --and TDTNAME (Block 115750). The output file is rewound to the~beginning to capture any utility output messages (block 116260) and the ~ile transfer user interface utility is invoked (Blo~k 116300). Decision Block 116410 checks to sae ' R9: .
~ ~ ~3 if the file transfer was successful. If it was, the program exits tje F~ procedure. If not, the procedure shows the messages in the output file (Block 116450), sets the error message field, GTDMSG equal to "FT FAILED" ~Block 116455), and exits the FT procedure with an error.

`: .
:.

TI-13766 264 ~
~: .
:: :

2~3~7~
TR~N8ACTION DEFINITION TA8L13 .
The Transaction Definition Table, or TDT, as used throughout this description, consists of various tablecii of information stacked together so that the IET can easily access the appropriate information a~ run-time for the transaction procedures. A~ seen in Figure 4, the TDT
consists of the following table types, described in further detail below: TDT overhead 36, list of panel map entries (TPE) 44, list of procedure entries (TCE) 46, list of menu entries (T~E) 48, list of language entries (TLE) 50 defining the various languages (i.e. English, French, German, etc.) in which the documentation is available, and list of SQL
data base processing proc~dures (DBSYNC) 52.

Where pointers are used, if the number of entries is zero or this particular type of entry is not used by this specific transaction, the pointer value may be NULL.

Each table type is described below by listing the name of the entry type and a brief description of its purpose.

~DT OVER~EAD~ Th~ TDT overhead 36 contains all o~ the global information about the transaction and pointers to the various tables~ It consists of the following fields-TDTID is the four character application identification.
TDTRELN is the four character rele~se number.
~TDTGTIME is the time that this TDT was generated.
TDTGDATE is the date that this TDT was generated.
TDTDREP is the eight character documentation reportname.
TDTDGEN is the eight character documentation generation name.
TDTAMENU is the pointer to the menu entry in the TPE
table.
~ ;~ TDTAHELP is the pointer to the help entry in the TPE
:~ :
~ TI-13766 265 ' .:

OE~ ~
~ ~ 2 ~ 3 ..... .. .
tableO
TDTAINFO is the pointer to the info entry in the TPE
table.
TDTAGLOS is the pointer to the glossary entry in the TPE table.
TDTNTP~ is the number of entries in the TPE table.
TDTATPE is the pointer to the f irst entry in the TPE
table.
TDTNTCE is the number of entries in the TCE table.
TDTATCE is the pointer to the ~irst entry in the TCE
table O -TDTAPPL is the ~our character application name.
TDTNTL~ is the number of entries in the TLE table.
TDTATLE is the point~r to the f lrst entry in the TLE
table.

~!RAN8ACTIO~T PANEI. EN~rnI~ TPE~. The TPE list 44 is an array of TPEs each describing a single transaction panel, the combination of which includes all panels required for the proces~ing of a procedure and cont:aining the following fields: .

TPENAME is the eight character panel name.
TPEAMAiP is the pointer to the panel map data for this panel. This is generated by the map compiler, , ex~ernal to the TDT.
TPEAITCE is the pointer to the input TCE for this panel.
TPEAOTCE is the pointer to the output TCE for this -:
panel .
TPERSVDl is a twelve character reserved f ield .
OPCHTA is the pointer to the help table.
TPENTME is the number of TMEs ~or this panel if it is a menu paneI.
TPEATME is the pointer to the f irst entry in the TME
table for this panel if it is a menu panel.
:

" ", ~ , ",, " ,; / ,; ~ "~ ,;, ," ~ ","; , "~ "~

2 ~

TPERSVD2 is a twenty character reserved fi~ld.

TRhNSACTION PROCEDURE E~IEB (TCE~. The TCE list 46 contains pointers to various VIEWs which are described by the View Map Object Header (VMOH) and View Map Ob3ect Field (VMOF~ structures which define views and are described later. The TCE list is an array of ~CEs each describing a single applica~ion-supplied procedure, the combination of which includes all procedures required for the processing of an application transaction. The TCE contains the ~ollowing fields:

TCENAME is the eight character procedure name.
TCEAPRGC is the pointer to the entry point of the application supplied procedure.
TCEAIVW is the pointer to the input view VMOH.
TCEAOVW is the pointer to the output view VMiOH.
TCEAPVW is the pointer to the profile view VMOH.
TCEDBTYP is a character describing the data base type.
(SQL - 1).
TCERSVD is a seven character reserved field.

~RAN~ACTIO~ ~EN~ ~N~IE~ ~ME). The TME list 48 is an array of TMEs each describing a single menu entry. Each TME
points to a TPE or a TCE, or both, and contains the following fields:

TMESEL is the eight character selection code for this entry.
TM~ATP~ is the pointer to the TPE to be used ~or this selection code.
TMEATCE is the pointer to the TCE to be used for this selection code.
TMEDESC is the thirty-two character description of this entry.

2 ~

TR~N8ACTION L~NG~AG~ ENTRIE~ ~Thæ)~ The TLE list 50 is an array of TLEs each describing a languag~ (i.e. English, French, German, etc.) in which the documentation is available, and containing the following ~ields:

TTENi~M~ is the eight character language name.
TLEDREP is the eight character documentation report name.
TLEDGEN is the eight character documentation generation name.
TLERSVD is a twenty-four character reserved field.

8Q~ DAT~ ~ 5 PROCE. 8ING PROC~D~ DB~7C~. The DBSYNC
table 52 contains the pointers to the various entry points for the data base proc~dures defined by the data base protocol and needed by IET during th~ execution o~ a transaction. ~t consists of ~he following fields:

CONNECT is the procedure pointer to the Pntry point of the data base connect procedure.

COMMIT is the procedure pointer t~ the entry point of the dat~ base commit procedure.

RELEASE is the procedure pointer to entry point of the the data base release procedure.

~I~W Na~ O~J~C~ X~AD~R ~YMO~). The Views discussed earlier are ~described by a View Nap Object Header (VMOH) 54 and a list of View Map Object Fields ~MOF) 56. The description of the VMOF 56 ~ollows the VMOH description given directly below. The VMOH 54 contains the static in~ormation about a view and a pointer to the array of VMOFs. It consists o~
the rollowing fields:
::: : :
~VMOHAPPL is the ~our character application name.

2 ~ 2 ~

VMO~VIEW is the eight character view name.
VMOHVTME is the view compile time.
VMOHVDT2 is the view compile date.
VMOHVER is the four character version.
VMOHFMT is the one character view format.
VMOHRSVO is a one character reserved field.
VMOHNE is the number of VMOF entries.
VMOH~E is the pointer to this view's VMOF array.

YI~ ~AP O~CT FI~LD ~NOF) AR~A~. The VMOF array 56 contains the displacement, length and type of each field in the view. Each VMOF entry consists of the following information:

~ OF~lED is the displacement of this data element in the transaction view work area.

VMOF~lEL is ~he lenyth of this data elemen~.

VMOFRlEN is the number of occurrences for this data element.

VMOFRlET is the one character data element type. This type includes, but is not restricted to the following types:
binary,~ character: signed character: un~iigned character;
small: short; long: hyper; unsigned small; unsigned short;
unsigned long: unsiigned hyper: single: and double.
:
VMOFRS~2 is a three character reserved field.

:

:
~ ~ TI-13766 269 ~ 8~
~ d ~ 7 ~d The last major area of the present invention is the IET, or dialog manager. The IET communicates with the user indirectly through the input and output messages. Whenever messag~s are communicated to the user the IET calls an kransaction processor interface function which communicates with the transaction processor. The transaction processor is then responsible ~or the presentation of output messages to the user and accepting input messages from the user. In this way a dialog may be maintained between the user and the application program through the IET and the transaction proce~sorO

Communication between the application program and the IET is performed through the transaction view. The data fields within the transaction view ~re initialized by the IET when it receives an input message. When the input data contains formatted text, the IET interprets the formatted text by using the header information in the input message to locate the appropriate map and then calls the map interpreter to extract the input field information from the input message and place in the transaction view. The data fields are also initialized by the! application procedure before relinquishing control to the IET. The data fields are then placed in the formatted output data when the IET
calls the map interpreter again. The formatted output is placed in the data portion of the out:put message and header information built. Communication fields within the transaction view exist to allow the applica~ion procedure to instruct the I~T as to what iaction to perform once the application has relinquished control. Two typical actions are to prssent a new panel to the user or to perform a link request to a new procedure.
~: .
The IET co~municates with the application profile. The IET maintains a separate application profile record for each unique user/application/transaction. A DBMS inter~ace -:
:
~ ~ TI-13766 270 rocedure called by IET performs all application profile input and output. Typically, the IET reads the application profile whenever a new message is received from the transaction processor and writes the application profile before sending a message to the transaction processor.

The IET provides the application with services for handling menus, help and documentation, message and screen formatting, and cooperative processing. The TDT includes the structure and names of the panels which contain the application menus. It also contains the list of application procedures and panels referenced by each menu entry. An IET
input and output procedure exists to perform processing and navigation for each level of menu supported by IET. Thus menu handling logic is completely handled by the IET without involving any application procedures. Help and documentation is supported by the IET in a similar manner.
The help and docume~tation files are listed in the TDT.
There are I~T input and output procedures for handling both help and documentation processing or navigation without involving any application procedure. The IET provides for cooperative processing through its link and return capabilities and its use of a profile view. This protocol allow data to be passed between two proce~ses and profiles for the maintenance of saved data in the two processes and application profile, allowing a dialog between the processes to obtain a coop~ratively achieved result. The IET provides th~ application control over message and screen formatting services through the control ~ields in the transaction view which indicate the current and next panel display names.
The application can control the panel displayed by changing th~se fields.
:
The services the IET provides for the application which i~clude menu handling, help and documentation handling, application profile management, cooperative processing and ~ TI-13766 271 '"' OE~3 ~

essage/screen formatting isolate the application from the platform software by allowing the IET to handle any differences in platform software and hardware related to interface differenc~s for file input/output, screen formatting and message handliny. The IET implementation for each platform provide isolation for the application program.
Further isolation is maintained through the use of common high level languages and a common embedded DBMS language interface for data base applications on all platforms. It is a result of the isolation from the hardware and software-dependent interfaces and the use of common language implementations which allow application portability across multiple execution environments.

The IET communicates with a remote application through the use of link and return protocols, data input and output view interfaces and a routing request header. The LINK is a re~uest to IET to initiate the execution of a remote application procedure. The RETURN is a request to IET to return control to the initiator vf the LINK request~ The interface view includes documentation on the initiating procedure, the remote application procedure, the user terminal devices and the systems on which they are located.
The INPUT view lists the items which are to be included as input then a LINK request is perfor~ed. The OUTPUT view lists the data items which are to be included as output on a RETURN request. All these views are included in the view object~ built by GTD ~or use by IET in the processing of LINK and ~TURN requests.

The IET performs different functions for both the LINK
and RETURN reque~ts depending on whether the application procedure is requesting LINK or RETURN ~unctions or whether the IET has just received an input message containing either a LINX or RETU~N routing request header. Whenever the IET
compli~s with an application LINK or RETURN request it f~ a ~uilds the head r as part of the output message. The header uses an i~entifying keyword at a well-known location in the data and includes the interface view as well as data obtained from the transaction view which correspGnds to the data items listed in the input (for LINK request) and output (for RETU~N request) views for the application procedure just executed. The output message is then sent to the transaction processor for handling. The transaction processor recognizes a routing request header on the output message and treats it appropriately. Whenever the IET
receives an input message containing a routing request header, the IET determines if the message has come to the correct system; if not, the message is forwarded to the appropriate system. Otherwise, the application profile is retrieved and placed in the transaction view, then the interface and input (for LINK requests) and output (for RETU~N reguests) view data is placed in the corresponding data names in the transaction view for the application procedure to be executed. The application procedure is then executed. The applications procedures involved are in control of exactly when the LINK and RETURN requests are performed.

At this point, the Information Engineering Task will be considered in greater detail. Figures 62a-bb depict a flow chart of the preferred embodiment of this aspect of the present invention. As stated earlier, the IET is the control module for ev~ry DAA transaction and is written to be enter d through a call from the transaction processing subsystem when thP DAA txansaction is executed by the user.
Such subsystems might be IMS on MVS or Tuxedo on Unix platform~.

IET must get control of a transaction via the transaction processing r,ystem, for every instance of the transaction eYecUtiOn. GTD forms an executable transaction module by '.

~ ~ ;r~ ~ ~ r~ ~
ink-editting the TDT, maps, user procedures and the IET
module together with the transaction sub-system main interface module which calls the IET.

Several key variable areas and components are referenced throughout the description of the IET logic, and are briefly described here.

Transaction Definition Table (TDT): As indicated earlier, the TDT is critical to the success of IET since the TDT provides all of the variable information, in table form, that the IET module needs to control the flow of panels and data between the user and the application procedures. The TDT also provides pointers to the menu panels, help panel, and glossary panel. Reference t~ the TDT discussion presented earlier will enable one to better understand the IET logic flow.

Transaction View ~TV): As defined earlier, a transaction view is a collection of variables that contains state information, names and pointers used throughout IET to control ~low of processing between IET and the user procedures. It consists of a set o~ well-known IET variables followed by user-specified variables. This is the only way IET and the user procedures have to communicate information back and forth. A pointer to this area is passed to a user's procedure Pvery time it is called. Example of fields contained in this view are the executing-system-name, active-panel-name, user-id and transaction-name.

IETM/IETI headers- These headers are separate collections of hlocks that precede the IET interface mesaages exchanged between systems and transactions. IET
interface messages ar used to communicate requests between systems and between transactions. They contain a header, a control block and the message or view data. The data in the ,f~
rl la ~ ader (IETM) and the control block (IETI~ provide IET with information regarding the origin and destination system environments of the message as well as the capabilities of the re?~uesting terminal. This data is used to route the message to the destination and the response back to the originator. It is also used to d~termine what conversion, if any, needs to be done on the data in the message. It should be noted that the names of the various fields are strictly of choice and should not limit the scope of the invention.

The I~TM header defines the total length of the interface message and the tra~saction requested. It consists of the following fields:

IETMLL is the length of the IETM message including this header.
IETMZZ is a reserved field and contains zero.
IETMTRAN is the eight character transaction name.
IETMBLNK is a one character field and contains blank.
IETMCONT is the eight charactler control code and contains "=XETCONT". This field is the key used by IET
to identify this as an inter~?ace message.

The IETI control block follows the IETM header and describ? 5 the originating and destination system environments. It consists of the following fields: ;

IETI~L is the length of the IETI control block.
IETIZZ is a reserved field and contains zero.
IETIAPPL is the four character application ID.
B TIVIEW is the eight character Vi2W name.
IETISYST i~ the eight character name of the system ; ow~ing the requesting terminal. This may not be the originating system fox the mes~age.
IETIRSVl is an eight character reserved field.
~ . :

.: ' -', 2~?,3 ~7 0 IETICC is the one character command code. It specifies the type of request (LINK, RETURN, FORWARD, or TERMINAL)o IETIRC is the one character return code.
IETIMC is the one character message code.
IETIHCNT is the one character hop count. This field is used to prevent looping in the network during routing.
IETIUSER is the eight character user ID.
IETITERM is the eight character terminal name.
IETIONO is a four character reserved field.
IETIAPLO is the our character originating application identification.
IETISYSO is the eight character originating system name.
IETITRNO is the eight character~originating transaction name.
IETIPRCO is the eight character originating procedure na~e.
IETIFMT is the one character IETI format (Normal = 1).
IETIRSV2 is a three character res~erved field.
IETIAPLl is the four character Destination Application Identification.
IETISYS1 isi the eight character destination system name.
IETITRNl is the eight character destination transaction name.
IETIPRrl is the eight character destination procedure name.
IETIMTCH is a one character, character type (E8CDIC =
O, ASCII = 1). It is used by IET at the destination to determine what character code conversion may be needed on the message data.
IETIMTIN is the one character integer type (Normal = o, ~yte-swapped = 1).
I~TIRSV4 is a six character reserved field.
IETITRMD is the sixteen character te~minal definition ' ~b ~

in~ormation. This defines the capa~ilities of the terminal.
IETIRSV5 is an eight character r~served field.

IBM 3270 daka streams are referenced in the following description because it reflects the preferred embodiment of the present invention. Nevertheless, such reference should not in any way limit the scope of the invention.

Consider first ~igure 62a, which depicts the b~ginning of the IET flowchart. As a result of the transaction subsystem main module having called the IET, IET logic at Block 10 does first time initialization of global accessible variables and key fields in the transaction view. Some of these variables and key fields include: a TDT pointer, iopcb and altpcb (both of which are passed to the IET by the transaction sub--system main module), as well as pointers to a screen build area, message buffer, view buffers, and documentation screen buffer. At Blork 20, the IET obtains the local system name from the system~

The main loop of IET begins at Block 30, wherein new messages are fe~ched from the transaction sub-system for the given transaction identification. This block starts by closing the do~umentation interface, if it was left open due to, for example, a previous pass through the main logic.

Block 40 initializes the transaction view. This ~consists of clearing the TV by zeroing the pointers and setting the character fields to blank, loading the system name, date and time from the operating system, and getting the TDT identificotion, application identification, and release number from the TDT.
:
At this point~ Block 50 is executed to get the next input fro~ the transaction subsystem. Decision block (60) ' ,. .

hen determines if any new data is available to the DAA ~ 3 ~ ~ ~ 7 system: STATUS = NO DATA?. If there is not a new da~a stream available, the IET interface jumps to block 1660 of Figure 62bb, discussed later, tu exit the IET interface.

If the logic of Block 60 has determined there is a new data stream available, Block 9o is executed. The user identification and terminal identification are retrieved from the sub-system iopcb and stored into the TV. Block 100 saves the terminal attributes, such as color capability, highlighting, reverse video, etc., and stores them in the TV .

Continuing to Figure 62b, Block 110 gets the transaction identification from the data stream and translates it to native code (ASCII or EBCDIC). Block 120 saves the transaction identification and stores it in the TV.

Next, Decision Block 130 checks the input data stream to see if the data i~ formatted, i.e. directly from a 3270 formatted screen. The check is made by looking for a 3270 SBA in the first byte of the 3270 data stream and, if found, the stream is declared formatted. This implies the data stream came from a 3270 type terminal with a formatted panel displayed.

"Unformatted" implies input from a cleared (unformatted 3270 screen~ or at least the first part of the input has no 3270 data stream. The latter case may occur, where formatted data is found later in the message following a special header. If the data stream is formatted then IET
will jump to block 780 of Figure 621, discussed later, where the formatted screen is processed.

The logic o~ Decision Block 140 at this point begins the proc~ssing of the "unfo~matted" data stream. This block 2 ~
hecks to see if the data was built by IET in another DAA
transaction, and inserted into this transaction, by looking for a literal " =IETCONT" ~ollowing the clear text train code in the input message. If the data stream is from a DAA
transaction, then it will have an IET header consisting of IETM and IETI, described earlier. If the test yields a negative decision, the IET interface moves to decision block 470 of Figure 62g, discussed later, where processing begirls for a true unformatted message from a 3270 terminal.

If, however, the test yields a positive decision, the IET moves to Decision Block 150, where it checks if the sending IET's character set is different from the the receiving IET's character set (e.g., ASCII versus EBCDIC).
by comparing the character type field of the IETI header with the receiver's type. If the IET header is from an EBCDIC system, and the local IET is ASCII, the IET interface converts all IE~I character fields to ASCII (Block 160).

When a message has IET headers, there should be three separate 2 byte binary length fields, one in IETM, one in IETI and one preceding the messages data following the IETI
header. Since the lengths are built by the sending IET
process, they will be in the native machine format of that IET's hardware. Some hardware stores the high-order byte ~irst followed by the low order byte (e.g., IBM 370) while other hardware stores there short values byte-swapped with the low oxder byte first followed by the high-order byte ~eOg., Intel)O Therefore at Block 170, the IET compares the local, or receiving, IET's binary length storage type to that of the sending IET's hardware type. Continuing to Figure 62c, if the types are compatible then IET jumps to Block 190. Otherwise the bytes are swapped in the three different length fields at Block 180. The IET then continues to Block 90 where it saves the user identification, terminal sy~tem, terminal identification, and t~rminal attributes f~
~ J3 rom the IETI header and stores them into the TV.

The loyic at D~cision Block 220 checks the IETI command code field for a LINK request code. A LINK request indicates that the requesting I~T has attached an input view block (following the IETI header) to be processed by this system and this transaction~ If this is not a LINX request then control is passed to block 310 of Figure 62e, discussed later.

If there is a LINR request code, the view stack is cleared (Block 230)o The view stack is kept on disk (hexetofore re~erred to as ROLLFILE3, indexed by user identification and application identification. Throughout IET operation this stack is used t~ save and restore view variables at different points in the transaction execution.
In addition, when a view is stored, the panel name and transaction name are also stored with the request. When a link request is rec~ived, the IET at Block 230 clears all previous views for the cuxrent user identification and application identification. The IET at Block 240 then puts the current I~TI header onto the top of the stack for the user and application identifications.

At Block 2~0, thP IET moves the name of the requested link-to-procedure from the IETI h~ader to the TV in preparation ~or execution of the procedure for the given input view that follows the IETI header. Continuing to Figure 62d, once the procedure name is identified, at Block 260, the IET scans the procedure table entries (TCE, discussed earlier) for the named procedure and saves a pointer to the TCE with a matching name.

~ Proceeding to Block 270, the IET uses the TCE block to locate the profile view list, TCEPVW~ This list is used to ex~ract tha profile view data fields from the TV and move : .

f~ ~

l~em to a separate view work area. Once the view work area is built, the IET has a contiguous list of fields which represents the profile view prior to processing the LINK
request input view. Block 280 then saves this profile view by putting it on to the stack for the specified user and application id.

Block 290 then uses the above input view list (VMO~/VMOF) and moves each field in the input view into the TV. As they are moved character fields are translated, if necessary, from EBCDIC to ASCII or visa-versa. Also byte swapping is done if the machine storag~ types are different (see Block 170 for discussion). As documented in the TDT, the VMOF entry for a given field contains the appropriate info~mation to do the mapping, includ~ing the offset into the TV, the length of the field, and the ~ormat of the field (character, etc.). After the TV is populated, the IET
interface continues to Block 1200 of Figure 62s, discussed later, to start the input procedure specified by the TCE
(Block 260 above~

If, a LINK request has not been indicated (Block 220), control is passed to Block 310. At this point, the IET
checks the IETI command code for a RETURN command. If it is n~t a RETURN control is passed to Block 400 of Figure 62f, discussed later. If it is a RETURN request, Block 320 is ex~cuted to extract the returned-to-procedure name from the IETI.

Block 330 operates similar to Block 260 and locates the TCE pointer for the returned-to-procedure.

At Block 340, the IET restores the profile view fields by popping the last pushed view off the stack for the user and applic~tion identi~ication. Included in the restore process is the output panel name saved when the LINK was done. Then , ~ 7 ~
le IET uses the TCE field, TCEPVW, as a pointer to the profile view list structure, VMOH, and its list of VMOF
entries (one per field in the view), to restore all the fields ~rom the profile view to the TV (Block 350).

The TCE is then used to locate the output view list, TCEOVW (31Ock 370). From this list of fields the TV is populated with the data from the view data that followed the IETI header. Block 370 employs similar logic to that of Block 350, except the output view list is used instead of the profile view list.

At this point, the IET at Block 380 sets the output panel name into the TV using the the panel name that was restored from the profile data base in block 340. Control is then passed to block 1200 of Figure 62s, discussed later, to start the output procedure specified by the TCE (Block 330 above).

Looking now at Figure 62f, Block 400 checks the IETI
command code for a FORWARD command. If there is no FORWARD
command, then control is passed to Block 430.

The FORWARD request is used by a DAA transaction on one sy~tem to pass input data, usually input terminal data, to another system o be executed by the same or different transaction on the destination system. For example, a terminal on one system can use the DA transaction to route a transaction request to a remote system for execution. This can be done by entering "DA sysid tran tran-input" from a cl ared screen. Where "sysid" is the name of the remote system, "tran" is the name of the transaction to be executed, and " tran-input" is optional transaction data.
The DA transaction would make use of this FORWARD request to build the IETM/IETI/message buffer to be executed on system sysid.

Tl-13766 282 -!'~-2 ~ 2 '~
If Block 400 has found a FORWARD command, at Block 410 the IET copies the message buffer following the IETI header to a work area and then branches back to Block 120 of Figure 62b, fox processing as if the message buffer was originated on the local system. It is possible in the preferred embodiment of the present invention for this message block to be examined and forwarded yet again to another system for execution. However, generally the FORWARD request is executed after one pass.

Block 430 checks the IETI command code for a TERMINAL
command. If it is not a TERMINAL command then control is passed to Block 110 to get the next transaction input.
Otherwise, the message from the data stream following the I~TI header i5 sent to the local terminal specified in the IETI header. Control is then passed back to Block 40 to process the next input for this transaction.

At Block 470, the IET checks the local machine character set for type of ASCII If it is not an ASCII machine, the IET
interface skips the next step and moves to Block 510. If it is an ASCII machine, the IET interface converts the data stream to ASCII code (500), and then moves to Block 510. ;

Next, the IET at Decision ~locX 510 checks if ~he da~a stream contains non-blank data passed the transaction code.
Non-blank data passed the transaction code means that a menu option may be present, or option data may await processing by the "UNFORMATTED" panel input procedure. If there is no data passed the transaction code then control is passed to Block 550.

Block 520 is executed when extra data exists. The first no~-blank character following the tran code is compared with a "/" or "-" indicating whether the user wants ko invoke a ..

- ' .
:, '' ~ ~ a pecifi~d command that follows that character. If neither '~/" or "=" are found, then control is passed to Block 550.

If "/" or "=" is found, Decision Block 530 further compares the command string following the character to a "RESET"~ If the string equals "RESET", control is passed to Block 1560, of Figure 62y, discussed later, where the transaction state is reset and the top level menu is displayed. If the string does not e~ual "RESET", Block 540 checks if the string equals "QUIT". Skipping to Figure 62x for a moment, control is then passed to Block 1530 if the string does equal "QUIT". Here the IET begins processing the QUIT request for the specified user and application identifications by deleting the application identification from the profile data base. Block 1540 then queues the message "DA =l" to the local system for execution. This invokes the Display Active transaction. Control is then passed to Block 30 where the next transaction message is received and processed.

Returning to Figure 62h, the logic at Block 550 begins the processing of transactions using only the tran code, which haæ been invoked from a cl~ar screen. This is one way a u~er may restart a transaction at the last known state and panel. The process is begun by blanking the panel name in the TV.

Desision Block 567 checks the current user identification for blanks. If the user identification has blank~, there is no user id, and the IET bypasses restoring the profile and passes control to Block 620. If the user identifica~ion has not blanks, the logic at Block 570 restores the profile view from the stack, including the -output panel name, for the given user identification and application identification.

' r~

At this point, Decision Block 580 checks if the last profile was a IETI control block by comparing the first part of the restored view to the literal "IETCONT ". If the result is negative, then sontrol is passed to Block 615 where the 'rv is populated from the restored profile view.

Block 590 is entered when an IET control block was restored (i.e., the result of Block 580 comparison is positive). A ~est is made to determine if the IET request was last passed to a diff~Prent transaction code than this code and passed to a different system identification than the current system. If the result of the test is positive, then control is passed to block 615 where the TV is populated from the just restored view.

Block 600 is executed when the result of the test in 590 is negative. The IET employs a process called TRACE FORWARD
whereby the IET can resen,d a message to the destination transaction and system id ~'ound in the restored IETI. This block builds a new message block which consist of the IETM, IETI, and a message buffer equal to the IE'I'I tran code. The IETI re~uest code is set to FORWAR~. This message block, when transmitted, is designed to restart the transaction on the destination ~ystem at the last rec~ested state from this tranjsystem. After the buffer is constructed, control is passed to, Block 142"t, of Figure 62v, discussed later, where the message is sent to the designated tran/system.

Block 6}5 populates the transaction view variables from the profile view restored in Block 570, much as the process described ~or Blocik 350 of Figure 62e. The input panel name is se~ to l'UNFORMAT" (Block 620).

Moving on to Figure 62j, Block 630 locates the TPE entry for the specified panel name. The TPE contains all the information to build and display a panel. Locating a panel .

~ G~
7 ~
s simply a matter of scanning each TPE entry until the desired panel name is found equal to the name in the TPE.
The first TPE is anchored in the TDT at field TDTATPE.

Next, the IET at Decision Block 640 checks to see if the data in the message buffer following the tran code was preceded with an ~ . If it was not, then control is passed to block 680. If, on the other hand, the tran code was preceded with an "=", Block 650 handles the menu restart request from the user. For example, XYZ =2 indicated transaction XYZ menu option 2 should be executed. The top level menu panel entry, TPE is located from the TDT using variable TDTAM~NU. From this TPE the menu input procedure entry, TCE, is located by using the TPEAITCE field in the TPE.

After Block 650 executes, Block 652 pops each of th views for thiC user identification and application identification until it locates the first view on the stack, which is the top menu view. If the top view is found, i.e.
the top menu profile view, the TV i5 restored from the view and the view stack is cleared. If thle the top vi~w is not found then nothing is restoxed in the TV, and the stack is left empty. Block 660 moves the command code ~ollowing the "=" to the command field in the TV. Control is then passed to Block 1200 of Figure 62s, discussed later, where the input procedure is ex~cuted for the menu panel.

Returning to a trans code not preceded by an "=", Block 680 checks for a blank output panel name and an input panel name of "UNFO~MA~". If both are found, the input message buffer is copied to the output area (Block 690) and control i~ passed to Block 960 where the input procedure for the input panel of UNFORMAT is called.
.
If either are not found, Block 710 starts the l~gic that r~.. . ~
~2~7~
epares to restart a transaction from a given panel. First the command code is blanked, then block 720 moves the output panel name to the TV. Block 730 then finds the TPE entry for the speci~ied panel name.

In Figure 62k, Block 740 checks the TPE for an output procedure entry pointer in the field TPEAOTCE. If the pointer exists, it points to a TCE entry of the procedure to be called prior to outputting the panel. Block 750 then sets the TCE address and passes control to Block 1200 of Figure 62s, where the specified procedure is executed. If an output procedure does not exist, then control is passed to Block 1610 of Figure 62z, discussed later, where the panel display is built and output to the terminal.

Block 780 begins the logic for messages that are formatted with 3270 data streams. (I.e. the message was determined to have a 3270 SBA at the beginning; see Block 130). At this point the IET expects to have a 3270 input stream that was received from a 3270 terminal that had a DAA
transaction panel displayed. An integral part of IET's processing of input from a terminal is the design of the screen. This is enforced to some degree by GTD when the panels are created. The rule is that the first thre~ fields on a DAA screen that are returned by the 3270 terminal must be the tran code, the panel name and the system id. This is facilitated in 3270 data streams by having these three fields as input/output fields with a modified data tag set.
This causes the 3270 to always return them when any transmit key is pressed. When these three fields are returned, the IET can continue processing where the transaction was last exited, invoking the next procedure specified to process the input.

Therefore, Decision Block 780 checks to see if the panel name is present in the data stream by looking for a second ,~ f--~ ~ ,r~

.
70 SBA and extracting the characters returned as the panel name. If the data stream is too short or does not have the second SBA, then control is paised to Block 870 of Figure 62n, discussed below, where this input is treated as a restart for the transaction. If the panel name was found, it is stored in the TV (Block 7~0) and is translated to ASCII provided IET is running on an ASCII machine.

Decision Block 800 operates similar to Decision Block 780 except the next SBA expected following the panel name is the system name. If this field is not present then control is passed to Block 870 of Figure 62n, where this input is treated as a restart for the transaction. Considering Figure 62m, if the field is found, BlocX 810 stores the panel name in the TV and translates it to ASCII provided IET
is running on an ASCII machine.

Decision block 820 compares the system name from the panel with the system on which IET is running; if they are equal the IET processes this screen and control is passed to block 860 where the profile is to be restored. BlocX 830 is executed when the system name from the panel is not the same as the system on which IET is executing. Therefore, IET
must forward this panel input for processing to the system name on the panel. IET verifies that the panel system name is a ~alid ne~work system by examining a local data base of valid na~es. Some systems' implementations may not have a table and therefore all names are potentially valid and should be forwarded to the next higher DAA system for delivery. If the system name is not deemed valid, control is pàssed to block 860 for processing on the local system.

Block 840 is ex~cuted when a forward request to a remote system is needed. This block constructs the IETM,IETI, followed by the message panel input flom the terminal. The exact field definitions were discussed earlier in connection ~'.

., r~ . ~
~ r~ ~

th the IET message format. The remote IET processing to handle this forward request is handled at Block 400. It is important to note that the IET~ is updated to contain information about the requesting terminal, the local and remote IET systems, relative tran code on each system, panel name on each system, and the type of machine that the local IET is executing on, whether ASCII/EBCDIC and byte swapped or not. As mention earlier, these IET hPaders facilitate routing to the remote system and proper translation when it arri~es. After the message block is formatted by block 840, control is passed to Block 1410 of Figure 62v, discussed later, for deliv~ry to remote system.

Block i360 is executed for a local system terminal input.
The system name in the TV is set to the local system --identification and control is passed to Block 870, which blanks the outpu1: name.

Continuing with Figure 62n, Blocks 880l 900, and 910 are identical logic to previous blocks 570-590 (i.e., the profile is restored for this user and application identifications). If the last thing done was an IET request to another system or transaction, then a trace forward request is built to restart the transaction/system found in the restored IETI profile (Block 910~ and control i9 passed to Block 1420 of Figure 62v, for transmissivn of the request to the desired system. For example, if the last thi~g done for thiis user and transaction was a link request to another system, and a return has not yet occurred, or the profile would not show a link outstanding, then this trace forward requ~st is designed to get the remote transaction to do a return again.

If the profile was not an IET request then control is passed to Block 930 which populates the TV from the restored profile view. lSee Block 350 for discussion). Then Block ~ ~ ~ r~ ~ r~ ~
'0 finds the TPE ~or the panel name specified in the TV
(see Block 630 ~or discussion).

Block 950 takes the panel map data pointed to by the TPEAMAP field of the TPE, along with the input 3270 data stream and calls TMS to extract the fields returned from the terminal to the appropriate fields in the TV as described by the panel map data area. TMS is a Texas Instruments, Incorporated 3270 screen facility, but other facilities could be developed or adapted use with the present invention, such as IBM's I~S MFS facility. The important thing is that the input ~ields returned from the terminal are map~ed, including conversion to internal representation, to the application's TV fields. In addition, the 3270 AID
key representation is updated in the TV.

Block 960 gets the TPE entry for the panel name. Then block 962 uses the TP~AITCE to locate the TCE entry for the input procedur~ to be called. Moving to Figure 620, Block 970 then saves the procedure name from the TCE into the TV.

Block 980 thereafter updates the binary field in the TV
for the function key. DAA application developers can generate their panels with an option field displayed on the panel as "OPTION:" and if the user types a string "Fnn", IET
will interpret thi~ ~he same as if the ~nn key was pressed.
This logic only applies if the user typed the function key name and pressed the ENTER key. If the function name was typed and another function key was depressed, the IET will used the 3270 generated AID key as the function key and the -user's typed function key name will ~e ignored. In any case after this function key logic, Block 990 will cause this option ~ield to be blanked in the TV.

At this point, the IET at Decision Block 1000 checks to see i~ the function key selected is F15. If F15 was r^~ . ~
~ 2 5~

~lected, the IET interface jumps to Block 1530 of Figure 62x, discussed earlier. F15 is used by DAA to indicate that the user wants to QUIT this application, so branching to 1530 will remove this application from the profile data base for the user and the DA transaction will be inserted. If the function key selected is not F15, the IET interface checks to see if the function key F24 is selected (Block 1010). If so, this indicates the usex wants to suspend the current application and see a list of his current active applications by use of the DA transaction. Block 102 builds a message buffer of "DA =1" for the user and inserts it to the transartion processing subsystem. After this, control is pa~sed to Block 1630 of Figure 62z, where transaction cleanup is performed.

Decision Block 1040 checks to see if the current panel is the H~LP, ~LOSSARY or MENU panel. If it is one of these, the control is passed to Block 1190 where the input procedure associated with the panel is to be executed.
Considering Figure 62e, if the current panel is not one of thes~ panels, Decision Block 1050 checks to see if the value of a selected function key equals 1, whish is the standard DAA HELP key. If it is not a 1 then control passes to Block 1150, where the next value for the selected key is tested.

Block 1060 begins the logic for displaying HELP panels for a particular application. First the help logic must save enough information that upon exit from the help screen, IET can restark the current panel with all of its fields.
This logic builds the help view area consisting of all the current input and output fields contained in the TMS buffer.
The view name is set to "HELPVIEW" to identi~y this view.

Block 1070 then pushes and puts this help view onto the stack file. A~ter the environment has been saved, the help logic can now prepare to output the help panel. Blocks 1080 .
Tq-13766 291 ::

~b ~
~ 3 ~
~ d 1090 save the current panel name, documentation chapter, section, and page names in the TV.

Block 1100 locates the TPE and TCE for the hPlp panel and help procedure respectively. The help panel TPE is anchored off TDT using field TDTAHELP. Next a help profile buffer is built (Block 1110) and, moving to Figure 62q, saved to the profile file (Block 1120). This is comparable to the logic for Blocks 270 and 280. Block 1130 opens the documentation file, locates the specified help page and read~ 20 lines into the TV. Then control is passed to Block 1610 of Figure 62z, discussed later, where the panel is built and output to the terminal.

Decision Block 1150 checks to see if the function key is a 3. F3 is used by I~T to allow the user to go back to the top menu. If it is 3, then control is passed to Block 15gO
where the kop menu panel is built and output.

If the function key is not 3, Decision Block 1160 checks to see if it is a 12. F12 is used by IET to perform a I~CANCELII. At this point the IET cancels the current panel and redisplays the last panel that preceded the canceled panel.

Moving now to ~igure 62s, the IET at this point blanks the message area in the TV.

Block 1200 begins the logic of executing a procedure ~thak is already setup via the TCE. This logic is branched to from sevexal pl~ces in IET. This block gets the address o~ ~he procedure from the TCE.

Decision Block 1210 examines the TDT to see if this procedure is a SQL procedure and if not, control is passed ~o Block 1240. If it is, Block 1220 checks a global flag to .

: ~, r~
:~' ~

~e if a SQL connect has been done for this user and application. If it has, control is p~ssed to Block 1240.
-Lf not, Block 1230 is exscuted do the SQL connect. IET llses he application id stxing as the SQ~ user id and SQL
password. This facilitates not requiring every user of the transaction be registered with the SQL system, but rather the application id is registered as the user id.

Block 12~0 calls the procedure passing the TV, and the transaction I/O control blocks.

Decision Block 1250 checks to see if the procedure was an SQL procedure and whether an SQL commit needs to be done.
If no, then control is passed to Block 1270. Otherwise, Block 1260 does the required SQL commit.

Block 1270 starts the logic to examine the exit-status of the just-called procedure. I~ the exit-state field in the TV is not equal to "ILINK", then control is passed to Block 1320.

Block 1280 processes the ILINK request which indicateis that the called procedure wishes to invoke another procedure immediataly. The name of the new procedure is first obtained from the TV. Next, Block 1290 blanXs the exit-state in the TV, and Block 1300 scans the list of TCE's for a match on the name sp~cified. The results is the address of the TCE
~or the new procedure. Control is then passed to Block 1200 cf Figure 62s, where the new procedure is executed.

T~hen the exit-state dnes not equal I~INK, Decision Block 1320 checks the exit-state for "QUIT". If it is there, then ~control i~ passed to Block 1530 of Figure 62x, discussed earIier, where the application is deleted from the profile and the DA tran~action is inserted for the user.

: ~, 2 ~ 2 3~ ~
When the exit-state does not equal QUIT either, Block 1330 next checks the exit-state for "RESET". If found, control is passed to Block 1560 of Figure 62y, discussed later, where the stack is cleaxed for the user/application and the top menu is invokPd.

Turning now to Figure 62u, Decision Block 1340 checks the exit-state for "LINK". If not found, control is passed to Block 1430 of Figure 62v, to check for a RETURN request;
otherwise, Block 1350 handles the "LINX" request. First the profile area ~or the current TCE is built. Then Block 1360 puts this pro~ile area on the stack file. (See Blocks 270-280 discussion above).

Block 1370 starts the process of building an IETM and IETI header in the message area. As previously discussed the IETM/I~TI construct is used to route data to a different transaction/system. A~ter the IETM/IETI headers are constructed, Block 1380 scans the list of TCE's for the name of the linked to procedure found in the TV. Block 1390 then uses the TCE block to locate the profile view list, VMOH/VMOF ~see TDT discussion earlier~O This list is used to extract the profile view data fields from the TV and move them to the area ~ollowing the IE'rM/IETI in the message buffer.

Moving now to Figure 62v, Block 1410 saves the IETI
head~r on the profile data base. The IET at Block 1420 then takes the current mescage block and finishes building the IETM and~IETI header~ All the character fields o~ the IETI
header are converted to E~CDIC if necessary and the destination tran code and the total length of the message are added to the IETM header. If the destination system is the same as the local system then the message block is yueued to th~ tran code on the local system, otherwise the block i~ queue~ for transmission to the destination system.

' :' r~
~ ntrol is then passed to Block 30 where the next input message is received from the transaction processing system.

Block 1430 checks the exit-state for "RETURN". If it is not "RETURN", then control is passed to Block 1490 for the IET to process the next panel.

Block 1435 handles the '1RETURN" request. The procedure has been invoked by a LINK request and is now returning to the invoking procedure. First the IETM and IETI pointers are constructed in the message buffer (Block 1435). Then Block 1440 restores the IETI view from the stacX. The IETI
was stored on the stack by the original LINK request. Block 1450 next builds the output view area after the IETI header in the buffer, using the procedures output view list, anchored of~ the TCE in field TCEOVW. Each field referenced by the list is moved to the output area.

Block 1460 clears the view stack, whereafter Block 1470 is executed to setup the tran code in the IETM header and the target system identification for transmission. Block 1480 then marks the IETI field IETICC: to indicate a return request, and Block 1490 blanks the exit-state.

Decision Block 1500 tests the current panel name in the TV for blanks and if present, th~n con~rol is passed to Block 1630 of Figure 62z, to build the transaction profile view in preparation for executing the next transaction request.
.
If the panel name is not blank, Block 1510 uses the panel name to ~ind the correct TPE. Control is then passed to Block 1610 of Figure 62z, where the panel specified is ~-processed.

Looking now at Figure 62y, Block 1560 is executed to .''''', ''''''''''''' '''",.,.,'~,',"', ' ''. ','''''''':,',''' ,'~,'," ," '";',"

~ turns the user to the top menu. Here the view stack is cleared and Block 1570 initializes the TV (see Block 40).
Then, according to Figure 62z, Block 1580 clears the message area in the TV, and Block 1590 displays the top m~nu. First the TPE is located from the TDT field TDTAMENU. Then at Block 1600 the TCE pointer is set to the menu procedure using the TMEATCE pointer in the TME entry for the top menu.

The IET at Block 1610 builds the 3270 data stream from the panel map and the TV. The logic of this block employs TMS, but as mentioned earlier, other facilities such as IBM's IMS MFS could be used. Block 1620 then outputs the data streams to the terminal. If the destination system is local, the message is queued to the local transaction system for delivery to the specified terminal. If the system is not the local system, then a IETM/IETI header is built and the 3~70 data stream is appended. The IETI request code is set to TERMINAL and the message is q~leued for transmission to the remote destination system.

Block 1630 builds the transaction profile view for the current procedure~ Then, as seen in Figure 62aa Block 1640 puts this view on the stack file. Control is then passed to Block 30 where the next transaction message is received and processed.

Decision Block 1660 exits the transaction by testing to see i~ a SQL connect was done and, if so, Block 1665 is executed to release the SQL data base. If not, control is passed to Bloc~ 1~70 which closes the documentation file if it is still open. Block 1680 then finishes the cleanup by closing the profile data base and freeing any allocated memory. Finally the IET returns to the transaction sub-system main module for termination of this transaction.
.:
Whil~ a specific embodiment of the invention has been :
:

:

~ '` , ~b ~ - ` 2 ~ 7 ~
,own and described, various modifications and alternate embodiments will occur to those skilled in the art.
Accordingly, it is intended that the invention be limited only in terms of the appended claims.

:

, :
:
~ : TI-13766 297 ~: :
. .

Claims (14)

1. A dialog flow manager for a transaction processor, comprising:
a panel input;
a mapping service to interpret said panel input into variables to be used to build panels;
a transaction processing subsystem;
an interface to said transaction processing system for communicating with said transaction processing system to get next input from user and send output to user;
a communication between two heterogeneous machine;
a table of instructions containing pointers to maps, views, and application procedures; and a translator which looks at said table of instructions to manage flow of input, output and procedure execution.

2. The dialog flow manager of claim 1, wherein said table of instructions also contains a table of logical terminal device characteristics.

3. A method for dialog flow management for translating data flow between a plurality of users, where at least one of said plurality of users is an application procedure, comprising:
(a) initializing field within a transaction view by a dialog flow manager;
(b) receiving a formatted input data message bearing a header containing information;
(c) reading said header information;
(d) searching said header information for a destination system name to determine whether said formatted input data message is intended for local processing;
(e) if it is not intended for local processing, routing said formatted input data message to a system matching said destination system name as a remote processing request, which system then proceeds at step (f);

(f) or, if said destination system name matches local system name, then interpreting said formatted input data message based upon said header information;
(g) yielding control of dialog flow to a called map interpreter;
(h) obtaining input field information from said formatted input data message by said map interpreter;
(i) initializing of data fields in transaction view by said map interpreter;
(j) populating said transaction view initialized data fields with said obtained information by said map interpreter;
(k) relinquishing control of dialog flow to said dialog flow manager;
(l) forwarding said populated transaction view to a preselected application procedure for processing of said obtained information;
(m) returning said populated transaction view data fields containing processed data to said dialog flow manager;
(n) yielding control of dialog flow to said called map interpreter;
(o) placing said data fields containing processed data from said transaction view into data portions of a formatted output data message;
(p) building an output message header information onto said formatted output data message; and (q) forwarding said output message bearing said output message header information to a preselected logical terminal.

4. The method for dialog flow management of claim 3, said step (b) of receiving a formatted input message bearing a header further comprising the steps of :
(r) determining whether said data input message is formatted;
(s) if said data input message is not formatted, formatting it into a data type according to application-supplied TI-13766.3 299 requirements available to said dialog manager; and (t) if it is formatted, accepting said data input message.

5. A method for dialog flow management for data input from a logical terminal to process a requested transaction such that said requested transaction may be restarted after having been suspended, the steps comprising:
(a) initializing variables;
(b) receiving said data input;
(c) determining whether said data input is formatted;
(d) reading a first profile view;
(e) generating a new profile view based on selected portions of said data input;
(f) converting input from input view and profile view;
(g) interfacing with a data base management system;
(h) calling a necessary procedure for said requested trans-action;
(i) processing said data from said input view and profile view;
(j) creating an output view;
(k) populating said output view with selected portions of said processed data;
(l) recording sufficient information in a second profile view to recreate aid output view, wherein said second profile view replaces said first profile view;
(m) storing said second profile view on disk;
(n) transmitting said processed data in said populated out-put view to said logical terminal; and (o) repeating steps (b) through (n) until no more data input is received.

6. A method for runtime dialog management between a plurality of users, where at least one of said users is an application procedure, and where at least one of said users is an original logical terminal, comprising the steps of:
(a) receiving an input from said original logical terminal;

(b) passing said received input to a dialog manager;
(c) translating said received input by the dialog manager into data type understood by said application procedure;
(d) forwarding said translated input to said application procedure;
(e) processing said translated input by said application procedure into processed data;
(f) forwarding said processed data to a said dialog manager;
(g) translating said processed data into data type under-stood by a logical terminal specified by said application procedure; and (h) transmitting said processed data from said dialog manager to said specified logical terminal.

7. The method of claim 6, wherein said step of passing said received input to a dialog manager further comprises the steps of:
(i) routing said received input by a transaction processor;
and (j) communicating said received input to said dialog manager via a transaction processor interface.

8. The method of claim 6, wherein said step of trans-lating said received input further comprises the step of:
(k) converting external data representations for said received input into internal machine representations for the designated application procedure.

9. The method of claim 6, wherein said processed data introduced in step (e) can be a request to the user for additional data, a request to another computer for coopera-tive processing, an output response to the user, or a calling for another transaction to be executed.

10. The method of claim 6, wherein said step of trans-lating said processed data further comprises the step of:

(l) converting internal machine representations for the designated application procedure into external data representations for said processed data.

11. The method of claim 6, wherein said step of trans-mitting said processed data from said dialog manager to said specified logical terminal, further comprises the steps of:
(m) communicating said processed data to said transaction processor via said transaction processor interface;
(n) formatting said processed data in a form understandable by said specified logical terminal; and (o) routing said formatted processed data by said trans-action processor to said specified logical terminal.

12. The method of claim 6, wherein said specified logical terminal may be said original logical terminal.

13. The method of claim 6, wherein said specified logical terminal may be a logical terminal elsewhere on a system where said original logical terminal also resides.

14. The method of claim 6, wherein said specified logical terminal may be a logical terminal located on a system other than that where said original logical terminal resides.

TI-13766.3 302