Re: MSF Problem

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.