MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » November 2008

RE: v6r1 strobjcvn



fixed

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





Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact