topic how to find Where Sas di job is running when it is runnig through SAS LSF in SAS Data Management

how to find Where Sas di job is running when it is runnig through SAS LSF

MG18 — Thu, 16 Mar 2017 07:40:39 GMT

We have scheduled One flow which run through LSF and one job in that flow which is running from last 8 hours. Usually it took only 1 hour but today it is taking more than 10 hours and this same job/flow has been running successfully from last 2 years and no changes has been made also.

i want to know where this job is runnig ? this there any to find out where sas di job is running ?

SAS DI job consist only user wrriten code and in that it is taking data from source and updating it through sas code only.

O/s -LINUX

Re: how to find Where Sas di job is running when it is runnig through SAS LSF

LinusH — Thu, 16 Mar 2017 08:09:37 GMT

http://support.sas.com/documentation/cdl/en/gridref/69583/HTML/default/viewer.htm#p1kgfem7vpt7ain1r2ce8jdcc3h5.htm

Re: how to find Where Sas di job is running when it is runnig through SAS LSF

MG18 — Thu, 16 Mar 2017 09:44:54 GMT

Hi ,

We are using the SAS LSF we dont have Grid manager and also we are using sas 9.3

Re: how to find Where Sas di job is running when it is runnig through SAS LSF

LinusH — Thu, 16 Mar 2017 12:29:00 GMT

Oh, I assumed when you asked on which host the batch was running on, that you had a grid.

So then there's just one host chose from, or do I miss something...?

Re: how to find Where Sas di job is running when it is runnig through SAS LSF

Patrick — Fri, 17 Mar 2017 23:48:30 GMT

Once you found the SAS log the first thing I'd be looking into:

1. are there much higher data volumes than usually (i.e. after a bad data load into source)

2. bad data loaded resulting in many to many relationships where the code expects it to be 1:1 or 1:m

3. has anything structurally changed in the data source or data target

- disabled, removed or changed index

- change to a column (i.e. change from VARCHAR5 to VARCHAR4000)

- additional columns and somewhere in the SAS code a SELECT *

- ......

Comparing the real times between a "good" and the "bad" SAS log should tell you which step needs further investigation.

I'd probably also check if there had been any maintenance work going on (like a massive backup process on the target DBMS).