The full / incremental unloads are important (I think we all agree on that)
but yes, they require exclusive (no one can be in the Environment / system
begin unloaded) and that's a problem for any company with offshore
developers; i.e. it's very hard to find a time when no usage is occurring.
We had to pivot to a mix of unloads *and* DFDSS. So we performed weekly
full unloads every weekend and had nightly DFDSS backups; not ideal but
Applications wouldn't agree to a nightly maintenance window. Obviously, a
true disaster occurring mid-week would have meant the loss of recent
changes but the DFDSS backups would at least give us a starting point.
Also, our move processors, on a move to PROD, had a step to copy the
current output executables; DBRMs, loadmods, etc. to a MINUS1 library. So
if production was NDV.PROD.LOADLIB, we also had a NDV.PROD.LOADLIB.MINUS1
that could be steplib'd to etc. We also did this when they wanted to
obsolete something from PROD - the processor would save all the output to
the MINUS1 libs. With all 3, you're covered for a lot of different
situations.
Back to unloads... Even during the weekend maintenance window, we still had
occasional trouble with developers being in Endevor during the scheduled
run of the full unload. To make them comply, we added a batch job that
would cancel TSO sessions of anyone ignoring the maintenance window, I
think we checked for an enqueue on the element catalog? I know that might
not be an option at some companies but it was effective for us.
To keep the developers informed (and keep them out during maintenance), we
added code to the Endevor CLIST (see below). The 'NEWS' dataset would
inform them of current events, remind them to say out during maintenance,
the 'STOP' dataset (which the TSO session cancel job would allocate at the
start / remove at the end) would simply exit them without invoking Endevor
/ QuickEdit. Not foolproof but worked well.
IF &SYSDSN('NDV.ENDEVOR.STOP') EQ &STR(OK) THEN DO
EX 'NDV.ENDEVOR.STOP'
EXIT CODE(0)
END
IF &SYSDSN('NDV.ENDEVOR.NEWS') EQ &STR(OK) THEN DO
EX 'NDV.ENDEVOR.NEWS'
END
*Dave Harding *
Client Services Consultant • Mainframe Software Division
Broadcom Software
Mobile 317-403-1740 |
dave.harding@broadcom.comUpcoming vacation: June 13 - 15, August 10 - 23
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
Original Message:
Sent: 5/20/2025 1:00:00 PM
From: John Scott
Subject: RE: ENDEVOR IS DOWN !
Yes its very useful for that - I am concerned about the time it would take if recovering many elements and associated outputs.
I just found this recent article Tips on maintaining Endevor for AdministratorsTips on maintaining Endevor for Administrators
This strongly suggests using Endevor unload/reload versus DFDSS but mentions the option using DFDSS for backing up everything (maybe for 1 environment) and UNLOAD FULL CHECKPOINT which then allows subsequent UNLOAD INCREMENTAL to only capture changes since. Also suggests DISP=OLD for housekeeping to get exclusive access but I wonder if that could lead to users left logged on holding up the housekeeping ?
Would there be an automated way to cancel users delaying housekeeping ? *MIM1040I MCFBACKUP WAITING FOR RESOURCES FOR 5 MINUTES
Original Message:
Sent: May 18, 2025 10:37 PM
From: Dana Crawford
Subject: ENDEVOR IS DOWN !
I've only ever needed RELOAD (full recovery), RESTORE (individual elements), and BACKOUT (package). If restoring old elements from backup, they get placed at the entry point of Endevor so that they go through full testing again.
Original Message:
Sent: May 15, 2025 09:51 AM
From: John Scott
Subject: ENDEVOR IS DOWN !
Any other methods suitable for handling events short of those that warrant a full DR and its only an Endevor outage after all ?
Original Message:
Sent: May 15, 2025 09:50 AM
From: John Scott
Subject: ENDEVOR IS DOWN !
Endevor is Development and Operations but sometimes Endevor seems to be in a no-mans land between test and prod.
How can we be ready to recover from unexpected loss of some of the Endevor datasets ?
Potentially a significant headache for an Endevor administrator but not like a PRODUCTION event that is going to trigger a SITE wide switch to your DR site.
The manual says "Use the Endevor Unload, Reload, and Validate utilities, also known as program C1BM5000, to mitigate physical device failure or site disasters." perhaps.
A focus on using Endevor UNLOAD of elements implies an ability to use these to RELOAD them in event that recovery is required.
Is there a single RELOAD job waiting for me to submit or would I have to find some previous full backups and find which incrementals to RELOAD on top building the JCL to reload in the middle of the night ?
RELOAD is great when helping a user who deleted an element by mistake.
But what about larger recovery scenarios that are not site wide disasters what is the best strategy ?
There may be HSM backups taken periodically but can they take into account the Endevor need to co-ordinate updates on base delta mcf and outputs and package to maintain integrity ?
It seems recovery scenarios where RELOAD alone is sufficient are limited.
RELOAD could be slow and you don't want to regenerate all those outputs and create new footprints too as RELOAD does not restore the outputs and ACMQ info so only useable for un-generated source.
So it seems you must also have co-ordinated images of the output libraries at the same time as the UNLOAD.
There may be some HSM backups taken periodically but are they timed to synchonise a snapshot of base delta mcf and outputs and package - are they easy to co-ordinate in recovery ?
So we probably need DFDSS backups of all datasets associated with the source co-ordinated at the same time as the backup.
Instead of having to use RELOAD to get the Endevor source and MCF back as it was then it could be much faster to DFDSS dump MCF BASE and DELTAs for an Environment at the same time as the outputs of the generated source for that Environment.
Is DFDSS for all datasets together at Environment level the preferred approach ?
Dump with datasets open or force users off ?