|The SERVER Procedure|
The PROC SERVER statement options are
The ACCTLVL= and LOG= options are related in that the ACCTLVL= option specifies when accounting information is logged, and the LOG= option specifies which accounting information is logged.
Value for ACCTLVL= may be
This option is used with a communications access method security option (for example, use the TCPSEC= option for TCP/IP). When the value of the AUTHENTICATE= option is REQUIRED, the security options of all the access methods that are used by the server must be set to _SECURE_. Also, PROC SERVER will not start up unless all of the access methods guarantee that they require a valid userid and password combination before establishing a connection between a client and the server.
When the value of the AUTHENTICATE= option is OPTIONAL, the communications access method security options may or may not be set to _SECURE_. Each access method may have its security option set differently. This situation can be useful for a site that trusts the identities of users that connect through one access method but does not trust the identities of users that connect through another access method. In this case, only the access method by which the non-trusted clients connect may have its security option set to _SECURE_, and the value of the AUTHENTICATE= option is set to OPTIONAL to allow the trusted users to connect without requiring authentication.
When an access method supplies an authenticated userid (typically, by requiring a connecting client to specify a valid userid and password combination), the server uses that validated identity to verify the user's authorization to access SAS files. When the value of the AUTHENTICATE= option is OPTIONAL and some access methods do not supply validated userids, those clients are allowed to access all SAS files that the server is allowed to access. In this situation, you should run the server under a userid that does not have open access to the files on its computer.
If you specify your own format for this option, the number to format that is supplied to the formatting routine is a SAS datetime value. For an example of the date and time format in the server's log, see Server Log Reporting All Logging Statistics.
Specifying the value _NODTS_ suppresses the date-time stamp.
An example of a long-running process is when a client accesses a PROC SQL view that joins two large data sets that require the server to sort the data sets. Another example is when a client issues a WHERE clause that causes the server to search millions of observations sequentially to find the first one that satisfies the WHERE clause.
You can specify multiple values for the LOG= option. To do this, enclose the values in parentheses and separate them with either a space or a comma; for example, LOG=(MESSAGE BYTECOUNT).
Note: The values IO and CPU are no longer accepted. The data that was reported by
the options in Version 6 offered limited accuracy, and the changes in resource
tracking in Version 7and Version 8 reduce the potential accuracy even further.
Note: If you previously set the SAS options
STIMER or FULLSTIMER because you had specified a LOG= option value of IO or
CPU, you can re-set or delete these SAS options in order to improve your server's
Value for LOG= may be
The value is automatically re-scaled prior to printing, and the appropriate character - K (when the count reaches ten million bytes), M (when the count reaches ten million K bytes), and G (when the count reaches ten million M bytes) - is appended to the value, which is printed with the SAS format COMMA10.0.
Note: Do not confuse the MESSAGE value for the LOG=
option with the option MSGNUMBER.
An example follows:
22JUL97:13:57:03 JSMITH(27) in "SQL(0) has issued select region,year, ytd from yearly.regsales where country='USA' to SQLVIEW.
For a typical server log, see Sample Log for SAS/SHARE Server SHARE2.
By default, a SAS data view is interpreted in the server SAS session, and the data that is produced by the view is transmitted to a client SAS session.
Occasionally, it is preferable to transmit the view - the instructions for producing the data - to a client SAS session and to have the view interpreted and the data assembled in the client SAS session. The RMTVIEW= option of the LIBNAME statement can be used to request this on a library-by-library basis.
The NORMTVIEW option enforces this action (transmission of the view instead of the data) for all users of the server, regardless of whether each user specifies the RMTVIEW= option in a LIBNAME statement.
This option is made available for specific needs and is only rarely appropriate. If you think that this option may be useful for a server, contact SAS Institute Technical Support to review the circumstances.
specifies a name for the server. The server name must meet the criteria for a valid SAS name, although it can also include the following special characters: dollar sign ($), at sign (@), and pound sign (#).
Server naming is also constrained by the host type and the access method that you specify for communication between a server and a client session. For complete information about how to name servers by host, see Communications Access Methods for SAS/CONNECT and SAS/SHARE Software.
06JAN1999:08:28:20.911 043131 SAS server SHR1 started
The message number
043131 identifies a PROC SERVER start-up operation.
Message numbers are useful for server log analysis applications. Such a program could count the number of instances of an operation that occur in a given client-server session. Collection and analysis of such statistics may help you with server load balancing. SAS provides a set of server log analysis program prototypes that you can customize for your needs. Among these prototypes is a file that maps message numbers to operations. See Introduction for information about the server log analysis tools.
Note: Because message numbers can change from one software
release to another, avoid hardcoding message numbers in your applications.
You may use macros instead.
Note: Do not
confuse the option MSGNUMBER with the MESSAGE value for the LOG= option.
For details about how the client supplies this password to an SQL CONNECT TO REMOTE statement, see Remote SQL Pass-Through (RSPT) Facility.
A transmission buffer is assigned while a server is processing a request from a user. If a server is asked by users to perform many long-running requests, transmission buffers can be tied up, making it necessary to increase the value of this option. In most cases, the value of this option can remain much smaller than the number of users that are simultaneously connected to the server.
There is an interaction between this option and the LRPYIELD= option. If the value of the LRPYIELD= option is high, long-running requests from users tend to yield more frequently, which provides more opportunity for new requests from users to be received by the server. This can result in transmission buffers being tied up by long-running requests that are yielding frequently (and therefore taking even longer to run). This situation may suggest increasing the value of the TBUFNO= option.
The amount of memory that is used by a server for transmission buffers can be calculated by multiplying the values of the TBUFNO= and TBUFSIZE= options.
You cannot calculate the number of observations per transfer by dividing the observation length into the value that you specify for the TBUFSIZE= option. To determine the effect of this option on your data sets, use the PROC SERVER option LOG=MESSAGE and compare the number of messages exchanged between the server and the client sessions as a function of the value of the TBUFSIZE= option and the data set's observation length.
Transfers of multiple observations are used only for data sets that are opened for output or for certain types of input. Multi-observation transfers are not used for data sets that are opened for update.
If the minimum amount of data that must be transferred exceeds the specified buffer size, the buffer size increases to allow the transfer. Specifying an excessive value for this option may cause your server or clients to run out of memory and, in turn, to terminate abnormally.
The following are examples of how to start a server:
proc server id=share1; proc server id=share1 noalloc; proc server id=share1 log=msg;
The first statement starts the server SHARE1. The second statement starts the server SHARE1 that does not allow clients to define SAS data libraries to the server. The third statement starts the server SHARE1 and reports all message counts to the server log.
Top of Page
Copyright 1999 by SAS Institute Inc., Cary, NC, USA. All rights reserved.