Date: Fri, 9 May 2008 14:13:07 +0100
Reply-To: CICS List <CICS-L@LISTSERV.UGA.EDU>
Sender: CICS List <CICS-L@LISTSERV.UGA.EDU>
From: "Laughton, Mark" <Mark.Laughton@UK.EXPERIAN.COM>
Subject: Re: CEE defs in shared CSD for different z/OS releases
In-Reply-To: A<6AAA5D083B74AA45B542BE8EBB2B26F001AB1FEF@EXCHANGE4.mms.AMS.LOCAL>
Content-Type: multipart/alternative;
Hi Sandy
sounds like we're very much in the same place (though we dont have separate JCL libs as system software levels are resolved dynamically thru symbolic aliases here).
Yes, that'd be terrific. And of course likewise, if we get there first I'll advise you on the relative success/failure....
The issue only really arises in the PROD environment (i.e. CICS sharing same CSD across multiple LPARs) but we're gonna deploy the concatenated defs into the TEST lpar ahead of its migration to 1.9 (end of June) to prove the concept before we hit UAT and PROD....
Keep you posted.
Appreciated
Mark
-----Original Message-----
From: CICS List [mailto:CICS-L@LISTSERV.UGA.EDU]On Behalf Of Stone, Sandy
Sent: 09 May 2008 13:43
To: CICS-L@LISTSERV.UGA.EDU
Subject: Re: CEE defs in shared CSD for different z/OS releases
We have separate procedure libraries for each z/OS 1.7 and 1.9. When we IPLd 1.7 my CICS JCL referred to those CEE libraries. 1.9 IPL referred to the 1.9 CICS JCL.
We only have one RDO so we concatenated the 1.9 CEE group after the 1.7 group in a group list shared by all CICS regions. When we go 1.9 permanently, we remove the 1.7 group from the group list.
This has worked for our sandbox LPAR and CICS regions. We're approaching our production 'test' with more regions and more robust activity.
If you wish, we can report back if this approach fails with apparent reasons. We'd probably then follow IBM's suggestion and create a new group list, (which we'd reference within the SYSIN PARMLIB member in our 1.9 JCL), pointing to the new CEE group. We thought there was a significant difference in the CEE groups this time.
hth,
stone
-----Original Message-----
From: CICS List [mailto:CICS-L@LISTSERV.UGA.EDU] On Behalf Of Lizette Koehler
Sent: Friday, May 09, 2008 8:21 AM
To: CICS-L@LISTSERV.UGA.EDU
Subject: Re: CEE defs in shared CSD for different z/OS releases
I am also interested in this topic.
I thought the CEE entires in CICS would be downward compatible? Is this correct that LE does not provide a downward compatible process for CICS and CEE CSD entries? That will make it rough on those of us that have common shared CSDs.
Lizette
[>] --> Snip
Hi
we're shortly undergoing a z/OS 1.7 to 1.9 migration, rolling this out across each LPAR one at a time. Fairly standard I guess.
One concern we have is regarding the CEE group defs and their compatibility with the corresponding LE version.
The simple approach (and the one recommended by IBM) is to upgrade the CSD of those CICS on the LPAR being upgraded at the same time as the LPAR upgraded i.e. the CEE.SCEESAMP(CEECCSED) member defs are *not* compatible with an earlier release.
Ok, its a pain (we have a large number of CICS systems on each LPAR - thats a lot of DFHCSD upgrades 'on the night' - it would have been nice to roll these out gradually and for them to be backwards compatible) - but it'll be guarenteed to work at least.
However, in the prod environment we have several scenarios which mean this 'upgrade the CSD on the night' approach wont work (or is at the least difficult):
1. we have a number of CICSplex groups (with CICS systems spanning multiple LPARs) using a shared CSD
2. we have some systems defined such they may be ARM restarted on a different LPAR if required (touch wood - its never happened!)
3. we have some systems (e.g. FORs) which are dynamically 'moved' between prod LPARs (by automation) during a planned outage
We approached IBM for advice and the only feasible solution (from them) appears to be to define 'version specific' CEE defs in their own groups (e.g. CEE170, CEE190) and to change our GRPLISTs such that each CICS system has a specific startup list containing the appropriate CEEnnn group (depending on which LPAR it runs on).
Apart from being a pain to position ourselves towards this (i.e. lots of change to go thru!) this doesnt completely solve the problem for those systems which aren't static (e.g. might be ARM restarted on a different LPAR). Also, given that IBM ship DFHLIST with the "CEE" group defined by default (and which is locked), this sorta goes against the grain and feels like a backwards step.
For reasons I wont go into here, we don't / can't use program autoinstall.
The obvious option to me seems to be to simply concatenate the defs from both versions and add them to the existing CEE group before the first z/OS upgrade. However, IBM can't / won't confirm that this will work.
I figure that this is no different from having program autoinstall active to install any required defs on demand, so ought to work?
Also, apart from the LANGUAGE attribute being removed from all the PROGRAM defs in the z/OS 1.9 defs (which shouldnt matter - right?), the addition of a lot more defs (mainly POSIX) and the removal of some old ones, there arent any changes to existing defs i.e. attributes which change between releases for the same definition. So we'll simply have some redundent, unused program defs (at either version).
Q. Does anyone else do this (and have you experienced any issues?)? If not, apart from using autoinstall, how do you manage this issue?
Wouldnt it be nice if CICS simply dynamically installed the appropriate LE defs during CICS initialisation, depending on the LE level on the host LPAR? Hmmmm....
[>] --> UnSnip
------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This message is intended only for the use of
the individual or entity to which it is addressed and may contain
information that is privileged, confidential or exempt from disclosure
by law. If the reader of this message is not the intended recipient, or
the employee or agent responsible for delivering the message to the
intended recipient, you are hereby notified that you are strictly
prohibited from printing, storing, disseminating, distributing or
copying this message. If you have received this message in error,
please notify us immediately by replying to the message and deleting it
from your computer. Neither this information block, the typed name of
the sender, nor anything else in this message is intended to constitute
an electronic signature, unless a specific statement to the contrary is
included in this message. Thank you, Antares Management Solutions.
==============================================================================
This e-mail has come from Experian, the only business to have been twice named the UK's 'Business of the Year’
----------
Do you have an interest in the strategies and solutions for Credit Risk management and Fraud prevention in the Telecom industry? Register for The European Telecom Forum, Palma de Mallorca 5-6 June. Visit: www.experian-da.com/telco08.html (simply paste the URL into your browser)
--------------
Discover how your choice of payment strategies can help you reduce cost, risk and fraud in your organisation.
Register free for Payment Strategies 2008, NEC Birmingham, 10 June. Visit: www.ps2008.co.uk (simply paste the URL into your browser.)
-------------
===================================================================================
Information in this e-mail and any attachments is confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other binding commitment through the use of this electronic communication unless it is issued in accordance with the Experian Limited standard terms and conditions of purchase or other express written agreement between Experian Limited and the recipient.
Although Experian has taken reasonable steps to ensure that this communication and any attachments are free from computer virus, you are advised to take your own steps to ensure that they are actually virus free.
Companies Act information:
Registered name: Experian Limited
Registered office: Talbot House, Talbot Street, Nottingham NG80 1TH
Place of registration: England and Wales
Registered number: 653331
[text/html]
