RE: CPF5009 , CPF5026, SQL9015 , MCH3601, MCH0601 -- MIDRANGE-L

IBM created test PTF SQPAH06.
Resolved the issue with CRTDUPOBJ for the one object.
CRTDUPOBJ OBJ(PNL00473) FROMLIB(IC08020600) OBJTYPE('*PGM') TOLIB(TOLIB)

From IBM support.

The issue is that during the handling of duplicate procedures the IBM i is getting error(s) msgMCH3601, msgMCH0601 and msgMCH1210. The new test PTF will not avoid the duplicates but should fix the problems when handling the duplicates. So in the CRTDUPOBJ you may see msgCPF5009 after the PTF, but the result would be the program is copied to the target library and sysroutine is updated with new entry.

Paul

-----Original Message-----
From: Steinmetz, Paul
Sent: Wednesday, May 28, 2014 5:39 PM
To: 'midrange-l@xxxxxxxxxxxx'
Subject: RE: CPF5009 , CPF5026, SQL9015 , MCH3601, MCH0601

Open PMR, CPS discussion in progress.
Various data sent.
3rd party app was doing a CRTDUPOBJ.

*NONE Command 05/28/14 11:34:02.024645 QCADRV QSYS 03BA UPD09C UP08020600 021D
Message . . . . : 20000 - CRTDUPOBJ OBJ(PNL00473) FROMLIB(IC08020600)
OBJTYPE('*PGM') TOLIB(UPIC08XXP)
CPC2206 Completion 00 05/28/14 11:34:02.032455 QSYCHONR QSYS 0695 QLIINSRT QSYS 051B
5770SS1 V7R1M0 100423 Job Log PENCOR06 05/28/14 11:34:40 Page 291
Job name . . . . . . . . . . : RELUPDATE User . . . . . . : UPMIS Number . . . . . . . . . . . : 904479
Job description . . . . . . : CM_SIGNON Library . . . . . : UPBRCOBJ
MSGID TYPE SEV DATE TIME FROM PGM LIBRARY INST TO PGM LIBRARY INST
Message . . . . : Ownership of object PNL00473 in UPIC08XXP type *PGM
changed.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, May 28, 2014 2:56 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: CPF5009 , CPF5026, SQL9015 , MCH3601, MCH0601

On 28-May-2014 11:56 -0500, Steinmetz, Paul wrote:

I had the exact same job give the same errors as previous runs, 3/14,
3/15, 3/31.
Is this a 3rd party application issue or IBM issue?

CPF5009 Diagnostic 10 05/28/14 11:34:02.068434
QDBSIGEX QSYS 0EBB QSQPROCR QSYS *STMT
To module . . . . . . . . . : QSQPROCR
To procedure . . . . . . . : PUT_SYSROUTINES_RCD
Statement . . . . . . . . . : 11602
Message . . . . : Duplicate record key in member SYSRO00001.
CPF5026 Sender copy 30 05/28/14 11:34:02.076876
QDBSIGEX QSYS 0252 QDBSIGEX QSYS 0252
Message . . . . : Duplicate key not allowed for member SYSRO00001.
CPF5026 Notify 30 05/28/14 11:34:02.076886
QDBSIGEX QSYS 0252 QSQPROCR QSYS *STMT
To module . . . . . . . . . : QSQPROCR
To procedure . . . . . . . : PUT_SYSROUTINES_RCD
Statement . . . . . . . . . : 11602
Message . . . . : Duplicate key not allowed for member SYSRO00001.
SQL9015 Information 30 05/28/14 11:34:02.093054
QSQPROCR QSYS *STMT QLICRDUP QSYS 0522
From module . . . . . . . . : QSQPROCR
From procedure . . . . . . : SENDMSGD
Statement . . . . . . . . . : 24137
Message . . . . : Program or service program PNL00473 restored
but not created as SQL object PNL00473 in UPIC08XXP.
MCH3601 Escape 40 05/28/14 11:34:02.096789
#rmsacs 001F58 QSQPROCR QSYS *STMT
To module . . . . . . . . . : QSQPROCR
To procedure . . . . . . . : PREPARE_SYSROUTINES_RCD
Statement . . . . . . . . . : 16636
Message . . . . : Pointer not set for location referenced.
MCH0601 Escape 40 05/28/14 11:34:02.096853
< gHighUse4K 000328 QSQPROCR QSYS *STMT
From Program . . . . . . . : stringHighUse4K
To module . . . . . . . . . : QSQPROCR
To procedure . . . . . . . : PREPARE_SYSROUTINES_RCD
Statement . . . . . . . . . : 17411
Message . . . . : Space offset X'00000000' or X'0000000000600000'
is outside current limit for object RELUPDATE UPMIS 904479.

Unless the 3rd party app was doing something unsupported, the LIC exception [MCHhhxx] errors are definitely an IBM issue. The other messaging that precedes those may be normal, or indicative of either an error with the 3rd party expectations or routine tracking [data] errors; that data could be problematic in either the Program Associated Space
(PAS) or in the catalog file(s) such as SYSROUTINE. However the routine being duplicated may have been created [or updated] when a particular defect existed, and that may have been an origin, for which the recovery might then involve getting a corrected copy of the object from the vendor, or perhaps just a clarification of an alternate resolution such as DROP of a problematic object performed before starting the failing process.

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.