|
View previous topic :: View next topic
|
| Author |
Message |
Abid Hasan
New User
Joined: 25 Mar 2013
Posts: 88
Location: India
|
|
|
|
<This is a duplicate topic of a thread posted in the Beginner's Forum; posting it here to increase the base of users, who can comment on it; any pointers pertaining to the discussion are really appreciated as it'd help us iron out the requirements from application perspective pertaining to the upgrade; many thanks. Please route the thread to another part of the forum, in case same has not been posted under correct head. The thread on >
| Quote: |
by Aki88 » Sat Jun 14, 2014 12:23 am
Hello,
My apologies for this redundant question, I am a little unclear- as this is outside my area of expertise and I happen to be in murky waters; any help-guidance-pointers are really appreciated. Thank you in advance!
We are currently on z/OS 1.12 and will very soon be moving to 1.13, the local system support team will be handling the upgrade, we being the application/developement/prod supp teams, have been asked to perform PIV on the upgraded OS. To be honest, the sys.supp aren't very inclined in guiding us.
I did look at the Share sessions for Migrating to 1.13; but, as I said there are certain grey areas which I am not very comfortable at.
From the perspective of the application we develop, we are aware of the checkpoints; the problem is arising in case of interfaces that we support.
We currently have MQ: V7.0.1; I am really not sure of the impact the upgrade might have here; aside this below is the current high-level checklist that I am looking at as an application owner:
1. Cobol, CICS, MQ commands should work just the way they were on the old z/OS version.
2. Compilations shouldn’t start failing for certain compilation options (we use a homegrown compilation tool; so it should not fail compatibility test to version 1.13)
3. The translated version of CICS commands should not start acting up.
4. We have an application subsystem, which currently uses Assembler in its core area; what might be the possible impact here?
5. On SIZE error, division by zero which currently may not be abending in PROD, shouldn’t start abending.
What else can I add here as sanity check; the more the better.
Once again, my apologies and sincere thanks for the pointers.
Thanks. |
|
|
| Back to top |
|
 |
Ed Goodman
Active Member
Joined: 08 Jun 2011
Posts: 556
Location: USA
|
|
|
|
At our site, the stuff that always gets us during upgrades are the workarounds that people have done since the last one. We have instances where we have copied load members from one release to another to keep some old code working. Those don't start blowing up for a few days when that weird condition gets hit. Or worse, it doesn't blow up, but makes for bad results.
The way we have to safeguard against it is to run batches before and after. We also do regression testing of the on line system. It's not truly structured, but it's the best we can do. |
|
| Back to top |
|
|
Abid Hasan
New User
Joined: 25 Mar 2013
Posts: 88
Location: India
|
|
|
|
True Ed; what I'm more worried about is - system is up post the upgrade/IPL, and a li'l while later the MQs start bombing or the online system start acting up when the actual traffic comes into play. MQ interface is tad bit mushy ground for me 
<Edit: Yup, a PROD batch will run post the upgrade; rather batch will be halfway through when the upgrade triggers, and the latter half inclusive of reporting jobs will run on the upgraded OS> |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| Abid Hasan wrote: |
| <Edit: Yup, a PROD batch will run post the upgrade; rather batch will be halfway through when the upgrade triggers, and the latter half inclusive of reporting jobs will run on the upgraded OS> |
Is there not a regular maintenance window in which this upgrade can be applied? |
|
| Back to top |
|
|
Abid Hasan
New User
Joined: 25 Mar 2013
Posts: 88
Location: India
|
|
|
|
Hello Akatsukami-san,
 We'll be requesting business for it. Upgrade is performed during non-business hours; and during this window we also have the PROD batch running; so we have to have the upgrade go hand-in-hand with the batch.
Pull the batch trigger by x-hours which would give us the buffer time for the maintenance window somewhere in between the batch, but only after the critical window is completed; which leaves us with the reporting and transmission processing (and a left-over processing portion of the batch). |
|
| Back to top |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011
Posts: 556
Location: USA
|
|
|
|
Yikes. There's your first sanity check right there!
If I were you, I'd make a program/job that will exercise the MQ queues about which you are worried.
Something you can run that will plop some record in there and watch them trigger whatever events they trigger. then run it before/after. |
|
| Back to top |
|
|
Abid Hasan
New User
Joined: 25 Mar 2013
Posts: 88
Location: India
|
|
|
|
Thanks Ed, I can get that done.
Really appreciate your help here; is there something on the lines of cryptographic techniques that I should also be worrying about? I know that this is a very ambiguous question, but considering the fact that we have tons of FTP (both GET and PUTs) processes, which send/receive data to/from the client/s as well as the scheme servers, all of them being 'secure' servers, and afa my understanding goes, there is a conversion/compression/encryption technique being applied prior to any kind of data transmission. I know that this can be answered by the local support but as I had mentioned earlier - not very helpful SYSP guys here. Upgrade shouldn't cause any problem in particular - but a policy change definitely can - has anyone faced this before? |
|
| Back to top |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011
Posts: 556
Location: USA
|
|
|
|
| The encryption and compression are probably happening on the servers, not the mainframe. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 2996
Location: NYC,USA
|
|
|
|
If you have a DB2 then double check the MIPS for batch and online programs, we did intercept suchsituation before so this might be another pointer to be added to your checklist.
Ed, Can you please suggest, How a DB2 can get impacted by this upgrade? as last time we suspected that was the case when we had a upgrade. |
|
| Back to top |
|
|
|
|
