Concurrently Accessing the Same Routine.

Nick_6789 · Post by **Nick_6789** » Thu Mar 23, 2006 9:33 pm

Hi all,

This error is randomly happening. Basically my job design is like this.

I have a job that concurrently runs 4 routine stages (Which all of them is acutally pointing to the same routine written just different table name parameter). And I am having the below error:

"DataStage Job 1036 Phantom 20788
[1908766] Done : DSD.RUN KOR_GetSysDate.KOR@KOR_F_01_NumberOfPremiumTransactions_Initial_Load@02 0/0 pSID=MIPRD pUID=STGMI pPwd=LL:@9:V@>9:L0F7I4JJ<BKI7F<>IM1Q4B pSrcTable="S_PMM001" pEnv=dwh pSTblOwner=STGMI DSJobController="KOR_F_01_NumberOfPremiumTransactions_Initial_Load"
Program "DSU.getTablePeriodNoKor": Line 12, Abort.
Attempting to Cleanup after ABORT raised in stage KOR_F_01_NumberOfPremiumTransactions_Initial_Load..JobControl"

Till now I cannot locate the problem but I am suspecting is the routine as pointed out in "DSU.getTablePeriodNoKor": Line 12, Abort.

My question is, is there a problem accessing a same routine with 4 different routine stages at the same time?

Because if that's the case, I might as well change the design to calling the routine one after another sequentially.

What do you guys reckon? =)

Thanks in advanced!

Warm regards,
Chang Lit (Sean)--

rasi · Post by **rasi** » Thu Mar 23, 2006 9:40 pm

Chang

There is no restriction in calling routines concurrently. I don't think that is the problem in your case. Go back to your routine and do full test on the routine to see whether it is working correct or not. You might need to give all different type of value which you receive from source. Trace back to the job where it aborted and see what is the source data and test it in your routine.

Thanks

kcbland · Post by **kcbland** » Thu Mar 23, 2006 9:51 pm

Paste the routine logic, we need to see what the routine is doing to see why concurrent execution might not work.

Nick_6789 · Post by **Nick_6789** » Thu Mar 23, 2006 9:56 pm

Hi all,

Here it is:

Call DSExecute("UNIX", "echo $ENVSTR", env, rval)

env = left(env, 3)

Openseq "/" : env : "/job/KOR/" : TableName : "_PeriodNo.txt" To INPUT Then
Call DSLogInfo("File read.","getTablePeriodNo")
End
Else Abort

Readseq bPERIOD From INPUT Then
Call DSLogInfo("Reading extract status.", bPERIOD)
End
Else Abort
Closeseq INPUT

if Increment <> 0 then

bPERIOD = bPERIOD + Increment

iMonth = bPERIOD[6, 2]
iYear = bPERIOD[1, 4]
Call DSLogInfo(iMonth, "iMonth Value")
if iMonth = "13" THEN
iYear = iYear + 1
bPERIOD = iYear : "001"
END
END

Call DSSetUserStatus(bPERIOD)

Ans = bPERIOD

Basically what it does is read a value from a file. Simple as that. Ignore the codes if increment <> 0 section. Cause that is never executed as far as I know.

Unless you guys could have noticed something odd about it that causes abortion.

I must add, that this error is random... it doesn't fail everytime which makes it dangerous because fails at most unexpected times.

Thanks guys.

Warm regards,
Chang Lit (Sean)--

rasi · Post by **rasi** » Thu Mar 23, 2006 10:35 pm

Chang

if Increment <> 0 then

Where do you assign Increment variable. I can't see this variable assigned.

Thanks

Nick_6789 · Post by **Nick_6789** » Thu Mar 23, 2006 10:43 pm

rasi wrote:Chang

if Increment <> 0 then
Where do you assign Increment variable. I can't see this variable assigned.

Thanks

Hi Rasi,

Increment is a parameter taken from outside the routine stage. I have a link to that routine stage with parameters TableName and Incremment.

ArndW · Post by **ArndW** » Fri Mar 24, 2006 2:30 am

Let's see: (a) your routine stop running with an "abort". (b) You have 2 abort statements in your routine.

Try putting in ON ERROR and getting the STATUS() and printing it out with a call to DSLogWarn() to see why you are getting a failed open or read. This is also logically the place in the program where you would have a concurrency issue.

It would also make sense to put a little loop around the OPENSEQ to ensure against a timing issue - I think the window is quite small so you wouldn't even need to put a SLEEP statement in, just give it 10-15 attempts before failing.

ray.wurlod · Post by **ray.wurlod** » Fri Mar 24, 2006 4:18 pm

OpenSeq will take its Else clause if the file being opened does not exist. You are unconditionally aborting in this case. You probably do not want to do this; check the Status() function to determine whether the sequential file is, in fact, opened for writing in the Else clause.

Find a generic sequential file opening routine like this one that handles all possible conditions, rather than take short cuts in your OpenSeq statements. Stay in control!

Nick_6789 · Post by **Nick_6789** » Sun Mar 26, 2006 6:49 pm

Hi Ray and Arnd,

I cannot view the extend of your replies. =P Being a non-paying member. I will work out with my co. and see if I can open up that membership later.

At the mean time, thanks, you have given me an idea about the force abort statement. This code was not developed by me and I have no experience in routine.

I will check out and see if the force abort does indeed cause the abortion. Thanks all. Will let you know the results.

Warm regards,
Chang Lit (Sean)--