SMD: there are no access point s for service: P4 registered on the message

[Former Member]

After I was fiddling some time ago with SMD I tried to start again today - and I'm stuck with the following error while setting up SMD:

- STEP 5: checking P4 Connection

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

P4 Connection to SMD Server failed

Root exception is: com.sap.engine.services.jndi.persistent.exceptions.NamingException: Exception while try

ing to get InitialContext. [Root exception is com.sap.engine.interfaces.cross.DestinationException: there

are no access points for service: P4 registered on the message server]

com.sap.engine.services.jndi.persistent.exceptions.NamingException: Exception while trying to get InitialC

ontext. [Root exception is com.sap.engine.interfaces.cross.DestinationException: there are no access point

s for service: P4 registered on the message server]

at com.sap.engine.services.jndi.InitialContextFactoryImpl.getInitialContext(InitialContextFactoryI

mpl.java:455)

at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)

at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)

at javax.naming.InitialContext.init(InitialContext.java:219)

at javax.naming.InitialContext.<init>(InitialContext.java:195)

at com.sap.smd.setup.CheckPrerequisiteSetup.checkP4Connection(CheckPrerequisiteSetup.java:510)

at com.sap.smd.setup.CheckPrerequisiteSetup.setup(CheckPrerequisiteSetup.java:173)

at com.sap.smd.setup.CheckPrerequisiteSetup.main(CheckPrerequisiteSetup.java:63)

Caused by: com.sap.engine.interfaces.cross.DestinationException: there are no access points for service: P

4 registered on the message server

The message server on the solution manager host on the specified port (8150) is running:

bash-3.00# netstat -f inet -an | grep 8150

*.8150 . 0 0 49152 0 LISTEN

I can resolve names backward and forward, since the system connects I assume it's no network issue.

What do I need to do in order to "register the P4 port" on the ABAP message server?

Regards,

Markus

[FredericOzon · Accepted solution]

Hi Markus,

I think you should run first the Diagnostics Setup Wizard, in order to desactivate the maintenance mode who desactivates the JNDI context.

Regards,

Frederic

[markus_doehr2 · Accepted solution]

Just did that a before I was trying to install the agent - ran the wizard again successfully - and tried again - same result. I now used a direct connection to the dispatcher node - this seems to work - at least I can see the agent.

I step to "Managed System - Setup Wizard", select the agent and execute it. I almost immediately get

Remote call to setup service on epjava failed : Unexpected exception.(cause=java.io.InvalidClassException com.sap.smd.agent.plugins.remotesetup.SapInstance; local class incompatible: stream classdesc serialVersionUID = -5590655822421529031, local class serialVersionUID = 1033110310377736492)

The locate version of LMService is SP13 Hotfix 3, the agent is SP13.

sigh

Regards,

Markus

[markus_doehr2 · Accepted solution]

one more question:

What is a "JNDI context"- and why is it necessary to be "deactivated" during that setup?

Can you now understand my concerns (in the other posts)? I'm willing to learn but one has to give me the chance to...

Markus

[FredericOzon · Accepted solution]

Just to be sure , the Solution Manager is a full SP13 version?

There is also a documentation to install the Diagnostics Agent

https://websmp204.sap-ag.de/~sapdownload/011000358700000806092007E

May you check if your parameters were correct.

You need to connect to the message server port or the P4 of the dispatcher directly.

Some tips for the port

"81NN - Java Msg srv inst.nb

5NN04 (P4)

5NN06 (P4 over SSL)

""NN"" stands for the Web Application Server (AS) Instance number (00…99)"

About the JNDI, the Agents connected are stored internally in a context, this means that the different agents register themselves to this context.

Then, when any diagnostics actions need a agent, it pick up the agent from this context.

When you activate the maintenance mode, this context is desactivated. This means empty. Diagnostics applications cannot access agents and agent cannot request info or archive from the SMD Server.

This could avoid for example: if you register an agent or an agent download a "agent applications" from Diagnostics Server and a the same time you deploy a new version of LMService: you may have the case that archive are corrupted.

When desacivating the maintenance mode, the agent will automatically reconnect (they have a loop of 30s, I think), and they download all the newest things from the server if there is any.

The same if the maintenance mode is on, and you try to install and agent. One of the first action is to connect to the server, to get the latest SMD agent runtime. In this case you may have a stack trace with JNDI info, in the installer.

