Tom

Minor note — that can often mean that the *DATABASE host server was ended or ended and restarted. MgtC gets a connection through SQL CLI when MgtC starts. It later tries to get data again, but the connection has been severed.

Not much help for you, I realize. But maybe it’s a useful bit for some future time. When you see it in MgtC, it’s usually necessary to ENDHOSTSVR/STRHOSTSVR for *MGTC to have it get a new connection to the database. (I’d like MgtC to attempt a reconnection on its own first.)

Tom

$
ls -al /QIBM/ProdData/Java400/jdk14/lib/ext
total: 76 kilobytes
drwxr-sr-x 2 QSYS 0 8192 Jun 27 2009 .
drwxr-sr-x 6 QSYS 0 53248 Jun 6 12:30 ..
lrwxrwxrwx 1 QSYS 0 42 Jun 27 2009 dnsns.jar -> /QIBM/P
rodData/Java400/jdk14/lib/dnsns.jar
lrwxrwxrwx 1 QSYS 0 51 Jun 27 2009 ibmjceprovider.jar -
> /QIBM/ProdData/Java400/jdk14/lib/ibmjceprovider.jar
lrwxrwxrwx 1 QSYS 0 44 Jun 27 2009 ldapsec.jar -> /QIBM
/ProdData/Java400/jdk14/lib/ldapsec.jar
lrwxrwxrwx 1 QSYS 0 47 Jun 27 2009 localedata.jar -> /Q
IBM/ProdData/Java400/jdk14/lib/localedata.jar
$

I deleted and restored, recreated files in the /OS400/MGTC folder, still no love.
They gave me an update for Accessi for Windows, iNavigator.
Sending more PTFs.

CPFB972 Diagnostic 40 06/13/10 20:28:04.270223 QYJSPART QSYS *STMT QYJSPART QSYS *STMT
From module . . . . . . . . : QYJSPNTV
From procedure . . . . . . : Java_com_ibm_as400_access_NativeMethods_runPro
gram
Statement . . . . . . . . . : 81
To module . . . . . . . . . : QYJSPNTV
To procedure . . . . . . . : Java_com_ibm_as400_access_NativeMethods_runPro
gram
Statement . . . . . . . . . : 81
Thread . . . . : 00005589
Message . . . . : Management Central object not found on server.
Cause . . . . . : A Management Central object of type
com.ibm.mc.client.definition.McEndpointSystem, name
xxx.xxx.dyndns.org, and owner QSECOFR could not be found. An object
with name xxx.xxx.dyndns.org possibly does not exist on the server.
Recovery . . . : If the problem persists, contact service.
CPFB972 Diagnostic 40 06/13/10 20:28:23.768825 QYJSPART QSYS *STMT QYJSPART QSYS *STMT
From user . . . . . . . . . : QSECOFR
From module . . . . . . . . : QYJSPNTV
From procedure . . . . . . : Java_com_ibm_as400_access_NativeMethods_runPro
gram
Statement . . . . . . . . . : 81
To module . . . . . . . . . : QYJSPNTV
To procedure . . . . . . . : Java_com_ibm_as400_access_NativeMethods_runPro
gram
Statement . . . . . . . . . : 81
Thread . . . . : 0000007F
Message . . . . : Management Central object not found on server.
Cause . . . . . : A Management Central object of type
com.ibm.mc.client.definition.McEndpointSystem, name
xxx.xxx.dyndns.org, and owner QSECOFR could not be found. An object
with name xxx.xxx.dyndns.org possibly does not exist on the server.
Recovery . . . : If the problem persists, contact service.
CPFB945 Diagnostic 40 06/13/10 20:28:24.096712 QYJSPART QSYS *STMT QYJSPART QSYS *STMT
From user . . . . . . . . . : QSECOFR
From module . . . . . . . . : QYJSPNTV
From procedure . . . . . . : Java_com_ibm_as400_access_NativeMethods_runPro
gram
Statement . . . . . . . . . : 81
To module . . . . . . . . . : QYJSPNTV
To procedure . . . . . . . : Java_com_ibm_as400_access_NativeMethods_runPro
gram
Statement . . . . . . . . . : 81
Thread . . . . : 0000007F
Message . . . . : Method not successful.
Cause . . . . . : Method isManageableUnique on class
com.ibm.mc.client.definition.McDefinitionView could not be completed
successfully. Recovery . . . : If the problem persists, contact service.

CPFB972 Diagnostic 40 06/14/10 20:28:12.158673 QYJSPART QSYS *STMT QYJSPART QSYS *STMT
From module . . . . . . . . : QYJSPNTV
From procedure . . . . . . : Java_com_ibm_as400_access_NativeMethods_runPro
gram
Statement . . . . . . . . . : 81
To module . . . . . . . . . : QYJSPNTV
To procedure . . . . . . . : Java_com_ibm_as400_access_NativeMethods_runPro
gram
Statement . . . . . . . . . : 81
Thread . . . . : 0000629C
Message . . . . : Management Central object not found on server.
Cause . . . . . : A Management Central object of type
com.ibm.mc.client.definition.McEndpointSystem, name
xxx.xxx.dyndns.org, and owner QSECOFR could not be found. An object
with name xxx.xxx.dyndns.org possibly does not exist on the server.

