Upgrade two E1 iSeries LPARS OS V5R4-V7R1 recommendations?

[shurtle]

Hello JDE List,

We have one JDE EnterpriseOne 9.0 instance on 8.98.4.10 with two AS400 Enterprise/DB LPARS on two physical iSeries on V5R4. The test LPAR hosts DV/PY/PS and the production LPAR hosts PD, system and security. We are planning an OS upgrade to V7R1. Oracle says it is OK to upgrade the test LPAR (DV/PY/PS) to V7R1, test for 1-2 weeks, and then upgrade the production LPAR (PD and system).

Has anyone had any experience with upgrading the OS of a test LPAR before the prod LPAR? Any gotchas we should look out for? When we upgraded from V5R3 to V5R4 in 2008 the recommendation was to upgrade both LPARS at the same time, so I was surprised (happily) that Oracle said it was ok to upgrade the test LPAR first.

We are doing/have done the following:
• Reviewed doc id 1250684.1 E1: OS: Server-to Server Database Communication Between System I Servers Using TCP/IP XDA Connectivity
• Researching any other Oracle documents for V6R1/V7R1 and MTRs
• Certifying all software installed will work with V7R1 and any PTFs needed
• Load latest V5R4 CUMs and PTFs for ANZOBJCVN tool
• Run ANZOBJCVN tool
During/after upgrade and program conversion of each LPAR:
• Load latest DB group PTF for V5R4 on both LPARs (if necessary)
• SAVE 21, reclaim storage and IPL
• Load latest V7R1 CUMS and PTFs for JDE E1 and other software
• Delete all JDE SQLPKGs on both servers when we upgrade LPAR
• Change the JDE.INI, BSFN BUILD and AS/400 sections
• Upgrade the iSeries Client Access version on all webdev clients
• Copy new jt400.jar from the ifs to Windows WebSphere servers (if newer)
• SAVE 21
• Test, test, test

Thanks, Sandy

 

[Michael L.]

Hi Sandy. Oracle gave you the correct information.

Back in 2011 I upgraded 7 partitions from V5R4M5 to i7.1. We did not upgrade our non-production & Production (3 physical iseries) partitions at the same time. We took several weeks to test prior to upgrading Production. The only gotcha I had was with the jt400.jar file. If you’re on WAS 6.x you might want to review the attachment. Don’t forget about the WebSphere fixpack.

Good luck with your OS upgrades.

Michael

 

[cncjunior1]

We upgraded our Test and Prod LPARs about a year and a half ago from V5R4 to V7R1 with no issues. We upgraded our TEST system first and had it running and doing testing for about three months before upgrading the Production system. Be sure to make sure all your group PTFs are fairly current on both systems before doing the upgrade. I don't recall having to change anything in for the BSFN section in the JDE.INI, however. All our TGTRLS variables in that section were set to *CURRENT and not the actual OS level.

 

[shurtle]

Thank you both for your input, it's good to know that others have successfully done the upgrade this way.

Michael, thanks for the note on the jt400.jar! Our Websphere 6.1 is on Windows and it is a supported fixpack of 27. What should I check? I need to upgrade to WAS 7.0 by the end of Sept and may do that before the upgrade. I see Oracle now supports WAS 8.5, but not until 8.98.4.11 and we are on 8.98.4.10. So, it looks like I will have to upgrade twice, bummer. We plan on upgrading to Tools 9.1 after the iSeries OS upgrade and I will probably go to WAS 8.5 then, but that will probably be next year.

CNCjunior1, I checked the server jde.inis and we also have the variables set to *CURRENT. We installed the latest CUMS last summer and they haven't come out with newer ones, so we should be good for that. If there are newer group PTFs for hiper, DB2, I might load those first.

Thanks again for the feedback.
Sandy

 

[shurtle]

Michael L and any one else on JDEList,

I have three follow up questions.

1. The first is about SQL packages. Some of the documents mention deleting all SQL Packages on both servers which I plan on doing.

But, I noticed that UBE SQL Packages are created on the Production server when UBEs are run on the test server in the system library. I am not sure why it creates a SQL package on the Prod server when the UBE is run for DV and/or PY on the test server, but it does. I have SQL Package Library set at 0.

Does this work this way for you and did it cause any issue when you upgraded the test server and tested before you upgraded the production server?

2. Did you have any issues with installing the Access for Windows for V7R1 with the lastest SP on the Dep server and building packages for either box

3. Can you do data refreshes from PD to DV/PY while they are on different OS levels. I do a savlib of PD business data to a SAVF and then ftp to the test server and RSTLIB.

Thank you for your help.

Sandy

 

[Larry Williams]

