RE: v6r1 strobjcvn

["Pete Massiello" <pmassiello-ml@xxxxxxxxxxxx>]

Mine was to a job queue that was setup for max of 5 at a time.  This allowed
a good utilization of the machine, but the system thrashing about.

If you run STROBJCVN *ALL as one command, it's a single threaded batch job,
converting one library at a time, when it finishes library A, it goes onto
library B.

Pete

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Franz
Sent: Tuesday, November 25, 2008 11:06 PM
To: Midrange Systems Technical Discussion
Subject: Re: v6r1 strobjcvn

Pete - were your submitted jobs to a queue where
max active = *nomax?
To me that sounds like the difference between yours, Larry's, and Rob's 
experience.
I don't think STROBJCVN *ALL does a massive convert many libs 
simultaneously.
Jim Franz

----- Original Message ----- 
From: "Pete Massiello" <pmassiello-ml@xxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, November 25, 2008 10:29 PM
Subject: RE: v6r1 strobjcvn


> Larry,
>
> I wrote the same thing a few months back about breaking these up
> into one job per library, as well as an article in COMMON Connect.  Do a
> SBMJOB on STROBJCVN for each User Library.  This way, you can just look at
> the submitting jobs *MSGQ and check for something that ended abnormally.
> Makes this so much easier.
>
> I would imagine in your SAP environments, you are doing more on the
> IFS side than you would be on i5/OS Programs.
>
> Have a Happy Thanksgiving.
>
> Pete
>
>
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Larry Bolhuis
> Sent: Tuesday, November 25, 2008 8:37 PM
> To: Midrange Systems Technical Discussion
> Cc: Midrange Systems Technical Discussion; midrange-l-bounces@xxxxxxxxxxxx
> Subject: Re: v6r1 strobjcvn
>
> Odd. We've done several V6R1 upgrades on large SAP partitions where we
> have run STROBJCVN *ALL with no problems. The job ran for around 8 hours
> with a couple CPUs assigned and about 32GB memory across 5TB systems.
>
> WHat I've not checked is the number of program objects. Perhaps we have
> far fewer than you?
>
>  - Larry
>
>
> Larry Bolhuis                   IBM Certified Advanced Technical Expert -
> System i Solutions
> Vice President                  IBM Certified Systems Expert:
> Arbor Solutions, Inc.              System i Technical Design and
> Implementation V6R1
>  If you can read this, thank a teacher....and since it's in English,
> thank a soldier.
>
>
>
>
>
> rob@xxxxxxxxx
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 11/25/2008 05:04 PM
> Please respond to
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
>
>
> To
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> cc
>
> Subject
> v6r1 strobjcvn
>
>
>
>
>
>
> I am running a STROBJCVN right now during a V5R4 to V6R1 upgrade on a
> 9408-M25-5634.
> I wrote a utility that used an api to extract every "user" library on the
> system and submit off a job.
> ie
> SBMJOB CMD(STROBJCVN LIB(&mylib) ) JOB(&mylib) JOBQ(ROB/STROBJCVN)
> At first I had that job queue as *nomax.  Then I started running into some
>
> strange aborts.  I suspect it had something to do with a thousand or so
> jobs beating the snot out of one output queue.  Throttling that down to 25
>
> or so jobs at a time stopped the strange aborts.
>
> Do not do a STROBJCVN LIB(*ALL).  That will probably abort due to the
> sheer number of spool files created and deleted.  Each job will have a FIN
>
> spool file for each object in each library.  Me, I wouldn't have opened a
> spool file until needed (USROPN).  Or, if they're doing something silly
> like displaying an object to a spool file and copying that to a disk file
> (instead of using an API) that would really rile me.  IBM feels the
> workaround of separate jobs for each library is sufficient.
>
> Several of my larger program libraries are all that's left.  They've been
> 'active' since around 11:30.  It's going on 5pm.
> Job         User        Type     -----Status-----  Function
> ERPLXO      QSECOFR     BATCH    ACTIVE            CMD-STROBJCVN
> ERPLX831O   QSECOFR     BATCH    ACTIVE            CMD-STROBJCVN
> ERPLX832O   QSECOFR     BATCH    ACTIVE            CMD-STROBJCVN
> ERPL832PTF  QSECOFR     BATCH    ACTIVE            CMD-STROBJCVN
> SOFTTURN02  QSECOFR     BATCH    ACTIVE            CMD-STROBJCVN
>
>
> Rob Berendt
> -- 
> Group Dekko Services, LLC
> Dept 01.073
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
> .