ERP2004 to ERP 6.0 EHP4 upgrade: Phase PARMVNT_XCNV SQL error -952

[Former Member]

Hey all,

We're doing an IBM i V6R1 upgrade from ERP2004 to ERP 6.0 EHP4 with a phase PARMVNT_XCNV stop error of SQL -952 errors on 9 tables (AKB_STATISTICS, ALMDRULES, BRR_TEXT, BRR_TEXT_C, DB2CCACCOR, DB2CCDAILY, DB2CCHOUR, IWEXADD, SAUNIT_NO_LEGACY) in the relevent MVNTXCNV.ELG log.

Looking at the TP logs this is a typical scenario using example table ALMDRULES above:

========================================================================

2 ETP360 Begin: Act. of Shadow-Nametabs with DDL ("2010/01/12 10:56:49")

2 ETP301 -

---

2 ETP399 processing modeflag 'F'

2 ETP301 -

---

2 ETP330XActivation of Shadownametabs with DDL

2 ETP301 -

---

3 ETP379X10:56:49: activating Nametab "ALMDRULES":

2 ETP399 >> Name of inactive nametab to read : DDXTT?

2 ETP399 >> Format of inactive nametab to read: 5.0

3 ETP355Xstatements:

3 ETP399 ALTER TABLE R3PR1DATA/"ALMDRULES"

3 ETP399 DROP "PAR5_NAME"

3 ETP399 DROP "PAR6_NAME"

3 ETP399

2WETP000 10:56:49: Retcode 1: error in DDL statement for "ALMDRULES " - repeat

2EETP345 10:57:02: Retcode 1: SQL-error "-952-Processing of the SQL statement ended. Reason code 1

2EETP345 0. MSGID= Job=287673/PR1OFR/TP" in DDL statement for "ALMDRULES "

2 ETP399 -

---

DB-ROLLBACK() -

---

2EETP334 10:57:02: error in DDL, nametab for "ALMDRULES" not activated

In the system joblog these entries report the ALMDRULES example failure:

=============================================================

Change to field PAR5_NAME may result in data loss.

Change to field PAR6_NAME may result in data loss.

Change of file ALMDRULES in R3PR1DATA canceled.

File ALMDRULES in R3PR1DATA not changed.

Processing of the SQL statement ended. Reason code 10.

I've already tried the RCLSTG *DBXREF process as described in Note 71258 "AS/400 Cross-re. files defective? RCLSTG *DBXREF", and found Note 589296 "Problems w/ database links during the System Switch Upgrade" but it doesn't seem a good match for this issue.

Has anyone on IBM i had this same phase issue going to ERP 6.0 EHP4? Thanks in advance for any help offered 😆

Scott

[volker_gldenpfennig · Accepted solution]

Hi Scott,

do you have the following in your rply list ?

WRKRPYLE

10 CPA0700 D *NONE

20 RPG0000 D *NONE

30 CBE0000 D *NONE

40 PLI0000 D *NONE

3201 CPA32B2 I *NONE <<<<<

If not, I do know the reason of your issue ...

Regards

Volker Gueldenpfennig, consolut international ag

http://www.consolut.net - http://www.4soi.de - http://www.easymarketplace.de

[Former Member · Accepted solution]

Volker,

Many thanks for your prompt response post- it is appreciated 😆

I did briefly consider adding an automatic reply entry as you suggested before posting here per Note 203342 "AS/400: SQL0952 during upgrade or transports" but decided against it after reading Note 760414 "iSeries: SQL-952 with "ALTER TABLE...DROP COLUMN" due to its Causes and Prerequisites text-->"This is a programming error. Since data can be lost..." possibly creating other upgrade errors. But I know you've done many iSeries upgrades so I'm going with your answer.

Is this a standard iSeries reply list entry for SAP application upgrades? I assume not. If not SAP should have documented or integrated it into the upgrade process itself but perhaps I missed it after reading the 100th upgrade note 😆

Vielen dank for your help, Volker! As we say in the US- "YOU'RE DA MAN!"

Scott

[volker_gldenpfennig · Accepted solution]

Hi Scott,

Yes, for SAP on iSeries, this is a "default setting" - during crtr3sys or crtr3inst, this is automatically created ...

=> it is ALWAYS needed - not only for upgrades.

But:

If you copy the system with IBM tools, you might tend to forget on these entries and then you run into trouble later on ...

Regards

Volker Gueldenpfennig, consolut international ag

http://www.consolut.net - http://www.4soi.de - http://www.easymarketplace.de

[rdiger_hckel · Accepted solution]

Hi Scott,

in my upgrade this phase ran without an error,

it succeeded successfully on Wednesday and ran for about ten minutes.

Have you already reached the downtime phase, especially the phase KX_SWITCH_1?

I would like to know if you had any problem as well.

Here is my problem thread:

[;

Kind regards,

Rüdiger Höckel