A couple of weeks ago in mid-January I upgraded one of our shops primary Endevor instances to V16.
This was all new to me – I’d been on the training courses, but where (really where Nick) is the training course telling me what to do in regards to an upgrade? Never fear, there will be a manual telling me this right? Wrong – there’s an install manual (which doesn’t even mention the word “upgrade” till page 115 – nevertheless I read the whole manual – all 257 pages. Ok that didn’t really help!
Realising I am just a lowly Endevor Administrator helped, I needed to talk to a number of different people in other roles like security and sysprogs and let’s not forget to inform the developers (users/customers too).
Is it really that hard? Well with hindsight, obviously not as much as I initially thought. To all of the guys who know how to do this already I imagine this is dull reading, but the basics of assembling the C1DEFLTS and EXITS and do I use Endevor to store the code that runs Endevor (Chicken/Egg scenario) – all interesting stuff.
So, we now have the ability to run two versions of Endevor and have converted to using PDSE’s. The allowing of two versions isn’t to rush forwards with the next release from CA but instead to allow us to pretest new versions before release. This reduces the risk from any upgrade if we use the admin staff as the test audience for the release. Doing this allowed us to pick up a couple of issues.
The actual implementation took about 5 hours as we restarted 3 LPARS on three different mainframes and tested inbetween (not just Endevor but the GUI interface piece we have supplied by IBM), the reason we were pushing against machine restarts was we were amending the LINKLIST permanently rather than dynamically. Funny point at the first restart realising I had made Endevor unavailable and couldn’t get into it myself to test – that bit was missing from my imp plan.
Issues seen beyond the upgrade so far was VSAM I/O issues (nothing to do with Endevor) – there’s an IBM issue with SMSVSAM but we’re affected the most as the underlying structure of Endevor is VSAM files and we use RLS. We had a nasty corrupted PDSE issue (again nothing to do with Endevor - this related to zOS 2.1). Both of those issues are with IBM. Finally two panel issues (PIR for next time - must check for 24*80 screen resolution – it seems a lot of people still use this scarily low display!).
The most complex piece to understand was the local customisations, sometimes it’s better to have a panel customisation rather than an exit and applying these on top of the base product. Endevor storing Endevor continues to intrigue me of how everyone else does it; we do, but our output files aren’t the “final destination” - so it’s a case of manual shipping ie copying the elements into the libraries.
Starting from scratch with understanding the components that make up the Endevor software base has really helped my understanding of what goes where but more importantly why.
Right – so I’m good for 18 months right? Just another 20 mainframes to go across 15 instances. What? Version 17 is out already…