·f ~:

AN END-USER APPLICATION FOR PHARMACEUTICAL RESEARCH

Guy TOULOUSE - SEMA GROUP (SUISSE) SA

CO-Authors Bernard LAVANANT

The design and development of specific applications is one of the main activities ofSEMA GROUP, the second largest software consulting and engineering company in Europe.

In this field; theSEMA GROUP engineers have acquired a long experience in the development of applications with the SAgS system, reinforced by a close partnership l-lith SAS Institute in France and in Sl-litzerland.

The purpose of this paper is to present how the rules and methods used for the development. of large, traditional applications also match the development of important applications using a Fourth Generation Language like SAs8I.

The sUCCess 0·£ such projects depends heavily on the USe of a methodology, from the early specifications phase up to the implementation of the application. The paper also presents some of the programming techniques used to improve the efficiency of the programming and future maintenance tasks.

As an illustration for these methods and programming techniques, the paper will start with a description of the DATA-POOL II project at elBA-GEIGY, a leading proje"ct with SAS, currently under development by SEMA GROUP (SUISSE) SA.

,. I. PRESENTATION OF THE DATA-POOL II PROJECT I

The project involves up to 6 engineers from SENA GROUP (Sui.sse) SA.

It has a total duration of 11 months, divided in two phases: - the analysis phase: design and speciHcations (June 90 - September 90)

. ~ the realization phase, programming, testing and implementation (October 90 ~ November 91)

1. :PURPOSE OF THE DATA-POOL II PROJECT

The application is dedicated to the Research and Development Department of elBA-GEIGY Pharrna. DiviSion in Basle#and desi9ned to match the specific needs of Pharmacokinetics.

Pharmacokinetics is the study, as a function of time, of the various aspects of the drug in the body; absorption, distribution, metabolisation, elimination.

It is based on the collection and analysis of fluid samples, followed by the design of a mathematical model, which is then used to simulate possible

\

\. experimental designs. ;,'

207

The purpose of DATA-POOL' II is first to cdl:lect and store data related to the drug studies carried out by the department)_ and then to use this database to produce reports and graphs needed for the assessment of drug properties.

DATA-POOL II provides therefore functions for - recording and evaluating a study

simulation by model calculations and definition of new experimental designs reporting (for official documentation of drug studies) protocols of new studies combining and comparing studies deducing meaningful biopharmaceutical parameters

Till now, the Research Department was using an application called DATA-POOL I. It has been developed over 15 years, being progressively complemented by 5 persons. It was written with SAS version 5. The decision to build a new version was recently taken for the following reasons :

- DATA-POOL I is made of a collection of independent specific programs, built after the individual demands of each user.

- It lacks functional and technical documentation, and presents therefore an appreciable risk of knowledge loss.

- The maintenance needs for and around the application are increasingly complex.

- Few users know how to use it. - It has an heterogeneous database structure for the needs of the Pool

level. - Very few error checks have been programmed.

The conclusion was then to redesign, extend and improve the quality of the application, and create a new version, called DATA-POOL II that would bring in the following advantages : '

- DATA-POOL II would be composed of one single integrated tool and would be an open system. It would standardize the processes of data capture and retrieval, guarantee the consistency and structure of data, closely check errors at data entry, and allow an easy comparison of several studies.

- The use of the application would be extended: new functions, accessible by a larger number of users.

- The application would be packaged and documented, and would benefit from the new improvements of the SAS System.

2. OBJECTIVES AND REQUIREMENTS

The Research Department includes two different levels: the LAB level and the POOL level, which correspond to two level of use and needs. Users at the LAB level perform studies to measure the kinetics of drugs and metabolites. Users at the POOL level compare and combine the results of several studies so as to produce the reports needed for the assessment of drug properties. Both levels access and enlarge the same database, and use common,' complementary or 'similar functions. It is therefore suitable to group their needs into one single application.

The DATA-POOL II users are R&D scientists in pharmacokinetics. They need a common structure to store all the necessary data. DATA-POOL II should provide them with all necessary control and flexibility required for the data processing. 'More than a recording tool, it should also be a progressive one that fits the complexity and professionality of the field. The system must be opened to be able to adapt to the evolution in the drug development process and to communicate with other sites and databases.

208

Figure 1 - The Conceptua1 Process Mode1

User decision

1 Q

INITIALISATION OF A SESSION

" .. Lab User Pool User

T IN; OF DATA I .-

Raw Data Validated study Validated study

A B

TRAHSFORHATION OF DATA o

Lab Original Pool original Data Data

Selected Data Selected Data Log

~ATlON g

G H I POOL COMPUTATION

• II Reduced Data Reduced Data

