Upgrade from Xe to ???

Client wants to migrate from early Xe release to ???. There are about 20 custom objects and 12 interfaces to other software products.
Related to this upgrade is a 'model' built in the new release that will be rolled out to 5 additional site over the next 24 months. The 2 sites that are live with current Xe version will be brought along in the future (not upgraded prior to the rollout).
Any suggestions about which release (8.0 or 8.9)?

Many thanx ...
Rob
Xe
Unix
Oracle

I have been using 8.9 stand-alone for teaching a class for the last 2 weeks. This is my first exposure to it. I am not impressed with it. While I have made the changes suggested in this forum to speed up the stand alone version it's still a perfromance hog. Some of the changes to the development tools have been less than desireable. Since 8.9 now uses unicode all C business functions which use any strings and string functions have to be converted to use new unicode string functions.
|
If I had to vote I would choose ERP8. The only bad thing to this is 8.9 is the future and the jump has to be made sometime.
|

I'd consider 8.9. No sense in looking at an outdated version of software. The only caveat is that 8.9 is "bleeding edge" so to speak so, you'll have to be aware that there may be a few bugs in the software. I'm working on an 8.9 implementation as we speak and I can see no reason not to upgrade to this version of the software. Yes, there are several changes to the technology but, nothing that should keep you from upgrading. Yes, the Demo version is slow but, that's not indicative of the true performance of the software in a live environment.

Thanks for the insight.
Rob

Hi Rob/Mike,
I'm over in Europe too Rob and the feedback Im getting on 8.9 from the apps side is that its VERY flakey.
Although this is mainly around the new functionallity, one client that is implementing this version has a team of programmers making it work - we are not talking about mods here!
On another site there was a kind of swat team in.....

Having been through a base XE (remember the fun on that one?!), I am currenctly recomending to my clients that they wait until its gone through its settling down time before embarking on the upgrade.

In terms of 8/8.9 XE->8 is an easier step (afterall its really XE v4) and it extends the period before you need to go to 8.9. After that point 8.9 will pretty much be stable.

If I was doing a large rollout - I'd take it to 8 with the role based security, and then look to rollout a stable 8.9 in a year or two.

Anyway, my 2 cents worth.

Warm regards

Peter

If you are going to install ERP 8.9, check you disks. In December they rebuilt the software. You don't want to install the old one.
You have the old set if
1. There is nothing related to December on the top of disks.
2. In your set you have Update 0 CD.

Good luck. We chose ERP8.9

Alex-admin
XE, ERP8.9, Oracle, Sun

When you upgrade from XE to EO8.9, what is the effort to carry forward the customized XE objects and custom developed client objects (like reports, versions, custom files ect.) Do we have to re-develop them again or will it be part of the upgrade?

Our CNC personnel brought over our custom objects from XE to 8.9 except for OW Explorer menus. Most objects seem to function ok. However, most of the customizations that do not work are based on a copy of a standard object with the copy customized. If the standard object has had functionality changes, the custom object may no longer function properly. Watch out for table and processing option changes. The new ER compare allows the comparision between objects of different names, so we are using it a lot.

Husni,

We are in the processing of upgrading from XE to EO89. Our approach was that all our system 55-59 objects we copied over (in spec merge). All customizations to PeopleSoft objects are documented, and we will review the need to re-apply those in EO89 on a case-by-case basis. There's more work in the retrofit stage, but I think we'll have a more stable environment, instead of relying on spec merge (which has burned us badly in the past).

There are 2 things that I see beyond the normal pains of upgrading to new version. These 2 items are a result of the change to unicode in 8.9.
|
1) Any custom C business functions which use the normal char strings and string functions will need to modified to use the new unicode string functions.
|
2) Table conversions that read text files will now need new settings. The Table conversions read unicode characters now. There is a mapping application, which I don't know the name of, that needs to be utilized so the TC can interpret the standard char strings from a text file. Somebody in the list may have done this already and knows the name of this new mapping application.
|
|

Scott,

I'm not sure what you're getting at with point #1? Are you saying that custom C BSFNs utilizing Visual C 6.0 Char/String Functions don't work in 8.9?!? Could you elaborate? Thanks.

