Ugly 8.10 gotchas to watch out for.....

Good Morning,

we are currently in the process of upgrading to EO 8.10 and I wanted to make people aware of some of the issues we are seeing, hopefully I can prevent some other people fro hitting the same brick wall we hit.

First issue - Table conversions. During the YC process we ran into several table conversion errors, which seemed to die for no reson. Unfortunately there were valid logs to look for so PS wasn't much help. It seemd that if we ran the TC again it would get through more, but the F42199 would convert. What do you know I ran it on the deployment server and it ran perfectly. Well that is after I copied the spec from the planner path code to the PY pathcode (not documented, but instructed by PS)

Well on to the UNICODE conversion. If you read through the upgrade manual it mentions deleting 88 and 89 files before running the conversion. DO NOT DELETE THEM!!!!!! Unfortunately there are 235 BSFN't that still reference them in the include file. If you remove them the server build will not complete. We had to re-add them in order to get our server build to work.

Save location - If you plan on using it, be sure to load ESU PG398 otherwise you will not be able to see the save location eventhough it exists.

Debug errors - We are seeing a lot of errors in our debugs "Right Character Data Truncation" and "Invalid Cursor" After sending oodles of ODBC traces and logs to bot IBM and PS, they are looking into it, but they continue to blame each other, so if we ever see a resolution it will be surprising.

Client Access level (CWBODBC.Dll) we were finding several of our custom versions with processing options were corrupt (greek characters) Well it seems if you use client access V5R2 and your version of CWBODBC.dll is 9.0.8.0 you get this corruption. Be sure to upgrade to 9.0.8.1. Unfortunately we had a lot of cleanup because of this.

Misc errors - We have several calls in to PS about programs not working as designed, or changed in EO 8.10 tha tjust don't make sense so I will post up more info as I see it come along. There is also an issue with task views that if you put a value in the country code for a custom task you will run into problems with them not showing up. We has a call open on that as well.

Please feel free to add to this list, I would like to keep it alive for all the people moving to 8.10

Bill

Bravo! Good job...now we know what you've been doing with your summer.

Could you please elaborate just a tad re: your configuration? We have sub-co's doing this early next year. Thanks for the warnings.

A.D.

Bravo! Good job...now we know what you've been doing with your summer.

Could you please elaborate just a tad re: your configuration? We have sub-co's doing this early next year. Thanks for the warnings.

A.D.

Click to expand...

Sure no problem.....

We actually have 4 systems here. Currently we have 2 XE production systems one for corparate, and one for international, and 2 development systems.

Our 8.10 system will be set up like this.

2 deployment servers (development and production) and 2 iSeries servers. Our development system will be connected to our production system using omw. (same as our current XE system). This allows us to isolate the production system from development. I know it sounds confusing, but it's fairly simple once setup.

As of this point we have set up 2 development systems with EO 8.10. we are developing on one of our systems and we are testing on the other system. We are transfering objects from system to system using a third party package called boomerang.

The worst part is we are running into lots of different types of issues, ranging from setup (new funtionality in 8.10) to real problems that need work. It will take us a little time yet, but Thanksgiving go live is coming up quick.

Also, some BSFNs use non-Unicode code. Looks like AS400 has more problems with that than wintel client so some UBEs (like R42800) might not work on server.

Bojan.

Thanks for the 8.10 traps.

I just noticed the processing option corruption this morning.

