Jumping from 14.x to 18.x

DBohner-(db)

Legendary Poster
Many of you will say, "Bout Time"... as we leave SP 14.2 and prepare for the
jump to 18.x.... Thus the questions...

When migrating from one SP to the next, how do we know which custom
applications get touched? We don't have a lot of customs, but those we do
have are HEAVILY modded.

I have been unable to obtain a list of objects that get tweaked during the
upgrade... anyone wanna suggest where I look? I haven't found it....

Thanks in advance!




Daniel Bohner
[email protected]
www.existinglight.net
JDE - XE & AS/400
JDE - B7331 & MS SQL 7x
 
Upgrading to a new service pack level does not change application
objects. If you, however, wanted to find out what objects were changed
you can use GH9611 and choose Specification Merge Selection, then type a
C in the QBE Mod Flag to find changed objects. This quote is from the
listserv, I'm not sure from who but it explains a SP versus an ESU:
------------------
Your CNC consultant gave you the correct answer - Service Packs do not
change application objects. They are not a collection of ESUs (ASU's or
updates are an accumulation of ESUs). They do however change portions of
the base foundation which all the applications depend on. As such
Service Packs can change application behavior (fix and/or cause bugs).

A service pack is just the "system" (+ few other things like
documentation and interop) portion of the OneWorld software. If you
look on your deployment server or even a OneWorld client workstation,
you will see a directory named "system" under the "B7333"(deployment
server) or "B7"(client) directory. When you apply a service pack, it is
the contents of the system directory that get replaced.

JDE refers to "system" as the "foundation" because all of the OneWorld
application obects rely on it (much like a house relies on its
foundation). When you apply a service pack, you are essentially
replacing the foundation, yet leaving the house alone. In replacing the
foundation, however, there is potential that applications that used to
work may not work afterwards (this scenario is typically minimized and,
in most cases, a one-off is available to fix the issue).

It's important to understand that the service pack does not change the
application itself. I.e. there are no application obects delivered with
a service pack. Hence when you apply a service pack, you do not do a
Spec Merge (Doing a Spec Merge is indicative of applying changed
application objects).

In summary, service packs do not change OneWorld objects. However, if
you apply a service pack, it is possible (though rare) that a particular
application may not work as it used to.
-----------------

ENT: AS400 V4R5 Xe SP16.1
DEP: NT 6a SQL 7 SP3, Central Objects
JAS: Win2000

Many of you will say, "Bout Time"... as we leave SP 14.2 and prepare
for the
jump to 18.x.... Thus the questions...

When migrating from one SP to the next, how do we know which custom
applications get touched? We don't have a lot of customs, but those we
do
have are HEAVILY modded.

I have been unable to obtain a list of objects that get tweaked during
the
upgrade... anyone wanna suggest where I look? I haven't found it....

Thanks in advance!




Daniel Bohner
[email protected]
www.existinglight.net
JDE - XE & AS/400
JDE - B7331 & MS SQL 7x
--------------------------


AS400 V4R5 Coexist CO-NT Xe SP16.1
Websphere 3.5.4 on AS400 JAS SP16.1
 
Daniel,

Application specific objects should not be "changed" by an SP upgrade since by definition this is a change to the System foundation only. Application specific objects may be "affected" because the foundation now behaves differently (if for example we were relying on a bug before, which is now fixed, or a new bug is introduced). Other than those caveats I would not worry about losing custom changes during a SP upgrade. You still need to test to ensure that your applications work as expected though. Multiple foundations are a good way to do this.

Larry Jones
[email protected]
OneWorld XE, SP 15.1
HPUX 11, Oracle SE 8.1.6
Mfg, Distribution, Financials
 
I agree with the other posts. Objects are not directly affected by a service pack. ESU/ASU/CUME - Yes, Service Pack - No.

However, as Larry states, the applications may behave differently as they are now running under a different version or the foundation code "runtime engine".

The number one thing I have found between service packs is problems with user overrides. The handling of UO's seem to have changed regularly between service packs. If you find strange grid behavior or invalid overwrite or read errors after the service pack, check for user overrides on the suspect application and remove them. This is in fact mentioned in the service pack installation guide. It may drive your users and apps consultants crazy recreating them but there is really no way around it.

Regards,

Justin Miller
[email protected]

working with B7332 and XE on AS/400, NT, Solaris and AIX
 
Back
Top