SP23_T1: Any tried it yet?

Bill Dotson

Reputable Poster
Has anyone installed SP23_T1 yet? We're installing a new iSeries ES with V5R4, which requires SP23_R1 at minimum. Since SP23_T1 has been out for a little while (and hasn't been recalled), we think it makes sense to go ahead with it, but for reassurance, we're wondering if anyone else has installed and tested it yet?
 
Bill

I'm not on iSeries but I installed it last week and deployed it to myself. I haven't had any issues so far. I haven't deployed it to the project team for major testing yet. I'll do that probably this week. I'll let you know if I have any issues.

Patty
 
Are you using SP23_T1 on a fat client, with a different SP on your enterprise server?
 
No, please don't do that. That is definitely asking for trouble. The only time you should do this is if you are doing a multi-foundation install for testing purposes.
 
We're embarking on it this week. Not as400 but I'll let you know how we go.
 
Bill

I have two enterprise servers. One for production and one for the test environments. SP23_T1 is running on a fat client and the test enterprise server. This is my way of doing "multi-foundation". I've always done it this way and haven't had any problems.

I have my new service pack on the deployment server as describe in the OTI-03-0096 document except the system, systemcomp, oneworld client install directories are still the old service pack. I don't want production user getting the wrong service pack on new/re-install when we are still in test mode.

Patty
 
Patty,

That explains it -- I misunderstood what you were saying. But it still begs the question -- do you access your production ES from the fat client with SP23_T1? Does it work, or does JDE turn blue and blow bits?

BTW, we're staying on Xe for a good long while, too.

Bill
 
Bill

I haven't applied SP23_T1 to my production ES server yet. I just sent out a test package to my test team today. All of these user are fat client. I've been using it for a week or more and no blue screens or blown bits. LOL.

Most of our users are fat clients. We have a couple of terminal servers being used. When I apply SP23_T1 to my ES server most user will be accessing it from a fat client. Does that answer your question?

Patty
 
Patty,

Yes, that answers the question. Thanks to everyone for their input!

Bill
 
I installed SP23_T1 on an iSeries on 1/20. So far no major issues, but a couple of small things I'm investigating:
1) on a full package install we get an Error! box at the end, with no other info. No info in the PC (or Citrix Server) event log either. Doesn't matter what environment. We've built a new full PD package this weekend and installed - got the error. I've also installed a DV full package that just had the foundation compressed, and got the same error. So far I haven't seen any major problems.
2) I have an open call with Oracle on a truncation issue on printqueue member names logging in the net jobs. Again, can't tie these to any real job that' running. They're just there.
Production users are all on Citrix, and we use some fat clients for devlopers & power users.
 
The error message at the end of the install is probably due to a bug with the Client Listener... assuming you, like everyone else, don't use it, just take the ClientListener= line out of the install.inf file in the OneWorld Client Install directory on the deployment server. This started happening to us with SP23_R1, and there's a SAR about it, 7930569, where they say that several clients have reported it but it's closed because they can't reproduce it in-house.
 
Thanks for the info!

If, as reported, the error you're getting is due to the client listener, we should be okay. We haven't used that since before go-live. Seems like a pretty lame thing to install by default. (I hope I'm not insulting the writer of the client listener, should he/she be lurking in this forum.)

We ran into a problem with UBE names getting truncated when the next job number went above 999,999. That made the UBE names too long for the jobname field, so JDE truncates the version. Weird, and caused us some problems in the past. Now we just reset the job number about once a year or so.

Makes you wonder -- why are they always fixing stuff that isn't broken, with the result often being that the unbroken things are now broken? That's the very reason we don't much like updating service packs unless we absolutely have to.
 
Somewhat later than planned - an update. SP23_T1 installed BUT we have an odd problem or two which we're trying to work through.

Grids are playing up a bit
We have some currency amounts not obeying the display decimals rules properly in the web client. Work fine if the fat client though.

More as it emerges.
 
For the most part testing is going well.

I did have reports of two memory errors. The first was myself for jdel.dll. At the time I didn't think to check the jde.log file. I haven't received an error like this in over five years.

On the second error the user didn't give me any more details. I search the KG and found nothing related to SP23_T1 and jdel.dll. I'll keep you posted.

Patty
 
Is this the issue you were seeing on the UBE truncation? Since SP23_T1 I see these diagnostic errors in the UBE kernels. I never find evidence of a job number in JDE that corresponds to the number in the message, although it is in the current sequence of numbers being used. I've had a help desk call in for this since 1/20, with no luck..only more requests for logs.

Member F3044102 removed from file PRINTQUEUE in B7334SYS.
Member S3044102 for file PRINTQUEUE in library B7334SYS not found.
Member L3044102 for file PRINTQUEUE in library B7334SYS not found.
Member T3044102 for file PRINTQUEUE in library B7334SYS not found.
Member A3044102 for file PRINTQUEUE in library B7334SYS not found.
Value 'X3044102_I' for MBR exceeds 10 characters.
 
Hi,

I remember having all kind of weird errors on Xe AS/400
when PrintQueue exceeded 32767 members.
Maybe it's not related to your issue, but you may
give it a try.
Once I purged WSJ (from JDE application) and reduced
my PDFs below that "magic" number all these errors
disappeared.
 
The maximum number of members in the Printqueue file is 32767. Your system will grind to a halt once you reach that magic number. We purge anything older than 2 weeks from submitted jobs every week, to prevent that problem. Newer releases of E1 store PDFs in the IFS instead, avoiding this problem for now.
 
The issue we saw was JDE truncating the version on job names, instead of something less meaningful, like the job number. For example, R5542565, version CP0009SC, job number 1234567 became R5542565_CP0009S_1234567.pdf. We would have preferred that it truncate from the right, not the middle, so that the name would be R5542565_CP0009SC_123456.pdf. But then, that would make sense, explaining why it wasn't done that way.

If allowed to go on too long, I can see how this could result in invalid MBR names, since they might easily exceed 10 characters. We check the next job number on our system periodically, and reset it to a much lower number when it gets above about 950,000. That's easier than dealing with the problems that start cropping up when the job number reaches 7 digits.
 
Thanks for the suggestion. We purge the printqueue when it reaches 24,000 members. I have a scheduled job that monitors for the number of members and sends me an e-mail when it reaches that number. Then I run a purge.
 
Re: SP23_T1: Dead on the web

We have finally ground to a halt on T1 because the web client won't format the company code correctly. (i.e. enter 30 - should be fornatted to 00030 - remains as 30 - no data selected). JDE have accepted it needs a SAR. So for now we're looking back to S1 or forward to something after U1 which came out before we had the bug accepted.

mad.gif
 
Back
Top