unable to start management central
I was trying to start management central using the command STRTCPSVR *MGTC as the job QYPSSRV under QSYSWRK was not running which is supposed to be the job for management central.
But when I tried that, I got the error TCP1A10.
however, when I start it using iseries navigator it shows as started, but the entry QYPSSRV under QSYSWRK still does not show. When I try to connecto to management central to view graph history, it fails to connect to management central. It says, unable to connect to management central and it cannot be connected. Please help
Software/Hardware used:
Software/Hardware used:
ASKED:
March 11, 2008 5:48 AM
UPDATED:
April 8, 2010 6:39 PM
Answer Wiki:
Hi,
I would start looking at why you can't start the job using STRTCPSVR. If you can't start the job this way, you're not likely to be able to start it via navigator.
Try changing the logging on your job using CHGJOB LOG(4 00 *SECLVL) LOGCLPGM(*YES), then try the STRTCPSVR again. Then take a look in your joblog to see what messages you receive. There is most likely an error message which gives more insight into why the STRTCPSVR fails.
Regards,
Martin Gilbert.
David Vasta --> One other thing to do and this works some of the time, Change the QSECOFR password, you can even make it the same things as it was before but for some reason that works some of the time. Just type over it and hit enter then try to start it back up and see if that helps. I had a server once that about once a month would do this and I used my little trick every time and it worked.
To see all answers submitted to the Answer Wiki: View Answer History.
Strange that changing the QSECOFR password makes a difference. But it can’t hurt to try.
If the QSECOFR trick actually works, it is probably because the LanMan password attribute has been disabled. Use the NetServer feature in iSeries Navigator to list and re-enabled profiles for LAN access.
It shouldn’t really require typing anything into a password field nor any other field. Simply pressing <enter> after prompting CHGUSRPRF <disabledProfile> is enough. The LanMan attribute gets reset whether anything changes or not. (If that’s really where the problem is.)
Tom
We had a somewhat related problem recently. Rochester recommended checking the job log for job QYPSJSVR. It did reveal some helpful info.