Discussion: z/OS Upgrade- Post Upgrade Sanity Checks



IBM OS/370, MVS, OS/390, Linux, TPF, VM/CMS, VM/ESA, VSE/ESA, z/VM, z/VSE, z/OS, z/OS.e etc...

Discussion: z/OS Upgrade- Post Upgrade Sanity Checks

Postby 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.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

Re: Discussion: z/OS Upgrade- Post Upgrade Sanity Checks

 

Re: Discussion: z/OS Upgrade- Post Upgrade Sanity Checks

Postby steve-myers » Sat Jun 14, 2014 4:02 am

Just a few thoughts. In my last gig I did support for a (mostly) Assembler application, so I can speak from some degree of experience.

Assembler applications, unless there are some very obscure z/OS issues, rarely have trouble on a release change. Based on what I've seen, I very much doubt there will be issues going from 12 to 13. If it does break, most likely it will break fairly quickly, not months after the change.

About the only compilers that change from release to release are C/C++ and Java. The High Level Assembler does not change with the z/OS release, but MACLIB and MODGEN do. You might do trial assemblies to try to see if there are MACLIB issues. I can't recall any issues, though.

These users thanked the author steve-myers for the post:
Aki88 (Sat Jun 14, 2014 9:30 am)
steve-myers
Global moderator
 
Posts: 2078
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 235 times

Re: Discussion: z/OS Upgrade- Post Upgrade Sanity Checks

Postby Aki88 » Sat Jun 14, 2014 11:25 am

Thank you Steve; will keep this in mind.

Is there anything else that we should be looking out for, from the perspective of CICS/MQ/TCP-IP protocols/rest of the interfaces; any pointers help us stream-line the movement.


Thanks.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

Re: Discussion: z/OS Upgrade- Post Upgrade Sanity Checks

Postby chinatrain99 » Wed May 20, 2015 8:53 pm

Last November, I went from z/os 1.12 to 2.1. Nobody tested anything before we went from DEV to PROD so we had to back out. We could have used someone like you to kick the application area into shape. My big issue was the language environment variables. In version 2.1 you had to go from an exit to parameters in a SYS1.PARMLIB member. I believe that this is a migration option/recommendation in version 1.13. Look for CICS screens not mapping properly and we also had an issue where Easytrieve was calling a COBOL program and the COBOL program was no longer re-entrant so the program kept loading over and over as the Easytrieve ran. I don't believe there was, or much of a hop, for MQ. COBOL was the same version. Fault Analyzer had some changes. It also didn't use exits and had PARMLIB changes. Other than that, pretty smooth BUT the LE environment caused big, big issues
chinatrain99
 
Posts: 12
Joined: Wed May 20, 2015 8:38 pm
Has thanked: 0 time
Been thanked: 0 time


Return to Operating Systems

 


  • Related topics
    Replies
    Views
    Last post