× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




Rob- thank you for going to so much detail in testing the impact and
specifics of this process (and thank you particularly for taking the time
to be so vocal about it on the listserv). It will be a big help to alot of
us as we get further into the process over the next year or so!






rob@xxxxxxxxx
Sent by:
midrange-l-bounce To
s@xxxxxxxxxxxx midrange-l@xxxxxxxxxxxx
cc

05/20/2008 02:47 Subject
PM STROBJCVN


Please respond to
Midrange Systems
Technical
Discussion
<midrange-l@midra
nge.com>






Ok, so, you've passed ANZOBJCVN, upgraded to V6R1, and now run STROBJCVN
so your users do not pay the "first touch" penalty. I think we discussed
this on a thread but I can't remember. Anyway, when you run STROBJCVN you
might want to change your system value QMAXSPLF first. In fact, due to an
issue I had, the redpiece on STROBJCVN will be upgraded to suggest this.
Apparently IBM opens a spool file for each object they convert, but rarely
(if ever) writes to the spool file. The spool file gets closed and
immediately goes to a FIN state. However, it still counts as one of the
spool files controlled by QMAXSPLF. Another suggestion is to submit a
STROBJCVN for each user library instead of one big job for *ALLUSR. I
wrote a program that determines if a library is a *ALLUSR and fires off a
STROBJCVN for that library (giving the library name as the job name, etc).
If you still have enough objects in a single library you still may have
to modify QMAXSPLF.
IBM will not change the logic to only generate the spool file if needed.
They are still working on the issue that a particular message id doesn't
"trim" one of the parameters passed to the message and thus ties up over a
whole page of blank space in the joblog in the middle of the message.

Failure to change QMAXSPLF, or break down STROBJCVN into manageable pieces
may result in erroneous messages that numerous objects would not convert.
When the only real problem was that it couldn't generate the false spool
file.

Note: Even Domino recommends you run STROBJCVN on the IBM Domino LPP
libraries after the upgrade to avoid the first touch penalty when firing
up Domino.

Gosh, I hope IBM isn't doing something real stupid like
DSPOBJD OUTPUT(*pRINT)
CPYSPLF...
DLTSPLF
But something made me think it was more of a SQL issue because of some
other message in the joblog that I can't remember.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

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


_____________________________________________________________________________

Scanned by IBM Email Security Management Services powered by MessageLabs.
For more information please visit http://www.ers.ibm.com
_____________________________________________________________________________


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.