Yes, all SQL packages should be deleted after JDE services have ended and before an OS upgrade or DB fix pack install. This should be done when the system is in restricted state. This includes the QZDAPKG system package (see http://www-01.ibm.com/support/docview.wss?uid=nas186256a81004eff5c86256ff500732959).
UBE SQL packages name for each UBE should normally be created in your JDE sys library when the jde.ini has SQL Package Library=0. UBE SQL packages named after the job number should be in in QRECOVERY when the jde.ini has SQL Package Library=2. SQL packages are created in the data library by remote DB connections ODBC or JDBC. They will have various names depending on the JDE process that created them - ACTIVCAFJA, ACTIVCANJA, BUSBUIAFJA for example.
No, we do not have any issues with the latest Access for Windows SP on the deployment server. In fact, we have a policy where when update the latest PTFs each quarter. We do the DV/PY servers, test and then do the PD servers. We have never had an issue.
Yes we do refresh DV/PY data from PD and we have done this when PD was at V6 and DV was at V7. We do a custom refresh with SAV/RST process using a tape. As long as the target server is at a higher OS level there should not be a problem. If the target server is at a lower OS level, then the SAV just needs to use the TGTRLS parameter.

 

[shurtle]

Larry,

Thanks for the input! I was wondering if you also see SQL packages for UBEs run on your test system in the system library on your production server? And that while the servers are running under different OS, this caused no issues?

Regards,
Sandy

 

[Larry Williams]

Sandy,
The SQL packages are local each machine. For the system library, I'm not referring to the system datasource libary (SY900/SY910) but to the E900SYS/E910SYS library.

 

[shurtle]

Larry,

I thought they were local also. But, I have deleted the R0006P *SQLPKG on my production server in E900BSYS and run R0006P in DV900 on the test server and had it create a R0006P *SQLPKG in E900BSYS on the Production server (as well as one on the test server). I made sure that R0006P wasn't run in PD900 on the Prod server.

Is anyone else seeing this behavior?

Sandy

 

[shurtle]

Michael L,

I have a follow-up question about SQLPKGs. Some of the documents mention deleting all SQL Packages on both servers which I plan on doing.

But, I noticed that UBE SQL Packages are created on the Production server when UBEs are run on the test server in the system library. I am not sure why it creates a SQL package on the Prod server when the UBE is run for DV and/or PY on the test server, but it does. I have SQL Package Library set at 0.

Does this work this way for you and did it cause any issue when you upgraded the test server and tested before you upgraded the production server?

Regards,
Sandy

 

[MagarG]

Like Larry said, the SQL Packages should be local to each machine. On our Test LPAR, it's a separate IP Address, machine name, etc. Sounds like something is not configured correctly on the test box that has references to the production machine name.

 

[Tom_Davidson]

One possiblilty is if you use a common OL and DD I'd expect the package to actually be made on the other system. You can use the PRTSQLINF command to see what SQL statements are in the package.

Tom

 

[shurtle]

I looked at the prtsqlinf for the sql packages on each server. After I run R0006P on the test server and look at the prtsqlinf output for the R0006P SQLPKG on the Production server, it only has select statements for SY900 and OL900 tables. The R0006P SQLPKG on the test server, has SELECTs for DV bus data, CODV900, SVM900, etc.

I then ran R0006P on the production server and looked at the prtsqlinf on the R0006P SQLPKG on the production server and it had selects for COPD900, prod bus data, etc.

Does anyone else have this type of setup and are they seeing SQLPKGs created on the production server when UBEs are run on test in the system lib?

If this is not 'normal', any ideas what setting to look at?

Thanks for everyone's input.
Sandy

 

[shurtle]

Larry,

Did you delete the QZDAPKG SQLPKG on your production server along with the one on the test server when you upgraded the OS on your test server?

Thanks,
Sandy

 

[Larry Williams]

No, you only need to work about the SQL packages on the machine that is having the upgrade or db fix pack installed. You see SQL packages on your PD machine for UBEs run on DV/PY package because I'm assuming your PD machine as your SYxxx library and the UBEs on the DV/PY machine are using DRDA to access that library. So, SQL packages will get created due to that access. If you take a look at the SQL package you'll find it will only have entries related to the SYxxx library within it.
Also, don't forget that SQL packages should be removed when there is database changes - altered tables, new indexes, etc. Also, we run a custom program that deletes UBE SQL packages whenever an update package is deployed that contains that UBE.

 

[shurtle]

FYI,

Oraclse support said that the behavior of creating a SQLPKG in the system library on the Production server for selects on SY900, OL900, etc. tables are valid when a UBE was run on the test server and that this should not cause any issues after the upgrade of the OS on the test server (SQL Package Library=0). They said to delete the non IBM SQLPKGs on both servers when we upgrade the test server and to delete the IBM QZDAPKG on each server when upgrading that server.

Regards,
Sandy

 

[cdawes]

I've done about 10+ of these projects and reviewing this thread there are a few things missing.

I would start by going to MOS, add a filter (Powerview) for JDE EnterpriseOne product line and search on anything that has V7R1, AS400 migration, AS400 upgrade.

You've missed changes for Server Manager (JDBC path), need to build a full package (relink works only for a tools change not an O/S change) and a few other items.

Most of this is on MOS if you follow the search filter above.

No changes should be required to the JDE.INI

The jt400.jar should come from www.sourceforge.net/projects/jt400
Don't use any other jt400.jar file.


Colin

 

[shurtle]

Colin,

Thanks for the input! I have been reviewing docs from the MOS. I have follow up questions for you.

Per doc id 642797.1, it only recommends a full package build if you have done a tools release upgrade along with the OS upgrade. We are already at 8.98.4.10, so I am not doing a tools release upgrade. I was planning a full build to validate the upgrade, but was going to let the users test while it was building. I am trying to keep the outage window for the production server as short as possible.

2. I was planning on getting the latest jt400.jar after applying the latest IBM PTF for IBM i Access for Windows. Why do you recommend the jt400.jar from the www.sourceforge.net/projects/jt400 website and no other?

Sandy

 

[Dave_Texas_Was_In_Miami]

We are going through the same process but have a diff. issue.
We set the new iSeries to security level 40. restored all libraries and IFS etc.
E1 Services fails to create the JVM's.
Anyone else have this issue?

 

[shurtle]

Hi Colin,
Thank you for the heads up. I talked to Oracle about the full package build and they said you were correct (so the doc was not clear). They also said to use the latest jt400.jar from the website you gave.

So, again thanks for the heads up!