These explanation are delivered during Solman Starter Pack, to System Administrators.

Frederic

[markus_doehr2 · Accepted solution]

Frederic, I appreciate your engagement... really - thank you for that.

Just to be sure , the Solution Manager is a full SP13 version?

Yes - it was migrated from 2.2 to 3.1, then upgraded to 3.2 and finally upgraded to 4.0 - and since two days after availability of SP13 it´s on SP13 (ST is on SP14).

There is also a documentation to install the Diagnostics Agent

https://websmp204.sap-ag.de/~sapdownload/011000358700000806092007E

May you check if your parameters were correct.

You need to connect to the message server port or the P4 of the dispatcher directly.

Some tips for the port

"81NN - Java Msg srv inst.nb

5NN04 (P4)

5NN06 (P4 over SSL)

""NN"" stands for the Web Application Server (AS) Instance number (00&#133;99)"

My instance is running on 50 - so the message server is on 8150 - I verified this in in DEFAULT.PFL and transaction SMMS. The problem is (according to the error message) not, that the agent can´t connect to the message server, somehow the P4 port is not "registered" to the message server. I´m pretty sure this is something a new 4.0 SR2 installation is doing, it was just not done because the system was upgraded and not installed (it´s not the first thing, that is not working as documented because "upgrading" customers are forgotten in documentations...)

About the JNDI, the Agents connected are stored internally in a context, this means that the different agents register themselves to this context.

Then, when any diagnostics actions need a agent, it pick up the agent from this context.

When you activate the maintenance mode, this context is desactivated. This means empty. Diagnostics applications cannot access agents and agent cannot request info or archive from the SMD Server.

This could avoid for example: if you register an agent or an agent download a "agent applications" from Diagnostics Server and a the same time you deploy a new version of LMService: you may have the case that archive are corrupted.

So if I follow that correclty I would need to shutdown all the connected agents (or those agents, that are actually starting up) when I upgrade the LMService - either via SP installation or via SDM? Hum...

When desacivating the maintenance mode, the agent will automatically reconnect (they have a loop of 30s, I think), and they download all the newest things from the server if there is any.

The agent is showing:

**********************************************************************

JHVM_LoadJavaVM: Java VM created OK.

**********************************************************************

JHVM_BuildArgumentList: main method arguments of node

-> arg[ 0]: run

-> arg[ 1]: jcontrol

**********************************************************************

Tue Jan 8 21:25:07 2008

JHVM_RegisterNatives: registering methods in com.sap.bc.proj.jstartup.JStartupFramework

JLaunchISetState: change state from to

JLaunchISetState: change state from to

JLaunchISetState: change state from to

Tue Jan 8 21:25:14 2008

JLaunchISetState: change state from to

Tue Jan 8 21:25:19 2008

JLaunchISetState: change state from to

The same if the maintenance mode is on, and you try to install and agent. One of the first action is to connect to the server, to get the latest SMD agent runtime. In this case you may have a stack trace with JNDI info, in the installer.

I don´t have such stack trace on the SMD.

I have, however, this:

and

#1.5^H#001185E8ABA300740000000C000024A30004433C2DC626BA#1199825651895#com.sap.smd.server#sap.com/tc_wddis

pwda#com.sap.smd.server#J2EE_ADMIN#398##solmgr_SOP_507479150#J2EE_ADMIN#db63d8d0be2a11dc9eb1001185e8aba3#T

hread[Thread-87,5,SAPEngine_Application_Thread[impl:3]_Group]##0#0#Error##Java###[Setup]Failed to use remo

te setup service on epjava

#1#com.sap.engine.services.rmi_p4.exception.P4BaseRuntimeException: Unexpected exception.

at com.sap.engine.services.rmi_p4.server.P4ObjectBrokerServerImpl.getException(P4ObjectBrokerServe

rImpl.java:950)

at com.sap.engine.services.rmi_p4.server.P4ObjectBrokerServerImpl.getException(P4ObjectBrokerServe

rImpl.java:928)

at com.sap.smd.agent.plugins.remotesetup.IRemoteSetupService_Stub.setup(IRemoteSetupService_Stub.j

ava:112)

at com.sap.sup.admin.setup.SapCluster.remoteInstanceSetup(SapCluster.java:635)

at com.sap.sup.admin.setup.SapCluster.setup(SapCluster.java:561)

at com.sap.sup.admin.setup.SapCluster.access$000(SapCluster.java:26)

at com.sap.sup.admin.setup.SapCluster$SetupRunner.run(SapCluster.java:774)

at java.lang.Thread.run(Thread.java:534)

Caused by: java.io.InvalidClassException: com.sap.smd.agent.plugins.remotesetup.SapInstance; local class i

ncompatible: stream classdesc serialVersionUID = -5590655822421529031, local class serialVersionUID = 1033

110310377736492

at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:463)

