Download Development of a SAS/DB2 Business Application

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