How to differentiate a Job from a Job Sequence in script

[BradMiller]

Hello,

I'm writing a UNIX script which modifies 'dsjob -run' present in existing scripts to either 'dsjob -run -mode RESET' or 'dsjob -run -mode NORMAL' based on job type i.e., Job or Sequence respectively.

Is there a way to find out if a job is a DataStage Job or Sequence from UNIX command line?

Thanks for your time.
Brad

[chulett]

Not directly, no. It would be nice if "dsjob -jobinfo" included this but it doesn't.

You'd need to query the repository for the JOBTYPEIND value of that job. A search will turn up mulitple conversations on the topic, including this one. That should still work fine in the 8.x release, however someone may know the equivalent sql query for the XMETA repository as well.

[Meera]

There is just one command to run either sequence or job. One way out to differentiate between the two from unix command line would be based on their naming standards used. Normally all jobs would be named in a way different from the way sequence is defined. Based on the ETL naming standards, there would be a different literals to specify a job versus specifying a sequence. Might be you could use that as a key to seperate both, at command line.

[chulett]

Ah... if only it was that easy.

[BradMiller]

Is there a way to query repository from UNIX command line?

[chulett]

Sure, I wouldn't have mentioned it otherwise.

You can run any valid 'sql' that you would in say the Administrator from the command line. I'll see if I can find an example, but a search for "uvsh" or "dssh" should turn something up.

One example, should give you the basic idea:

viewtopic.php?t=122516

[BradMiller]

It worked !!!

Thanks a lot.

[pnpmarques]

In DS8 you could try:
dssearch -ljobs -uses -oj <PROJECT> <JOB>

[kduke]

You should reset a job if the status is not in a runable state.

[sbass1]

Hi,

I'm trying to do something similar: I want to conditionally reset a job, but not a sequence.

Rationale: An aborted job needs to be reset before it will run. An aborted sequence does not (at least in my environment - I think that's what Aborted/Restartable means in Director. But, resetting the sequence resets its checkpoint, so it restarts from the beginning, which I don't want.

So, in pseudocode: If JobName is not a Sequence Then If LastRun Failed Then Reset.

Here are some code snippets for what I'm doing, in case others find it useful:

Did the last run abort?

Code: Select all

LAST_RUN=$(${DSHOME}/bin/dsjob -jobinfo $PROJECT $JOB_NAME 2> /dev/null | egrep "Job Status" | cut -f2 -d:)
case "$LAST_RUN" in
   *FAILED*)
      printf "\nLast run of $_PROJECT $_JOB_NAME aborted, Resetting Job $_PROJECT $_JOB_NAME\n"
      printf "${DSHOME}/bin/dsjob -run -mode RESET $PROJECT $JOB_NAME"
              ${DSHOME}/bin/dsjob -run -mode RESET $PROJECT $JOB_NAME
      sleep 5
   ;;
   *)
   ;;
esac

Is the named item a job or sequence?

Code: Select all

dssh "SELECT JOBTYPE,NAME FROM DS_JOBS WHERE NAME='TestJob' AND JOBTYPE='2';" | egrep 'records listed' | cut -f1 -d" "

returns 0

Code: Select all

dssh "SELECT JOBTYPE,NAME FROM DS_JOBS WHERE NAME='TestJob_Seq' AND JOBTYPE='2';" | egrep 'records listed' | cut -f1 -d" "

returns 1

(JOBTYPE=2 == Sequence Job)

Now, my questions:

1) Is there any way to get dssh or uvsh to "point" to the right project without actually cd'ing to it? This is a very generic script; I'd prefer not to cd to the project directory unless I have to.

2) Is there a way to cancel the !@#$ default behaviour of dssh and uvsh from converting the case of the input commands? foo becomes FOO, FOO becomes foo. A right royal PITA when I'm trying to type ... NAME='TestJob' (case sensitive).

Thanks...

P.S.: IBM, if you're "listening", you sure don't make this process easy, do you? A lot of hopping through hoops to support functionality that should be OOTB IMO.

[ArndW]

(1) Not easy. You could enter the uvsh then issue a "LOGTO {Projectname}" command.
(2) "PTERM CASE NOINVERT" will do the trick for you.

[chulett]

Dammit, Arnd... beat me to it.

[sbass1]

(1) Not easy. You could enter the uvsh then issue a "LOGTO {Projectname}" command.
(2) "PTERM CASE NOINVERT" will do the trick for you.

OK, in the shell, I cd to my project directory.

Code: Select all

uvsh "SELECT JOBTYPE,NAME FROM DS_JOBS WHERE NAME='TestJob_Seq' AND JOBTYPE='2';" | egrep 'records listed' | cut -f1 -d" "

returns "1"

Code: Select all

uvsh "LOGTO DEV_GGS; SELECT JOBTYPE,NAME FROM DS_JOBS WHERE NAME='TestJob_Seq' AND JOBTYPE='2';" | egrep 'records listed' | cut -f1 -d" "

silently returns nothing. Both have $?=0.

Should I expect this second command to work?

If I enter the uvsh environment, then execute the commands, it works. But, I want to call this non-interactively from a script:

Code: Select all

> uvsh
DataStage Command Language 7.5
Copyright (c) 1997 - 2004 Ascential Software Corporation. All Rights Reserved
DEV_GGS logged on: Fri Aug 21 10:22:32 2009

>LOGTO DEV_GGS
>select jobtype,name from ds_jobs where name='tESTjOB_sEQ' and jobtype='2';   <<< friggin CASE INVERT breaks cut-and-paste.
DataStage/SQL: Table "ds_jobs" does not exist.
>PTERM CASE NOINVERT
>SELECT JOBTYPE,NAME FROM DS_JOBS WHERE NAME='TestJob_Seq' AND JOBTYPE='2';
JOBTYPE...    Job name............

2             TestJob_Seq

1 records listed.
>LOGTO UAT_GGS
>SELECT JOBTYPE,NAME FROM DS_JOBS WHERE NAME='TestJob_Seq' AND JOBTYPE='2';
Compiling "JOBTYPE".
IF JOBTYPEIND =  THEN 0 ELSE JOBTYPEIND

0 records listed.
>LOGTO TST_GGS
>SELECT JOBTYPE,NAME FROM DS_JOBS WHERE NAME='TestJob_Seq' AND JOBTYPE='2';
Compiling "JOBTYPE".
IF JOBTYPEIND =  THEN 0 ELSE JOBTYPEIND

0 records listed.
>

Quick Craig...you can still get in the last post lol

[chulett]

I would wager it's the trailing semi-colon after the LOGTO that's causing it to fail, it doesn't need one, only 'sql' does. I'm afraid I don't know what the proper separator would be and have only done this in a 'here document' style before:

Code: Select all

./bin/uvsh<<EOF 
  LOGTO <Project>
  SELECT XXXXXX 
EOF

And while you do need the 'PTERM' statement to make an interactive cut/paste work, is it really needed in a scripted session like this?

[sbass1]

Thanks Craig,

And while you do need the 'PTERM' statement to make an interactive cut/paste work,

Since command recall (often bound to up-arrow) doesn't work (which is fine, I think other SQL utilities are similar), I mark the text in Putty, then paste it. And the default behaviour transforms the text to unworkable format.

is it really needed in a scripted session like this?

No, my comment was just referring to the interactive session.

IMO PTERM CASE INVERT is a horrid default. And why are the select statements case sensitive anyway? Why should SELECT * FROM DS_JOBS vs. select * from ds_jobs make any difference? If there's a good reason for the default behavior I can't see it.

(No reply needed, just Monday morning ranting...)