TS-383

Is it possible to eliminate hard-coded SAS/SHARE serverids and server-controlled SAS data library names from users' applications?

INPUT:
Is it possible to eliminate hard-coded SAS/SHARE serverids and server-controlled SAS data library names from users' applications?

OUTPUT:
The Institute supplies a set of autocall macros that make this possible, while also providing a more dynamic, flexible, and easily maintained server environment.

The basis for this functionality is the APPLSYS macro library, which contains tables that associate SAS data library names with SAS/SHARE server aliases (the DEFAULTS member), and server aliases with actual serverids (the SERVERID member). The name and structure of the APPLSYS macro library is host-specific, but on MVS (which will be used in the examples to follow), it is implemented as a Partitioned Data Set (PDS) named SAS.SASSAML by default. The name of the APPLSYS macro library is contained in the SHRMACS member of the Institute-supplied autocall macro library on all platforms, and can be changed to conform to site-specific naming conventions.

The Institute-supplied SHRMACS autocall macro uses its first argument and the information in the APPLSYS macro library tables to compile a set of macros that generate a range of SAS statements to access both servers and libraries. Since the tables are evaluated each time SHRMACS is executed (typically at the beginning of the SAS session), the generated statements change dynamically based on the current information in the tables. Execution of the SHRMACS macro is required before using any of the other macros that it compiles. Additionally, any reference to a server alias rather than a serverid must use the macros. A common mistake is to reference a server alias in "open code". This typically produces error messages and/or unexpected results, since the server alias is interpreted as an actual serverid.

Consider the following scenario: a company with three departments which require server-controlled libraries (Finance, Human Resources, and Marketing). In the interest of simplicity, we will assume that each department has just one server-controlled SAS data library. The contents of the DEFAULTS member of the APPLSYS macro library are:

%servlib(finance.sas.library,finserv); %servlib(hr.sas.library,hrserv);
%servlib(mkt.sas.library,mktserv);

In each case, the first argument to the SERVLIB macro is the physical data set name and the second is the server alias associated with that SAS data library. The contents of the SERVERID member are:

%servid(finserv,sasserv1);
%servid(hrserv,sasserv1);
%servid(mktserv,sasserv1);

In each case, the first argument to the SERVID macro is the server alias and the second is the actual serverid. Note that in the simplest case the three unique aliases map to the same serverid. As any department's needs change (as reflected, for example, by the number of jobs or users accessing the library) the department's library can be transferred to a separate server by changing the appropriate SERVID specification and starting a server with the new serverid. No changes are required in the application code.

In the users' application, the only statements required to access the library through the server are the SHRMACS and LIBDEF macros: SHRMACS compiles LIBDEF (as well as other macros that are applicable to a user's session) and LIBDEF generates the syntactically correct LIBNAME statement. For example, a user in the Marketing Department would include the following in the application source code:

%shrmacs(user);
%libdef(libref,mkt.sas.library);

where "libref" is the libref used to reference the SAS data library in the application. The argument passed to SHRMACS ("user" in this case) controls which macros are generated for subsequent use. Other valid values are "server" and "oper". Note that neither the server alias nor the serverid appear in the application code. The LIBDEF macro generates the following LIBNAME statement:

libname libref 'mkt.sas.library' server=sasserv1;

based on its parameters and the current contents of the APPLSYS macro library tables.

This process can be taken one step further by removing the physical data set name from the application's LIBDEF macro invocation. Two changes are required, the first in the DEFAULTS member. Instead of giving a data set name in the SERVLIB macro, a libref is specified. For example, the reference to the library owned by the Finance Department would change to:

%servlib(finlib,finserv);

The second change is the Finance Department's SAS library must be defined to the server ahead of time, specifying the libref FINLIB. This can be done with a LIBNAME statement or an external allocation (e.g. DD card) in the server's execution, or a PROC OPERATE with an ALLOCATE LIBRARY statement from another SAS session. For example, the following LIBNAME statement can be included in the server's execution before the server's invocation:

libname finlib 'finance.sas.library';

Then the LIBDEF macro in the application source code becomes:

%libdef(finlib);

This eliminates both the serverid and physical data set name from the application's source code, but requires that the physical data set name be coded and maintained in another location (e.g. an AUTOEXEC file for the server).

The server administrator can also use the information in the APPLSYS macro library in conjunction with SHRMACS to access servers. For example, if the Finance Department is anticipating a great deal of activity in its library during a year end audit, the library can be transferred to a dedicated server by changing the entry in the SERVERID member to:

%servid(finserv,sasserv2);

The server administrator can then start the new server with:

%shrmacs(server);
%strtsrv(finserv);

and access that server without having to remember the new serverid by issuing:

%shrmacs(oper);
%operate(finserv);

Based on the current information in the APPLSYS macro library tables, the statement generated by the OPERATE macro is:

proc operate server=sasserv2;

and correctly reflects the new serverid, SASSERV2.

By implementing the APPLSYS macro library and requiring applications to use the autocall macros instead of hardcoded SAS data library names and serverids, sites can make their SAS/SHARE environments more dynamic, flexible, and easy to maintain. Applications can be moved from one server to another, servers and data sets can be renamed, and server load can be balanced to accommodate users' needs without requiring changes to the users' application code.

All of this discussion exercises only the basic functionality offered by the Institute-supplied autocall macros. Most of the macros mentioned have other parameters available for other site- or application-specific needs. For more information about the APPLSYS macro library and supplied autocall macros, refer to SAS/SHARE Software, Usage and Reference, Version 6, First Edition, and the host-specific Technical Reports for SAS/SHARE software.