SI~~l~ 0

I J I I'OOl SIIIUlA TION

I Simulated Data

Sinulated Data

ABC

209

DATA-POOL II users can also be non-experienced SAS users, with different degrees of SAS knowledge. DATA-POOL II must consequently be usable with a minimum of SAS experience. It must be attractive, easy to understand and to use, which requires a high ergonomics level. The desired function should be displayed easily, using the windowing, pmenus and block menus facilities.

The reliability of the data will have to be guaranteed through data entry controls and the overall quality and consistency of the product.

3. MAIN FUNCTIONS

The Conceptual Process Model shows the succession of the main operations needed within pharmacokinetics studies. (see figure 1)

3.1 Data entry

The data entry is performed and structured through a sequence of screens, either required or optional, that makes a large use of windowing facilities.

These screens provide different levels of data entry in terms of functions study, application, subject, measurement; and in terms of organization Lab level, Pool level.

On line error checking has been set up to check for valid values, required fields and cross validation of fields. A data entry help is also given through such features as selection table or multi-units entry.

The security of the data entry is managed through access controls, and validation steps and flags.

3.2 Process and exploitation of the data

~ANSFORMATION OF UNITS /.

~SELECTION OF DATA

c===lr ____ S_IM __ U_L_A_T_I_O_N_S~ ________ _,

. COMPUTATIONS

These functions are performed through a series of dynamic screens. Since the original raw data is protected, many iteration of these processes can be performed within the same study on a copy of the data. Logging facilities are provided to keep trace of the selections.

210

'"to

3.3 Reporting

Reporting can be done over all the data available, including data resulting from process operations. A series of customized screens have been designed to allow the users to create reports or graphs with a wide choice of variables and layouts.

graphs

reports

Can be 2 or 3 dimensions, possibility of having multiple graphs per pages. There are specialized screens for the choice of graph types, presentation, legend and contents.

Can be 2 or 3 dimensions. There are specialized screens for the choice of predefined reports, presentation, contents, sort order and "group by" selections.

As these modular screens can produce a lot of different queries for the definition of many graphs and reports, the application also includes functions to protocol these queries.

3.4 Combination of studies

The combination of studies is needed at the Pool level, to produce analysis by drug. Through a common database architecture, DATA-POOL II facilitates the comparison or concatenation of data from several studies.

Functions have been developed to let the user select studies and merge the data from all selected studies. The user can then perform a series of processes (calculations, simulations) using these data.

4. TECHNICAL ENVIRONMENT

The application is developped using SAS version 6.06 under VMS. the central node. The data are stored in SAS datasets.

I VAX 6320 (VMS) I Ethernet netware

\

DEC ! PCSA

