RE: Fw: PM/400 record locks

Neil,

You are right on the mark about the amount of time it takes to end
performance data collector.  I have seen it take up to three minutes on a
little 270.  It does not do much good to have a fast IPL if it takes longer
to bring the system down.....  :-)

We are in the process of installing an i5 520 to replace it.  That is
another can on snakes....

Regards,

Mike Shaw

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Neil Palmer/DPS
Sent: Thursday, November 04, 2004 3:43 PM
To: Midrange Systems Technical Discussion
Subject: Re: Fw: PM/400 record locks

Jim,

Haven't seen that, although when going to a restricted state there is one 
program that seems to take over a minute before it finally ends.  Can't 
recall if it's CRTPFRDTA or QYPSPRFCOL - or something else.

...Neil




Jim Essinger <esinger@xxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
2004/11/04 18:02



To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: Fw: PM/400 record locks






   I have had a problem with object locks since we went to V5R2.  When the
   system is brought down to restricted mode, there is still a PM400 job 
that
   locks an object, and that causes the dedicated save to fail.  I have to
   kill the PM400 job after the system comes down to a restricted mode. 
This
   has been a thorn in my side for a quite a while.

   Jim Essinger
   208-452-4058 ext 133

   At 01:41 PM 11/4/2004, you wrote:

     Yes, we have seen a few systems that occasionally encounter record 
locks
     between Q1PDR and Q1PMONTH jobs.   We are modifying the PM iSeries 
code
     for
     new systems to run these jobs at completely different times to avoid
     these
     locks.  If this is a problem on your system, it is recommended that 
you
     change the time of the Q1PMONTH job via GO PM400, Work with
     automatically
     scheduled jobs, option 2 to change on Q1PMONTH.  Change it to a time
     that
     no PM iSeries jobs are scheduled; by default 03:00 would work.

     Royan Bartley
     IBM Rochester
     207-230-0416
     T/L 776-9966
     Internet:  royan@xxxxxxxxxx
     PM eServer iSeries: http://www.ibm.com/eserver/iseries/pm

     "It's kind of fun to do the impossible."  Walt Disney
     ----- Forwarded by Royan Bartley/Rochester/IBM on 11/04/2004 02:58 PM
     -----

  
                  Neil Palmer/DPS   
  
  

     Has anyone else seen record locks in the Q1PDR job (in QSYSWRK
     subsystem)
     at month-end, because IBM's default settings for scheduling jobs has
     Q1PMONTH run at the same time at month-end that the Q1PDR job is
     running?
     I've seen this on 3 customer V5R2 systems at the October month-end. 
     They
     have three single thread job queues (Q1PSCHQ, Q1PSCHQ2 & Q1PSCHQ3) so 
it
     looks like someone coding PM/400 screwed up and didn't submit Q1PDR &
     Q1PMONTH to the same job queue.

     ...Neil
 
  



--
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.