On 07-Jan-2014 14:59 -0800, Glenn Gundermann wrote:
I'm at a client and don't have access to another system to compare. I
think something is amiss here because we have to STRMSF each Monday
morning.
We should infer the system was powered down and then IPLed on Monday
morning.?
I would appreciate if you could see how this differs from your shop.
First, we're on 6.1.
QSYSWRK has an autostart job QZMFECOX, which does a STRMSF.
Pretty much standard AFaIK.
The joblog for QMSF says SMTP jobs not active and ends.
What message identifier and message details from the spooled joblog?
Best to include the request message and all information up to the
escape message for the failing STRMSF request.
SMTP is configured to "Start when TCP/IP is started".
So CHGSMTPA AUTOSTART(*YES) is in effect.?
The controlling subsystem has an autostart job that does a STRTCP,
which would start SMTP.
And the parameter defaults for STRTCP are the system-supplied vs
modified?
This is a custom autostart entry apparently; i.e. not system-supplied.?
Perhaps remove that AJE, and use the STRTCP(*YES) feature of the IPL
attributes; i.e. CHGIPLA STRTCP(*YES) to enable TCP/IP as part of each
IPL instead of that Autostart Job Entry.
The two autostart jobs start at almost the same time (only 1 second
apart).
The timing is such that QMSF starts about 46 seconds before the
STRTCP runs so SMTP isn't running yet.
Hmmm... one second but 46 seconds? I am not sure I understand...
seems like the implication is that the same thing is described in two
ways? Is the intended implication, that the start of the SMTP server
job [as the effect of the STRTCP; i.e. not the STRTCP itself] is fully
46sec after the STRMSF?
What to do to fix MSF?
Apparently, investigate the [details behind the] slow start of TCP
servers [notably the SMTP]... and the specifics behind the unstated
message [and any preceding diagnostics] for which the STRMSF fails.
Btw, they do not have anything set in QSTRUPPGM. It's set to *NONE.
As a second question, they have STRTCPSVR *ALL in the controlling
subsystem autostart job. This generates CPF3894 Cancel reply
received for message TCP1A15.
Interestingly the only reference to that message I found was the v5r1
MTU which stated with regard to "Starting or ending all TCP/IP servers"
that "With V5R1, when an attempt is made in *interactive mode* to start
all servers (STRTCPSVR *ALL) or to end all servers (ENDTCPSVR *ALL), an
inquiry message is displayed." Emphasis [with asterisks] my own.
Perhaps there is a defect, such that the inquiry message gets issued in
an autostart job.?
What is best to resolve this?:
- ADDRPYLE for TCP1A15 with RPY(G)
The above is helpful to effect that reply, only if the autostart job
is running with INQMSGRPY(*SYSRPYL). If not defined that way, and the
Job Description is not changed to that, then changing the default reply
in the message is also an option. There is also an exit program for
inquiry messages... but that would be overkill for just this one msg.
- use STRTCPSVR *AUTOSTART
The above seems likely to circumvent the inquiry, given the text of
the message referring to the attempt being "starting all servers".
Though perhaps changing to STRTCPSVR SERVER(*SMTP) instead?
- remove STRTCPSVR altogether since it's been canceling and
therefore not being used
The above, removing the autostart job entry that performs that
request, seems reasonable for that reason. Apparently only the effect
of STRRCPSVR SERVER(*AUTOSTART) has been the norm [implicit with the
STRTCP], albeit too slowly to allow the STRMSF to function without errors.
I do not recall the means for starting an the autostart jobs, e.g.
with regard to using the JOBQ() from the *JOBD... or without any job
queue... so ensure the work entering the controlling subsystem is not
throttled either through the job queue attributes or the subsystem or
otherwise; i.e. for the controlling subsystem, make sure any values for
jobs are *NOMAX. And ensure the base and machine pools [QMCHPOOL]
settings are not ridiculously low with performance adjustment [QPFRADJ]
turned off.
I would try removing\deactivating all STRTCP and STRTCPSVR actions
from the autostart job entries, and let the STRTCP and the effect of
servers identified with AUTOSTART(*YES) to activate via the CHGIPLA
STRTCP(*YES). If that did not assist, then I would wonder if perhaps
some /performance issues/ mentioned here in the past with IPV6 might
somehow be related... and thus the next try would be additionally to
modify the STRTCP to not start that capability; i.e. CHGCMDDFT STRTCP
'STRIP6(*NO)', so the STRTCP performed by the OS for post-IPL does not
include that. And if still no luck, I would modify most servers [other
than SMTP] to AUTOSTART(*NO), and then reinstate the autostart that did
the STRTCPSVR as a CALL to a program that starts the additionally
desired servers separately [or *ALL] after a delay to await somewhat
longer than the newly timed difference between startup of SMTP and the
startup of QMSF. Failing any of those, I would probably go to my
service provider [might just start with that if my call was effectively
/free/] or modify the startup for MSF to be a CALL to a program that
polls awaiting the necessary pre-requisite startup activity before
issuing the STRMSF.
midrange.com