The bottom line is that in pre ERP9 the strings are all arrays of char. In ERP9 the strings are are now arrays of unsigned int. Consequently the normal C string functions will not work on the new unicode strings. For more information you will need to read the unicode dev guidelines on the knowledge garden or other unicode reference.
|

Scott,

As you area aware - finding things in the KG is not an objective solution to most questions. Can you provide the document number for the Unicode/Dev. document - doing so will save us all a couple hours of searching the KG for something that should be easily apparent.

If you can - thanks!

Daniel

Take a look here:

Unicode Guidelines
https://knowledge.jdedwards.com/content/KG/Documentation/Private/UnicodeGuidelines.pdf

Using CodeChangeCom
(Utility that converts code to Unicode)
https://knowledge.jdedwards.com/content/KG/Documentation/Private/UsingCodeChangeCom.pdf

Although in the past I tried to do more selective searches I am beginning to become a big fan of the main KG search button and lots of keywords. I can generally find what I need. I get a lot of hits but the ranking algorithm that is now used seems to put what I am looking for at the top. I picked up those link with "unicode development guide"

We are slated to upgrade development from Xe to 8.10 in 2 weeks, begin alpha testing, beta testing, etc. Go live for production isn't until Febuary of 2005, allowing ample time for user testing, retrofitting, etc.

One of my concerns is the effort involved in accomodating Unicode within custom objects (BSFN, APP, UBE, etc.) We try to leave the system "plain vanilla" as much as possible, but we do have some custom objects.

Given that we have no plans and cannot foresee EVER having the need to support any language beyond English (we are a local government) I question the need to convert everything to Unicode (business data and control tables are optional as I understand). The flip side to this argument is that PeopleSoft may force us to convert to Unicode (rather than make it optional) at some point in the future. My counter to that is, "we'll cross that bridge when and if it happens".

Scott, and anyone else that has been involved with upgrading from Xe to 8.9 or 8.10, what is the amount of effort needed? Are C BSFN's and TC's the only things that will need to be modified?

Thanks in advance,

Maybe I am learning something here, you can tell me. I didn't think anything was unicode until 8.9. Am I hearing that 8.1 is also unicode? If so, ugh! I figured 8.1 was the ERP 8 version with some enhancements.
|
Non-unicode issues I have found with 8.9 is some Z file processors have changed. In some cases the old ones aren't available anymore. If you have any inbound interfaces that call Z file processes you will have to check to see if the UBEs you are calling still exist.
|

I believe William was talking about 8.10, that is eight dot ten, which is the follow on to 8.9 , not 8.1, eight dot one.

Tim Rathjen is right, its 8.10 (eight dot ten) we are upgrading to, as in the one after 8.9!

Thanks for the heads up with zfiles, I have a lot of inbound interop stuff, some of which uses zfiles. Anyone know which zfiles were dropped?

Scott, I still want to know how much effort it took to convert C BSFN's and other objects as a result of Unicode conversion. Thanks,

Software should go to a numbering system that makes more sense. I was just having a discussion with a co-worker about 8.9 vs 8.10 vs 8.11etc. While I have been doing software development I got all tripped up over the 8.10 being eight dot ten and not eight dot one. I interpreted 8.10 to be same as 8.1 which meant a version between ERP8 and ERP9 (8.9), ugh!
|
Thanks for the additional clarification!
|

As far as converting the C functions here's what I think:
1) First, I remembering hearing about a conversion tool to convert current C code to the unicode. Perhaps someone on the list remembers about this conversion tool, anyone? You may still need to review the code after the tool converts the code.
|
2)If there isn't a conversion tool the effort of converting is based on the amount of C code you have to convert. But, I still consider it a time consuming task. You have to convert every line of code that deals with the standard ASCII strings (1 byte) to use the new unicode strings (2 bytes). Everywhere that you used the standard C string functions you will need to use unicode string functions. E1 does offer a macro (_J) to convert string constants and std ASCII strings, this helps.
|
Hard to get more detail than this in a post, but hope it helps
|