Gilles Chrzaszcz

4月 172017
 

In this post, I will explain how LASR Servers (both Distributed and Non-distributed) are started from the SAS Visual Analytics Administrator application. We will also look at one particular issue and I will provide you with more details to understand the situation and two strategies to address this issue.

When you start a LASR Server from the Visual Analytics Administrator application, the system processes your request in slightly different ways depending on whether you are starting a distributed or non-distributed LASR Server.

What happens in the background for a distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the distributed LASR Server startup code generated in step 2, and the SAS Workspace Server session executes it.

6.     As soon as the distributed LASR Server startup code is executed, a distributed LASR Server instance is created. This instance is independent from the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection drop down. But the LASR Server instance is up and persistent until the administrator stops it.

What happens for a non-distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the non-distributed LASR Server startup code generated on step 2, and the SAS Workspace Server session executes it.

6.     As soon as the non-distributed LASR Server startup code is executed, a non-distributed LASR Server instance is created. This instance is dependent on the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection become persistent until the administrator stops the non-distributed LASR Server.
The SAS Workspace Server session and the client connection are required for the non-distributed LASR Server to be up and persistent.

Potential non-distributed LASR Server issue

The client connection between the JES and the SAS Workspace Server session in non-distributed deployment is crucial. This connection has to be persistent during the non-distributed LASR Server lifetime. As soon as the JES or SAS Workspace Server session goes down, the client connection is broken and the non-distributed LASR Server will go down as well. And, its data become unavailable.

If administrators manage their SAS non-distributed LASR Servers from the SAS Visual Analytics Administrator web application, this will create a dependency between the non-distributed LASR Servers and the middle tier - more specifically with the SASServer1_1 instance (the sas.wip.soapservices application). This dependency does not exist for distributed LASR Servers.

When the dependency exists, each time the middle tier or the SASServer1_1 instance is down, all non-distributed LASR Servers that were managed using the SAS Visual Analytics Administrator will go down automatically because the client connection to the non-distributed LASR Server is broken and its associated SAS Workspace Server session will go down.

This issue will also appear if the network connection between the Middle Tier and the SAS Visual Analytics Root Node is broken. This will break the client connection and terminate the SAS Workspace Server session(s) and their associated non-distributed LASR Server(s).

How can we prevent the issue?

I can think of at least two techniques you can use to prevent the dependency of your non-distributed LASR Servers upon your middle-tier:

  • Start your non-distributed LASR Servers from a SAS program.
  • Configure your LASR Server to start using the AutoLoad facility.

Start your non-distributed LASR Server from a SAS program

Here is a sample program that you might use to start a non-distributed LASR Server:

/* Start the LASR Analytic Server by defining the LASR library*/
libname LASRLIB SASIOLA 
        startserver  host="sasserver01.race.sas.com" port=10013
        signer="sasserver05.race.sas.com:7980/SASLASRAuthorization";
 
/* Keep the SAS session up until SERVERTERM received */
proc vasmp;
   serverwait  port=10013;
quit;

 

This program could be scheduled or set as a service under UNIX or Windows to be executed as soon as SAS Visual Analytics is started/restarted. Whichever strategy you use, you will want to have the code run after these services are up and available:

The SAS Metadata Server.
The Object Spawner on the SAS Visual Analytics Root Node.
The SASLASRAuthaurization service on the Middle Tier:

Start the non-distributed LASR Server Using the AutoLoad capability

AutoLoad runs as a periodic scheduled task. In the standard configuration, a new run of AutoLoad is started every 15 minutes.
AutoLoad periodically scans the contents of a designated host directory, which is referred to as the AutoLoad data directory or drop zone.
AutoLoad will automatically start the associated SAS LASR Server, if it is not yet started.

If you do not already have a LASR library configured with AutoLoad, you will need to use the SAS Deployment Manager application to configure an AutoLoad directory.

In Administration Tasks, choose Configure an AutoLoad Directory for SAS Visual Analytics. And follow the instructions.