at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1521)

at j

So exactly the error I´m seeing in the Firefox when I try to setup the agent.

These explanation are delivered during Solman Starter Pack, to System Administrators.

Is that the way it works? Through consultants only? Hmm...

Markus

[markus_doehr2 · Accepted solution]

BTW: an OSS call was created for that problem (the P4 error): 18242/2008.

[FredericOzon · Accepted solution]

So if I follow that correclty I would need to shutdown all the connected agents (or those agents, that are actually starting up) when I upgrade the LMService - either via SP installation or via SDM? Hum...

No, this why there is Maintenance Mode, to lock all communications and avoid to work on the managed systems. Agents knows how to react and go for a sleep mode.

Frederic

[markus_doehr2 · Accepted solution]

Ok - since I did that before that can´t be the reason for this error.

Markus

[FredericOzon · Accepted solution]

Let see if Primary support can help you.

Frederic

[markus_doehr2 · Accepted solution]

Just to update the call:

The message server connection works only if there is more than one server node on the monitoring system.

Markus

[markus_doehr2 · Accepted solution]

Update II:

Accoding to "the development" one should be able to connect to the message server even if there´s only one server process. So we´re now at the beginning again....

Can you feel the pain I have and that all this just sucks and upsets me?

Regards,

Markus

[FredericOzon · Accepted solution]

Hi,

I can feel it yes. But I am pretty sure, you will have a solution.

I ran successfully installation on different OS (Linux, AIX, etc) with Cluster and Fail over system. I am confident in this product

Frederic

[markus_doehr2 · Accepted solution]

J2EE has proven to be the worst piece of software we ever implemented (started with 6.20) - from an administrative point of view. ABAP has been very very stable, reliable, deterministic, you get real error messages including a user context, there are clean search paths how to search for a solution, you can see anytime what a specific user is doing, including all the context information - if you want to. Not some silly non-speaking java exceptions - we have > 100.000 of them on our production portal filling up the filesystem in the "archive" directory:

$ grep -i exception *.trc | wc -l

122972

No company (I know of) would accept some thousands dumps in an ABAP system each day - because it makes finding the real errors and problems impossible.

Thus - I´m not sure if a product on top of that (means, agent + another Java stack as distributed engine on a second system) which is producing the same amount of "logged errors" can enable me, in diagnosing problems better and even find out, IF we have a problem at all despite those 100.000 things logged as "error".

How many of the systems you installed already have been upgraded systems (means, SolMan upgrades/Unicode migrated systems, Portal/J2EE upgrades) and no new implementations?

Markus

[FredericOzon · Accepted solution]

Let's stay on the problem, we do not need to launch a troll here.

[FredericOzon · Accepted solution]

Hi Markus,

Just to be sure on the main problem.

Did you use the port for the message server ABap or the one for Java?

They are differents, and Abap message server does not know P4.

I am pretty sure you know it, but just want you to check.

I would try 8100 for Java, you may test it by launching this URL

http://host:8100//msgserver/text/logon

You should have something like for Java one (In my case 8100)

version 1.0

J2EE17694600

J2EE mytestserver 50100 LB=1

J2EES mytestserver 50101 LB=1

P4 mytestserver 50104 LB=1

P4S mytestserver 50106 LB=1

P4HTTP mytestserver 50105 LB=1

JC_mytestserver_NC1_01

SDM mytestserver 50118

And for Abap something like (In my case 8101: Sys num 01)

version 1.0

mytestserver_NC1_01

DIAG mytestserver 3201 LB=8

RFC mytestserver 3301

HTTP mytestserver 8001

Regards,

Frederic

[markus_doehr2 · Accepted solution]