{

VAX PC VAX

SAS is run on

- -

terminals computer stations (*)

Figure 2 - The hardware structure

211

I II. PRESENTATION OF THE METHODOLOGY

The methodology that has been followed for the development of the DATA-POOL II project is based on the MERISE methodology. It uses the traditional 3 stages analysis phase, realization phase and implementation of the application.

1. THE ANALYSIS PHASE

Even when using a Fourth Generation Language like the SAS System, that allows fast programming and modifications, it is valuable to pay a lot of attention to the analysis phase.

Four main steps should be considered for the analysis. These steps follow a progressive descending approach, from the most general aspects (therefore the most stable ones) to the most detailed (the most subjected to variations). This organization of tasks also helps to precisely identify and express the needs of the users. The specification file, produced as a result of this analysis phase, can later be used as a solid basis for the preparation of the realization. A careful validation of this file minimizes the number of steps back during the realization phase.

c==== GENERAL SPECIFICATIONS

c==== DETAILED SPECIFICATIONS

c==== VALIDATION

I PREPARATION OF THE REALIZATION PHASE

Figure 3 - The four steps of the analysis phase.

1.1 The general specifications

The general specifications are based on a separate identification of the data and the processes.

After a collection and examination of all possible information supports, the data types are identified and structured into several entities. The relations between these entities are also expressed and qualified. The result is the construction of a Conceptual Data Model that presents the organization of these entities and relations.

A Logical Data Model is later deduced from the Conceptual Data Model. That model clarifies the dependences between entities. When using a Fourth Generation Language, the final structure of the data tables is most often very near from the structure presented in the Logical Data Model.

After an examination of the information flows, it is possible to identify the main operations that will have to be performed by the system. They are presented through a Conceptual Process Model. This model shows the events that are needed to start each one of the operations, and the results produced by the operation. The succession of events and results sets up the links between operations. The main management rules attached to each operation are also collected during that phase.

212

b ,; ~.:

h ~' >,

t , k t~: ~,'

~ y ~\ ~, ~; <;-. ...,. {f ? .~ )'.

,"

1.:

"

f

~ , ..

~ r :",

'";;i" ",

f ,~ c'

.;."

!-

t: J ;,,~:<

\ ,~ ~, 'J"~

~ \.. ':1'!:~ COl:,

S'.

'~;'

"

" ':

~

This Conceptual Process Model is later derived into an Organizational Process Model, from which a list of procedures can be defined. These procedures will be used to divide and organize the programming tasks and the program structure of the application. ..

1.2 Detailed specifications

This step is used to define in details the external features of the application. For each procedure, there is a description of

- the screens - the screens dialog - the error checking on entry fields - the accesses to the database - the background treatments - any other specific task

The SAS System can be very useful for a large part of the production of these specifications, especially for the drawing of screens. This eases the specification tasks, and anticipates some of the programming tasks that will have to be done later on.

After the detailed specifications have been written, a cross check between data and processes has to be achieved. This task is absolutely useful to verify the consistency of the specifications.

1.3 Technical study

The technical study is part of the detailed specifications. Its aim is to give an evaluation of the application from the programming point of view, and to set up the main technical guidelines for the realization phase.

The technical study includes an estimation of data volumes and the quantification of the accesses to the database. This leads to an optimization of the Logical Data Model and the definition of the physical organization of the database.

It also includes some tests of the software solution. These tests pay specific attention to response times : identification of the points where low response times may occur and definition of improved solutions. They also focus on some new programming techniques that will be needed by the application.

It eventually describes the hardware and software solutions.

1.4 Validation

A double validation is made at the end of the specifications.

One consists in an internal validation by SEMA GROUP that has a dual purpose : - check the consistency of the proposed database and specifications - check in details the technical feasability of the designed application

The other is the traditional validation by the users, whose aim is mainly to verify that it meets the specified needs. This validation is often easier when the SAS System has been used to specify the screens and the screen dialogs, letting the user benefit from a prototyp version of the application.

213

I

1.5 Preparation of the realization phase

This preparation consists in the classification of the software components : utilities, routines, reusable code, specific modules. It is then possible to sort these components by types, difficulty level, place in the application, and deduce the priorities for the programming and the time saving possibilities.

This identification is also used for a detailed estimation of the time needed for the programming of each task and procedure. A schedule for the development of every procedure is then set up.

The definition of programming and documentation guidelines is also part of this phase.

2. THE REALIZATION PHASE

2 . 1 programming

As for the programming tasks, the realization phase remains traditional. There isa large use of program skeletons and macro programs to maintain the modular composition of the application and ease further improvements. Some of the programming techniques used are described in the third part of this paper.

To keep a high level of quality and clarity throughout the programming, specific attention is paid on the programmer tests, the performance tests and the writing of the technical documentation. An internal quality control is additionally performed by SEMA GROUP experts.

2.2 Acceptance tests

During the programming phase, the procedures are progressively made available to some of the users according to a predefined time table of users milestones. It gives them time to discover how to use the procedures and to express their remarks, so that they can be considered by the programming team before the final delivery of the application.

A global receipt occurs at the end of the programming phase, each parties being responsible of a certain part of the tests.

SEMA GROUP checks that the programs are running without bugs and that they fit the specifications. A detailed plan of all the tests performed is then listed, with the results of these tests. +his will be used as a check list if any problem occurs later.

The users tests focus more on the functional part of the project the screen, using facilities, accuracy of the displayed data.

SEMA GROUP USERS results

test • • plan TECHNICAL FUNCTIONAL

TESTS TESTS

• feed back

214

contents of

I III. PROGRAMMING TECHNIQUES I The DATA-POOL II application uses the following SAS softwares

SAS/FSI?®

SAS/STArr@ SAS / GRAP}f@ II

The application uses the V606 engine and the CONCUR engine. Most of the programming is done with the SCL and MACRO languages. The techniques presented hereafter use the SCL language. They have been developed for several reasons : standardization of the programs, optimization of the performances, handling of specific situations (ie concurrent accesses).

1. SCREENS AND SCREEN DATASETS

All informations are presented on the screen following the same standard structure.

jti tIe line . o menu line . 1 message line 2 function keys line

user interaction area

23 validation area

Figure 4 - The standard structure of the screens

DATA-POOL II uses 6 types of screens

~ MENU SCREEN

~CONSULTATION SCREEN

I INPUT SCREEN

~ SELECTION

~I~ __ H_E_L_P __ S_C_R_E_E~N ______ --,

_ MESSAGE SCREEN

SCREEN

215

1.1 Standard inputs and outputs

