Client/server work flow(b/w EG and App server)

[jakarman]

The role of the objectspawner...

That process is starting all those subprocesses and does a user context  switch. Workspaces  (pooled/standard) and de Stored process servers.

To be able to do that the object spawner is needing all that information from the metadata-server. It will read that information when that object spawner process is started. That Includes the scritps ports userid-s and password-s. The user-ids/passwords are needed as shared/group accounts for the SP and pooled-WS.

These keys/passwords can be found/set at the general servers tab in the SAS-metadata (SMC).  This process of reading the metadataserver can be found in the metdataserver log. When more information is visible you can see the requests for users/passwords scripts.

When you have made errors in the metadata this information cannot be read anymore at startup. Your service will be down.

When the metadata server is not ready to handle requests for the objectspawner. The objectspawner may start but starting the services will fail.

The object spawner is connecting to the metadataserver there os text-configfile having the sastrust key being defined (and pswd) so it can connect (and do everything sastrust is allow to do).  

When  processes are running the objectspawner and metadataserver may be restarted without disturbing those running processes.

As a pitty in Unix it are dependent processes of the objectspawner, with thatl dependency they are going down also with that one.

Stored process

As the are mentioned: there are several parts on those. 1/ The sas source 2/ the sas metadata conection to a sas server  3/ the executing by either a WS or SP one.

The stored process approach makes sense when there is a SDLC (software Development Life Cycle) with a DTAP (Develop Test Acceptance Production) segregation.

Having approved tested/validated code deployed to production you can accept the usage of a shared/group account with limited usage. (no code changed allowed, validated users).

A webbased is a good example. AMO and Eguide can also use SP's (sas-code / metadata) either run by a SP or WS.

SAS DI is a development tool (only WS) that can generate the sas-code to be used in a SP definition (sas code / metadata).

The same word SP is used in several different meaningsm pinpoint on the meaning what it is about with every action.

[jakarman]

sasprofile,

1/ performance starts at the OS level. That is not SAS specific there is al lot about that.

   Configuring hardware for SAS: what you should know before you install - SAS Users 

2/ In the basic concepts 9.3 and 9.4 are not really different.  They changed as lot as example the VM-tools and the SAS/secure bundling.

   http://support.sas.com/documentation/cdl/en/whatsnew/64788/PDF/default/whatsnew.pdf

3/ Migration is described at Maintenance Releases and Product Upgrades All depends on what there is already running in the current situation

    metadata based, solutions, batch grid or just only Foundation by terminal usage (like SAS studio).

4/ That inventarization is the fist thing needed to be done

    Pre-req is sufficient SAS knowledge to ask for the needed things (chicken/egg problem what is first)

5/ There are many ways of deployments (multi tier) all is dependent on the target environments and their req-s.

It is not unusual to be faced by the need for repackaging the installation. leaving the SDW to be used on a isolated first machine that will become the source-image.

There are two stages in this that ins the installation and that gets being followed by the configuration. The configuration can need a lot of attention when there are business requirements and policies that are having conflicts with the SAS default approach.

  Pre-req is sufficient SAS and business and applicable policies knowledge to ask for the needed things (chicken/egg problem what is first)

It looks to me you are uncertain on 4 and 5.

[BStone]

To be honest, I would consult your SAS Account Manager to clarify your questions.

The majority of answers are based on different SAS version which are different to one another, espeically when it comes to the process of executing, querying, etc. SAS 9.4 and Grid functionality will also play a big and different role in terms of processing, depending how your environment is set up.

SAS documentation is great for guidance, but I would start by replicating exactly what you are trying to see:

1. Enable additional logging

2. Replicate whatever process you need information on, make sure you take note of the User ID and times your open a SAS Application, execute a job, etc.

3. Go through the server logs based on the User ID and times you noted in point 2.

That's the beauty of SAS, there is not just 1 way of setting servers / processes up.

[sasprofile]

Getting Data into SAS from Pivotal(HAWQ)

Hi all,

Please can anyone help me how to get data which is located in Pivotal(HAWQ) into SAS.

am using SAS 9.2 on solaris 5.10.

please give me step by step process to get data using SAS/ACCESS Interface to ODBC.

am completely new to this i dont know how to do this

I would really appreciate for all your help.

Thank you

[SASKiwi]

You should really start a new discussion for a new topic.....

However here is a good starting point (page 42) assuming SAS/ACCESS Interface to ODBC is already installed and licensed and you have the Pivotal ODBC driver installed:

http://support.sas.com/documentation/installcenter/en/ikfdtnunxcg/61994/PDF/default/config.pdf