×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 22 Mar 2013 09:50, John McKee wrote:
The mess that happened last week was traced to a modification.
For reference, that was the following thread:
Subject: Down system?????
http://archive.midrange.com/midrange-l/201303/threads.html#00638
The modification was in a startup program.
So like Rob suggested in the following message in that older thread,
how the origin could be tracked down.
http://archive.midrange.com/midrange-l/201303/msg00661.html
We don't use (apparently) a modified QSTRUPPGM. Instead, an autostart
job is involved. That job had a modification applied that requested
if the startup should continue. I don't know yet, and maybe never
will, why that message was not viewable on QSYSOPR.
The spooled QPJOBLOG in WRKJOB JOB(STARTUP/BSYPGMR/302225)
OPTION(*SPLF) could reveal; IIRC the indication of what message queue to
which the message was sent is visible. At least the sending program and
instruction would be there, so as to allow redirect to the program
source to find out, just as Rob suggested.
DSPLOG QHST PERIOD((as-appropriate)) JOB(STARTUP/BSYPGMR/302225)
would show if the message had [as an inquiry] been sent to QSYSOPR, but
possibly was deleted before your review.
It is my understanding that the purpose was to prevent users from
jumping onto the system when maintenance was being done. My thought
was that maybe CHGIPLA might have been better.......
That Start in Restricted-State feature [STRRSTD(*YES)] is intended to
ensure the QCTLSBSD is not started. But sometimes there are
requirements to start some stuff but not others. From what has been
described, I think the non-QSTRUP autostart job entry and its processing
need to be more fully understood for what it intended for the given
situation, and how that autostart can operate in conjunction with the
QSTUPJD autostart job rather than with some apparent conflict.
However, that brings up another issue:
Every week for at least the last 15 years, the system was IPLed
every week. This goes back to CISC. We are now on v5r4m0. IPL is
now every two weeks. Nowhere near current on PTFs.
Question was asked of me: Do we even need to IPL anymore?
I have seen mention of IPL quarterly, and even longer. Does PTF
level make any difference?
Since v5r3, aside from mostly just the condition reported by CPI0997,
a system that is not having maintenance applied need effectively-never,
to IPL. An exception being to resolve an issue that can only be
resolved by powering down [or after a power outage, the powering up] of
the system. But even for /apparent/ requirements to PwrDwn, there are
sometimes circumventions; e.g. for a subsystem that will not end, it
could remain never-ending and any devices that are not released can have
alternates created, then a different subsystem created and activated
with those alternate devices. Other /circumventions/ might require
/patches/ which are not as simple as just creating alternate objects to
replace those for which an IPL might otherwise be required.
Boss is reluctant to apply PTFs as he does not want to break
something.
Heh. And to not fix things that are [not yet known to be] broken ;-)
With years of no maintenance, I wondered months ago about blowing
the link loader.
Given the described status, little harm should come from permanently
applying all LIC fixes on an upcoming IPL. That followed by load and
apply of just the LIC HIPers would limit any potential issues for limits
on the link loader; then a second IPL to add the remaining LIC PTFs. Or
an install of a more recent re-save, or an upgrade to a more recent
resave of V5R4M5 if not already installed, could similarly limit any
potential issues.
As an Amazon Associate we earn from qualifying purchases.