v6r1 strobjcvn

[rob@xxxxxxxxx]

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