IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

z/OS Upgrade- Post Upgrade Sanity Checks


IBM Mainframe Forums -> All Other Mainframe Topics
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Abid Hasan

New User


Joined: 25 Mar 2013
Posts: 88
Location: India

PostPosted: Mon Jun 16, 2014 11:37 am
Reply with quote

<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
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Mon Jun 16, 2014 5:45 pm
Reply with quote

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
View user's profile Send private message
Abid Hasan

New User


Joined: 25 Mar 2013
Posts: 88
Location: India

PostPosted: Mon Jun 16, 2014 7:31 pm
Reply with quote

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 icon_sad.gif

<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
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Mon Jun 16, 2014 8:25 pm
Reply with quote

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>

icon_eek.gif

Is there not a regular maintenance window in which this upgrade can be applied?
Back to top
View user's profile Send private message
Abid Hasan

New User


Joined: 25 Mar 2013
Posts: 88
Location: India

PostPosted: Mon Jun 16, 2014 8:38 pm
Reply with quote

Hello Akatsukami-san,

icon_lol.gif 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
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Tue Jun 17, 2014 12:25 am
Reply with quote

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
View user's profile Send private message
Abid Hasan

New User


Joined: 25 Mar 2013
Posts: 88
Location: India

PostPosted: Tue Jun 17, 2014 12:04 pm
Reply with quote

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
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Tue Jun 17, 2014 6:19 pm
Reply with quote

The encryption and compression are probably happening on the servers, not the mainframe.
Back to top
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3049
Location: NYC,USA

PostPosted: Tue Jun 17, 2014 7:48 pm
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> All Other Mainframe Topics

 


Similar Topics
Topic Forum Replies
No new posts PD not working for unsigned packed JO... DFSORT/ICETOOL 5
No new posts Help with CA7 Post Command CA Products 0
No new posts Dynamic condition checks COBOL Programming 5
This topic is locked: you cannot edit posts or make replies. Upgrade to Enterprise COBOL 6 COBOL Programming 4
No new posts Backup issues after upgrade to zOS 2.2 All Other Mainframe Topics 0
Search our Forums:

Back to Top