Thursday, August 28, 2014

During installation, the SAS Deployment Wizard creates a sas.servers script on each UNIX and z/OS server tier machine. You can perform the following tasks with this script:

start, stop, or restart all of the SAS servers and spawners on the machine in the correct order by using a single command
display the status of all the SAS servers and spawners on the machine by using a single command

Note: To use the script on z/OS systems, you must run the servers under UNIX System Services (USS). On z/OS systems, SAS recommends operating servers as started tasks. See Starting and Stopping SAS Servers on z/OS. [cautionend]

The script performs the preceding tasks for all instances of the following servers, spawners, and services that are installed on the machine:

SAS Metadata Server
SAS object spawner
SAS OLAP Server
SAS/CONNECT spawner
SAS/SHARE server
SAS Table Server
SAS Services Application (Remote Services)
SAS Deployment Tester server

The sas.servers script is located in the top level of your configuration directory. For example, in a Level 1 deployment, the script is located in the following path:SAS-configuration-directory/Lev1/.

CAUTION:: You should not directly update the sas.servers script.If the script needs to be updated (for example, to add new servers or remove servers), then regenerate the script by using generate_boot_scripts.sh.

Use the sas.servers Script to Start, Stop, or Restart All Servers or to Display the Status of Servers

To use the sas.servers script to start, stop, or restart all servers on a UNIX or z/OS machine or to display the status of all servers on the machine, follow these steps:

Log on as the SAS Installer user (for example, sas).
Go to the directorySAS-configuration-directory/Lev1/.
Type ./sas.servers followed by one of the following arguments:

start

starts the servers and spawners in the following order: SAS Metadata Server, SAS OLAP Server, SAS object spawner, SAS/SHARE server, SAS/CONNECT spawner, SAS Table Server, SAS Remote Services, SAS Deployment Tester server.
Note: The OLAP server, object spawner, SAS/SHARE server, SAS/CONNECT spawner, and table server require that the metadata server be running. If the metadata server is configured on a different host machine, make sure that the server is running before you use this script. [cautionend]

stop

stops the servers and spawners in the following order: SAS Deployment Tester server, SAS Remote Services, SAS Table Server, SAS/CONNECT spawner, SAS/SHARE server, SAS object spawner, SAS OLAP Server, SAS Metadata Server.
Note:

When you stop the metadata server, any dependent servers and spawners (whether they are on the same host machine or a different machine) will stop running.
Before you stop an OLAP server, you should first stop the active sessions, as follows:
1. In SAS Management Console, expand the Monitoring node and the SAS OLAP Server Monitornode.
2. Right-click the name of the logical SAS OLAP Server, and select Connect.
3. In the dialog box that appears, enter your user name and password and click OK.
4. Right-click the name of each session that you want to close, and select Close Session.

restart

stops and then starts the servers and spawners in the following order: SAS Metadata Server, SAS OLAP Server, SAS object spawner, SAS/SHARE server, SAS/CONNECT spawner, SAS Table Server, SAS Remote Services.

status

displays the current status of the servers and spawners in the following format:
server-name server-instance(process-ID) is running|is stopped.
For example, the following messages mean that two instances of the SAS OLAP Server are configured on the machine. The first instance is running, and the second instance is stopped:

SAS OLAP Server 1 (pid 29529) is running
SAS OLAP Server 2 (pid 29530) is stopped

Using generate_boot_scripts.sh to Regenerate the sas.servers Script

About generate_boot_scripts.sh

The generate_boot_scripts.sh script enables you to automatically regenerate the sas.servers script for a particular UNIX or z/OS host machine. This feature is useful in the following types of situations:

You have configured a new server or spawner on the machine. In this situation, the script generation process detects the new server or spawner and adds it to the sas.servers script.
You have removed a server or spawner configuration from the machine. In this situation, the script generation process detects the absence of the server or spawner and removes it from the sas.servers script.
You want to remove a server or spawner from the script so that you can operate it separately, or you want to add a server or spawner that you previously removed.
You have changed the location of the server's log.

About the server-name.srv Files

On UNIX and z/OS systems, each server's configuration directory contains a file called server-name.srv. For example, the metadata server's configuration directory contains a file called MetadataServer.srv, and the workspace server's configuration directory contains a file called WorkspaceServer.srv.
The generate_boot_scripts.sh script accesses each of the server-name.srv files to determine which servers and spawners are to be included in the sas.servers script. If a server's server-name.srv file contains the keyword ENABLE, then the server is included in the script. If the file contains the keyword DISABLE, then the server is excluded from the script.
In the initial configuration, all server-name.srv files contain the keyword ENABLE.
The server-name.srv files also contain the path to the server's startup script and the path to the server's log files.

Regenerate the sas.servers Script

To regenerate the sas.servers script, follow these steps:

Log on as the SAS Installer user (for example, sas).
If you want to remove a server or spawner from the script, or if you want to add a server or spawner that you previously removed, follow these steps:
1. Navigate to the server's configuration directory and open the file server-name.srv in an editor.
  For example, if you want to remove the SAS/SHARE server from the script, you would go to SAS-configuration-directory/Lev1/ShareServer and open the file ShareServer.srv.
2. Locate the line that contains the keyword ENABLE or DISABLE. If you want to exclude the server from the sas.servers script, change the keyword to ENABLE. If you want to include the server in the sas.servers script, change the keyword to DISABLE. Save the file.
Go to the directorySAS-configuration-directory/Lev1/.
Enter the following command:./generate_boot_scripts.sh
A new sas.servers script is created to reflect the servers that are currently configured on the machine. If any of the server-name.srv files contain the keyword DISABLE, the following message appears:
<number-of-disabled-servers> SAS servers were explicitly disabled in their .srv files

