QS Plugin Error

Infosphere's Quality Product

Moderators: chulett, rschirm

Post Reply
jhmckeever
Premium Member
Premium Member
Posts: 301
Joined: Thu Jul 14, 2005 10:27 am
Location: Melbourne, Australia
Contact:

QS Plugin Error

Post by jhmckeever »

Hi Everyone,

I've got a DataStage job which (up until very recently) has been using the QualityStage plugin without problems. Now when I run the same job get:

Code: Select all

SCV_pHX3_Standardise..SCVSTAN: Failed to open QSRT connection: check qsrtmngr is running, job is deployed
I'm confused as my servers (QSSERV and QSRTMNGR) are running, and are on the correct port.

Code: Select all

$ qsserv
qsserv(2788):Thu Jun 15 13:09:55 2006 LOG: $Build: (SINGLE)RELEASE qsserv_7_0_1_7_040120_15:36:59 $
qsserv(2788):Thu Jun 15 13:09:55 2006 LOG: Start
qsserv(2788):Thu Jun 15 13:09:55 2006 LOG:  LOCALE is: C

qsserv

qsserv(2788):Thu Jun 15 13:09:55 2006 LOG:  using hardwired value from 'inet.h'
qsserv(2788):Thu Jun 15 13:09:55 2006 LOG:  Server started as process 2788, using port 22323, getpid()
and

Code: Select all

$ qsrtmngr
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 LOG: $Build: (SINGLE)RELEASE qsrtmngr_7_0_1_7_040120_15:29:45 $
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 LOG: Start
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 LOG:  LOCALE is: C

qsrtmngr

qsrtmngr(2790):Thu Jun 15 13:10:11 2006 LOG:  gid=2790
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE:  pTrEnterFmt
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE:  pTrEnterFmt
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 IPE_POST:  [irtmanager.c] [irt_mngr_setup] [713] INFO: 0001 Manager started as process 2790, using port 6010
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE: RETURN [1]: [ipelog.c] [ipe_post_msg] 125
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE:  pTrEnterFmt
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE:  pTrEnterFmt
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE: RETURN [1]: [irtcmdsrv.c] [one_port_setup_real] 298
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE: RETURN [1]: [irtcmdsrv.c] [one_port_setup] 311
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE:  pTrEnterFmt
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE: RETURN [1]: [ipesys.c] [ipe_calloc] 546
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE:  pTrEnterFmt
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE: RETURN [1]: [irtcmdsrv.c] [set_tcp_nodelay] 125
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE: RETURN [1]: [irtmanager.c] [irt_mngr_setup] 743
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE:  pTrEnterFmt
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE: RETURN [1]: [irtmanager.c] [irt_autostart_services] 1684
qsrtmngr(2790):Thu Jun 15 13:10:11 2006 TRACE:  pTrEnterFmt
The above looks a little suspicious to me. Any thoughts? Although the client runs fine ...

Code: Select all

$ qsrtclnt
qsrtclnt(8926):Thu Jun 15 14:31:34 2006 LOG: $Build: (SINGLE)RELEASE qsrtclnt_7_0_1_7_040120_15:30:23 $
qsrtclnt(8926):Thu Jun 15 14:31:34 2006 LOG: Start
qsrtclnt(8926):Thu Jun 15 14:31:34 2006 LOG:  LOCALE is: C

qsrtclnt

qsrtclnt(8926):Thu Jun 15 14:31:34 2006 LOG:  gid=8926
qsrtclnt(8926):Thu Jun 15 14:31:34 2006 IPE_POST:  [irtclnt.c] [doTest] [231] INFO: 0001 MNGR_TEST: irtmngr at localhost:6010 is OK

qsrtclnt(8926):Thu Jun 15 14:31:34 2006 LOG:  End
We've been tightening our security and all users (dsadm, et al) have been moved onto the same primary group (dstage). Perhaps this is related to the problem?

Any ideas on where I can look next are very gratefully received. :-)

John.
<b>John McKeever</b>
Data Migrators
<b><a href="https://www.mettleci.com">MettleCI</a> - DevOps for DataStage</b>
<a href="http://www.datamigrators.com/"><img src="https://www.datamigrators.com/assets/im ... l.png"></a>
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

What looks suspicious? There are not error/warning messages, though it appears you have tracing enabled.

Have you created user IDs for qsserv and qsrtmngr and, if so, are these also in the dstage group?

Have you checked that you (or someone) actually deployed the SCVSTAN job? All QualityStage jobs must be deployed before they can be run.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
lstsaur
Participant
Posts: 1139
Joined: Thu Oct 21, 2004 9:59 pm

Post by lstsaur »

John,
Your primary group (dstage) has no access to the qsadm's stuff. Try using dsadm or any member in dstage group to start/stop the QSRT manager, you will see the same error, Failed to Open QSRT connection.
jhmckeever
Premium Member
Premium Member
Posts: 301
Joined: Thu Jul 14, 2005 10:27 am
Location: Melbourne, Australia
Contact:

