On 2/1/2016 2:17 PM, Chris Bipes wrote:
And if something goes wrong with the CL, you are hosed.
It seems to me that the most likely issue is the SSL / TLS configuration
that's at fault. There's very little that can go wrong with DLYJOB,
ENDTCPSVR, DLTJOB, STRTCPSVR; the CLP itself is unlikely to cause a
problem. It's easy enough to test the CLP itself /before/ making
changes to the SSL / TLS settings.
Web or iSeries Access will keep you connected to the server.
I myself tend to think 'script' before I think 'GUI' but that comes from
a lifetime of writing code for a living, I guess. That's too many words
to say that this CLP wouldn't preclude me from using a GUI as a backup
position.
Any submitted jobs or home grown programs leave a
chance that the telnet server goes down and does not restart.
Having already tested the CLP (see above) it would then become clear
that the issue is one of my wrecking the configuration. Pedantically,
it wouldn't be the CLP which rendered Telnet nonworking; it would be my
poor configuration skills. Which are no better if I end Telnet with a
GUI or a CLP. :-) Once I mis-configure and then end Telnet, I am indeed
hosed.
Now what do you do?
In no particular order:
FTP CMD STRTCPSVR
*ADMIN / port 2005 web UI
SBMRMTCMD from another LPAR
ssh from my PC
RMTCMD from my PC
If I have really managed to destroy the Telnet configuration, I'll
almost certainly need to IPL to DST in order to inspect and adjust.
Although my first instinct is to have already written a CLP which would
restore the Telnet configuration to it's earlier, working state. And
submitted that with a 15 minute delay so that it would run just after my
first attempt.
Having a test LPAR makes this sort of thing easier to do than working on
a production machine at midnight, but I've done both.
midrange.com