Once you have AutoLoad setup, you must make sure certain LASR Library Extended Attributes are set correctly to ensure that the AutoLoad process will automatically start your LASR Server. You will want to set/verify the following attributes for the LASR library:

  • To enable the LASR Server AutoStart only:

  • VA.AutoLoad.AutoStart: YES to indicate that you want the associated LASR Server to be started if it is not already running.
  • VA.AutoLoad.Enabled: YES to enable the AutoLoad process for the Library.
  • To enable the LASR table(s) AutoLoad (optional):

  • VA.Default.MetadataFolder: to relocate the table(s) metadata registration against a specific metadata folder.
  • VA.Default.Location: to specify the location of the table directory at OS level.
  • VA.Default.Sync.*: to manage the table(s) from the VA.Default.Location.

On your SAS Visual Analytics machine, you have to:

  • Set the appropriate security against the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef] to be sure that the appropriate LASR Server administrator will be allowed to manage it.
  • Set the AutoLoad process frequency (default is 15 minutes).
    “TIME_INTERVAL_MINUTES=[Your-Value]” in the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] file.
    Note: Reference the SAS Visual Analytics Administration Guide for more about  the timing of AutoLoad.
  • Schedule the AutoLoad process using the LASR Server administrator account responsible to manage this particular LASR Server by executing the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] script.

