I agree on STROBJCVN. Every V5R4 to 6.1 upgrade that I have done,
and every V5R4 to 7.1 I have done I always run STROBJCVN as part of the post
upgrade process. I do not want to have the user's response time effected by
"first touch". I wouldn't do this any other way.

Also, when restoring objects, I usually never force conversion then
as it seems to make the restore longer. I can restore multiple libraries
quicker, and then run the STROBJCVN command over each library as it is
restored. This also gives you the ability to run multi-threaded.


Pete Massiello
iTech Solutions

Add iTech Solutions on Facebook:
Add iTech Solutions on LinkedIn:

iTech Solutions because IBM i (AS/400s) didn't come with System

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Wednesday, August 18, 2010 12:16 PM
To: Midrange Systems Technical Discussion
Subject: Re: i5/OS V6R1 not converting *SRVPGMs on "first touch"?

BTW - if objects are created starting from V5R1, removing observability
still leaves the creation data. If they are reporting as not
convertible, then that vendor hasn't done their homework, and you need a
new version.

It doesn't have to come from a 7.1. system for the purpose of being
convertible. All our stuff is compiled to v5r1 and runs fine on 6.1 and
7.1, everything converts just fine.

I'm beginning to think that customers should run STROBJCVN *CONVERT on
their 6.1 or 7.1 systems. This is because then the conversion is done
already, you don't have to rely on first touch. One place where first
touch doesn't work is if I send a debuggable module to a customer, in
order to troubleshoot a reported problem. If the *PGM or *SRVPGM has not
been converted yet, we get a message about the object can't be updated
because it hasn't been converted yet. Seems UPDPGM is not considered a
"touch"! Running STROBJCVN takes care of things. Or running the command
that uses the object.


On 8/18/2010 10:08 AM, sjl wrote:
Mark -

Are these objects that belong to a software package?

Many software vendors (such as Oracle's JDE World Software) supply objects
with observability removed.

By running the ANZOBJCVN command on the V5.4 system, we identified
of objects that would not convert. In consideration of our pending V5.4
V7.1 conversion, it will be necessary for us to get a new tape from Oracle
that has objects saved from their V7.1 system.

- sjl

Mark wrote:
One of our customers is in the process of converting from V5R3 to V6R1
... (side-by-side upgrade; separate box.)

For some reason, they are getting this message in some job logs:

CPI5D20 Information 10 08/17/10 08:34:07.122556 QBNBIND QSYS *STMT
From module . . . . . . . . : QBNBLOAD
From procedure . . . . . . : QBNBLOAD__ProgramManager__Load
Statement . . . . . . . . . : 9
To module . . . . . . . . . : QBNBLOAD
To . . . . . . . : QBNBLOAD__LoadObject
Statement . . . . . . . . . : 5
Message . . . . : Service program SRVPGM01 requires conversion.
Cause . . . . . : Service program SRVPGM01 in library *LIBL requires
conversion because it is not in the format required. Converting a
program to the current format may change the way it uses argument
optimization (ARGOPT). Recovery . . . : If there are problems with
ARGOPT, convert this service program, and then try the command
again. Use
the Start Object Conversion (STROBJCVN) command to convert the

For some reason, they changed QFRCCVNRST to "1" (from the IBM
recommended default of "3".) Yet, most of the objects in the library
where these *SRVPGMs reside say "Conversion required . . . *NO". But
for some reason, a few of them say "*YES" and they have *UNOBS for the
Observable information.

I thought OS/400 and i5/OS was supposed to automatically convert such
objects on "first touch" (or first use), as needed?

I told the customer to submit a batch job to run a STROBJCVN for the
library containing these objects, and that seems to have resolved this
issue. But, is this now necessary?

Is anyone else seeing this?

This thread ...


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