strict guidelines have been defined for the programs related to each type of screen defined above. The inputs and outputs needed for the display and use of a screen have also been classified and standardized as far as possible.

Some inputs are needed for all types of screens and are thus considered as part of the structure of the screen program: Screen dataset, Message dataset, Recovery dataset.

other inputs or outputs are optional, depending on the content and specific functions of the screen. ,macros, parameters, SAS PMENUS, DATA-POOL II datasets, log files, user datasets and user files.

Screen datasets Message datasets Recovery datasebs

DATA-POOL II datasets

~ screen

Other macros Parameters SAS PMENUS

Log files User datasets User files

Figure 5 - The standard inputs and outputs

1.2 Screen dataset

One screen dataset is attached to each of the screens. It contains one observation per supported language. This dataset is read in the INIT step before each display of the screen. Each item of information on the screen is declared as a variable and correspond to a label stored in the screen dataset.

LANGUAGE WNAME WKEYS label

e 1 e 40 e 78 e17 ij i = Line number,

j = Label rank on line i (one variable for every label on the screen)

Figure 6 - Structure of a screen dataset

This structure is the same for all types of screens except for block menu screens. These screens have' a different dataset structure to accomodate the SeL block function wi'th which menu screens are built.

LANGUAGE WNAME ITITLE IOPTn

e 1 e 40 e17 e 17'

'Block menu title Text of the menu Box, with 1 <= n <= 12

Figure 7 - Structure of a screen dataset (Block menu screens)

Figure 8 shows how' screen datasets are used in a program.

216

I\) ... --.J

<",;,r"'.'"

/** ••••••••••••• * •• *****.** •• * •••• ~*~.*k •• A* •• *.****** ••••••••• *** * PROGRAM NAME: SASEXE.PROC09.S090,LA.PROGRAM .. * PROGRAMMER NAME: B. LAVANANT '{SEMA GROUP CH) .. • USAGE: Select a treatment ot a study, to ,enter measurements .. concarn1n9 that study

• • UPDATES ENHANCEMENTS · -------- ------------------------------------------------------• 051/01/511 .. .. CALLING PROGRAMS2 SASEU.PROCOJ.sCJOl.l'ROGRAM .. SASEXE. PR0e04. S,04 0 1. PROGRAIM t.hrouqh • S:ASEXE. PROC21.S21J),1. PROGRAM .. .. PROGRAMS CALLUl: •

SASEXE. TABLE .'8'1'004. PJIOGRA1!I SASEK!: .PROC09. S0901B.1'>RO,GlI.I\M SASEXE.ROU'l'lNE.BO003.l'ROGRAl\I tole,ssags bOx routine .. ..

• MACRO-VAlUABLES VALVE IN V.u.UE 0t1T .. coMM£N'l'S

.. GLNlG

.. GSTUDY

.. XTRI$AT

• • DATASETS

none TRDTREAT

read only read ,0000y

OPENED CLOSED USED

.. ----------------• nona • ....... * ............. * ... * ••• ' ......... *******."" ........ ***.**-***>1**,** •• / lenqth qlanq

intabla 1ncall 1helP inSD901l wname ClIl\1 istatus !s090ll ,

lnit:

$12 /* langueqe o'f the user as a where clause */ $35 I. path to ~he TREA~T table ./ $35 /. path to the next screen ,,/ $17 1* halp soreencall-ed */ $17 I. nallle of the &Or_It data1let .. / $4-0 1* window name */ $ 8 1* command issued by user ft/ $ 1 1ft exit status of the messa~ routine */

8 /. s=aen datA51!t i15.entifler */

control always,

1ft temporary development

call symput('GSTVDY', 'LEV1LABNHEAD=Y'): *1 /* reading ot maoro variables *1

qlanq-symqet C 'GLNlG' ) I stdstUdy-symqetC'GSTUDY')i

/ .. initiali1lation of non-screen v~.'dbles */

inlllsg .. IISASEJlE.ROVTINE.R0003.PROGRAM": intable=nSASEXE.T:A8U:.ST004.PROGRAM": incaU="SASEXE.PROC09.S0901B.PROGRAM"; ihelp."S090lA"llaubstr(qlang,1l,1)!!".HELP"; ins0901l~IIUTIL.80901AL"; wname-nll ,

/* opening and reading of screen dataset */

iS09011-open(i.ns09011, 'i'H if bOgell-O then do;

IO!lll display (inms9, '1!!9050' ,1ns09011, , , ,scr-eenn<l.lOO () ) ; ca]'l exeocmd( '<tCANl::EL/ .l!!NDSAS') I

_Gl: ele. do:

