RACROUTE REQUEST=FASTAUTH uses the resident profiles to perform authorization checking. RACROUTE REQUEST=FASTAUTH gathers no statistics, issues no service calls (SVCs), and is branch-entered by the resource manager. The RACROUTE REQUEST=FASTAUTH service is SRB-compatible.

If you use RACROUTE REQUEST=FASTAUTH rather than RACROUTE REQUEST=AUTH, you can improve your application's performance. FASTAUTH is particularly useful for applications that have stringent performance requirements. But FASTAUTH processing does complicate your application coding: if your application does not run in system key or supervisor state, you must use RACROUTE REQUEST=LIST to load the profiles into storage. If you use RACROUTE REQUEST=LIST,ENVIR=CREATE,GLOBAL=NO to load the profiles into storage, then you must issue REQUEST=LIST,ENVIR=DELETE to delete the profiles when you are done. In addition, if your application is long-running, you might need to supply a "refresh" mechanism in case the security administrator has changed a profile.

However, if you issue RACROUTE REQUEST=LIST,GLOBAL=YES to load the profiles into a data space, the administrator can refresh the profiles with SETROPTS RACLIST REFRESH. Therefore, your application does not have to provide a method to refresh the profiles. Likewise, REQUEST=LIST,ENVIR=DELETE deletes the application's access to the profiles, but not the data space; SETROPTS NORACLIST deletes the data space. If RACGLIST profiles are being maintained in conjunction with RACLISTed data, a SETROPTS NORACLIST deletes the RACGLIST classname_nnnnn profiles on the database.

If your application runs in an authorized state, it can use profiles brought into storage by SETROPTS RACLIST for authorization checking, and no RACROUTE REQUEST=LIST is required.