Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Encyclopedia of World Problems and Human Potential wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Clusterpoint wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Ingres (database) wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
DEVELOPMENT OF A SAS/DB2 BUSINESS APPLICATION ft1 - lP1wl Spooll'llllWnS aumldl WijJOltaUIllldl JP>ee1tern BSO~emexnt Support - Zwolllle 9 The Netherllaum~ ABSTRACT When combining the enhancements of SASIACCESS· and SASI AJt in SAS 6.06 it is possible to develop business applications using SAS software (instead of COBOL or FORTRAN) with DB2- as database management system. This paper discusses our experiences with the development of a multi-user SAS/DB2 business application concerning the control and registration of all hard- and software in a large industrial organisation. Our experiences with SASI AF were very positive, especially because it was possible to build a structured and very user-friendly application in a short period of time. The 6.06 DB2 interface gave a number of serious problems. The problems were concerning the referential integrity used in DB2, locking, COMMIT/ROLLBACK and performance. With workarounds we were able to solve the problems. In SAS 6.07 enhancements to SASI ACCESS Software will address some off these problems. This paper ends with a discussion of the solutions implemented in SAS 6.07. 1 INTRODUCflON BSO/Management Support, part of world-wide operating BSOIORIGIN, is specialised in supporting management by making management information accessible by means of modern information technology. BSO/MS is providing Information Technology services for over 10 years in the Netherlands. One of the areas in which BSO/MS is experienced, is building applications in 4GL, amongst which SAS. Because of SAS-expertise, BSO/Management Support has been involved in the realisation of a project at a client. The client is an national operating company in the area of energy-supply. About 2000 employees are working on some 10 different locations in the Netherlands. The project is called 'Computerfacility Control' and the aim was to build an information system for: control and registration of all hardand software within the company. logical control over the computer network tracking and tracing of problem reports and maintenance actions At the start of the building of the information system the company had already made the following decisions: - the application will be build with SAS - as Database Management System DB2 un .... BSO/Management Support Zwolle 1 - 13 .,., 63 will be used the application will be build on an IBM-mainframe operating under MVS - management of the computer network on a logical level. registration and progress control on hardware defects. registration of (hardware) maintenance contracts. The Database Management System DB2 was chosen because- company policy prescribed that all corporate data had to be managed by DB2. SAS was chosen as development tool because of good experiences with SAS in earlier projects within the company. Users were satisfied with the user-friendly interface and the capabjlities of SAS~ Developers were satisfied with SAS because rapid application development was possible. 2.2 Dimensions Within the system 17.000 hard- and software components have to be registered. The . total value of these components is over ten million US dollars. The hardware equipment resides on some ten different geographical locations and there are some 1.500 employees working with or on the installed hard- and/or software. This paper starts with a brief description of the project 'Computerfacility Control'. After this description we'll discuss some of our experiences with·. SAS/AF in building the application. Then we'll discuss the difficulties we had to fight to get the interface between SAS and DB2 working properly. Based on our experiences with a version 6.06 SAS/DB2 application, this paper ends with a discussion of the possibilities of using version 6.07 for developing SAS/DB2 applications. 2.3 Datamodel When specifying the system on a logical level extensive use was made of the casetool Exceleratore • For Database administration this meant there was no difference between the deliverables from a project realised with COBOL/FORTRAN and our SAS project. The deliverables from Excelerator were used, next to building the Database, Storagegroups, Tablespaces, Datatables, views and indexes, for constructing an enterprise wide logical globaldatamodel. 2 PROJECT DESCRIPTION 2.1~ The goals of the project 'Computerfacility Control' are: - a good control over the process of request until delivery or iristaIment of hard- and software on the desktop. - registration of installed hard and software on the desktop. #1#' u .. BSO/Management Support Zwolle The Logical datamodel and the physical datamodel were developed with Excelerator. The physical datamodel consists of 27 data tables (Figure 8). The most important entities in the datamodel are: - Equipment. This entity contains all the specific hard- and software components. - Request. This entity contains all the 2 - 13 '#11 64 · requests for delivery and/or instalment of hard- or software. - Installation. This entity contains all the hard-and/or software components installed on an employee's desktop. Network. This entity contains all the connections of hardware within the computer network. - Hardware defect. This entity contains all the defects on hardware articles. - Contract. This entity contains all the maintenance contracts for (groups of) hardware articles Every data table has a primary key composed of one or more fields/columns. For performance reasons nearly every data table has one or more indexes defined on it. . Relations between the entities are defined by means of referential integrity rules. There are three kinds of referential integrity rules in DB2: * Restrict: Suppose you have a table called A on which a delete restrict relation is defined with table B. If you want to delete an occurrence from A whose key value still occurs in another table, then you will not be able to perform the deletion. E.g. an article type can't be deleted if there still are articles of this type. the value representing the maintenance contract code in the article table will be nullified. * Cascade: Suppose you have a table called A on which a delete cascade relation is defined with table B. If you want to delete an occurrence from A whose key value still occurs in B, these occurrences in B will automatically be deleted as well. E.g. If you delete an article the network information regarding this article in the network table is automatically deleted as well. ALTER TABLE Userid.T ONE FOREIGN KEY ( COLUMNNAME ) REFERENCES Userid.T TWO ON DELETE RESTRICT; Figure 1: Example ALTER statement The relations are defined in DB2 by means of an alter statement, like the one defined in Figure 1. From the physical datamodel Excelerator is able to generate all the necessary DDL statements for the database, the tables, the views, the keys, the indexes and the referential integrity rules. In chapter four we'll tell more about what is being handled by DB2 and by the SAS system in the application. * Set null: Suppose you have a table called A on which a delete set null relation is defined with table B. If you want to delete an occurrence from A whose key value occurs in B, then the values in the column in B will receive the value null/missing. E.g. If a maintenance contract is deleted, #1#' IU. !.!!.!. 3 SAS ANDDB2 As we explained earlier DB2 was the central database manager. All the data was stored there. DB2 also handles the integrity testing BSO/Management Support Zwolle 3 - 13 65 these problems. So before we had a working application on DB2 quite a number of adjustments had to be made to the application to overcome the problems. If no referential integrity from DB2 tro been us:rl most of these problems would not have occurred. for the referential integrity elements implemented in release 2.2 of DB2. This meant we didn't have to code out all kinds of database actions. They were specified in DB2. SAS was used to: * maintain the database (insert new, modify and delete records in the database); * generate reports; * clarify details, concerning an item in the database, stored elsewhere in the same database; * generate standard forms. 4 SASlAF AmlCA1I<:N DEVfl".OP. MENT As you can imagine this could have been done by COBOUFORTRAN. The SAS system was chosen because its speed of development, nice front-end, standard features that made real user friendly systems possible. Because the application was built by a team and to speed up development it was important to first create an environment in which development could take place in a structured way. This development environment was built using SASIAF and implemented the following functions (see Figure 2): 4.1 Development environment Initial coding of the application (first prototype) was done on SAS datasets. The reason was the physical datamodel from Excelerator wasn't finished yet. Next to that the intended users had to adapt to the new system. They previously discussed detailed design aspects of the system with the idea it would be build with Cobol at the start and later on with C. Because of the use of SAS certain aspects were to be realised in a different manner. After having build the complete application on SAS-datasets, the application had to be moved to DB2-tables. SAS Institute presents its software as data independent which means it presents a logical way of working with data and engines work out the details. Working with tables is fully transparent. If the SASI ACCESS interface to DB2 was fully transparent, the application should still be working after moving it to DB2. This was not the case however. During the development of the application we had already investigated the problems and difficulties in the interface to DB2 and had already thought of solutions and workarounds to overcome #1#' IU. !.m.. * Development: This function determines the library and catalog you're working on and creates the correct allocations. Within this function you can choose the kind of entries you want to access: programs, sourres, tables or screens. If for example programs is chosen, PROC BUILD is called. * Test: Here the appropriate AF-command is issued to start the initial entry of the application. It simulates the way the users who will be using the application will log on to the application. * Copy management: This function protects the integrity of program development as it prevents the possibility of several team members editing the same entry at the same time. This is done by moving (not copying) entries from someone's development library to the central test-level: if a developer wants to change a particular entry he has to copy it from the central test-level to his own BSO/Management Support Zwolle 4 - 13 66 library. During this copy-process the copy management program (also written in SASI AF) is flagged, indicating that the entry is being changed and nobody may copy the entry for change before the original developer has moved the entry back to the central test-level (compare IBM's LMFand SCL-utilities and Pansophic's PANVALET and PANAPT). 4.2 General structure After the development environment was created, the general internal and external structure of the programs was designed during the development of the first windows. The general internal structure contains the following labels: * Information: Her e the aVailability of any INIT: Initialisation of variables information soun:e necessary for development is organised. First of all it allows to look into the SAS Usage Notes. It also accommodates news which is important for the developer as well as access to a maintained 'bugs'-database for the application. MAIN: Checks which fields are modified and calls the corresponding labels. Also checks which command is given by pull-down menu, function key or push-button and calls the corresponding label * Documentation: This function generates tables with cross-references between programs, between programs and tables and between programs and macros. To generate these cross-reference tables a catalog listing is written to an external file. This file is scanned for certain strings, for example 'CALL DISPLAY'. The result of the scanning is put in cross reference tables with calling item and called ·item. The tables are used to generate cross-reference reports and to search directly for specific cross-references. TERM: Checks if modifications on the screen have been saved READ: Fetches a record for an entered key-value WRITE: Inserts a new record or updates an existing record after checking if all required fields haven been entered and after checking on relations between entered values (e.g. an end-date must be after a start-date) DELETE: Deletes a record _. IillIiI CHK < field> : Performs checks on entered value in a single field (if the key field has been entered, the READ-label is called; if the record doesn't exist it is presumed that the user wants to enter a new record • • Figure 2: Development environment <command>: Executes command given by user #1#' ,u. "#1 . BSO/Management Support Zwolle 5 - 13 67 This division into well defined labels, results in a modular construction of programs. The 1abe1s (rnocIUIes) for field-dxW and oommands can easily be used in other programs were the same fields or commands are used. This speeds up building of the application. The modular approach also makes it easier to understand the programs and therefore makes future maintenance easier. To have a universal interface to the user throughout the whole applicatioo, al9J a general external structure was decided on: * block-menu's: The two highest levels of the application consist of block-menu's. By choosing from the menu's the user can go to the desired window. * function keys: One set of function keys is defined for the whole application. Each window uses this set of function keys. If a key is not used in a window, there is just no < oommand > -Jabel for it So nothing happens in the window if that key is pressed. * pull-down menu's: Besides function keys, pull down menu's are made available to operate the application. The general structure of the pull-down menu's is the same in each window (see Figure 3) and is conform SAA/CUA. Fouritemsar~distinguished: operations on the database (insert, update, delete) - local: local options - global: global options - help: help screens PROCPMENUCAT=lib.appIDESC'Pmenuonsomeacreens' MENU M2BOP004; ITEM ITEM ITEM ITEM 'File' MENU = tile; 'Locale' MENU = locale; 'Globale' MENU = globale; 'Help' Selection = help; SELECTION End 'End' SELECTION Cancel 'Cancel' SELECTION Help 'Help' SELECTION Delele 'Xdelete' SELECTION Save 'Xsave' SELECTION Input 'Xinput'; SELECTION Rows 'Rows'; SELECTION Info 'Info'; SELECTION Prinl 'Xprint' SELECTION Selc.:t 'Select'; SELECTION SeIUp 'Setup'; SELECTION Shoo"kcys 'Showkeys'; SELECTION Report 'Report'; MENU File; ITEM 'Delete' ITEM 'Save' ITEM 'Cancer ITEM 'End' SELECTION = delete; SELECTION = save; SELECTION = cancel; SELECTION = end; MENU Locale; ITEM 'Input' SELECTION = input; SELECTION = rows; ITEM 'Rows' ITEM 'Info' SELECTION = info; ITEM 'Print' SELECTION = print; ITEM 'Select' SELECTION = select; MENU Globale; ITEM 'Setup' SELECTION = setup; ITEM 'Keys' SELECTION = showkcys; ITEM 'Reporting'SELECTION = report; RUN; ~UIT; Figure 3: Pull-down menu file: Each window has it's own pull-down menu. * push-buttons: In simple windows pushbuttons are used instead ofpull-<lown menu's. Mostly there are only three buttons: OK, GOBACK and HELP. #.#. BSO/Management Support Zwolle * selection list: On all fields where you can enter only a limited number of values, it's possible to enter a '1' and then a selection list appears in which a value can be chosen. Mostly ~ selection lists contain the contents of a table. With all above mentioned features offered by SASI AF a strong, user-friendly interface with great possibilities was built. The result 6 - 13 I'" ",. 68 was an application on an IBM-mainframe which looked like a PC-application. code out of a table - macro to put a selection list on the screen if a '1' is entered - etc. 4.3 Macros To speed up development and to stimulate standardisation much use has been made of macros. The macro-definitions are stored in separate source entries. To generate the macros, a special program is automatically started when SAS is started (see Figure 4). All macrodefinitions are copied to the.preview buffer and then submitted. If a new macro is developed (or an existing macro is changed) all that has to be done is to put the name in the array and start the program again. An example is given in Figure 5. The macro GETDESC gets the description for an entered code out of a table. The macro is called with a type-parameter (C: character; N: numeric), a dataset name, the name of the code variable, the value of the code and the name of the description variable. Depending on the type (C or N) the dataset is opened with a whereclause. If a record is found, then the description is put on the screen, otherwise the cursor is put on the code-variable that lights up red, an alarm is given and a message is generated by calling another macro with an error number. %MACRO GeldeSC:(lype, dsn, value, c:olvar, ARRAY names {.} $ 8 ('Mread', 'Mwrite', 'Mdcle!e' 'Menor', 'Mc:hkblnk', 'Mc:hkquo'); INrr: CALL PREVIEW(,CLEAR '); DO i = I TO DIM(names); rc: = PREVIEW(,COPY', 'lib.appl. II namel(i}); END; SUBMrr CONTINUE; ENDSUBMrr; MAIN: TERM: RETURN; SC:rVlf, field); &sc:rval = _BLANK_; IF &value = _BLANK_ THEN RETURN; %IF &value = N %THEN %00; dsidl =OPEN("appl.&dsn(WHERE=(&where= "II &valuc II '1'); %END; %ELSEDO; dsidl = OPEN("appl.&dsn(WHERE=(&where='· II &vw II "'»", 'I'); %END; IF dsidl < = 0 THEN 00; %msg(12); RETURN; END; rc: = FETCH(dsidl); IF rc: = 0 THEN 00; &src:var = GETVARC(dsidl, vamum(dsidl, ·&c:oIvar"»; END; ELSE DO; &sc:rvar = _BLANK_; ERRORON &tieJd; ALARM; CURSOR &tieJd; END; rc: = CLOSE(dsidl); %MEND; "»", Figure 4: program generating macros In building the application some 15 different macros where used. Most of them were used for error-message handling and for field-input handling: - macro to generate an error-message given an error number - macro to put an error-message on a pop-up screen - macro to check the existence of an entered value in a table - macro to get the description for an entered Hii" un BSO/Management Support Zwolle Figure 5: Macro Getdesc At this moment everything was ready to build the application: a development environment was created, the general internal and external 7 - 13 !.!!1.. 69 Integrity) properly then your application software is bad, and the developing company no good" . Once this rumour starts spreading in the organisation, you might as well stop developing. To get around this problem we used PROC DBLOAD to update DB2 tables directly. Three separate SCL programs were made for inserting, updating and deleting (see Figure 6). Instead of INSERT(dsid), APPEND(dsid) and DELOBS(dsid) the SCL programs are called. The SCL programs are called with strings which contain the variables, the values and a where-clause. By updating DB2 directly however, synchronisation problems occurred between the SAS-view and the DB2table. To synchronise again, the SAS-view was closed and opened after each update of the table. structure of the windows were designed and the macros were generated. The application was now in little time completely built on SAS datasets. In this way we avoided interference between building the application and solving interfacing problems with DB2. 5 PROBLEMS AND SOLUfIONSI WORKAROUNDS 5.1 Referential inteerity Problem: Because of the use of primary keys and referential integrity rules in DB2, updating of a table is not possible if you were using the SCL functions UPDATE. The return code -535 was ~ back by DB2, implying that it's not allowed to update a primary key column with an 'UPDATE WHERE CURRENT OF CURSOR', even if one did not change that column (problem ENTRY rc 2 table $ 80 ...ilerecl $ 200 selcll $ 200 OPTIONAL = seld2 selcl3 $ 200; is registered in nlllTiJer V6-FNGINE0765 of the SAS Usage Notes). INIT: SUBMIT CONTINUE; PROC DBLOAD; ssm = &db2ssid; SQL UPDATE &table SET &selcll &selct:2 &setcl3 WHERE &wherecl; RUN; QUIT; ENDSUBMIT; rc = SYMGETN('syserr'); MAIN: TERM: RETURN; Solution: The solutions suggested in the SAS Usage Notes were not useful. Not using the primary key in your ACCESS descriptor and view descriptor would lead to the situation where you would not have a identifier for your observations or records. You might duplicate the primary key but then you would have to put the burden of keeping the primary key fields and their duplicates equal in all situations. Try telling that to the DB2 administrators. Their reaction will be and was: "If your system is not able to handle this (referential ##1' '#I' ,,#. BSO/Management Support Zwolle Figure 6: Source of SCL program for updating 5.2 Lockine Problem: DB2 doesn't have, next to Page lock and Tablespace lock, an option 8 - 13 70 of Read Lock is No lock like for instance INGRES e does. A Read Lock results therefore always in a Share Lock. Normally this is not a problem, but in our application much use is made of selection-lists that contain the contents of a table. This results in a Share Lock for the whole table, so no-one else can update the table during the time someone has a selection list open. still not good enough. To improve the performance, special multi-table views were created in DB2 for the multi-table queries. Perfonnance increased considerably because the DB2 optimizer performs much better than the SAS optimizer. 5.4 Commit I Rollback Problem: SAS does not manage COMMIT and ROLLBACK the same way as DB2. After every PROC DBLOAD automatically a OOMMIT is given. It's not possible to have a ROLLBACK to an earlier state of the database if an error occurs somewhere in a series of related actions updating the database. Solution: Before a selection-list with the contents of a table is shown, the table is copied into a temporary SAS-dataset. The selection-list is then opened on this temporary dataset. The only drawback is a little loss of performance, because the copying takes some time. Consequence is yOu cannot presave the integrity of the database. 5.3 Performance Solution: In the application most updates on the database were single actions on one table. In this case there is no problem. In case of a series of related actions on more than one table the actions were put in a particular order, so that recovering the integrity of the database was possible in case of errors. For instance if an insert in roe table was 00upkrl to an UJXIale in another table, the update was done first. In case the update went Problem: Performance of the system was rather poor, especially if data was needed out of two or more tables via a SQL-join. Solution: The first action was the placement of a ZAP known as Z-606-0651. Normally if a SAS-view is opened SAS first generates a SELECT COUNT(*) to get the number of records in a table. This SELECT COUNT(*) is rather bad for the performance and in most cases it's not necessary to know the number of records. The ZAP prevented the generation of a SELECT COUNT(*) and thus improved the performance. wrong the dataha~ was still integer. In case the insert went wrong, the user could start the action again. To maintain the integrity of the database as much as possible, extensive error-messages were given telling the user exactly what to do. The use of referential integrity rules Now the perfonnance on single-table queries was good. The perfollllance of multi-table queries however was Hii' .... BSO/Management Support Zwolle 9 - 13 !!!!. 71 The date value in SAS also is not the same as the date value in DB2. These problems occur when using PROC DBLOAD. made the problem also smaller. Some related actions on more than one table were performed by the referential integrity rules, for instance the delete cascade: one PROC DBLOAD rermving a reoord awses DB2 to automatically remove related records in another table. The solution adopted above is far from perfect, but there is no alternative in version 6.06. Solution: Before an update of a DB2 table is done by a PROC DBLOAD, the missing value for a numeric variable is converted to NULL and the SAS date value is converted to a DB2 date value. 5.5 DB2 Error-handlina= 5.7 Access and view descriptors Problem: If something goes wrong in updating Problem: Acces and view descriptors have DB2 with PROC DBLOAD only a return code 4, 8, or 16 is returned to indicate something went wrong. The DB2 return. code is not available, so it's impossible to give an error message telling exactly what went wrong. to be created interactively for each separate database (development, test and production-database). In SAS variable names can only be 8 characters long where-as variable names in DB2 can be 18 characters long. Solution: During development the exact DB2 return code and message can be Solution: For the first problem there is no solution, so it just means a lot of found in the LOG-window. To the users we only gave a general error-message. A possible solution would be to extract in some manner the DB2 message out of the LOG-window and display it to the user. This is however only useful if the user has some DB2 knowledge so he can understand the messages. extra work. For the second problem we created DB2-views with variable-names of only 8 characters long. 5.8 Security Problem: All users of the application need Update-, In.sert- and Delete-privileges for the DB2 tables. If a user can leave the application he can update tables straight-away without any checks normally made by the application. 5.6 Null value I date value Problem: The missing value for a numeric variable in SAS is not the same as the NULL value in DB2 because the SAS missing value is not conform to the specifications of the ANSI-2 standard. .,.. ##1' .UI Solution: When a users starts the application he doesn't get in SAS but goes straight to the application. All command-lines within the BSO/Management Support Zwolle 10-13 72 application haven been replaced by pull-down menu's or pushbuttons, so no user can get out of the application during normal operation. To prevent getting a command-line in case of errors in th: awficatioo, th: qXioo ERROR ABEND is active. tables had to be prefixed with 'T_' and views with 'V_'. We used DB2 synonyms and DB2 views on DB2 views to be able to use the same table and column names when working with DB2 tables via ego PROC SQL and PROC DBLOAD; SQL ..... There are no entries in the 'SYSffiM.SYSCOLUMNS' table for a synonym nor for a view. The key field column is empty beaUJse you can't declare a primary key on a view or synonym. The way to find out what the primary key is on a table referenced via a view and/or synonym is combining information etc from a diversity of DB2 catalog tables which tell you how views relate to views and tables. You can also find out to which table or view a synonym refers. The relationship between one column in a table or view and an other view, however is hidden in the parse tree information stored in DB2 catalog tables like SYSmM.SYSYTREE. Initial testing suggegs further research by the Institute. To solve all problems concerning the interfucing to DB2 a lot of adjustments in the application were necessary. Now an advantage of the use of macros became visible. Because some of the problems could be solved by adjusting the macro's, we didn't have to go through all the programs to make the same adjustment everywhere. After adjustment of the macro's, all the programs were compiled again. Nevertheless it's clear that the SAS/ACCESS interface to DB2 in version 6.06 is not as transparent as it should be for full SAS/DB2 business applications. 6 SASlDB2 6.fY1 AND 1lIE FUIlJRE 6.2 SOL-passthroueh facility This facility addresses part of the problem described in paragraph 5.3 (the part about multiple table queries). It will make obsolete some 25 DB2 views which had been constructed for performance reasons. These views had been created and are maintained by the Database Administrators. The application is referencing these views. These views hide information about what is being done inside the application and for that reason it is recommendable to remove them. Furthermore it will make efficient combining of information from SAS tables with information stored in DB2 possible. Next to this with 6.07 it will also be possible to submit directly to your DBMS. This means an alternative to PROC DBLOAD; SQL .... If you submit to your DBMS, you will not automatically have a COMMIT 6.1 Referential inteerity support in SAS The need for referential integrity support is already known through presentations during user conferences. This would help solving the problem described in paragraph 5.1. The Institute investigated the problem and found a solution implemented in release 6.07. The Institute says there is only one drawback: You will need read authorization on the DB2 catalog. To be more precise the table 'SYSmM.SYSCOLUMNS' beaUJse in it you can see for a table which columns are in the primary key. This procedure is working well if the table you are updating is a table. In our situation they are not. BecauseofDB2 standards, updating is never done on tables but only on views. DB2 #.#. lUI m.!. BSO/Management Support Zwolle 11 - 13 73 WORK or ROLLBACK WORK. See also next paragraph. 6.3 Macro variables with DB2 With release 6.07 the_application is able to receive a completion code (SQLCODE) and error messages back from DB2. Because of this it is possible to solve the problems discussed in paragraph 5.4 and 5.5. It is also possible to realise even more complex database transactions. E.g. create a function to rename a key in one table. This function doesn't only update this table, but also a set of other tables. In Figure 7 we describe %MACRO update; EXECUTE (UPDATE tablel) BY DB2; %IF &SQLXRC = 0 %THEN %DO; EXECUTE (UPDATE table2) BY DB2; %IF &SQLXRC = 0 %THEN %DO; EXECUTE (UPDATE table3) BY DB2; %IF &SQLXRC = 0 %THEN %DO; EXECUTE (COMMIT WORK) BY DB2; '.lEND; '.lELSEDO; EXECUTE (ROLLBACK WORK) BY DB2; '.lEND; %ELSE DO; EXECUTE (ROLLBACK WORK) BY DB2; '.lEND; %ELSE DO; EXECUTE (ROLLBACK WORK) BY DB2; %END; '.lMEND; 6.4 Creatin2 descriptors in batch Back in version 6.07 is the possibility to generate ACCESS- and VIEW descriptors in batch. This will address the problem in version 5.7. With the use of extra views in DB2 we can map long DB2 names to names with maximal 8 characters. 6.5 Dynamic VS. Static SOL SAS uses for its interface to DB2 Dynamic SQL. This is the easiest way for the SAS software developers. In this organisation there is a strong resentment against Dynamic SQL for business applications. Static SQL is preferred, because modification of the database can be controlled by granting on a plan. Next to that Static SQL outperforms Dynamic SQL. A question to investigate is whether utilities to build static SQL "Access descriptors/view descriptors" in future releases might be possible. Without it possible application of SAS Software might be refused where as it has shown to deliver applications that, especially where user functional satisfaction is concerned, beats languages like COBOL and FORTRAN. Figure 7: Multi table up9ating macro a macro that will need a parameter list defining the old values that will be replaced by new values. The macro updates the first table. If this action succeeds the second table is updated. If not, a ROLLBACK is issued and no more update actions will be carried out. If the last table update action is oomplcted soccessfully a COMMIT WORK will be issued. #.u ,." BSO/Management Support Zwolle "f' 12 - 13 74 Figure 8: Datamodel schema The authors wish to thank among others Jan Westra and Mariet Smeets for their work on the project. If you have any questions or comments regarding this paper, you can contact the authors by writing to the following address: BSO/Management Support Zwolle B. V. Dr. Stolteweg 58 Postbus 30164 8003 CD Zwolle The Netherlands phone: +31 38 533388 Fax: + 31 38 533427 SAS·, SAS/~, SAS/ACCESS· are registered trademarks and SAS/DB2- is a trademark ofSAS Institute Inc., Cary, North Carolina. USA DB2- is a trademark of International Business Machines Corporation, Armonk, New York, USA INGRES· is a registered trademark of ASK Ingres, Alameda, California, USA Excelerator· is a registered trademark of Index Technology Corporation, Cambridge, Massachusetts, USA nn . .I f BSO/Management Support Zwolle ~ 13 - 13 75