ro-whare{1sD9Dll. qlang1 I calls.t(isotOll, , rc-r8tdb11e&9Dll): if ro ne 0 then do:

call dlsplay{inmsg, '119055', 1n5l(91)11., • , ,.screenname () , : oal1 exeoomd ,( 'QCAl!fCEL: ENDSAS' I : rc=clo.eCi.09011); ~

end; .... else 4o,; IQ

call WIla .. (wname) I c:: rCO<C1oMCJ.aO!lOll): Ii oallwrevionC·,1,1',80)1 ~ oa:ll display (iDtable, l,J "STDSTUDy·'.tl lllltdstu'Ciyl I"'" ,trdtreat) ; CO if'trdtreat ne _b1ank_ then call exeCcmcl("EN"D") I

end; end;

return; ~ I»

main: ~ ClIICi-word (1, 'u' ) I .... it cmd nil lin then link keysl .g

'* ver1fy if a treatment was choeen */

if trdtreat eq blanlCthen clo I call wreq1on(9,1,fi,80) I call diaplay(intable, 1., "BTDSTUDlI=It'1 ! stdstully I I"''', trdtreat) ; 1t tr4treat ne blank then call execcmd ("END") I

end, --~.turn,

term: if .tatu. _n'E" then do'

It trati=.at ne })l~ then do; call .~llt(TXTR£AT',trdtr.at): call Goto(inoall,'B'):

end, alse do;

call dieplay(.imneq, '1::0400') ; status -'R':

end,- -.nd,

return;

k-eys: .. l-ect (Cllld) J

when('DP2KELP') call d1sp1ay(ihelp); whan ( 'D'2Ql1n") do:

call d1aplay(inmag,'CB1)lO',' ',istatus); if istatue-Z" then cal.l execcmd ("QCANCEL;

end: otherwhe,

.nih return,

E:NDSAS") i

o HI

I»

!II C'l

~ g ~ I» rt' I» !II ~ rt'

1.3 Message dataset

The message dataset is used to store all messages that may be required for the application. There are four kinds of messages: information, warning, error and confirmation. All messages are displayed in a dialog box. All messages, but the information message, require acknowledgment from the user.

The message dataset is unique for the application. It contains one observation per message and per supported language. It is subsetted at application login time, keeping only the observations that correspond to the selected language.

LANGUAGE C 1 MSGCODE C 5 coded Lnnnn L= ( C, E, I , W) ,

nnnn=sequence # MSG C 78

Figure 9 - structure of the message dataset

1.4 Recovery dataset

The recovery dataset is used to store the initial values of the screen, so that they can be recalled, or compared with the new values.

It contains - one variable for every data field on the screen - one observation per default.

For lists, there will be one observation per line, with a tag field to store whether the field was selected or not.

1.5 Label dictionnary and translation program

This dictionnary is independent from the programs and screen definitions, and complements the screen dataset facilities. It contains all the labels for all the screen of an application, and as many columns as languages.

Each screen dataset added to the application is also added to the labels dictionnary.

LIBNAME Char 8 Library Name MEMNAME Char 8 Library Member Name NAME Char 8 Variable Name LENGTH Num 8 Variable Length LABEL Char 40 Variable Label E Char 78 English G Char 78 German F Char 78 French

Figure 10 - structure of the labels dictionnary

Some simple tools have been realized with SAS/FSpa to enable the DATA-POOL II administrator to easily update this label dictionnary.

218

"-' '\' , ::'::.;r:.~:'~~~ ' .• ,:.:

I\) ...... CD

• PROGRAM NAME: SASEXE.PROC21.S2101 • • PROGRAMMER NAME: B. LAVANANT (SEMA CROUP CHi • • USAGE: .elect a stuCly !:lefore startinq proceeSures 06, 07, 08, 09 * 10, 22 and 23. • Allocate the correct VMS directory to" the RAWDATA library • contain1nq all the "raw t1ata" tables ot that study. * * UPDATES ENHANCEMENTS · -------- ------------------------------------------------------* 10/12/90

• * CALLING PROGRAMS: SASEXE.PROC04.S0401 :" . "* PROGRAMS CALLED: SASEXE.PROC06.S0601A

SASEXE.PROC07.S0701 SASEXE.PROC08.S0801 SAS!XE.PROC09.S0901A SASEXE.PROCIO.81000 sAsEXE.PROC22.S2201 SASEXE.PROC23.S2301 SASEXE.PROC02.S0501 SASEXE.ROUTINE.R0003 SASEXE. ROUTINE. R0014 SASBXE.TABLE.STOlO SASEXE.TABLE.STOll

* • • * * * * * * * * *

Messaqe routine Locate routine Druq ta!:lle stueSy ta!:lla for S2101

* MACRO-VARIABLES VALUE IN VALUE OUT COMMENTS * --------------- -------- ---------* GLANG * GSTODY * GFPOOL * PARM * * • DATASETS

language ot the user STDSTUDY STDP'POOL

VMS path name to DB not a maoro, but a system paramster in SASCONFIG.CFG

OPENED CLOSED USED · ---------------. --------• DB.DRUeJ Y * DB.STUDY I Y Y • *** •• ** ••••• * ••• *.**** ••••• *.*.*********.*****,*,*.**.*"·'**'****1

ENTRY XCALL $35 /* path to the next screen *f : length glang

1nmsg inloc 1st010 iatOll inB0!501 ihalp 1ns21011 indruq instudy iwhere wname iparm 1 lib 1821011 1study isearch cmeS

$12 1* screen dataset where clause *1 $35 1* path name to message box routine *1 $35 1* path name to locate routine *1 $35 1* path name to drug selection ta!:lle *1 $35 f* path name to study selection table *1 $35 1* path name to PRoCOa.S050l *1 $17 f* path name to proper help screen *1 $17 1* name ot the screen dataset *f $17 f* name of the DRUG table *1 $17 1* name of the STUDY table *1 $200 f* where clause applied to STUDY *1 $40 1* name ot the window *1 $80 1* name of the DB VMS directory *1 $801* name otthe VMS directory *1

8 1* screen DSS identifier *1 8 /* STUDY table identifier */ 8 f* locate return code *1

$ 8 1* command typed by user *1

; initl

stddottel stdweiqh stdheigh stdtdata stdtlab atdtpool aUtra stdhead stidir stdminpr row col

8 f* beginn1ng of the study kf $ 1 1* weight unit */ $ 1 /* height unit */ $ 1 1* lab flaq */ $ 1 IA head ot the lab validation flag *1 $ 1 1* Pool flag *1 $ 1 1* protocol complete flag '/ $20 1* person repon.ible for the data *1

l /* number of the VMS directory */ " 8 /* minimum duration ot a periOd *f 3 /* scraen row */ 3 1* screen column *1

control always;

1* reading ot macro variables *1

qlanqa aymqet('GLANG'); iparm=optqetc('PARM')I

1* temporary xcall xcal1-"saaexe.proc06.S0601.program"I

*1 1* inltlalieation of non-screen variables .1

inmag="DP2EXE.ROtrrlNE.R0003.PROGRAM"; inloc-"SASEXE.ROUTINE.R0014.PROGRAM"; 1atolO .. nSASEXE.TABLE.STOlO.PROGRAM"; lstOll="SASEXE. TABLE. STOll. PROGRAM" I InS0501-"DP2EXE.PROC02.S0501.PROGRAM" I ihelp="S2101" I I 8ub8tr(qlanq, 11, 1) I I".HELP"; 1n8Z1011-"U'l'IL. S2l01L"; in4ruq-"DB.DlWCn, inatu4y-"DB.STUDY"I wname-"" I aticl.t.r-O; atitra="'" at4lllinpro=o, 8tdtpool-"" ;

1* aUbaettlnq ot screen DSS and initialisation of labels ./

ia21011-open(inB21011,'l'); it i821011 le 0 then dOj

call diaplay(inmaq,'29050',lns2l01l, ",screenname(»; oal1 execcmd('QCANCEL; ENDSAS');

end; 8l.e dOl

rc~h.r.(i.2101l,glang): call Bet(ia210ll)I rc-tetch (i821011)" I it ro ne 0 then dOl

"call diaplay(inmsq,'E9055',ins21011,' ',screenname(»; statu8 -'H',

rc:-cl08i(i8210ll); end; al.e 4cI

ro=olo •• (i8210ll): call wname(wname): latudy-opan(instudy,'i'j; it iatudy 1e 0 then do:

call d1splay(inmsq,'E9050',lnstudy,' ',screenname(»I call qoto (xoaIl,'a');

end 1 return;

'" :-

~ .... ~ ~ ... ... t'n g. fIl RI rt'

o HI

I»

fIl RI .... RI n rt' .... g rt'

~ .... RI

2. USE OF TABLES FOR CHECKING OR SELECTION

Most SCL selection functions allow only one selection. SCL programs have thus been created to display the contents of a dataset in a table format and allow the selection of one or more items from that table. The programs provide a find pushbutton to help locate a particular item in the table (similar with SAs/ASSIS~ standard selection function).

The value of the selected key variables are then passed back through a list of parameters. If the list is too long, the table is subsetted and the subset is then used in the calling program. (See figure 11)

The call to a selection table is done by hitting a given function key on the corresponding field.

3. SUBMIT OF BATCH JOBS

To improve the response times of the application, some tasks, like heavy selections or some graph generations, are run in batch mode after being built through an interactive screen.

This is the sequence to construct a batch job :

1. generate the code and store it in the preview window

2. call a program that saves the code and submits the batch job, using a system command.

Figure 12 shows an example of such a submit.

4. MULTI USER ACCESSES

Although the application is built to minimize multi user accesses, it remains necessary to check for concurrent accesses in the case of an update to the database.

Some principles have been followed to limit the occurences of such conflicts :

1. In SCL, the datasets are opened in update mode (with record level locking) as late as possible in the program. The exclusive access is then controlled through a software trick (described hereafter).

2. When possible, user subsets of the datasets are used.

3. In case of the execution of SAS code through a submit block, each input dataset, that is part of the shared database, is opened with record level locking (CNTLLEV=RECORD).

There are two main risks of access conflict : - when more than one user tries to update the same observation at the same time. - when a user is sorting a dataset (after inserting lines) and another one

tries to update that dataset.

220

Figure 12 - Submit of a batch job

r ;.*.~*******.**************.***.****************************w****

* PROGRAM NAME: SASEXE.ROUTINE.R0023.PROGRAM ".

.. PROGRAMJI1ER NAME; B. LAVANANT (SEMA GROUP CH)

". USAGE: submit SAS co~e in Batch .. • - UPDATES ENHANCEMENTS * ------- ------------------------------------------------------• 14/03/91

• CALLING PROGRAMS:

* PROGRAMS CALLED: SASEXE.ROUTINE.R0003.PROGRAM Message box ". [datapoolII]dp2batch.com (VMS file) * * MACRO-VARIABLES VALUE IN VALUE OUT COMMENTS * ---------------• * • OATASETS OPENED CLOSED USED * ----------------.. .. ••••• *.****** ......... ************* ••• * •• ************ •• ***********./

ENTRY XFlLE XTEXT

$20 /* na~e of the VMS file that will contain the code */ $17 /* text display in the message box */

: init:

1* initialisation of non-screen variables *1

1nmsq-"SASEXE.ROUTINE.R0003.PROGRAM"; inref-"BATCHJOB"; inbatoh=aubatr(optgetc('PARM'),1,19) 1 1 ")dp2batch.colll"; VllIscmd-'SUBMIT/NOTIFY/NOPRINTER/PARAMETER=("ll lxfilel I ''') '!!inbatchi rc-t!lename(inref,xt11e);

