× 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.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.