DSXchange

Hi,

We are migrating from Server to Parallel and we are trying to use DB2 EE stage to connect to remote database. We get the following error during view data.

##F TFPM 000279 14:03:30(002) <DB2_UDB_Enterprise_23,0> Fatal Error: Caught ORCHESTRATE exception in parallel process: APT_Archive::BadClass: From: Loading memory archive: Could not find "APT_DB2ReadOperator".

##E TFPM 000000 14:03:30(002) <node_db2node0> , player 1 terminated unexpectedly.
##E TFPM 000338 14:03:30(000) <main_program> Unexpected exit status 1
##E TFSR 000011 14:03:35(000) <main_program> Step execution finished with status = FAILED.

I did check the config file which did not give any errors.

Following are the files which is out there in /opt/dsadm/Ascential/DataStage/PXEngine/lib/ folder.

lrwxrwxrwx 1 dsadm dstage 12 Jun 30 2009 orchdb2op.o@ -> orchdb2op8.o*
-rwxr-xr-x 1 dsadm dstage 1562379 Oct 31 2007 orchdb2op7.o*
-rwxr-xr-x 1 dsadm dstage 1567962 Oct 31 2007 orchdb2op8.o*

DB2 version is 9.5. But I see a file here as *op8. Is that a problem ?

Can anyone throw some light at this ?

Appreciate your help...

Thanks

Multiple versions are provided because different customers use different versions of DB2. The symbolic link points to the appropriate one.

Hi - We are facing the same issue in our project ,We are setting up 8.7 .

The Job is executing fine when i run from designer, but when i run the job from Unix using a script, i'm getting the error

DW_SEL_Classification,0: Fatal Error: Caught ORCHESTRATE exception in parallel process: APT_Archive::BadClass: From: Loading memory archive: Could not find "APT_DB2ReadOperator".
node_db2_server1: Player 1 terminated unexpectedly.
main_program: APT_PMsectionLeader(3, db2_server1), player 1 - Unexpected exit status 1.
main_program: Step execution finished with status = FAILED.

Please help me to resolve this issue.

Thanks,
Prasanna

Are you sourcing the dsenv file in your script to get access to all the libraries?

Check it by having your script use echo $DSHOME. If it is blank, then you've not sourced the dsenv file.

To resolve it, add the following to the beginning of your script:
. `cat /.dshome`/dsenv

That string starts with "period space" and uses the "back quotes" located next to the 1 key on US keyboards which cause the cat command to be executed and used in the command string.

Another way to do what Andy proposed (and I'm guessing he does it this way too, as often as not) is

And the "back quote" that Andy mentions is officially called a grave accent.

Do I criticize your accent?

Thankfully, no you do not mon ami.

Hi Chulett,Andy and Ray

We are sourcing/executing $DSHOME/dsenv in our shell script before calling the datstage Job.

I've verified that again.

The issue happens only with the Enterprise stage called from a Shell script, When the same job is converted to use Connector Stage it is running fine from the shell script.(We've lot of old jobs developed in 8.0 using enterprise stage)

Thanks,
Prasanna

You've checked the things I would check - library access, dsenv sourcing, etc. I can't help any further because I don't have access to a release 7 system to do any investigation. Unless somebody else can assist, you might have to go to your support provider. If you do, please post the solution here to help others in the future.

I missed to export the variable REMOTE_DB_INSTALL_LOC in the dsenv file, including this variable in the dsenv resolved the issue.

But i dont understand how did the job run from client

Thanks,
prasanna

Client connects via the DataStage RPC mechanism and, in so doing, inherits the environment of dsrpcd. Perhaps that environment includes REMOTE_DB_INSTALL_LOC ?

Hi Ray - One more question, When the same job was converted to use the "connector" stage it was running fine from the script without the variable in REMOTE_DB_INSTALL_LOC in the dsenv file.

So this variable, is it something specific to the Enterprise stage?

Thanks,
Prasanna