return I

main: rc-preview('FIL!',inret)7 rc-preview('CLEAR');

r.turn;

term: rc-ayatem(Vll\8Qmd)1 call wreq1on(9,lO,6,60): call d1sPlay(1nmsq,'Io715',xtext);

return 1

221

Some instructions have been included in a loop to allow an easier handling of the access conflicts.

Example of code: do until (rc = 0) ; rc = sort (dataset, "key1 key2")

end ;

Case 1 : One user is trying to insert or update one line in a dataset and, as a result of a conflict, cannot insert or update.

~:e~'~ G T G ,

r- //<val> "-/ ~ ___________ --l

update demand

wait and retry

locked dataset -

The program comes back to the state it was just before the user hit the validation key.

He will then be able to validate again.

Case 2 One user is updating or appending an observation and a second user is trying to sort the same dataset just after inserting lines

update sort demand User 2 II T II

"----~./ ~ loop

The sort is not done.

The second user goes into an infinite loop around the sort function, until the first user frees the observation locking the dataset and preventing the sort operation.

Case 3 : ... and a third user is also trying to sort the dataset.

sort demand §ser2 update W=~~==~,~<---------------- ~ T ~

--------=::i)~__ '---------~ locked dataset sort demand ,User 3

<,- ~ ~: After the first user freed the dataset, whoever successfully locks the dataset first, sorts it first.