Post by jhmckeever »

Istsaur,

'qsadm' a member of 'dstage'. Our admin changed all our QualityStage files to be now owned by 'dsadm' - Could this be the problem?

What account is used to by DataStage to connect to QSRT? It is 'dsadm', the user running the job, or 'qsadm'? User 'qsadm' can't see one of the libraries:

Code: Select all

$ whoami
dsadm
$ qsrtclnt
qsrtclnt(3825):Tue Jun 20 16:49:50 2006 LOG: $Build: (SINGLE)RELEASE qsrtclnt_7_0_1_7_040120                        _15:30:23 $
qsrtclnt(3825):Tue Jun 20 16:49:50 2006 LOG: Start
qsrtclnt(3825):Tue Jun 20 16:49:50 2006 LOG:  LOCALE is: C

qsrtclnt

qsrtclnt(3825):Tue Jun 20 16:49:50 2006 LOG:  gid=3825
qsrtclnt(3825):Tue Jun 20 16:49:50 2006 IPE_POST:  [irtclnt.c] [doTest] [231] INFO: 0001 MNG                        R_TEST: irtmngr at localhost:6010 is OK

qsrtclnt(3825):Tue Jun 20 16:49:50 2006 LOG:  End
$ su qsadm
Password:
$ qsrtclnt
/usr/lib/dld.sl: Can't open shared library: /Vality/LIC/1.0.4/lib/liblicense.sl
/usr/lib/dld.sl: No such file or directory
Abort(coredump)
Any help gratefully received.
John.
<b>John McKeever</b>
Data Migrators
<b><a href="https://www.mettleci.com">MettleCI</a> - DevOps for DataStage</b>
<a href="http://www.datamigrators.com/"><img src="https://www.datamigrators.com/assets/im ... l.png"></a>
lstsaur
Participant
Posts: 1139
Joined: Thu Oct 21, 2004 9:59 pm

Post by lstsaur »

John,
It's obviously now that qsadm has a permission problem. It couldn't even run the qsrtclnt command because of "/usr/lib/dld.sl: Can't open shared library". Ask your system adm to grant the qsadm to read/execute this library. Hopefully, that's the only problem. Let me know if you still having the problem.
jhmckeever
Premium Member
Premium Member
Posts: 301
Joined: Thu Jul 14, 2005 10:27 am
Location: Melbourne, Australia
Contact:

Post by jhmckeever »

That's the confusing thing - qsadm already has read/execute privileges on the library:

Code: Select all

$ whoami
qsadm
$ ll libli*
-rwxrwxrwx   1 dsadm      dstage       45056 Jan 16  2004 liblicense.sl
$
Anywhere else I need to check persmissions?
<b>John McKeever</b>
Data Migrators
<b><a href="https://www.mettleci.com">MettleCI</a> - DevOps for DataStage</b>
<a href="http://www.datamigrators.com/"><img src="https://www.datamigrators.com/assets/im ... l.png"></a>
lstsaur
Participant
Posts: 1139
Joined: Thu Oct 21, 2004 9:59 pm

Post by lstsaur »

John,
Actually, the error message is complained about "/usr/lib/dld.sl: No such file or directory".
Also, can you issue the following command:

ps -eaf |grep 6010

I would like to see whose id, dsadm or qsadm, is used to start the qsrtmngr?
lstsaur
Participant
Posts: 1139
Joined: Thu Oct 21, 2004 9:59 pm

Post by lstsaur »

Hi John,
Guess what? Now I am getting the exact same problem that you have.
Both qsserv and qsrtmngr are up and running; all of sudden DataStage jobs using QS plug-in got aborted. These jobs have been worked in the past.
Opened a case with Ascential, but so far they have no answer either.
Just wondering did you get your problem fixed?
jhmckeever
Premium Member
Premium Member
Posts: 301
Joined: Thu Jul 14, 2005 10:27 am
Location: Melbourne, Australia
Contact:

Post by jhmckeever »

My installation now works. The actual problem was that our SYSADMIN has altered ownership of all files previously owned by qsadm to dsadm.

I ran QSRTMNGR in trace mode 3 and tested my job from the command line using QSRTPITST. I saw from the QSRTMNGR log that the RT Manager couldn't write to directory '/tmp/IRTManager'. This directory was orphaned (owned by user '104' - which didn't exist) and no-one could read/write/execute or delete it.

Getting the SYSDAMIN to delete this directory solved the problem, although I couldn't run my jobs from QSforDS plugin intil I'd tested each one using the QSRTIPTST utility.

J.
<b>John McKeever</b>
Data Migrators
<b><a href="https://www.mettleci.com">MettleCI</a> - DevOps for DataStage</b>
<a href="http://www.datamigrators.com/"><img src="https://www.datamigrators.com/assets/im ... l.png"></a>
Post Reply