Author Topic: Any Migration guides from R9.5 to 10.1  (Read 58 times)

LizetteKoehler

  • Jr. Member
  • **
  • Posts: 17
    • View Profile
Any Migration guides from R9.5 to 10.1
« on: February 12, 2020, 11:50:22 AM »
We are going to upgrade from 9.5 to 10.1

But like the time we implemented 9.5 - as a system programmer - there does not seem to be any cohesive check list to lay out all the steps that are needed to do this upgrade.

Did anyone create a system programmer check list that could be shared?

Specifically, where does the zFS file get mounted?  and are any of the files in the filesystem mounted or just the main file?

Once the files are mounted and then STC JCL is updated with the new APF Authorized Load libs, and DB2 load libs, and the ARSBIN path, any other changes needed?

Do we need to run ARSDB prior to starting up CMOD?  Do all the scripts need to run or just certain ones prior to startup?

Inquiring minds want to know.

Thank you

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 916
    • View Profile
Re: Any Migration guides from R9.5 to 10.1
« Reply #1 on: February 12, 2020, 02:13:58 PM »
Lizette - don't make the upgrade more complicated than it needs to be.

By the way, one of the biggest issues we see with upgrades is that the userid performing the upgrade had all the permissions needed when upgrading a test instance but not when upgrading production.

Anyway, looking at the 10.1 readme:

1. Stop all Content Manager OnDemand activity on databases being upgraded to V10.1.0.

Okay, that makes sense.  Bring down arssockd and everyone else.

2. Backup the Content Manager OnDemand database or make sure a current backup is available.

This is tougher because so many tables point to other tables which point to other tables.

But I have good news.  Unless something really improbable happens you should never have to back out your tables because starting at the 9.5 level of CMOD, V9.5 executables (SARSLOAD and HFS) will work just fine with V10.1 tables.  In other words if you bring up 10.1 and immediately hit an issue don't back out your tables, just revert back to V9.5 code.  This is tested and thus far I've seen no reports of any issues in this area.

* where does the zFS file get mounted? Anywhere you want as long as every //ARSBIN DD points to it.  But the easiest would be to just unmount the old CMOD product HFS and mount the new one.

are any of the files in the filesystem mounted or just the main file?  Just the product HFS.

3. Run the following commands ... (arsdb).  If you're running them from your userid you should export the following, this is what I have in my dot-profile.

STEPLIB=$STEPLIB:ARS.ARSV1010.USERLOAD:ARS.ARSV1010.SARSLOAD:DB2.V12R1M0.SDSNEXIT:DB2.V12R1M0.SDSNLOAD:DB2.V12R1M0.SDSNLOD2
DSNAOINI=/etc/ars/V1010/cli.ini
PATH=/bin:/usr/lpp/ars/V10R1M0/bin:/usr/lpp/java/J8.0_64/bin:$HOME:.
export STEPLIB
export DSNAOINI       
export PATH     

Admittedly perhaps this should be part of the readme.     

There is no magic in the drop indexes, create indexes, and maintenance and runstat steps.  If you want to do that with your own tools, go right ahead.
______________

* Do we need to run ARSDB prior to starting up CMOD?

Yes!  If you try to run Version 9.5 database defs with Version 10 code you get all sorts of ugly errors.

You can run a V10 database with V9.5 code, but not the other way around.
___________

Then change arssockd and other jobs and procs to point to the V10.1 code and bring it all up.

What's the single biggest issue with this upgrade?  Exits because of the change to 64 bit arssockd.

I welcome comments from others.

Ed

#zOS #ODF

LizetteKoehler

  • Jr. Member
  • **
  • Posts: 17
    • View Profile
Re: Any Migration guides from R9.5 to 10.1
« Reply #2 on: February 13, 2020, 08:31:26 AM »
We took the dive into doing the following

1) Mount the new zFS for CMOD R10.1 on a new path
2)  Updated the //ARSBIN DD statement to point to the new path
3)  Replaced old SARSLOAD with new SARSLOAD
4)  Had CMOD Admin (which required DBADM) run the arsdb -vu
5)  Started ARSSOCKD

Amazing - it worked.  Us silly system programmers do tend to complicate things.  This was successful and was way too easy.

Thank you

Lizette

Ed_Arnold

  • Hero Member
  • *****
  • Posts: 916
    • View Profile
Re: Any Migration guides from R9.5 to 10.1
« Reply #3 on: February 13, 2020, 02:30:02 PM »
Good to hear it worked as advertised for you, Lizette.

Let me put in a shameless plug for the V10.1 Release Notes:

http://www.odusergroup.org/forums/index.php?topic=2252.0

As the old Holiday Inn ads used to say, "The best surprise is no surprise."

Ed
#zOS #ODF

scottnys

  • Jr. Member
  • **
  • Posts: 25
    • View Profile
Re: Any Migration guides from R9.5 to 10.1
« Reply #4 on: Today at 11:39:19 AM »
I also suggest upgrading the CMOD System log, if you have an older Instance. (maybe before v9.5).  You can tell by looking at the System Log AG.  The "msg_text" field on older versions is 254 characters.  The new one is 2000 var.  In the document it is "Optional".  If you don't upgraded it, the end of line in the Message is truncated.  Also adds DB2 Timestamp columns in addition to CMOD date/timestamps.

https://www.ibm.com/support/pages/upgrade-guide-content-manager-ondemand-server-v1010

Optional, but recommended. Update the System Log and System Load application groups and folders to support new style dates.

Important: Once this is performed, older clients (prior to V9.0.0) will not be able to query the System Log or System Load folders.

Note: When the System Log and System Load application groups are updated, the current table will be closed and a new one will be opened once a new message or load is generated.

Note: Running these update commands will remove any user/group specific folder fields that have been defined for the System Log and System Load Folders. Customers will have to add the user/group specific folder fields again after the update is done.
Update the System Log application group and folder:

arssyscr -I instance_name -l -u

Update the System Load application group and folder:

arssyscr -I instance_name -a -u