Then the situation is as case 2.

222

5. GENERATION OF GRAPHS

Graphs are built using a series of data entry screens, that allow the user to define a wide range of options. Each entry screen is dedicated to one or more aspects of a graph: type, contents, axis •.•

The generation of a SAS program producing a complete graph is rather complex tasks have therefore been divided into modules. Each module stores the part of the program that it generates in a SAS catalog SOURCE member.

The different parts of the code can then be generated at different times, without worrying about the logical sequence of the entire SAS program. A final routine then recalls in the proper order all the source membered saved, and submit the whole program to generate the graph (figure 14).

i 1 12GREPLAY 3

AXIS

~ ~ 1 Code ci 1 Code EI

.., RECALL ROUTINE

GOPTIONS

~ 1 Code AI

I Code A

Code B •

Code C

Code D

Code E

4 CONTENTS 15 LEGEND

~ 1 Code BI

SAS program for the generation of the graph

~ 1 Code

Figure 13 - The generation of a graph

6. AUTOMATIC DOCUMENTATION OF SAS/AF (AND DATASETS)

DI

A full documentation of each dataset is created using the LABEL, LENGTH and FORMAT SAS instructions. This documentation is helpful to later build and update such facilities as a label dictionnary or a variable dictionnary.

A unique description of each SCL program exists in the catalog directory. It is complemented by a programmer documentation inside the source code :