Launch a troll? well.. I´m arguing, not blindly bashing but since nobody is picking up those arguments (not in this thread and also not in others) I have to assume, that I´m totally right and there´s nothing one can argue against or that it´s ignored, because people know it and there´s nothing what can be done.

Markus

[FredericOzon · Accepted solution]

I am here to discuss Java Vs Abap. There is disadvantage and advantage on both.

Did you try with Java message port?

[markus_doehr2 · Accepted solution]

I´m not trying to discuss ABAP vs. Java - I am searching for a way to find out how to deal with and manage Java instances - that´s why I´m trying to set up SMD.

I removed the agent and re-installed it using 8101 (why 01? my instance is running on 50 - so it should be 51, right?)

After I corrected the problem with the ulimit -v (sigh) I could start the agent. Now I ran the diagnostics setup again. After that is finished I was trying to configure the agent. I step to "Managed system - setup wizard" and I get

The SMD Agent ' is the correct one. The solution is also correctly defined (with that name)

Markus

[markus_doehr2 · Accepted solution]

one more information:

If I step to troubleshooting I get

No upload data (cca_systemlandscape.xml template) found on Please make sure the solution was successfully published from Solution Manager (SMDIAG_WIZARD)

I thought with SP13 that wizard shouldn´t be used any more... (note 1055791 - SMDIAG_WIZARD:specified installation path is not correct)

Why does the system (which is on SP13) recommend to run that wizard if it shouldn´t be ran?

Markus

[FredericOzon · Accepted solution]

Hi Markus,

You installed twice an agent with the same name. But the system should react on it.

If it still with error in the managed setup Wizard after sometimes, You should reset the 'server name' entry from Diagnostics Agent Administration.

Right click on the name of the agent, you will a action entry for that.

When doing the reset and coming back to managed setup, you may have the message: Agent not migrated, please run the upgrader.

This is a wrong message, I think due to some side effect. Just assign the Agent from the UI, and it should be ok.

Then you can go to the next step.

Regards,

Frederic

[markus_doehr2 · Accepted solution]

> You installed twice an agent with the same name. But the system should react on it.

Can this be triggered somehow?

> Then you can go to the next step.

Ok - did that. I was able to run the setup but I get

1. Wily Introscope

Failed to configure EP Agent for epjava

!! Exception : java.lang.NullPointerException

Wily is happily running on the SolMan system.

2.

The profile parameter jstartup/recorder is not set in the Java profile ETL_JC00_<hostname>, if it is a backup profile, please rename it (e.g. <SID>_<INSTANCE>_<HOSTNAME>.bak)

Does that mean I have to put this in each of the managed instances and then restart?

Markus

[FredericOzon · Accepted solution]

Hi,

1- Not nice error But did you deploy the ISAGENTSMD71_XX-SCA has described in the documentation

Chapter : 5.3.2 Software prerequisites for Wily Introscope

Agents

2- Yes.

Frederic

[FredericOzon · Accepted solution]

one more information:

If I step to troubleshooting I get

No upload data (cca_systemlandscape.xml template) found on <hostname> Please make sure the solution was successfully published from Solution Manager (SMDIAG_WIZARD)

I thought with SP13 that wizard shouldn´t be used any more... (note 1055791 - SMDIAG_WIZARD:specified installation path is not correct)

Why does the system (which is on SP13) recommend to run that wizard if it shouldn´t be ran?

Markus

I think the troubleshoot guide, you have is partly invalid. The SMDIAG_WIZARD is not use since SAP Solution Manager 4.0 SP12.

Regards,

Frederic

[markus_doehr2 · Accepted solution]

If I step to troubleshooting I get

No upload data (cca_systemlandscape.xml template) found on <hostname> Please make sure the solution was successfully published from Solution Manager (SMDIAG_WIZARD)

I thought with SP13 that wizard shouldn´t be used any more... (note 1055791 - SMDIAG_WIZARD:specified installation path is not correct)

Why does the system (which is on SP13) recommend to run that wizard if it shouldn´t be ran?

Markus

I think the troubleshoot guide, you have is partly invalid. The SMDIAG_WIZARD is not use since SAP Solution Manager 4.0 SP12.

It´s not a guide telling me to do that but the troubleshooting section in the SMD itself.

Markus

[FredericOzon · Accepted solution]

