RE: MCH2601 error when calling QSYSUPWD API -- MIDRANGE-L

You didn't mention release levels.
Check this V3R6 APAR.  Says there will be no PTF for V3R6 (or V3R7 I
believe).Sounds like you're already doing what is suggested in the
COMMENTS section.
 A "UR1" close means 'fixed in a future release" - and no, they don't
state WHAT that future release is/will be.   :-)


Item SA71017 

  APAR Identifier ...... SA71017       Last Changed..98/02/17  
  OSP-MSGMCH2601 T/QSYSUPWD X"0179
 
 
  Symptom ...... IN INCORROUT         Status ........... CLOSED  UR1
  Severity ................... 2      Date Closed ......... 98/02/03
  Component .......... 5716SS1WM      Duplicate of ........
  Reported Release ......... 360      Fixed Release ............ 999
  Component Name 5716 OS/400 WRK      Special Notice
  Current Target Date ..98/02/05      Flags
  SCP ...................
  Platform ............
 
  Status Detail: APARCLOSURE - APAR is being closed.
 
  PE PTF List:
 
  PTF List:
  Release 360   : No PTF planned
  Release 370   : No PTF planned
 
 
  Parent APAR:
  Child APAR list:
 
 
  ERROR DESCRIPTION:
  ******* (Do NOT alter/erase this or next 3 lines) *******
  * EQUIVALENT ABSTRACT:
  OSP-MSGMCH2601 T/QSYSUPWD X_0179
  *
   R360 C7140
   MSGMCH2601 F/#CFOCHKR x'0009F8 T/QSYSUPWD x'0179
   lock enforcement rules broken trying to access obj QSYUPTBL
   Very intermittent, when passwords are being sent and
   updated on other systems using the QSYSUPWD API.
  
  LOCAL FIX:
  
  PROBLEM SUMMARY:
   R360 C7140
   MSGMCH2601 F/#CFOCHKR x'0009F8 T/QSYSUPWD x'0179
   lock enforcement rules broken trying to access obj QSYUPTBL
   Very intermittent, when passwords are being sent and
   updated on other systems using the QSYSUPWD API.
 
 
 

  PROBLEM CONCLUSION:
 
  TEMPORARY FIX:
 
  COMMENTS:
  An internal object (QSYUPTBL) must be locked to update a user's
  password.  Code will be added to make a second attempt to lock
  this object if the first attempt fails.  If the second attempt
  fails, escape message CPF2225 will be sent.  The program that is
  calling QSYSUPWD can monitor for CPF2225 and try the call to
  QSYSUPWD again if further attempts to change the password are
  required.
 
  MODULES/MACROS:
 
  SRLS:      NONE
 
  RTN CODES:
 
  CIRCUMVENTION:
  None.
 
   MESSAGE TO SUBMITTER: UPDATED 02/11/98

Neil Palmer                                AS/400~~~~~      
NxTrend Technology - Canada  ___________          ___  ~     
Thornhill, Ontario,  Canada        |OOOOOOOOOO| ________  o|__||=   
Phone: (905) 731-9000  x238        |__________|_|______|_|______)   
Cell.: (416) 565-1682  x238         oo      oo   oo  oo   OOOo=o\   
Fax:   (905) 731-9202            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
mailto:NPalmer@NxTrend.com         AS/400  The Ultimate Business Server

http://www.NxTrend.com


        -----Original Message-----
        From:   Qile [SMTP:Qile@aol.com]
        Sent:   Monday, March 23, 1998 11:45 PM
        To:     MIDRANGE-L@midrange.com
        Subject:        MCH2601 error when calling QSYSUPWD API

        We have a network of 10 AS/400's and synchronize password
changes across
        systems using the QSYRUPWD (Retrieve encrypted user password)
and QSYSUPD (Set
        user password API's).

        We have noticed that sporadically we get MCH2601 errors "Lock
enforcement
        rules broken when trying to access object QSYUPTBL" when calling
the set API
        to change a password on a remote system. There does not seem to
be anything
        that we can think of that would cause these errors, and we now
just wait ten
        seconds and try again, at which time the call to the API
*usually* completes
        normally.

        Was just wondering if anyone else has come across this problem
and if so if
        you know how we could find out what the underlying problem is.

        Thanks for any info on this.

        Paul Jackson, Costco Wholesale, Issaquah, WA
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---