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

Next submission date was Sunday 3/12 at 2am.
From the BRMS recovery report:
STEP001: Recover Licensed Internal Code: Started at: 2023-03-11-15:00
STEP002: Recover Operating system Start date/time: 2023-03-11-17:37
STEP004: Recover BRMS product and associated libraries: Start
STEP013: Recover Required System Libraries Start 2023-03-11-19:02
STEP015: Recover Media sets Concurrently Start time not recorded but
shortly afterwards
However coworker messed up and started disk mirroring. One, we never use
mirroring. If it's internal disk we use RAID 6. Two, this was on a SAN so
it's stupid to start IBM i mirroring. Three, this cuts your disk in half
so we filled up. This caused us to IPL to DST to turn off mirroring and
resume the concurrent restore. At this time we were tired, dazed and
confused and lost track of time and our best guess is a little off as it
was over a week ago.

On Wed, Mar 22, 2023 at 3:14 PM Gavin Inman <midrangelist@xxxxxxxxxxxxxx>

First IPL on the power 10, what was the date/time? Was it before the
next submission date?

On 3/22/2023 7:58 AM, Rob Berendt wrote:

Had an interesting fluke we noticed after our system migration from a Power
9 to a Power 10. Exec team is currently on a retreat. A salesperson calls
just noticing that he hasn't received his daily sales report since then.
So we do a WRKJOBSCDE and notice that it's not on hold, etc. Job
description, job queue, etc are used for numerous other jobs so that's not
it. Then we noticed that the next submit date was for 10 days ago (day
migration completed). Weird. So I ran this SQL:
where NEXT_SUBMISSION_DATE < current date
and that was the only one in this condition.

Prior to that it was running fat, dumb and happy as evidenced by this:
select *
FROM TABLE(QSYS2.HISTORY_LOG_INFO(current timestamp - 30 days, CURRENT

But, then we noticed it was 2am sharp that it was supposed to submit. The
system was in restricted state as it was being saved/restored from the
Power 9 to the Power 10.
And, (drum roll please), there was no 2am on 3/12 due to the time change.
So putting your system in restricted state to prevent DST anomalies is just
a shot to the foot.
That system migration does require you manually set your time as you are
doing manual IPLs and get prompted for the system date and time.
To fix the job schedule entry so that it would start running:
1 - holding and releasing it did nothing
2 - Putting a 2 on it to change it and entering the screens did change the
next submit date.

In case it's significant, RCYACN(*SBMRLS)

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related

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