Install sas.servers as a Boot Script

On UNIX machines, you can choose to install the sas.servers script as a boot script so that the servers will start automatically when you start the machine. The comments in the sas.servers script contain installation instructions that are tailored to your operating environment.

Top of Page

Monday, August 25, 2014

Configure - Changing SASAdm password

Here is a step by step process for change passwords on SAS EBI

1. ADD *SAS (this is the Local or Domain account you install SAS with) to the AdminUser.txt file.
2. Restart the Metadata server
3. In you SASHome directory start the SAS Deployement Manager.
4. Complete the prompts correctly. and Once this is all complete get out SAS DM.
5. Remove *SAS from the AdminUser.txt file
6. Restart the SAS metadata server.

Wednesday, July 9, 2014

Boot time of your computer

From the run prompt. Type CMD.
In the CMD window type systeminfo.
A listing will give the boot time as well as system information.

Firewall timeout issue

There are many times that you start to run a Enterprise Guide flow process and it takes a large amount of time to complete the processing of the flow. During that time your Enterprise Guide project losses connection and you have to start over. This has been a big issue for our state agency.
So let me tell you what is not the problem. Enterprise Guide is not the problem, so there is no setting or configuration that can be changed to correct this problem. The changes that need to be made are on the firewall side of this equation. When Enterprise Guide opens a connection it opens a connection to the metadata server port as well as a connection to the workspace server port. That workspace server port is continually be accessed so the timeout does not occur there. The connection to the metadata server is where the problem lies. Once the metadata verify your credentials it is not accessed again. When the firewall sees that the connection to the metadata server has not be accessed within the time that it has been set (most of the time 1 hour) it breaks that connection and that cause your flow process to not be able to be completed. Have your firewall timeout increase to more than the time it take for you to complete your flow process and the process will complete without problems.

Thursday, June 26, 2014

Extending the Observation Count for a 32-Bit SAS Data File

SAS Support Link for SAS 9.4 EBI systems

Understanding the Observation Count in a SAS Data File

SAS Support Link

What directory is my EGP in (by code)

Question:

I wonder how to get by code the directory of the .egp I'm currently in.

Answer:

This will return the location of the project.

%put &_CLIENTPROJECTPATH;

How to speed up a Proc SQL sequence with Proc Sorts & Data merge

8. Re: A join in proc sql takes 5 hours and consumes a lot of disk space

SergioSanchez Jun 4, 2014 7:34 AM (in response to PGStats)

The data are in an Oracle Server and I make a copy of the datasets connecting to the server through a libname statement and after

data a;

set b (where = (var1<= date and var2>date and var3>date); where "b" is the dataset on the Oracle server

I do a left join, the target in most of the cases is to obtain the surrogate key of the second table and one or two variables more.Something like this

proc sql;

create table x as

select a.*, b.var1, b.var2, b.var3

from dataset1 as a left join dataset2 as b

on (a.var1 = b.var1);

quit;

There is no index at all in any of the datasets and no message appears in the log about an issue in the performance
Report Abuse

Like (0)

Reply
Helpful Answer9. Re: A join in proc sql takes 5 hours and consumes a lot of disk space

KurtBremser Jun 4, 2014 8:01 AM (in response to SergioSanchez)

Try this:

proc sort

data=b /* this is your original oracle data set */

(where = (var1<= date and var2>date and var3>date)

out=dataset1

;

by var1;

run;

proc sort

data=dataset2 (keep=var1 var2 var3)

out=data2x

;

by var1;

run;

data x;

merge

dataset1 (in=a)

data2x

;

by var1;

if a;

run;

Compare this method and the SQL method using options fullstimer;

Also watch the disks while the jobs are running; you may be surprised by the disk usage(s).

I remember when I first came across a piece of code done by a SAS consultant that had > 100 lines. I quickly saw that I could do the same in one create table with ~ 10 lines in PROC SQL, so why bother with all that code? Then I had to wait 5 hours for my SQL to finish, while his code took about 20 minutes to produce the same result. With less than half the disk space.

Wednesday, June 25, 2014

How to connect to Oracle using SQL Plus

First select SQL Plus from you all programs menu:

Next put in your Username, Password, and TNSNames.org path name with out the quotes.

After it is success log on you should see the version of the database you have just connected to. From here you can query the database with other commands.

_____________________________________________________________________

Dan Strickland

Inland Fisheries Division

Texas Parks and Wildlife

3407-A S.Chadbourne Street

San Angelo, TX 76903

Phone: 512-666-4546

DanwStrickland@gmail.com

Learn how you can help Texas State Parks

https://www.youtube.com/watch?v=FjqccYmx13w

Tuesday, June 24, 2014

How to configure the license file for Dataflux Data Management Studio 2.5

How to setup the license file for Dataflux Data Management Studio 2.5

This is the Initial Error I received on starting up Dataflux Data Management Studio 2.5. It could not locate my license file.

DM studio will not start unless that license file is in the location it is configured to. If you need to change the location in the configuration file that file is app.cfg located in the below directory.

Use notepad to change the directory and sid file name that contains you license information. be sure to save it as a cfg file and not a text file.

Once this is done start up DM studio and you should not get your initial error.

_________________________________________________________________