Re: Was this a migration issue, a time change issue or a combination of both?

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
2023-03-11-18:20
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>
wrote:

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:
SELECT *
FROM QSYS2.SCHEDULED_JOB_INFO
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
TIMESTAMP)) A
where A.MESSAGE_TEXT like '%ERPGLES1%' or A.MESSAGE_SECOND_LEVEL_TEXT like
'%ERPGLES1%';

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