I tried to start management centeral but error accured.

How did you try to start MgtC — through the STRTCPSVR command or through iSeries Navigator? Where do you see the message — in your joblog, in a MgtC joblog or in a message window in iNav?

Are all of the necessary host servers started?

Tom

I have the same problem after I went from 5.4 to 7.1. This is happening at IPL time, not if I manually STRTCPSVR. Seems like it may be timing, but what. What actually starts MGTC if there’s no explicit STRTCPSVR *MGTC or *ALL?

What actually starts MGTC if there’s no explicit STRTCPSVR *MGTC or *ALL?

Check iSeries Navigator under the connection -> Network-> Servers-> TCP/IP. Select Management Central ‘Properties’. If MgtC is starting implicitly, it’s probably because “Start when TCP/IP is started” is selected.

MgtC needs at least the Database and the Remote Command/Distributed Program Call host servers to be started before MgtC can get anything done. If those are not also auto-started, then MgtC will have trouble.

Tom

Well, both those servers are started and I still have the problem. Going to pull MGTC froom the list and start it myself in the start up program and see what happens.

Going to pull MGTC froom the list and start it myself in the start up program…

If everything else in the system seems to be running fine, then I would ENDTCPSVR *MGTC, and then STRTCPSVR *MGTC after it has stopped.

By manually ending and restarting when you’re confident other servers are fully operational, things like timing problems are mostly eliminated.

For example, MgtC can start and be in a fully operational state. Some time later, someone does ENDHOSTSVR *DATABASE and STRHOSTSVR *DATABASE. You won’t necessarily see anything at that time that indicates a problem for MgtC. But if you try some MgtC functions later, the result will often be a failure. The connection to the database by MgtC was established through an internal SQL CLI job that is separate from the MgtC job. MgtC doesn’t know anything is wrong until a request comes through that requires use of that connection that might now be dead.

Ending and restarting MgtC helps ensure that all related components are currently in sync. If all works then, it’s more of an indication of a timing issue. The QHST history log can be useful in collecting names of all related jobs in case various joblogs need to be reviewed. Job start/end messages will cluster in QHST.

Tom

But, that doesn’t do me any good when I need it running right after an IPL (which is usually on the weekend), not Monday morning when I come in. In this case it’s not ending because of something someone else is doing. It’s never starting, abending within 10 minutes of the IPL/STRTCP.

Include a STRTCPSVR *MGTC in your startup program (QSTRUPPGM system value most places) if you need it up and running following an IPL.

…that doesn’t do me any good when I need it running right after an IPL…

That’s true.

However it does you a lot of good if it helps pin down where the problem is. If you don’t locate the cause of the problem, there isn’t much that will do you any good.

The point was to see if MgtC would start under those conditions or if it still threw errors. If it starts at some time after all has settled from an IPL and all other servers are known to be running correctly, we can look at possible timing conflicts. But if it still doesn’t start working under those conditions, there are completely different areas to look at.

You mentioned in your first comment “This is happening at IPL time, not if I manually STRTCPSVR.” Run a controlled test and let us know the results. Given your earlier comment, the results should be good.

That will confirm which of a couple possible directions to go next.

Tom

Which part of this statment didn’t you understand?
“This is happening at IPL time, not if I manually STRTCPSVR.” (implied, not assumed, later, after IPL is completed!).
That is a controlled test IMHO.