Very Nice, in which area did you get it or in which bubble?

Frederic

[markus_doehr2 · Accepted solution]

Very nice? I doubt so...

Diagnostic Setup - Managed System - Troubleshooting

In the displaced grid under "Message"

Markus

[markus_doehr2 · Accepted solution]

1- Not nice error But did you deploy the ISAGENTSMD71_XX-SCA has described in the documentation

Chapter : 5.3.2 Software prerequisites for Wily Introscope

Agents

I will need to uninstall the "old agent" first - which implies a restart of the system (what I was saying earlier).

2- Yes.

oh yeah... how do I find out who´s doing something on that engine - to inform the users that it will be restarted?

Markus

[FredericOzon · Accepted solution]

oh yeah... how do I find out who´s doing something on that engine - to inform the users that it will be restarted?

Markus

Contact your System Administrator. I do not see what is funny here.

[markus_doehr2 · Accepted solution]

I AM the system administrator of that engine - how to find out who´s logged on the portal?

Markus

[FredericOzon · Accepted solution]

So I would suggest you to run a telnet on the Portal, Add servlet_jsp set of command, you should have then a command to get all J2ee and Portal open sessions.

Frederic

[markus_doehr2 · Accepted solution]

The wily agent was removed (according to the installation documentation).

If I now execute the setup for managed system I get

WARNING: JVM parameter -Dcom.wily.introscope.agent.agentName= was not set yet. Please setup the Bytecode Agent and run the Wilyhost setup step again.

-> Temporarily using the following Bytecode Agent name: ETL_epjava_server0

Failed to configure EP Agent for epjava

!! Exception : java.lang.NullPointerException

so: Documentation says (on page 12, 5.4.3), that the old agents must be removed. Now, the wizard says, that they need to be installed...

sigh

Markus

[FredericOzon · Accepted solution]

Yes, I know this pretty nice issue.

Run the Introscope Setup Wizard to push the newest Introscope Agent(and name), Then by running again the managed setup wizard and selecting only the Wily Host option.

You should be ride of this issue.

Regards,

Frederic

[markus_doehr2 · Accepted solution]

Hi Frederic,

I tried that - I selected the agent, everything looks good. When I click on the "setup agent" button, the system starts and run and run until I finally get a "page cannot be displayed" (after 30+ minutes).

During that time I don´t see any activity of jlaunch neither on the solman nor on the managed system. Both engines and agents are still running., nothing obvious in the logfiles (besides the "usual" exceptions).

sigh

What is missing here?

Regards + thanx for you time.

Markus

[markus_doehr2 · Accepted solution]

I restarted SolMan, I restarted the agent - result is the same. I undeployed ISAAGENT and re-deployed it and tried again - same result.

I can see absolutely no activity of jlaunch (neither on SolMan nor on the managed syste) after having clicked on "setup", the browser just sits there and runs in circles. The agent log doesn´t show anything, wily EM doesn´t show anything as well, finally the browser times out.

Now it would be time again to create an OSS call, collect screenshots, logs and try to explain them, what´s happening and finally get an answer like "please install the latest blabla"... ". deepsigh

You´ve got any idea? if not then, well, it´s time go give up.

Markus

[FredericOzon · Accepted solution]

Hi Markus,

There was an issue in the past with P4 protocol, which locked the process and result in the time out in the setup.

SAP note 999138 was the one who resolved it.

Best Regards,

Frederic

[markus_doehr2 · Accepted solution]

Hi Frederic,

thank you for your answer.

The file is no more available - calling that sapmats link gives me a

"

Sorry, the file you want to download, is already deleted or the id is incorrect.

"

Since the directory to be patched is 7.009 and the note was last time updated last year I assume that error is fixed in the SP13 patch...

Markus

[markus_doehr2 · Accepted solution]

Update:

After having deployed the ISAAGENT again I got a "Java NullPointerException" when I was trying to set up the managed system during wily configuration although the wily agent was correctly pushed before manually.

Reason of that seems to be (according to the OSS call), that configtool does inconsistently delete server nodes out of the cluster (removing a node).

<rant>

What an utter crap if one can't apparently even trust the basic administration tools...

</rant>

Markus

[FredericOzon · Accepted solution]

Oups I did not see your previous answer.

So this is not Diagnostics, the guilty guy ;).

