Download Using SAS/ACCESS Software with PC Files and Databases

Using SAS/ACCESS® Software with PC Files and Databases
Forrest Boozer, SAS Institute Inc., .Cary, NC
ABSTRACT
EMPLOYEE Table
This paper discusses the SAS/ACCESS® software products
EMPID
FNAME
LNAME
DEPT
available under OS/2® and Microsoft Windows and describes the
way the products work in both environments. The paper explains
001
Henrietta
Hacker
ISO
020
Sammy
Slick
MKT
003
Justin
Doit
CEO
the differences i)etween the interfaces for DIF files, DBFfiles,
Database Manager, and AS/400® Data and demonstrates how to
use them efficiently. Plans for future enhancements to the
SAS/ACCESS products for pes are also discussed.
.
Salary Table
INTRODUCTION
The explosive use of pes in today's workplace has been a mixed
blessing. Everyone from administrative assistants to chairmen of
the board have pes on their desks. Often these users have the need
to access data from the corporate, departmental, workgroup and
personal levels of the organization. Frequently these levels of data
are organized and administered by different people within the
bUsiness organization. For example, corporate data may reside on
an AS/400 that is administered by ISO; departmental data may be
managed by the department's" PC Expert" and reside in OS/2
Database Manager or dBASE IV; personal data such as sales leads
or expenses may be maintained by the individual in a spreadsheet
such as Lotus 1-2-3.
EMPID
SALARY
BQNUSCOD
001
35,000
020
30,000
t
003
120,000
10
The EMPLOYEE table Simply contains the names, employee IDs
and departments for all employees in a company. Because of the
confidentiality of salary information it is kept in a separate table,
SALARY, so that access to the information may be restricted.
In the EMPLOYEE table, the EMPIO column contains numeric
values representing employee ids. The FNAME, LNAME and DEPT
columns are character and contain the values for the first names,
last names and departments of the employees.
At some point, an individual or org'anization within the business may
need'to collect and analyze data from these disjoint database
systertls Of write an application that allows users seamless access
to the data. The SAS® System provides applications programmers
and users with a vast number of development and analysis tools
for manipulating data while the SAS/ACCESS products allow these
tools to be used on data stored in non-SAS files or database
management systems (DBMSs).
In the SALARY table all columns are numeric. As in the EMPLOYEE
table, the EMPID -column contains employee IDs. The SALARY and
BONl)SCOD columns contain the salary and the bonus code that
the employees are to receive.
There are basically two different types of SAS/ACCESS interfaces
available on the PC platform. The first interface type simply reads
a file of a specific format. The second type actually makes calls to
a DBMS which in turn directly manipulates the data under its control
and returns results of queries to the interface.
FEATURES OF A SAS/ACCESS INTERFACE
A SAS/ACCESS interface may have any number of features 'and
abilities. In Release 6.08 of the SA'S System, a full featured
SAS/ACCESS product will have ~e following components:
The advantages and disadvantages of each interface and type of
interface will be discussed in this paper. However, some things are
common regardless of the interface you are using. This paper will
take advantage -of the common thread between the interfaces. First
a model of a full featured SAS/ACCESS product will be presented
at a functional level. Then the properties that are common within a
specific interface type will be presented followed by a discussion of
the unique properties of each interface of that type.
• ACCESS Procedure
o non-interactive descriptor creation
o interactive, window based descriptor cre~tion
o data extraction
• DBlOAD Procedure
o non-interactive table creation
EXAMPLE DATA
o interactive, window based table creation
The examples given in this paper will be used to illustrate a single
feature or attribute of an interface. Because the illustrations are
narrow in scope, the sample data will be used repeatedly where
ever appropriate. Forexample, the EMPLOYEE table may be a SAS
data file in one example and a DIF file in the next. The following
tables are used for the examples in this paper.
o access descriptor creation
o Sal statement
• Interface View Engine
o read-write data access
o Sal Procedure Pass-Through Facility
Each of the major components above may support the features
listed below them. !-lowever, a component for a particular interface
may not support all of the possible features: Every interface consists
of at least the ACCESS Procedure and Interface View Engine
components.
179
engine and SQl procedure are then able to dynamically process
the information returned from the DBMS.
ACCESS Procedure
The basic function of the ACCESS procedure is to provrde the SAS
engine supervisor and the interface 110 engine with information
concerning the location and type of data to be retrieved from an
external source. This information is stored in SAS descriptor files.
There are two types of descriptor files, access and view.
CHARACTERISTICS OF A PC FilE INTERFACE
A PC file interface is simply an interface that reads a specific file
format. The products that create these files typicarly have no
method by which the SAS System can call them to retrieve data.
The only access to the data is by accessing the file directly without
regard for the program creating the data. This method of acceSSing
the data is especially useful when the data has been exported from
a "non-DBMS" program such as a spreadsheet or'personal
scheduler that does not use DBF or DIF files as the native method
of data storage.
All descriptors contain identifying information such as database and
table name or filename, column names and types, and the SAS
variable names and formats that correspond to the columns in the
table. However, access and view descriptors differ in usage.
An access descriptor can be considered a master descriptor
containing a complete description of a single data source. It is
created by first identifying where and how the data is stored to the
access procedure. The procedure then looks at the data to
determine the names of the columns or fields and the type of data
that they contain. It may also generate default SAS variable names
and formats corresponding to each column. You then have the
ability to further modify the access descriptor by changing SAS
names and formats and dropping columns from the descriptor so
that they can not be accessed by the SAS System.
The lack of the ability to call a programming interface to retrieVe data
presents a problem for storing subsetting information in the view
descriptor. Typically in aSAS/ACCESSinterface, DBMS specific
clauses such as WHERE and ORDER BY may be entered into the
Selection Criteria Entry Window. The clauses entered into this
window are theh passed down to the DBMS to filter and order
records which will be returned to the SAS System. It is impossible
for a PC file interface to do this because the engine-reads'the data
directly from the file itself. However, the ability to subset the records
returned from a view descriptor is very 'desirable. To accommodate
this ability, a SAS WHERE clause may be entered into the Selection
Criteria Entry window and stored in the view descriptor. When the
view descriptor is used in a SAS program the WH ERE clause is
given to the SAS engine supervisor (which makes the calls into the
interface view engines) so that it will filter records as they are
returned from the engine before giving them to a SAS procedure
or data step. The figure below illustrates the flow of data between
a SA~ procedure and PC file.
A view descriptor contains a subset of the information in an access
descriptor, These descriptors are created based on the information
stored in an access descriptor j not by direcUy querying the source
of the data. You have the ability to select all of the information that
is made available to the SAS System in the access descriptor or
to select only a few of the columns. In addition to selecting columns,
specific rows may be selected ~y specifying a WHERE clause 10
be stored in the view. Each time the view is referenced in a SAS
program this WHERE clause is used to filter the records being
returned to the SAS System.
The ACCESS procedure for all PC based SAS/ACCESS interfaces
has the ability to create these deSCriptors using interactive windows
and to extract external data into a SAS data file. Optio'nally, some
SAS/ACCESS products have the ability to crea~e descriptors
non-interactively using procedure statements.
I SAS Procedure I SAS System
W /'-
DBlOAD Procedure
The primary function of the DBl(.)~D procedure is to create tables
or files in an external data source' and load them with the data from
a SAS data file or view descriptor. The creation of these tables or
files may be done interactively or non-interactively using either
DBlOAD procedure windows or statements.
I
Engine Supervisor
,1/ /1'
I Interface Enginek .
In addition to creating external data, the DBlOAD procedure is able
to create access descriptors for the tables and files that it creates.
Optionally, PROC DBlOAD for a particular SAS/ACCESS product
may be able to pass non-query SQlstatements to the DBMS.
These statements may be useful for dropping tables, creating
indexes on newly loaded tables or granting database permissions.
Not all SAS/ACCESS products support the DBlOAD procedure.
/
,
View
Descriptor
,
PC File
Interface View Engine
All SAS data sets and views access their data through engines.
Each SAS/ACCESS interface provides an engine that allows the
SAS System to direcUy access data in an external source without
first extracting it into a SAS data file.
Data flow between a SAS Procedure and PC file
Unfortunately there is no method by which ordering information can
be stored in the view descriptor of a PC file interface.
Use of the engine is transparent in a SAS program. Anytime a view
descriptor is used with a data step or procedure, the interface
engine is loaded and used to access the actual data. All interface
view engines provide ~t least read access to external data. Most
view engines provide write access to the data ~ well.
PC File DBlOAD Procedures
The DBlOAD procedure for PC files contains all of the features of
the standard DBlOAD procedure described earlier with one
exception. Because this interface operates at the file level, with no
DBMS to handle SAS System requests for data manipulation, the
PROC DBlOAD SOL statement is not supported.
In addition to providing data access via view descriptors, some
interface engines support the SQl Procedure Pass-Through
Facility. This facility allows you to specify both query and non-query
SQl statements that are passed directly to a DBMS. The interface
180
THE DBF FilE INTERFACE
carries very little information about the data it contains other than
the data itself. There is a header portion of the file which typically<
only contains the number of vectors (columns or vari'ables) and
tuples (rows or observations) that are contained in the file. Only two
types of data, character and numeric, are supported in the file.
These data tYpes may be intermixed within the same vector just as
they might appear in a spreadsheet. All data values in a DIF file are
stored in ASCII format with each individual value represented using
two variable length records. For example, the figure below displays
a single record for the employee SAMMY SLICK from the
EMPlOYEE.DIF file.
The SAS System interface to OBF files is available in the
SAS/ACCESS Interface to PC File Formats. This interface contains
PROC ACCESS, PROC DBlOAD and an Interface View engine.
DBF files are database files created by several PC based database
products, the most notable of which is dBASE. The format of a OBF
file is fairly structured. It contains a header section containing
descriptive information about the data within the file. Data records
within the file are organized in a rectangular manner following the
header information. All data, including numeric values, are stored
as the ASCII character representation aftha value. A number of
data types including date, numeric, float, characteJ and logical
are, supported in the SAS/ACCESS interface. However, because
the, data for a memo type field does not actually exist within the OBF
-1,0
BOT
O,2.000000000000000E+01
file it is not supported.
V
Another property of OBF files is that each data record is preceded
1,0
by asingle byte indicating whether or not the record has been
marked for deletion. Marking a record for deletion does not actually
remove it from the file. A separate utility must be executed to
remove the "deleted" records.
• sammy·
1,0
"Slick·
1,0
"MKT"
DBF FU~. ACCESS Procedure
The ACCESS procedure for OBF files is fairly uncomplicated
because the header information describes the fields contained in
the file. All that is required for the ACCESS procedure to obtain a
description of the file is the name of the file itself. The ACCESS
procedure reads the header information of the file and may create
default SAS names and formats lor each of the fields in the file.
OIF File ACCESS Procedure
The process for describing DIF file data is unique among PC based
SAS/ACCESS products. These differences are based on the DIF
file's association with spreadsheets. Frequendy both character and
numeric data are intermixed in the same column, this mixing is
reflec~d in the DIF file as well. Additionally, column names (labels)
are not part of some global header information, but rather are part
of the data itself. Thus, column names are indistinguish~ble _from
column data. To accommodate these file ,characteristics the
ACCESS procedure for DIF files give you the ability to direct and
customize the creation of access descriptors beyond providing the
filename and assigning SAS variable attributes.
In addition to the fields defined in the header of the_ OBF fiola, the
ACCESS procedure also treats the field that marks records for
deletion as adata field for the file, This gives you the ability to
associate a WHERE clause with the view descriptor th.at can filter
"deleted" records so that they are not used by SAS procedures.
OBF File Interface View Engine
You may .provide the ACCESS procedure with two pi£:lces of
information that determine the default names that will be associated
with the columns in the file and the row in the file that will be
considered the first row of valid data. By default, the ACCESS
procedure will generate column names in the form of COLO,'COl1,
COL2, ... for each of the columns represented in the DIF file and
will treat the first row in the file as the first observation. Typically
though, the .first row of these files will contain a row of character
values labeling each column. This row of labels may also be
separated from the actual data values by one or Il}.ore rows that
somehow further' distinguish them from the d.ata. On the .DIF File
Access Descriptor Identification Window you may indicate that the
first row of the OIF file should be treated as column names and how
many rows to Skip before the actual data begins. For -example, you
have a spreadsheet with column labels in the first row followed by
ablankrowwith actual data beginning inthethird row. To geta
proper descrip~jon of this file, you should ,indicate that column
names should be generated from the fir&t,row and that two rows
should be skipped before the actual data begins.
The interface view engine for OBF files supports reading, writing
and updating of records. Another feature of this engine that may be
advantageous in some applications is its ability to randomly access
records within the OBF file based on record number. In other words,
if you are using the FSEDIT procedure and want to read observation
2045 the en,gine can calculate where in the- file that record begins
and then position itself on it without reading any other records in the
file,
There are several other things that should be noted about the
engine that are due largely to the lack of a callable programming
interface.
rvtIltiple users are able to open the same DBF file for read access
using the engine. However, when the file is being opened for update
access, an exclusive lock is placed on the file and only,the user
opening the file for update will be able to access the file,
dBASE and other products using OBF files for data storage can
create index fi!$S that their products use to quickly access specific
rows ,of data or to return rows in a specific order. Because the OBF
files themselves do not contain information concerning the
existence or location of the index files created on them the interface
engine cannot·take advantage of these files.
An additional enhancementto the .DIF File Aocess Descriptor
Display window in Version 6.08 of the SAS System is the ability to
change the column types from that determined by the ACCESS
procedure. The ACCESS procedure will read the first row of data
(after skipping the number of rows indicated on the .DIF File Access
Descriptor Identification Window) and use the data tyPe olthe
valu$S in that row as the expe~d type for the values in following
rows. This method for deten:nining column types i$- at best an
educated guess for several reasons. First, OfF,files allow the
intermixing of data types within the same column. The column type
in the first row may not be the same as the predominant (or desired)
THE DIF FilE INTERFACE
The SAS System interface to OIF files is available in the
SAS/ACCESS Interface to PC File Formats. This interface contains
Proc ACCESS, Proc DBlOAD and an Interfa~ View engine.
The structure of the DIF file itself is somewhat free form and typically
181
type. Also, jf no data has been entered for several columns at the
end of the first row, the DIF file may contain absolutely no
information concerning those columns forthatrow. When this
occurs on the first row of data, the ACCESS procedure will by
default expect the values in those columns to be characters. You
may change. the column type from that determjned by the ACCESS
procedure simply by changing "C" (character) to "1>1" (numeric) or
vice versa for the individual columns that are incorrect.
character column will be returned to the SAS System as the
character representation of the number rather than a missing value.
DIF File Date & Time Values
Date values are a speciai case in DIF files because there is no date
data type, only character and numeric. However, lotus 1-2-3
software does allow you to enter and display date values on a
spreadsheet. These vaiues are stored as a numeric representation
of the date'and are written to the DIF file as a numeric value.
However, the Lotus 1-2-3 numeric representation of a date differs
from that of a SAS software date or datetime value. So, the numeric
date value must be converted between the SAS System
representation and the lotus representation in order to be
meaningful. The DBlOAD procedure and view interface engines do
this automatically for all numeric variables which have a date, time
or datetime SAS variable format.
DIF File DBLOAD Procedure
By default the DBlOAD procedure begins loading data directly in
the first row ofthe DIF file. No information about SAS variable
names or labels is written to the file. You may indicate that the SAS
variable names or labels be written to the first row of the DIF tile
on the .DIF File load Identification Window or by using the
DIFLABEl procedure statement. When this feature is used, a blank
row is automatically written after the labels to differentiate them from
the actual data which will begin in the third row. The tables below
illustrate the difference in using the DIFLABEl feature when loading
the employee data set.
001
Henrietta
Hacker
ISD
020
Sammy
Slick
MKT
003
Justin
Doit
CEO
CHARACTERISTICS OF A DBMS INTERFACE
The second type of SAS/ACCESS interface available on the PC
platform is an interface to a database management system. In these
interfaces. the data is completely controlled by the DBMS. The SAS
System makes requests of the DBMS which in turn accesses data
and returns information. The relationship between the interfac;e and
the DBMS provides for a number of additionaUeatures in these
SAS/ACCESS interfaces. The figure below iIIustrate~ the flow of
information between the elements of the SAS System and a DBMS
data_ source.
Data loaded into the EMPLOYEE.DIF Iile without DIFLABEL.
EMPID
FNAME
LNAME
DEPT
I SAS Procedure I SAS System
001
Henrietta
Hacker
ISD
020
Sammy
Slick
MKT
003
Justin
. Doit
CEO
,1/
i
/1'
I Engine- Supervisor
,I
W /1'
View
Descriptor
I Interface Engine
Data loaded into the EMPLOYEE.DlF Iile with DIFLABEL.
,V
DIF File Interfa!Ce Yiew Engine
The unstructured· nature of DIF files forces some restrictions on the
interface view engine. The most notable restriction is that the engine
is read-only. Also, the engine is not able to calculate where a
particular record will begin 'or end. This prevents the 'engine from
being able to jump directly to any requested observation or to the'
previous record. Instead, the erigine must positidn on a known
record prior to the requested record'and read forward until the
desired record is found. This problem can be quite 'obvious when
scrolling backward tJsingthe FSBROWSE procedure oil a large DIF
file. Each time that you scroll backward, the'engine must -repOSition
on'the first reco'rd and then read each record until the previous
record is read. This repositioning can cause a noticeable delay,
especrally if you are positioned somewhere well beyond the
beginning of the file.
I
DBMS
t=
Data
/
E)(ternal
Data
Source
Relationship between SAS Procedure, SAS/ACCESS Interface,
DBMS and the data
Currently on the PC-piatform.all of the DBMSs that are being
accessed are relational databases. Typically relationa1 data is
stored in rows and columns of a table within a database. The
actual file structures that the DBMS uses for storing and organizing
this data is unknown to applications other than the DBMS itself.
These products- use SOL as their primary data manipulation
lan-guage. Generally, this allows an interface to build Sal
statements for selecting, updating and inserting data. Additionally,
statements for administering the database suoh as granting
permissions and creating indexes may be passed to the DBMS.
Any time the engine encounters a data value whose type does not
match that expected in the view descriptor, that vaiue is treated as
a-missing value. For example, if a numeric value is found in a
column that is expected to contain character values only, it will
become a missing value. However, because the produ"ct that
produced the DIFfile allowed the intermixing of data, itmay be
advantageous for you to view the data in a'-SAS procedure without
having these numeric values converted to missing. In Release 6.08
of the SAS System this can be accomplished by setting an operating
system environment variable DIFNUMS to YES in your contig.sas
file. When DIFNUMS is YES, ail numeric values encountered in a
Selecting and Ordering DBMS Data
The SOL SELECT statement allows a WHERE Clause to be used
to filter the rows that are going to be returned from a table.
Additionally an ORDER BY clause may also be appended to it to
cause the rows to be returned in a specific order. The SAS/ACCESS
182
interfaces allow you to take advantage of these clauses in several
ways.
two clauses are logically ANDed together so that the data returned
must meet both criteria.
First, whenever a SAS WHERE or BY statement is used in
association with a view descriptor, the statement is translated into
a DBMS specific WHERE or ORDER BY clause and appended to
the SELECT statement generated by the engine. The translation of
the SAS statement typically requires changing SAS variable names
to DBMS column names and, in WHERE statements, changing SAS
specific expressions to logically equivalent DBMS expressions.
Accessing Specific DBMS Rows
When a DBMS processes a SELECT statement, it determines the
rows that meet the WHERE criteria and return those rows to the
application. Rows are not guaranteed to be returned in any specific
order unless an ORDER BY clause is specified on the SELECT
statement. In addition, there is no way to indicate to the DBMS that
the Nth row satisfying the statement should be returned. This
situation presents a problem for DBMS view engines similar to that
of the DIF File engine. There is no way for the engine to access a
specific row number Without fetching eaqh record that satisfies the
SELECT statement until the desired row inumber is found. For this
reason, scrolling backwards in a full screen procedure like FSED1T
may encounter a delay when compared to scrolling forward. Moving
forward simply causes the engine to fetch the next row from the
DBMS. Moving bacKward means that the current SELECT
statement must be closed, reopened and each row fetched until the
previous record number is found.
For example, the view descriptor VIEWLIB.SALARY is based on the
Database Manager table SASDEMO.SALARY. The SAS variable
name in the view descriptor for the BONUSCOD column is BONUS
and the variable name for the EMPID column is EMPID. If you want
to print a list of all employees who have a bonuscode sorted by
empid, submit the following SAS statements.
PRoe PRINT DATA=VIEWLIB.SALARY;
WHERE BONUS IS NOT MISSING;
BY EMPIO;
RUN;
In this case the following clauses:
DBLOAD Procedure SQL Statement
WHERE (·BONUSCOO" IS NOT NULL)
ORDER BY EMPID
In addition to creating and loading tables, the DBlOAD procedure
enables you to pass non-select statements to the DBMS. This
feature is extremely useful in the OBlOAD procedure for dropping
old tables and issuing administrative commands on newly created
tables.
are added to the SELECT statement generated by the engine.
When the select statement is passed to the DBMS, it can use
indexes and any other means aVc:Ulable to it to optimize the retrieval
of the data. Also, only the rows that meet the WHERE clause criteria
are passed back to the SAS interface. This cuts down on the amount
of 110 that takes place between the interface engine and the DBMS
as well as theamount of data conversion that the engine must
perform,
PROC DBLOAD DBMS=DBMGR DATA=SASUSER.SALARY;
IN 'SAMPLE';
TABLE=SASDEMO.SALARYi
SQL DROP TABLE SASDEMO.SALARY;
LIST ALL;
LOAD;
The second place that you can taKe advantage of the~e DBMS
specific Sal clauses is by storing them in the view descriptor. When
creating or editing a view descriptor you can enter these clauses
in the Selection Criteria Entry Window. The clauses that you enter
must be OBMS specific, using the column names, not SAS variable
names. Each time that the view descriptor is used in a SAS
program, the stored clauses are added to the select statement
generated by the engine.
RUN;
PR08 DBLOAD DBMS=DBMGR DATA=SASUSER.SALARY;
IN 'SAMPLE';
TABLE=SASDEMO.SALARYi
SQL CREATE UNIQUE INDEX SASDEMO.EMPID NDX
ON SASDEMO.SALARY (EMPID);
SQL GRANT SELECT ON SASDEMO.SALARY
TO PUBLIC;
RUN;
SRS~
F_t.
EJ'FID
8H..NIT
3.0
DCIl..l..NIIO.II!
II!. 0
EI.N.9DI
In the example above, the DB).,.OAD procedure for Database
Manager is used twice. Once to create the table
SASDEMO.SALARY table in the SAMPLE database and once to
define an index and grant permissions on the table. ,These
operations must take place in separate batch mode invocations of
the DBlOAD procedure because Sal statements are immediately
passed to the DBMS by the procedure, but tables are not actually
created until the RUN statement is encountered. So, although you
can drop and recreate a table in one invocation of the DBlOAD
procedure, indexes and ~rmissions cannot be granted on the new
table until after the RUN statement because the table will not exist
until that time.
SQL' Procedure Pass-Through Facility
For example, the display above shows WHERE and ORDER BY
clauses being entered to create the view descriptor
VIEWLlB.BONUS. Each time that this view is referenced, only the
data wher,e the BON USCODE exists will be returned and it will
always be returned in sorted order. No SAS WH ERE or BY
statements are required on the procedure or data step to make this
happen.
An additional engine feature that is available on some interfaces is
the Sal Procedure Pass-Through Facility. This feature is used
exclusively with the SOL procedure to allow both query and
non-query Sal statements to be passed to a database
management s~tem for execution.
The pass-through feature is especially useful for joining data from
multiple tables in a single database. This is because a Single SQl
SELECT statement that joins the data may be passed to the DBMS.
The DBMS, not the SAS System, then performs the join using any
In cases where a SAS WHERE clause is used in combinatio'n with
a view descriptor that already contains a DBMS WHERE clause, the
183
optimizations available to it and returning only the data that satisfies
the SELECT statement.
Database Manager Pass-Through Facility
An experimental feature, the SOL Procedure Pass-Through Facility,
was added to the Database Manager interface with the production
release of Release 6.08 of the SAS System. This feature was not
announced or documented at the time of the production release.
Initial reports from sites testing the interface are very favorable and
indicate that SOL Pass~ Through for Database Manager is fairly
stable. To acquire a copy of the documentation simply call SAS
Institute Technical Support Division and request the preliminary
documentation for SAS/ACCESs«' Interface for Database Manager:
PROC SQL;
TITLE "EMPLOYEE SALARIES';
SELECT * FROM CONNECTION TO AS400
(SELECT FNAME, LNAME, SALARY
FROM SASDEMO/EMPLOYEE,
SASDEMO/SALARY
WHERE EMPLOYEE.EMPID = SALARY.EMPID
ORDER BY SALARY);
SOL Procedure Pass- Through Facility.
In the example above, the AS/400 tables SASDEMO/EMPLOYEE
and SASDEMO/SALARY were joined to produce a listing of
employees and their salaries sorted by salary. The data was joined
and sorted on the AS/400 before being returned to the SOL
procedure. The output below shows the results produced by these
statements.
Setting Up the Database Manager Interface
Aside from actually installing Database Manager and defining
databases, there are several things that must be done prior to using
the interface.
All users using the Database Manager must be defined through
User Profile Management Services. The userids maintained in this
service are used to maintain the security of the data stored in
Database Manager. Individual users must begranted specific
permissions to access data in tables created by other users. If ,you
do not have any permissions on a specific table, Database Manager
will not allow you any access to the data.
EMPLOYEE SALARIES
FNAME
LNAME
SALARY
Sammy
Henrietta
Justin
Sli,ck
Hacker
Ooit
30000
35000
120000
Before the SAS System can access Database Manager tables, the
database must know that the SAS engine may try to access -it arid
what the interface may try to do. To do this an application must be
"bound" to each individual database that it needs to access. The
SAS/ACCESS interface to Database Manager supplies both a bind
module and a command file (ACCESS.CMD) for binding the
interface to Database Manager databases.
Several methods are also available with the SOL procedure to
create a SAS data file or a PROC SOL view reflecting the results
of the query. These methods will allow other SAS procedures to
operate on the joined data.
Without pass-through, the SOL procedure will have to use view
descriptors to access the DBMS data. This would mean that all data
accessible to each individual view would be returned to the SOL
procedure which would then perform the join. Using view
descriptors for joins has several drawbacks in that DBMS
optimizations such as indexes are not available to the SOL
procedure and sometimes large amounts of data not needed for the
join may be returned from the DBMS just to be discarded.
To perform the actual bind, you must have created the SASDEMO
use rid in User Profile Management Services and currently be
logged in as that user. Then enter the command:
ACCESS database-name
-CONFIG configuration- file-;:_name
where da tabase-name is the name of the database to which the
"bind" is'being performed and configuration-file-name is
the riame of the cenfig.sas file that you use to run the SAS S.ystem.
THE 0512 DATABASE MANAGER INTERFACE
The ACCESS command will locate the bind module and issue the
SQLBIND ~ommand to Database Manag,er. -Once the bind h~_ been
successfully accomplishe,~, you musti$-sue the foUowing Sal
statement to permit other users to acceS$ the database using the
SAS/ACCESS interface:
The SAS/ACCESS Interface to OS/2 Database Manager contains
the ACCESS and DBLOAD procedures, an interface view engine
and most of the features that may be found in these components.
The most notable feature that is currently not available is the
ACCESS procedure statements needed to create access and view
descriptors non":'interactively.
GRANT
OS/2 Database Manager is the IBM® relational databas'e
management system that runs under OS/2. The latest release of
database manager is packaged in the IBM Extended Services for
OS/2 and runs under OS/2 1.31 & 2.0 as a 16 bit application.
Database Manager databases define<;l on other machines
connected by a network may be accessed on a local machine using
the Remote Data Services component of Database Manager.
EXECUTE
ON
PROGRAM
SASOEMO.SASOII TO
PUBLIC
THE AS/400 DATA INTERFACE
The SAS/ACCESS Interface to AS/400 Data is composed of the
ACCESS procedure and an interface view engine. The ACCESS
procedure for this interface does not support statements that allow
the non-interactive creation of access and view descriptors.
However. the interface view engine supports the SOL Procedure
Pass-Through Facility, allowing Sal s~tements and querie,s to be
sent directly to the AS/400 for execution.
Although the Release 6.08 of the SAS System is a 32 bit applicetion
running under 0512 2.0, the SAS/ACCESS interface is still able to
use the 16 bit Database Man/ilger at a cost. The,cost is that each
call made to a Database Manager function must be "Thunked".
Thunking is the process by which program control and parameters
are passed between 32 bit and 16 bit applications. During the
transfer of control, the program stack must be manipulated and all
pointers converted between the 32 bit flat memory model and the
16 bit segmented memory model. These conversions must take
place while calling into a function and on returning from it.
The AS/400 provides a computing environment where hardware
and software are highly integrated. The operating system,
OS/400®, has many builtin features including a relational database
management system. Data in this relational database may be
managed natively via non-Sal means or in an SOL collection. The
SAS/ACCESS interface may access data managed by eith-er
means. The database functions of OS/400 operating system are
integrated to the extent that Sal queries for non-S'Ol managed
184
data are supported.
The AS400MSG environment variable is use.d to indicate the
librarylfile name of the compiled SASFMSG CL program. If the
name of the program is changed to anything other than SASFMSG,
or if the library where it resides is not in your *UBl library list then
this variable should be set. The format of value shOUld be
library/filename. If this environment variable is ·not,set, a default
of "L1BUSASFMSG will be used.
The SASIACCESS Interface to ASI400 Data is able to access data
on an AS/400 by using the Remote SOL Application Program
Interlace (API) of the IBM PC SUPPORTI400 software. Using this
interface, SASIACCESS software is able to pass SOL statements
and queries to the PC Support product which in turn sends the
request to· the AS/400 via Communications Manager and returns
the results to the PC.
AS400CMT
Indicates the level of commitment control and locking that the
interface should operate under. Valid values are:
Like OS/2 Database Manager, PC Supportl400 is a 16 bit
application. As discussed with the Database Manager interface, all
calls made into its API functions must.be thunked. The figure below
illustrates the flow of information between the SAS procedure and
the AS/400 database file.
1 SAS Procedure 1
II
NONE
No commitment control. Default locking is used such
that read or update locks are acquired as a row is read
and released when the next row is read.
CHG
Change control. Update locks for updateable CUr;., .Ji"$
only. Update locks for unchanged records
released as the cursor moves to the next row. Lo :r;
for changed rows are released at Commit C:, ','0!P);
Otherwise no locks are acquired .
CS
Cursor Stability control. Always uses a read or up(latp
lock. as appropriate. Read locks and Upd::F'" i, ,'"._, 'r""'
unchanged records are released as th~ cursor moves
to the next row. Locks for changed rows '~i;: rele':"JSed
at commit or rollback.
All
Full commitment control and locking. All locks acquireri
are maintained until a commit or rollback " '~':.:urs
SAS System
.J.T
E.g;••
SUP.~",o~
.J,. T
v;.w
1 Interlace Engine
Descriptor
J I
I. PC Support/400 1
I
I
AS/400Host
»
~PCSIPP09
Database
File
I
If a level of commitment control is specified (any va~u", othe; than
NONE), then commitment control is used. However, IJse of
commitment control prohibits the use of non·journaled dat',v:;ase
files. If no commitment control is used (i.e. NON!:.:; :·,en >-.-·ath
joumaled and non·journaled database files can be accessed. The
default value for this variable is NONE.
Data Flow between the SAS System and ASI400
Options Affecting the ASI400 Data Interface
If you are using PC Supporv400 Version 2 Release 1 the only valid
values for this variable are: NONE and ALL.
For the features supported, the abilities of the AS/400 interface
follow very closely with those mentioned earlier in the
"CHARACTERISTICS OF A DBMS INTERFACE" section.
However, these abilities may be altered and performance improved
by using a number of options that have been provided by the AS/400
interface. These options are passed to the interface by using OS/2
environment variables. Values may be assigned to these variables
by using the -SET system option in your config.sas file. For
example, the line:
AS400DEC
Indicates the numeric decimal separator to be used. Valid values
are a period (.) or comma (,). The default value is period (.).
AS400BUF
Defines the size of tt:le buffer used for data transfers. Valid values
are integers from 1 to 31' and represent the size of the buffer in
kilobytes. The default value is SK.
-SET AS400CMT CHG
may be added to your contig.sas file to assign the value CHG to
the AS400CMT environment variable. Thefollowing environment
variables are used with the AS/400 interface:
AS400UPD
Indicates if rows returned from a select statement may be updated.
A value of YES indicates that SELECT statements should be
invoked so that rows can be modified. NO would not allow updates
of selected rows.
AS400PLU
The Partner logical Unit name by which Communications Manager
recognizes the AS/400 host. If this environment variable is not set.
a default of 52S0PlU is used.
In addition to the ability to update.rows, this variable affects I/O with
the AS/400. When a value of YES is used, records are returned from
the AS/400 one ata time and rows can be fetched from severat
different tables at the same time. However, if a value of NO is used,.
rows are returned from the AS/400 in blocks and rows can only be
fetched from one table at a time. If you only intend to read data.from
one table during the execution of a proc, then you may want to set
this environment variable to NO to increase performance.
AS400MSG
Messages for Sal errors that occur on the AS/400 are not available
to the interface through PC Support's remote Sal API. In order for
the interface to get text for these error messages a Command
Language (CL) program, SASFMSG, must be uploaded and
compiled on the AS/400 when the interface is installed.
If this environment variable is not set, a default of YES is used.
When the interface encounters an Sal error during an operation,
information concerning the error is collected and passed to the
SASFMSG program on the AS1400. This program will take the
information and fetch the appropriate message from the AS/400
Sal message file sending it back to the interface on the PC.
185
running under both OS/2 2.0 and Microsoft Windows 3.1 and
Release 6.09 release is under development for Microsoft Windows
NT. The interfaces discussed in this paper are either available with
the Release 6.08 production release or will be released as an
add-on product some time after the initial release of the SAS
System.
AS400IYAT & AS400TlM
Data types for dates, times and timestamps were ad~ed to 05/400
in Ve~ion 2 Release 1.1. To accommodate these data types two
OS/2 enVironment variables are used to determine the format of the
date and time values returned to the engine from the AS/400. The
name of the environment variable used for the date format is
AS400DAT; for time format it is AS400TIM. The following table
All of the following interfaces, except the interface to SYBASE and
SQl Server, are available with the production release of Release
6.08 of the SAS System.
shows the possible values for these variables and which values are
valid for a particular format.
Valid for
AS400DAT
Valid for
AS400TIM
YMD
Y
N
MDY
Y
N
DMY
Y
N
JUL
Y
HMS
N
Y
ISO
Y
Y
USA
Y
Y
EUR
Y
Y
JIS
Y
Y
Variable Value
.
• SAS/ACCESS interface to PC File Formats
• SAS/ACCESS interface to OSI2 Database Manager
• SAS/ACCESS interface to AS/400 Data
• SAS/ACCESS interface to SYBASE and SOL Server
The DBF and DIF file interfaces discussed in this paper are
packaged together into the SAS/ACCESS Interface to PC File
Formats product.
-
N
Although each of the interfaces discussed in this paper are available
on the PC platform, they are not always supported on both the OSI2
and Microsoft Windows operating environments. The table below
reflects the availability afthe SAS/ACCESS products in these
environments.
SAS/Access Product
By default, date values will be returned from the AS/400 in format
specified by the aDATFMT system value on the AS/400. This same
value should be specified as the value for the AS400DAT
environment variable. In 05/400 Version 2 Release 1.1 ther.e is no
system value for the time format; the default is HMS. However, if
the time'format is modified by·another'means (such as modifying
the time format associated wrth the PC Support job that is
communicating with the engine), then the that time format should
be specified for the AS400TIM environment variable.
OS/2
. Microsoft
Windows
PC File Formats
Y
Y
Database Manager
Y
N
AS/400 Data
Y
N
SYBASE and SOL
Server
N
Y
CONCLUSION
This paper has discussed the components and features of the
SAS/ACCESS products that are available on the PC platlorm. Each
interface was discussed with special emphasis on the
characteristics and options that make ,them unique. You should
have gained an understanding of the abilities of each interface and
the principles upon which they are based. Using this understanding
you should be able to use these interfaces efficiently, avoiding the
pitfalls that may exist in some.
FUTURE ENHANCEMENTS TO PC BASED SAS/ACCESS
INTERFACES
To a large extent enhancements to SAS/ACCESS interfaces are
driven by demand from you. The first three interfaces discussed in
this paper, DIF Files, DBF Files and Database Manager are
complete with the exception of providing AC'CESS procedure
statements allowing non-interactive creation of descriptors. The
AS/400 interface also lacks this feature as well as the DBlOAD
procedure. All of these features are under consideration to become
enhancements; however availability has not been determined. If
you have a specific need for an enhancement to these interfaces,
please contact your SAS Software Representative.
SAS and SAS/ACCESS are registered trademarks or trademarks
of SAS Institute Inc. in the USA and other countries. IBM. ASJ400,
OS/2 and OS/400 are registered trademarks or trade:marks of
International Business Machines Corporation. ® indicates USA
registration
A new interface is currently under development to be a add-on
product under Release 6.08 of the SAS System for Microsoft
Windows. The SAS/ACCESS Interface to SYBASE and SQLServer
will be a full feature interface providing ACCESS and DBlOAD
procedures with windowed and non-interactive modes of operation.
The view engine of this new interface will also support the SQl
procedure Pass-Through Facility. The Sal Server interface is
being built against Release 4.2 of the SQl Server Client and will
support stored procedur~s and triggers.
Other brand and product names are registered trademarks or
trademarks of their respective companies.
'
SUMMARY OF SAS/ACCESS AVAILABILITY
The SAS system currently has Release 6.08 production releases
186