Executing SAS/AF Applications |
The
AFAPPLICATION command is similar to the AF command, but it enables you to
run multiple SAS/AF applications simultaneously.
Each application that is executed with the AFAPPLICATION command runs as
a separate task.
The
AFAPPLICATION command uses the same syntax as the AF command:
AFAPPLICATION <AUTORECALL=YES | NO>
|
<AUTOTERM=YES | NO | VERBOSE | NOVERBOSE>
|
|
<CATALOG=libref.catalog-name.entry-name.entry-type>
|
|
<CATNAME=libref.catalog-reference(libref.catalog-1
...
libref.catalog-n)>
|
|
<FRAME=frame-number |
frame-name>
|
|
<SCLPROF=COVERAGE |
TIMER>
|
|
Note: The
AFAPPLICATION command can be abbreviated as AFAPPL
or AFA.
The AFAPPLICATION command options are the same as for the AF command.
See Options for details.
The AFAPPLICATION command is
similar to the AF command in the
following ways:
-
The same command options can be used.
-
The checkpoint entry identified in SASUSER.PROFILE.AF.AFGO runs
if the CATALOG= option is omitted.
-
Application-specific options that you supply with the command
are passed to the application for further processing via the _CMDLIST_ sublist
of the local environment list.
The AFAPPLICATION command differs from the AF command in that it does
not update the AF checkpoint. That is, the name of the initial entry in the
application that is executed by the AFAPPLICATION command (or the name and
frame of the CBT entry, if the user is exiting from a CBT entry) is not recorded
in the SASUSER.PROFILE.AF.AFGO entry as it is for the AF command.
When you run a
SAS/AF application
with the AFAPPLICATION command, remember that other applications may be running
at the same time. Those other applications may try to access the same SAS
data sets or members of SAS catalogs as your application. For example, suppose
your application uses the FILLIST function to read an SLIST catalog member.
Before your application updates the list and writes it back to the SLIST
entry, another application that has update access to the catalog can read
from and write to the same SLIST entry. This situation can create problems
with data integrity.
If your application needs to share data with another application, you
should consider
-
opening your data sets with member-level locking to prevent other
applications from opening the data sets at the same time
-
accessing your catalog and data files through SAS/SHARE software
so that other applications can have simultaneous update access
-
locking your catalog entries and other SAS data files by using
the SCL LOCK function.
Copyright © 2007 by SAS Institute Inc., Cary, NC, USA. All rights reserved.