Validate the AutoLoad setup by stopping the SAS LASR Server from SAS Visual Analytics Administrator application, or using SAS code. Wait for the “TIME_INTERVAL_MINUTES=[Your-Value]“, and look at the LASR Server status in SAS Visual Analytics Administrator application, and the AutoLoad logs in [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/Logs (one log file each time the AutoLoad process is executed).

Whichever technique is used, the non-distributed LASR server will no longer be dependent on the middle-tier.

I hope this article has been helpful to you.

How LASR servers are started from SAS Visual Analytics Administrator was published on SAS Users.

4月 172017
 

In this post, I will explain how LASR Servers (both Distributed and Non-distributed) are started from the SAS Visual Analytics Administrator application. We will also look at one particular issue and I will provide you with more details to understand the situation and two strategies to address this issue.

When you start a LASR Server from the Visual Analytics Administrator application, the system processes your request in slightly different ways depending on whether you are starting a distributed or non-distributed LASR Server.

What happens in the background for a distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the distributed LASR Server startup code generated in step 2, and the SAS Workspace Server session executes it.

6.     As soon as the distributed LASR Server startup code is executed, a distributed LASR Server instance is created. This instance is independent from the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection drop down. But the LASR Server instance is up and persistent until the administrator stops it.

What happens for a non-distributed LASR Server?

1.     The administrator starts a LASR Server from the Visual Analytics Administrator application.

2.     The Visual Analytics Administrator application generates the required code and sends it to the JES to be executed on the SAS Visual Analytics Root Node.

3.     The JES invokes the SAS Object Spawner on the Visual Analytics Root Node.

4.     The SAS Object Spawner initializes a SAS Workspace Server session.

5.     A client connection is established between the JES and the SAS Workspace Server session.
The JES sends the non-distributed LASR Server startup code generated on step 2, and the SAS Workspace Server session executes it.

6.     As soon as the non-distributed LASR Server startup code is executed, a non-distributed LASR Server instance is created. This instance is dependent on the SAS Workspace Server session.
After the distributed LASR Server startup code executes, the SAS Workspace Server session, and the client connection become persistent until the administrator stops the non-distributed LASR Server.
The SAS Workspace Server session and the client connection are required for the non-distributed LASR Server to be up and persistent.

Potential non-distributed LASR Server issue

The client connection between the JES and the SAS Workspace Server session in non-distributed deployment is crucial. This connection has to be persistent during the non-distributed LASR Server lifetime. As soon as the JES or SAS Workspace Server session goes down, the client connection is broken and the non-distributed LASR Server will go down as well. And, its data become unavailable.

If administrators manage their SAS non-distributed LASR Servers from the SAS Visual Analytics Administrator web application, this will create a dependency between the non-distributed LASR Servers and the middle tier - more specifically with the SASServer1_1 instance (the sas.wip.soapservices application). This dependency does not exist for distributed LASR Servers.

When the dependency exists, each time the middle tier or the SASServer1_1 instance is down, all non-distributed LASR Servers that were managed using the SAS Visual Analytics Administrator will go down automatically because the client connection to the non-distributed LASR Server is broken and its associated SAS Workspace Server session will go down.

This issue will also appear if the network connection between the Middle Tier and the SAS Visual Analytics Root Node is broken. This will break the client connection and terminate the SAS Workspace Server session(s) and their associated non-distributed LASR Server(s).

How can we prevent the issue?

I can think of at least two techniques you can use to prevent the dependency of your non-distributed LASR Servers upon your middle-tier:

  • Start your non-distributed LASR Servers from a SAS program.
  • Configure your LASR Server to start using the AutoLoad facility.

Start your non-distributed LASR Server from a SAS program

Here is a sample program that you might use to start a non-distributed LASR Server:

/* Start the LASR Analytic Server by defining the LASR library*/
libname LASRLIB SASIOLA 
        startserver  host="sasserver01.race.sas.com" port=10013
        signer="sasserver05.race.sas.com:7980/SASLASRAuthorization";
 
/* Keep the SAS session up until SERVERTERM received */
proc vasmp;
   serverwait  port=10013;
quit;

 

This program could be scheduled or set as a service under UNIX or Windows to be executed as soon as SAS Visual Analytics is started/restarted. Whichever strategy you use, you will want to have the code run after these services are up and available:

The SAS Metadata Server.
The Object Spawner on the SAS Visual Analytics Root Node.
The SASLASRAuthaurization service on the Middle Tier:

Start the non-distributed LASR Server Using the AutoLoad capability

AutoLoad runs as a periodic scheduled task. In the standard configuration, a new run of AutoLoad is started every 15 minutes.
AutoLoad periodically scans the contents of a designated host directory, which is referred to as the AutoLoad data directory or drop zone.
AutoLoad will automatically start the associated SAS LASR Server, if it is not yet started.

If you do not already have a LASR library configured with AutoLoad, you will need to use the SAS Deployment Manager application to configure an AutoLoad directory.

In Administration Tasks, choose Configure an AutoLoad Directory for SAS Visual Analytics. And follow the instructions.

Once you have AutoLoad setup, you must make sure certain LASR Library Extended Attributes are set correctly to ensure that the AutoLoad process will automatically start your LASR Server. You will want to set/verify the following attributes for the LASR library:

  • To enable the LASR Server AutoStart only:

  • VA.AutoLoad.AutoStart: YES to indicate that you want the associated LASR Server to be started if it is not already running.
  • VA.AutoLoad.Enabled: YES to enable the AutoLoad process for the Library.
  • To enable the LASR table(s) AutoLoad (optional):

  • VA.Default.MetadataFolder: to relocate the table(s) metadata registration against a specific metadata folder.
  • VA.Default.Location: to specify the location of the table directory at OS level.
  • VA.Default.Sync.*: to manage the table(s) from the VA.Default.Location.

On your SAS Visual Analytics machine, you have to:

  • Set the appropriate security against the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef] to be sure that the appropriate LASR Server administrator will be allowed to manage it.
  • Set the AutoLoad process frequency (default is 15 minutes).
    “TIME_INTERVAL_MINUTES=[Your-Value]” in the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] file.
    Note: Reference the SAS Visual Analytics Administration Guide for more about  the timing of AutoLoad.
  • Schedule the AutoLoad process using the LASR Server administrator account responsible to manage this particular LASR Server by executing the [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/schedule.[sh|bat] script.

Validate the AutoLoad setup by stopping the SAS LASR Server from SAS Visual Analytics Administrator application, or using SAS code. Wait for the “TIME_INTERVAL_MINUTES=[Your-Value]“, and look at the LASR Server status in SAS Visual Analytics Administrator application, and the AutoLoad logs in [SAS-Configuration-Directory]/Levn/Applications/AutoLoad/[Your-LASR-Server-Library-LibRef]/Logs (one log file each time the AutoLoad process is executed).

Whichever technique is used, the non-distributed LASR server will no longer be dependent on the middle-tier.

I hope this article has been helpful to you.

How LASR servers are started from SAS Visual Analytics Administrator was published on SAS Users.

1月 212016
 

GridManagerAs of SAS 9.4 M3, SAS Grid Computing has a new tool: the Grid Manager Module for SAS Environment Manager 2.5. This module provides some of the same monitoring and management functions as IBM Platform RTM for SAS, so you can monitor and manage your grid using the same application that you use to manage the rest of your SAS environment.

As an LSF administrator, if defined also as a SAS Environment Manager user, you can access this Web application/module from SAS Environment Manager (http://YourSAS.AppServer:7080/)

GridManagerModule

Note: It is also possible to access the Grid Manager Web application directly through http://YourSAS.AppServer:7980/SASGridManager.

Out of the box, and based on deployment and configuration best practices, the Grid Manager Module for SAS Environment Manager 2.5 may not work as expected. The SAS Grid environment requires some post installation/configuration steps.

The goal of this post is to help you learn about these steps…

Why does SAS Grid Manager Module for SAS Environment Manager 2.5 require post installation/configuration steps?

The best practices for SAS Grid Computing are to deploy all SAS software components using a specific SAS Installation User (I.E.: sas or sasinst) account, and to deploy all IBM Platform Suite for SAS software components using a specific LSF Administrator User (I.E.:lsfadmin) account. The SAS Installation User and the LSF Administrator User are both members of a unique user group, generally “sas“.

Traditionally, the SAS software components are installed and configured using the SAS Deployment Wizard application, and the IBM Platform Suite for SAS software components are installed and configured using the IBM Platform installation tools.

But since SAS 9.4 M3, there is one component of the IBM Platform Suite for SAS software, IBM Platform PWS (Platform Web Services) that is installed and configured using the SAS Deployment Wizard. Because of that, IBM Platform PWS is installed, configured and managed by the SAS Installation User, not the LSF Administrator.

The IBM Platform PWS component, as the SAS Grid Manager Module for SAS Environment Manager 2.5, is a middle-tier application that “interfaces” with the IBM Platform LSF components that reside on the SAS Grid Control Server.

Each time an administrator manages the LSF or HA (High Availability) configuration using the SAS Grid Manager Module for SAS Environment Manager 2.5, this module has to read from and/or write to information from IBM Platform LSF components on the SAS Grid Control Server through IBM Platform PWS from the middle-tier host. If all of these components are not installed, configured, and managed by the same user, these actions may generate errors making it impossible to manage LSF and High Availability configurations.

For this reason, post installation/configuration steps are required to make the SAS Grid Manager Module for SAS Environment Manager 2.5 fully functional.

The post installation/configuration steps…

1 -   Obtain the required IBM Platform PWS fix for SAS Grid

Contact SAS Tech Support to obtain the IBM Platform PWS fix for SAS Grid.
The fix is named pws9.1.3_build65123.zip. The fix will contain a Readme.txt file that explains the installation process.

2 -   Configure your SAS Grid environment

A.  It is required that passwordless SSH be configured between the IBM Platform PWS host and the IBM Platform LSF master host (I.E.: SAS Grid Control Node) for the user who starts the IBM Platform PWS SpringSource tcServer instance (The SAS Installation User). This will allow the IBM Platform PWS user to SSH to the IBM Platform LSF master host as the Primary LSF Administrator (I.E.: ssh lsfadmin@lsf_master_host) without a password prompt.

B.  On the IBM Platform LSF master host (I.E.: SAS Grid Control Node) you need to modify/adjust the permissions against the IBM Platform LSF configuration files.

i.  Go to the IBM Platform LSF configuration directory.
[PlatformSuiteForSAS-Top-Directory]/lsf/conf/

ii.  Add the group write (‘w‘) permission to all files located under this directory which will allow the SAS Installation User to write/modify these files.
chmod -R g+w *

iii.  Add the group read (‘r‘) permission to certain files located under this directory which do not have it by default which will allow the SAS Installation User to read these files.

a.  Go to [PlatformSuiteForSAS-Top-Directory]/lsf/conf/ego/sas_cluster/kernel

b.  Change the group permissions on specific files
chmod -R g+r dh512.pem pamauth.conf server.pem users.xml

3 -   Install the IBM Platform PWS fix for SAS.

A.  Stop IBM Platform PWS

B.  Apply the IBM Platform PWS webapps/platform fix.

i.  Go to [SAS-Configuration-Directory]/Levn/Web/Staging/exploded/platformpws/platform

ii.  Backup, and replace these specific .class and .properties files (detailed in the Readme.txt file) with files from the IBM Platform PWS fix.

./WEB-INF/classes/com/platform/gui/pac/util/shell/ShellHelper.class
./WEB-INF/classes/com/platform/pws/pwsResource.properties
./WEB-INF/classes/com/platform/pws/util/lsfConfig/LSFConfigApplyUtil.class
./WEB-INF/classes/com/platform/pws/util/lsfConfig/LSFConfigApplyUtil$DataFormatException.class
./WEB-INF/classes/com/platform/pws/util/NonShareHelper.class
./WEB-INF/classes/com/platform/pws/util/NonShareHelper$FileException.class
./WEB-INF/classes/com/platform/pws/util/PWSUtil.class
./WEB-INF/classes/com/platform/pws/util/PWSUtil$ResultEntry.class
./WEB-INF/classes/com/platform/pws/webservice/impl/LSFConfigWebServiceImpl.class

iii.  Add this specific .class file from the IBM Platform PWS fix.

./WEB-INF/classes/com/platform/pws/util/lsfConfig/LSFConfigApplyUtil$LSFConfigApplyException.class

iv.  Go to [SAS-Configuration-Directory]/Levn/Web/WebAppServer/SASServer14_1/sas_webapps/platform.web.services.war

v.  Repeat steps "ii." and "iii." against this directory.

C.   Start/Restart IBM Platform PWS.

 

After applying these post configuration steps, you should now be able to use the SAS Grid Manager Module for SAS Environment Manager 2.5 to manage your grid much like you do with IBM Platform RTM.

GridManagerModule2

I hope this article has been helpful to you.

tags: SAS Administrators, SAS Environment Manager, SAS Grid Manager, SAS Prof

SAS Grid Series: Grid Manager Module for SAS Environment Manager – post configuration was published on SAS Users.

11月 262014
 

Several new capabilities and components are available in SAS Environment Manager 2.4, the web-based administration solution for a SAS environment. For me, the most important enhancement is probably the SAS Environment Manager Service Management Architecture Framework, which provides features and functions that enable SAS Environment Manager to fit into a service-oriented architecture (SOA). The Management Architecture Framework includes:

All these components are organized around the heart of the Service Management Architecture Framework: the SAS Environment Manager Data Mart. In this post, I’d like to share more details about its setup and use.

What is the SAS Environment Manager Data Mart?

The SAS Environment Manager Data Mart is a collection of tables that store monitored data in a data infrastructure that is provided by the SAS Environment Manager Extended Monitoring. These data are collected using the various ETL processes and stored in a standard format, making it easy for SAS administrators to run audit reports and perform analyses on performance and usage.

The data in the Data Mart are also used to populate predefined stored process reports that are provided as part of SAS Environment Manager Report Center. SAS administrators may also use the Data Mart tables for custom reporting and analysis, or they can be used to feed SAS Visual Analytics reports for the administrator autoload environment. You can the full documentation on the SAS Environment Manager Data Mart in the SAS® Environment Manager 2.4 User’s Guide.

How is data collected and stored?

The SAS Environment Manager Data Mart contain standardized data from:

  • Metrics data read from monitored resources across the SAS environment
  • Data read from SAS server’s and spawner’s logs
  • Specific data read and extracted from SAS solutions

Each of these data sources has a separate data source and ETL process:

  • Agent-Collected Metrics (ACM) ETL. This ETL Process runs against the SAS Environment Manager Database. It collects these data, standardizes it, and stores it in the SAS Environment Manager Data Mart tables (ACM tables).
  • Audit, Performance and Measurement (APM) ETL. This ETL Process runs against SAS logs. You probably know this component as the downloadable SAS APM package. This package is now totally integrated in SAS Environment Manager. It collects these data, standardizes it and stores it in the SAS Environment Manager Data Mart tables (ARTIFACT tables).
  • Solution kit ETL processes. The solution kit framework can extend the capabilities of SAS Environment Manager to support specific solutions or applications. The framework includes support for collecting and storing operation information about the solution in the SAS Environment Manager Data Mart tables (KIT tables).

Information stored in these tables can be consumed using predefined or custom reports within SAS Environment Manager, SAS Visual Analytics or the application of your choice through direct access to the SAS data sets.

Click on the image below to see a diagram of data flow within the SAS Environment Manager Data Mart.

EV_datamart

How do I set up the data mart?

Installation and configuration. The SAS Environment Manager Service Management Architecture package is deployed and configured on the SAS Application context host using the SAS Deployment Wizard. For multi-context SAS deployments, the SAS Environment Manager Service Architecture package will be installed on one host in one SAS Application context and is treated as a single deployment.

Initialization steps. To begin, initialize SAS Environment Manager Extended Monitoring using a script provided with the software. During this step, different objects and components are created in SAS Environment Manager, and all the required SAS Environment Manager Data Mart tables are created.

The initialization of ACM, APM and Solution Kit ETL processes are independent of one another and require additional steps. The SAS administrator may initialize all or only one or two of them, depending on their auditing needs. For detailed initialization instructions for APM, ARM and Solution Kit ETL processes, please refer to the documentation: SAS® Environment Manager 2.4 User’s Guide (Chapter 9: Initializing and Enabling the Service Management Architecture).

ETL processes. By default, the ETL processes are executed every night at a predetermined time. This schedule is managed by SAS Environment Manager. If you want to execute these processes more frequently, you can schedule new jobs outside SAS Environment Manager, using the master ETL scripts provided with the software.

After you initialize each ETL process,  it’s a good practice is to run it manually to populate the SAS Environment Manager Data Mart. Otherwise, you will have to wait overnight to see the results and determine if data are being collected as you want.

What’s available in the Report Center?

The Report Center provides a convenient access point for the reports that are provided as part of SAS Environment Manager Service Management Architecture.

The Report Center contains predefined reports based on the data that are stored in the SAS Environment Manager Data Mart. These stored processes and reports were created during the SAS Environment Manager Extended Monitoring initialization and remain empty until one or more of the ETL processes is enabled.

The predefined stored processes and report provide a view of the performance and status of your SAS environment and its resources. These are only samples of the full range of reports that can be created against the SAS Environment Manager Data Mart data. SAS administrators can create custom stored processes and reports to meet their organization’s needs and store them in an appropriate metadata folder structure.

For detailed information about Report Center, please refer to the documentation: SAS® Environment Manager 2.4 User’s Guide (Chapter 10: Using the Report Center).

I hope this article has been helpful in introducing you to my favorite new features in SAS Environment Manager.

tags: monitoring jobs and processes, SAS Administrators, SAS Environment Manager, SAS Professional Services