- standardized program header - in-program comments

Most of the technical documentation needed for such an application can be nearly automatically produced using standard SAS functions - The program documentation can be printed using the print instruction of PROC

BUILD, using specific printer forms. - The labels of each screen, as well as the help screens, are printed for each

supported language. A cross reference of the message codes used in a program can be created, using a XREF dataset printed separately (sorted by program or by msgcode).

The source code of each program is however saved outside of SAS, to benefit from host utilities such as SEARCH commands.

223

Figure 14 - Generation of a graph

ENTRY: S2004E.PROGRAM Recall of every graphic commands Last updated: 04

***** SOURCE··*··

/************************.******************************* •••••• ~.~ * PROGRAM NAME: sUbmit-code tor all graphic commands * * PROGRAMMER NAME: N. LEGRENZI (SEMA GROUP CH) .. ~ uSAGE: Recall ot all qraphic commands

* UPDATES ENHANCEMENTS * ~------- ------------------------------------------------------* 22/03/91 Creation

* * CALLING PROGRAMS: S2004 * * PROGRAMS CALLED: * ~

~ MACRO-VARIABLES VALUE IN VALUE OUT COMMENTS . --------------- -------- --------- -------------------------* * DATASETS OPENED CLOSED * -_._------------ ------ --------* ***********************.**************************************.***/

/* D;:tT SECTION */

INIT;

RC=PREVIEW('COPY', 'WORK.TEMPLATE.GOPTIONS.SOURCE'); RC-PREVIEW('CO?Y','WORK.TEMPLATE.BLOODTIM.SOURCE') i RC-PREVIEW('COPY', 'WORK.TEMPLATE.MINMAX.SOURCE'): RC-PREVIEW('COPY', 'WORK.TEMPLATE.AXIS.SOURCE'); RC-PREVIEW( 'COPY', 'WORK.TEMPLATE.SYMBOL.SOURCE') : RC=PREVIEW('COPY', 'WORK.TEMPLATE.DELCAT.SOtJRCE') r RC-PREVIEW('COPY',tWORK.TEMPLATE.LEGEND.SOURCE') ; RC=PREVIEW('COPY', 'WORK.TEMPLATE.ANNO.SOURCE'): RC=PREVIEW('COPY','WORK.TEMPLATE.GSLIDE.SOURCE'): RC=PREVIEW('COPY','WORK.TEMPLATE.GPLOT.SOURCE'): RC=PREVIEW('C8PY', 'WORK.TEMPLATE.GREPLAY.SOURCE'); RC=PREVIEW('COPY', 'WORK.TEMPLATE.TREPLAY.SOURCE');

RC-PREVIEW('SAVE', 'WORK.TEMPLATE.ALLDEF.SOURCE'); RC=PREVIEW('CLEAR');

returnr

224

~; , ~ t;' ~: 0 c; ~ Ii 15 p. t' t' f,' ~ ~.

!: ~.

~-~ }" '(:; ~:, ~ . ... L:

~.

~ Ji l t:

1-t,

J: ·k ." r-.~ r,'

.. ~.

;:Ii j ~~ 1:'

:r l, ~;

:,~~

, ~.

\, ,,'

The DATA-POOL II application is entirely realized with SAS softwares. It has been specifically designed to meet the needs of pharmacokinetics.

The methodology used throughout the project guarantees that it is completed under good conditions of accuracy, delays and charges. That methodology has been adapted to important project developed with a Fourth Generation Language like SAS. One should noticed that the SAS system can be largely used for the implementation of the methodology.

Some programming techniques have also been developed to ease the programming tasks and to realize some of the features needed by the application.

SAS, SAS/AF, SAS/ASSIST, SAS/GRAPH, SAS/FSP and SAS/STAT are registered trademarks of SAS Institute Inc., Cary, NC, USA.

For any additional information, you may contact Guy TOULOUSE at

SEMA GROUP (SUISSE) SA 64 rue du Stand CH-1206 GENEVA Tel: (41.22) 789.07.30

225