AFAPPLICATION Command

Introduction

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.

Syntax

The AFAPPLICATION command uses the same syntax as the AF command:
AFAPPLICATION <AUTORECALL=YES | NO>
<AUTOSAVE=YES | NO>
<AUTOTERM=YES | NO | VERBOSE | NOVERBOSE>
<AWS=YES | NO | KEEP>
<CATALOG=libref.catalog-name.entry-name.entry-type>
<CATNAME=libref.catalog-reference(libref.catalog-1 ... libref.catalog-n)>
<CHECKLAST=YES | NO>
<DEBUG=YES | NO>
<FRAME=frame-number | frame-name>
<ICON=icon-number>
<LABEL=label>
<PMENU=YES | NO>
<RESIDENT=number>
<RESTART=YES | NO>
<SCLPROF=COVERAGE | TIMER>
<TITLE=title>
<application-options>
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.

Comparison with the AF Command

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.

Sharing Data Between Multiple Applications

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.