Calling on the "tree of Endevor knowledge"!
I know there are many of you out there faced with this challenge of blocking out users when you need to run maintenance jobs. Would you mind sharing your process with the wider group? We value your input and you will be a hero for such customers:
We continue to struggle with daily housekeeping processes being in contention with users within our Endevor environments. Do you all have any tricks we could use to basically stop people from being in Endevor while our housekeeping (unloads and backups) runs?
As always, THANK YOU for sharing!
At my current shop, there is a kill job that runs at the beginning of the weekly maintenance cycle. This kill job is a simple REXX routine that sends a TSO message to the user and allows a minute to save any Endevor work in progress. After that minute is up, the contending userid is cancelled. It takes mere moments for the maintenance to complete so the user can typically go right back into Endevor if they need to. We have had only one issue with that process in four years and that was when a larger-than-normal release decided to do an implementation during our nightly maintenance window - the result was that nightly maintenance was delayed by a couple hours - chalk that one up to Lessons Learned. At a previous Endevor shop, there was a nice CLIST that was put up at the beginning of Endevor maintenance to prevent further access. This CLIST presented a message that Endevor was currently unavailable for maintenance. When nightly processing was complete, nightly maintenance put the standard Endevor CLIST back in place. It seems like the success of either process is dependent either on an Operator watching and addressing ongoing contention messages or Automation that does that job.
Hope this helps,
We have a variety of methods - manual operator cancel when they see the houskeeping is trying to access a file in use.
I like Dana's idea of a REXX / built in cancel (sounds far more automated).
We have a file that has an availability marker in that we set to "YES/NO" which means users can't physically get into Endevor via the normal ISPF panels.
We also have our own Job class defined on one system - so we drain the initiators on that
We have found recently that our GUI (CARMA) usage through RDz is proving disruptive.
If you didn't know - there is no associated TSO session assigned when a user logs on via this product.
Files can be locked in such a way it is very difficult to release.
Our current call on this is to issue a Force Cancel against the RSED (RDz) task directly - although we have suffered a complete LPAR outage via this command previously - so try and tie it around IPL's if possible as there is a danger of using it.
This would be what we would want to adopt. Could you share a templated/masked version of this, or are you restricted with an intellectual property policy, like most sites?
Did you get some useful feedback?
YES! Thanks to all members who contributed to this post. I received several useful and interesting tips that have already provided value for the inquiring customer.
A+ rating to the Endevor Community for your collective knowledge and willingness to share and participate in the exchange!
One simple temporary security RACF/Top Secret/ACF2 change. Disable access until maintenance routines are complete and enable when they are done.
That would work if they are not in Endevor yet. But if they are already in Endevor and not currently active, or at their desk, the change would have no impact. There have been instances of users using macros to keep themselves active. Which in my mind should be a sackable offence due to the possible usage of appearing to be around when you are down the golf course
I should say "disable ENVIRONMENT access".... according to the well-planned and appropriately designed implementation of your External Security Interface. A single rule will do it... ..... but well-designed Native Security should provide the same capability...
We, Endevor administrators, need a way to quiesce or shutdown Endevor so as to prohibit usage and perform maintenance. LSERV control of the MCF files is only a partial solution and the performance of shared/remote systems can be prohibitive.
There should be a command that quiesces usage of Endevor that can be executed so that when complete, administrative work can proceed, whether it be backups or upgrades.
Security rules is, in my opinion, not the way to go as it only brings on more problems or headaches to users, administrators and support.
A suggestion might be to test or use an enqueue on an Environment or system so that access is prohibited?
Don't misinterpret my suggestion/solution, Bernie. One of the things I've always advocated is simplification of rules being used for Security. A lesson I learned a long time ago is that, when you first begin with Endevor, it becomes tempting to write rules for everything. I even created an entire ISPF based security administration system to maintain the rules I created. When the site I was at changed from ACF2 to RACF, I was forced to re-examine "what" was really needed versus "how".... and discovered we (administrators) have a tendency to grossly over-engineer "what" we need in order to overly restrict "how" we are doing it. I discovered I could cut down the hundreds of rules I had to a mere handful and not sacrifice a single layer of security in the process.
So I'm serious when I say "one" rule changed to DISALLOW for the time of the maintenance, changed back to "ALLOW" again afterwards. In essence, you make your security software work FOR you rather than AGAINST you!
Now... I'm not saying the POLITICS of getting the security administrators to let go of writing and maintaining the Endevor rules is easy... many sites have a very tough group thinking they know all there is to know about anything and everything related to security.... even if they haven't a clue about Endevor. But if you can get past that, you can set up a single job/command to provide that disable and a single job/command to re-enable it. And the mechanism already exists today versus a development or customization effort.
I like Bernie's idea. Can this be submitted as an idea? Perhaps the vendor could utilize John's suggestion and make it a utility that can be executed rather than involving the Security team or the SE team to implement a temporary ESI change (at least from my perspective).
Again, just to make sure it's understood, what I am advocating does NOT require a change to what is set up in ESI.
What I am saying is you can change the access allocation of a single rule to a single mask in ACF2/Top Secret/RACF (not Endevor and not ESI). Then, when you're done maintenance, you change the ACF2/Top Secret/RACF access rule to that single mask back to general access. The "on/off" switch actually already exists today; it's just controlled in the security software and whether it's a single switch or a whole load of switches is a function of how well or over engineered the rules were created.
To be honest, it's really really simple. BUT, like I said, it requires a (re)examination of the security you THINK you need versus the security you ACTUALLY need. Many sites have never "gone back" and relooked at what they implemented "way back when" because "it works". What I discovered is, when you really look at what you really need and put the politics aside, the rules can be (and actually are) very simple.
To illustrate a truly basic example, the first entry in the Endevor provided NAMEQU entry reads:
NAMEQU ENVIRONMENT_ACCESS, +
If I have a single rule in ACF2/RACF/Top Secret that allows READ access to rule "C1.ENVIRON.**", I allow access. If I temporarily change that rule to deny access, I temporarily suspend all activity in Endevor. On/off in the security software.
In reality, I can show you how you can even boil the rules down further to a mere handful, but I just want to make sure we aren't thinking its overly complex. It's really not.
But like I said, I'm not addressing the politics or egos involved!
We modified our ENUXSITE to read a "home grown" configuration file. Our configuration file contains a Y/N indicator telling ENUXSITE whether Endevor maintenance is being performed. If We update the indicator to Y, the ENUXSITE will return a C1DEFLTS table that doesn't exist, and prevents the user from going into Endevor. In addition, we have ENUXSITE display a message to the user letting them know Endevor maintenance is being performed. Once in maintenance mode, we see which users, if any, are holding up the ENDEVOR files and cancel the users. We use deferred allocation to allocate the Endevor files needed for TSO Foreground Endevor, so in theory our list of users only includes users currently in Endevor in one of their screens.
I hope this helps.