There is a problem with the cheque (check if you're American) update (R04575). If there are more than one cheque in a payment group then the update will fail on the server. Denver thinks it's because the business data is not unicode. It works for Denver, but their business data is unicode.

The problem is with a IBM API.

CHO,

Per the corruption - are those versions that were converted or
migrated (using a third party tool)?

A few issues can cause what appears to be Processing Option
corruption. One being that the VRPODATA.F983051 has not been
converted to unicode.

One fix is to open the Processing Option of each version and save...
when saved, the PODATA is saved as unicode. We are currently building
another solution.

(db)

--

hmmmmm............ Well I did a few early 8.9 upgrades when you still had to do "Update 0" and well gotta say 8.10 is sweet compared to this early process.

Thanks for the ESU for the save location. A couple other ESU's you'll need are (1) for R92TAM.......can't go web unless you can generate TAM and guess what? Don't work out o da box. (2) R98OWPU....don't work and I'm using "user" not "system" security. Oh what fun it'll be to manually create 300 user security records.

8.10 does look very polished though........

Other gotchas..........admin user switches from "JDE" to "PSFT". Really annoyed when I signed on as PSFT and was "locked out" since on Xe the default was no access (system brings over all security). I just had to turn off security server log into DEP810 and add records.

There are quite a few ESU's for 8.10 but most are small and quick to install.

Colin

Regarding version corruption. It is a known issue.

This is what response line has to say.

An issue like this has been reported in ICE 200950387:

PROBLEM
When creating a new Processing Option (PO) Template the PO Text looks
correct until check-in. After the check-in occurs, if you look in the
F98306 Processing Option text table in Central Objects, the PO Template
text is scrambled. This issue occurs whenever an update occurs to the
F98306 Processing Option Text table and can occur with a check-in or
promotion of a processing option template as well as occur during the spec
merge portion of an upgrade. This issue is specific to the AS/400 and
happens with the latest Iseries Client Access SI14294. This issue is also
specific to PeopleSoft Enterprise One releases 8.9 or 8.10.

RESOLUTION
The problem occurs due to issues with Client Access when inserting the
DBCLOB data type. When inserting DBCLOB LOB locator data it is not
inserted with the right length. This can lead to data that is corrupted.

This is resolved by installing the IBM APAR SE17523. Refer to the
following IBM site for additional information.

ftp://ftp.software.ibm.com/as400/products/clientaccess/win32/v5r2m0/files/odbc/

Another Wonderful mess........

Well here is the latest mess we are running into. More UNICODE fun. We are getting several errors with the UNICODE conversion, almost all of them are due to files that no longer need to be there, but deleting them will cause problems. If you look at the manual it talks about system 88 and 89 tables that need to be removed. Well we found out you have to delete them from the library, but not the OL. We are writing a CL the delete the tables only. Not a lot of fun.

Thanks for the useful information !

We are also planning ERP8.10 upgrade (from Xe, HP-UX) and so far I am unable to find any 'known issues for ..8.10 upgrade' or similar documents for ERP8.10
There were quite a few of them for previous upgrades on the good old KG, but I wasn't lucky with current web site. Well , They do have a 'upgrade' section, but I can only see regular upgrade guides.
I would greatly appreciate if someone can tell me where to find upgrade related info on psconnect web site.

Thanks !

Another Wonderful mess........

Well here is the latest mess we are running into. More UNICODE fun. We are getting several errors with the UNICODE ual it talks about system only. Not a lot of fun.

Click to expand...

Have you resolved the "Right Character Data Truncation" and "Invalid Cursor" issue yet?

A workaround to Client Access and processing option issue is to increase LOB threshold (ODBC performance tab /advance button) to 15360.

8.10 Upgrade issue, communication fails

We have upgraded our Development environment from B7334 to 8.10. Throughout the upgrade process everything worked fine. Porttest for PS810 and DV810 ran fine. As a final step before we generated HTML, we changed the PSFT password and restarted services. Lo and behold nothing worked after that. The gist of the logging says the 2 enterprise servers are unable to communicate with eachother. Porttest no longer runs. I am able to login to DV810 on clients.
I am currently still running the old DV7334 (created new Business data and control tables along with the required datasources) along with the rest of the standard environments across the 2 servers without any problems whatsoever.
I also have a "sandbox" copy of my live systems, and everything is working perfectly there. I have compared system and INI settings between my sandbox and live systems to verify all settings are the same. Peoplesoft has not helped so far (surprise!) though they are trying.
I have attached logs.
I have changed the PSFT password back to standard and verified it on both servers and in E1. Any suggestions or ideas are welcomed.

Very interesting!

Don't know if anybody else has seen this, but we had issues with the conversion of some custom code using custom data dictionary items of type "String".

Looking at the specs using UTBrowse, we found out that these items had a buffer size half the size it should have been, considering that Unicode is double byte. The items affected were tables, report interconnect, data structures, processing options and form interconnect.

This happened to us in two different configurations, upgrading from Xe to 8.9.PSFT never came back on this one.

The workaround was to go in OMW and perform an advanced get from the Xe environment. Can't tell why, but the advanced get code handled the conversion more efficiently.

Some code also disappeared from custom objects in the automatic conversion. This was also fixed doing an advanced get from the Xe production environment.

Finally, BEWARE of the UNICODE CONVERSION of C custom programs! The "slimmer", the tool that performs the conversion, does about 90% of the job. Make sure to go on a MANUAL CODE REVIEW after that since there are some parts the slimmer cannot figure. Unreviewed code will sometimes cause MEMORY VIOLATIONS, as there will most likely be some size mismatch in the code. This does NOT apply to NER.

We are in the process of Upgrading from Xe to 8.10. We have high customization of vanilla objects.
Could you please send the Methodology or Process for retrofitting the Custimizations.
Thanks in advance.
regards
Prakash