SQ99999 Diagnostic 30 06/14/10 20:28:11.540379 QSQCLI QSYS *STMT QSQCLI QSYS *STMT
From module . . . . . . . . : SQLCC
From procedure . . . . . . : EXCM0843
Statement . . . . . . . . . : 4637
To module . . . . . . . . . : SQLCC
To procedure . . . . . . . : SQLCloseCursor
Statement . . . . . . . . . : 10143
Thread . . . . : 0000629C
Message . . . . : Error occurred in SQL Call Level Interface
Cause . . . . . : A procedure call encountered an error. The error code is
17. Error codes are: 3 — Program type out of range. 4 — SQL data type out
of range. 9 — Argument value not valid. 10 — Function sequence error. 12
– Transaction operation state not valid. 13 — Memory management problem.
14 — Maximum number of handles allocated. 15 — No cursor name available.
16 — Handle type for operation not valid. 17 — Connection no longer
available. 21 — Descriptor or descriptor information not valid. Recovery .
. . : Refer to the DB2 for i5/OS SQL Call Level Interface (ODBC) topic
collection in the Database category in the i5/OS Information Center book for
a complete description of the error. Specifically, look at the procedure
that sent the error.

This is it for now. Standby. This is only 1 server with 1 LPAR. using DYNDNS with TCP settings. Don’t think makes any difference.

Csaba

It looks to me as if it is starting. So, it shouldn’t be that it isn’t starting — the problem should be that you can’t connect to it.

From the same PC, can you start the iSeries Access emulator? If you can, do you connect by name or by IP address? If by name, is it the same name that you use for the ‘central system’? Is it located from your PC by DNS or by an entry in the PC hosts table? (Do you have an entry in the PC hosts table?)

Since this is i 6.1, is it a new system? It should be fairly new, but you might have had it for quite a few months.

How do the other servers look? Do all host servers report okay? Does CWBPING from the PC report clean connections to the servers? Try ENDTCPSVR *MGTC followed by STRTCPSVR *MGTC after a few seconds to be sure it had time to end cleanly. Does the connection still fail? I’ve seen failures from having different servers start in a different order — MgtC can be very sensitive to how the *DATABASE server is handled for example.

The first thing that I would do is ensure that my ‘central system’ TCP/IP configuration was completely correct. That means a strict conformance to the basic RFCs. Three CFGTCP options should be in agreement:

1. Option 1 should show an ACTIVE interface in addition to the *LOOPBACK interface.
2. Option 10 should show that that ACTIVE interface has a corresponding entry in the iSeries hosts table.
3. Option 12 should show a Host name and a Domain name. The Domain name should be a valid domain name.

The combination host.domain should be the first name listed on the hosts table entry for the IP address of that ACTIVE interface. The option 12 Host name search priority should be *LOCAL to ensure that the entry in the iSeries hosts table is the one that is in effect.

Those might all be changed later, but that’s how they should be in order to do some testing. Once you can get things working with that configuration, you have a good chance of determining if changes will cause problems. I’ve seen failures because the host.domain combination isn’t the first name listed. And I’ve seen failures because a Domain name wasn’t valid. And I’ve seen failures because *REMOTE DNS lookups returned incorrect addresses.

Do you have any exit programs registered against the *DATABASE, *RMTCMD or *SIGNON servers? I’ve seen failures in i 6.1 from the Management Central CCSID changes.

Lots of possibilities. It’s probably best to start with TCP/IP fundamentals and then narrow the problem area down. That’s especially true when there are no error messages that you can locate. The problem might be in any of the other servers that MgtC connects to.

Tom

Here is the joblog:

QSYS/CALL PGM(QSYSDIR/QYPSJSVR) PARM(’1′)
JVM properties were loaded from a properties file.
Java Virtual Machine is Classic.
JVM properties were loaded from a properties file.
Start
Job 212083/QUSER/QSQSRVR used for SQL server mode processing.
Job 212390/QUSER/QSQSRVR used for SQL server mode processing.
Job 212389/QUSER/QSQSRVR used for SQL server mode processing.
Job 212402/QUSER/QSQSRVR used for SQL server mode processing.
Job 212401/QUSER/QSQSRVR used for SQL server mode processing.
Job 212408/QUSER/QSQSRVR used for SQL server mode processing.
Job 212407/QUSER/QSQSRVR used for SQL server mode processing.
Job 212412/QUSER/QSQSRVR used for SQL server mode processing.
Job 212411/QUSER/QSQSRVR used for SQL server mode processing.
Management Central is enabled as a provider of protocol 1024.
Management Central is enabled as a verifier of protocol 1024.
Object QYPSJDTAQ type *DTAQ created in library QMGTC2.
Management Central server McServer on port 5544,5555 started as Central.
Job 212526/QUSER/QSQSRVR used for SQL server mode processing.
Job 212525/QUSER/QSQSRVR used for SQL server mode processing.
Job 212594/QUSER/QSQSRVR used for SQL server mode processing.

Maybe i have to forward these ports as well, but MGTC not starting anyway.
See what these new PTF’s will do. Keep you posted, still any idea, please share it with me. Thank you very much.

Csaba

Try STRTCPSVR.

And what does the QYPSJSVR joblog show for the MgtC problems?

i 6.1 brought a couple changes to how MgtC interacts with some host servers, particularly the Remote Command server. (I haven’t heard from IBM why MgtC needs to run its commands through the Remote Command server when they are on the same system. I’d expect MgtC simply to execute commands directly.)

The MgtC joblog might show hints.

Tom