BTW, Do they provide a fix, for the config tool issue?

Regards,

Frederic

[markus_doehr2 · Accepted solution]

> So this is not Diagnostics, the guilty guy ;).

Well - other software doesn't have that specific problem with that "inconsistency", whether it's ok or not.

> BTW, Do they provide a fix, for the config tool issue?

Let's see. I'm certainly ask to create a different call for that - which I won't do.

This is the second major bug in configtool, the other one is that it's not possible to change the password in the secure store, ct says, it's changed, but it's not. We use a program from the development to do those changes. And the worst thing is: that OSS call was not classified as "fullfilled" for our competence center although without the development support and that hand-made java program we wouldn't have been able to fix it.

Markus

[markus_doehr2 · Accepted solution]

Just got the answer:

<...>

This seems to be a bug and was reported to the development; this should

be fixed for the next version;

<...>

Great! "In the next version"...

It's a BASIC tool for the administration and if it's not working correctly, I can't wait "for the next version".

Markus

[Former Member]

For anyone who comes accross this old thread with the error "there are no access point s for service: P4 registered on the message server". Make sure you are using the SCS message server port, it will look up the available P4 port/connections and then connect.

Standard SCS port scheme: 81<SCS instance number> (do not confuse with instance message server)

[symon_braunbaer]

Hello,

I am trying to setup a managed system in Solution Manager 7.1 SPS 12. At step 4 Enter System Parameters, when entering the Java Parameters and then hitting the Test Logon link, I am getting exactly the same error, so I found this thread and tried with 81<SCS instance number>, but it doesn't work... Can you please suggest another solution ? (for the production system it works, for the development it doesn't)

[Former Member]

Hi Markus

your problem is the SerialVersionID that you are using in the Satellite...

emote call to setup service on epjava failed : Unexpected exception.(cause=java.io.InvalidClassException com.sap.smd.agent.plugins.remotesetup.SapInstance; local class incompatible: stream classdesc serialVersionUID = -5590655822421529031, local class serialVersionUID = 1033110310377736492)

Please try this..

1) Remove any wily agent installed manually in the Satellite..

2) Download the last Wily_Agent...but use the Wily Agent for SDM deployment.... (ISAGENTSMD72_01-10005468.SCA Introscope Java Agent for SAP, deployment via SMD ) Is the last one..

3) Restart the JavaStack. Use this one..is really nice http://help.sap.com/saphelp_nw04s/helpdata/en/d5/84a5428295c911e10000000a1550b0/frameset.htm

4) In the Solution Manager go to --> Diagnostics Setup --> Managed System --> Introscope Agent..

5) Select your landscape and then Setup Introscope Agent..

Let me know how was..;-)))

Wence Lacaze

http://www.linkedin.com/in/solutionmanager

[markus_doehr2]

Hi Wenceslao,

Please try this..

1) Remove any wily agent installed manually in the Satellite..

Doing that on 20+ systems isn´t fun.

2) Download the last Wily_Agent...but use the Wily Agent for SDM deployment.... (ISAGENTSMD72_01-10005468.SCA Introscope Java Agent for SAP, deployment via SMD ) Is the last one..

If I do that, the J2EE engine will request a restart (due to adding Wily to the bootstrap code) and doing that will make the engine fail to start because of the bytecode of the agent being incompatible with the IBM JDK (which must be used on Linux) - see note 1149214.

3) Restart the JavaStack. Use this one..is really nice http://help.sap.com/saphelp_nw04s/helpdata/en/d5/84a5428295c911e10000000a1550b0/frameset.htm

Thanx! I knew this already but we totally avoid combined installations

4) In the Solution Manager go to --> Diagnostics Setup --> Managed System --> Introscope Agent..

5) Select your landscape and then Setup Introscope Agent..

Did that - it ended in a prio-1 call because the production portal was not coming up due to the incompatibility of Wily Agent vs. IBM JDK. On top of that, the above mentioned note does not described how to do that in an ISAAGENTSMD installation but only for the standalone Wily agent installations (you have to rename connector.jar to AutoProbeConnector.jar - which is totally not obvious to me).

So much for "compatibility" of Java.

Build once - debug everywhere.

Markus

[Former Member]

Sorry..my installation is on SM in W32/MAXDB and the client are AIX/ORACLE