SESSION Statement
Controls how a session is administered by the Application Server
Syntax
Arguments
- INIT=program-name
-
specifies programs to be run when a session is created and destroyed (including those that expire by timing out). By default, no program is run at the creation and destruction of a session. The program names referenced here
must be in the same format as the _PROGRAM variable. Also, the libraries or files that contain these programs must be allocated in a previous ALLOCATE statement.
- INVSESS=program-name
- specifies a program that is to be run in the place of the requested
program if the session that is specified by _SESSIONID does not exist. This can happen if the session expired or if the session ID was modified
by the client.
Two special macro variables are created for the invalid session program. The _USERPROGRAM variable contains the name of the program that was requested by the user. This is the value that is specified by the _PROGRAM variable in the original request. The _INVSESSREASON variable has NOSESSION as its value, which means that the session specified by _SESSIONID does not exist.
The invalid session program can be used to display an informative
response when a user session has expired or is otherwise inaccessible.
The response can redirect the user to an application login screen,
explain how to restart the application, or provide a friendlier
error message.
- TERM=program-name
- specifies programs to be run when a session is created and destroyed (including those that expire by timing out). By default, no program is run at the creation and destruction of a session. The program names referenced here must be in the same format as the _PROGRAM variable. Also, the libraries or files that contain these programs must be allocated in a previous ALLOCATE statement.
Remember that when you delete a session, it is only marked for deletion. A session is not deleted until the clean-up routine runs. A user creates a session only once throughout an application. The user can reuse the session, but deletion of the session does not occur until the end of the application.
In the following example, a user creates a session and then deletes that session. When the user tries to create a new session in the same test program they get a warning.
testa.sas (creates session1 -> calls testb.sas)
testb.sas (uses session1 -> deletes session1 -> creates new session2)
The user cannot create session2, because session1 is still being used. Furthermore, after a session is marked for deletion, another user cannot access that same session, even before the clean-up process runs.
- TIMEOUT=seconds
- specifies the number of seconds that elapse before a session expires. The default session timeout is 900 (15 minutes). This value can be changed in a request program by calling the Application Dispatcher APPSRVSET function. An Application Server does not honor a pool service idle timeout stop request from the Load Manager until all sessions have expired.
- MAXTIMEOUT=seconds
- is the maximum number of seconds that a timeout can be set to using the APPSRVSET function. For more information about setting the session timeout from a request program, see the SAS/IntrNet Application Dispatcher documentation for the APPSRVSET function.
- VERIFY=(variable-1 <...variable-n>)
- is a space-delimited list of variable names. A session reconnect is a request for a _SESSIONID for an existing session. For enhanced security, the Version 8 Application Server can verify
other request variables in addition to validating the _SESSIONID for all session re-connects. For example, the Version 8 Application Server can ensure that the variable _RMTUSER is the same for all session re-connects. This makes it more difficult for one client to steal another client's URL and access the first client's session information. Enclose the list of variables in parentheses.
