UNABLE TO SUBMIT UBE TO SERVER

2852/3380 Fri Sep 02 19:42:01.390 IPCMISC.C294
process 2852 <D:\PeopleSoft\ddp\B9\system\Bin32\jdesnet.exe> registered in entry 0

======================================================
3116/3028 Fri Sep 02 19:42:02.687 IPCMISC.C294
process 3116 <åv> registered in entry 1

3116/3028 Fri Sep 02 19:42:02.781 NETCFG.C251
Starting Kernel of Type:SECURITY KERNEL

3116/3028 Fri Sep 02 19:42:03.671 jdeksec.c3878
INITIALIZING SECURITY SERVER KERNEL

=========================================================

Sep 02 19:42:01.296 - 2852/3380 **** jdeDebugInit -- output to file.
Sep 02 19:42:01.375 - 2852/3380 gethostname returned: DECENT
Sep 02 19:42:01.390 - 2852/3380 process 2852 <D:\PeopleSoft\ddp\B9\system\Bin32\jdesnet.exe> registered in entry 0
Sep 02 19:42:01.390 - 2852/3380 process 2852 <D:\PeopleSoft\ddp\B9\system\Bin32\jdesnet.exe> registered in entry 0
Sep 02 19:42:01.406 - 2852/420 Changed dir to D:\PeopleSoft\ddp\B9\system\Bin32
============================================================
2776/3460 Fri Sep 02 19:42:02.015 cleanup.c117
Initializing Cleanup Program.
Any errors in this log file will not interfere with normal OneWorld Operation.

2776/3460 Fri Sep 02 19:42:02.031 cleanup.c144
Initializing Environment:DV9 . . .

2776/3460 Fri Sep 02 19:42:05.359 cleanup.c149
Initializing User JDE . . .

2776/3460 Fri Sep 02 19:42:05.531 cleanup.c189
No Jobs in the F986110 Table needed updating. Cleanup process exiting.
=====================================================
after submiting a ube

Sep 02 19:42:38.593 - 2968/3464 **** jdeDebugInit -- output to file.
Sep 02 19:42:38.671 - 2968/3464 gethostname returned: DECENT
Sep 02 19:42:38.671 - 2968/3464 process 2968 <jdenet_n> registered in entry 2
Sep 02 19:42:38.671 - 2968/3464 process 2968 <jdenet_n> registered in entry 2
Sep 02 19:43:21.531 - 2968/3464 Net program ended, pid = 2968, signal = 11
Sep 02 19:43:21.546 - 2968/3464 Net program ended, pid = 2968, signal = 11
Sep 02 19:43:21.546 - 2968/3464 API ipcSawZombieProcV1 : process 2968 set to Zombie in entry 2
Sep 02 19:43:21.546 - 2968/3464 API ipcSawZombieProcV1 : process 2968 set to Zombie in entry 2
 

Attachments

  • 96228-LOGSCLIENTE.zip
    70 KB · Views: 81
Is it something to do with some new updates from MS....!!! Just a thought though !!!
 
Alright folks, JDE/Oracle has fixed the issue for us. The fix replaces JDEUNICODE.DLL and makes an entry into the server's JDE.INI to point to a specific temp directory. It is a retro from 8.94. I still don't know what th eissue is, but it seems to work in our system.

Mention call # 3996585 and have them verify that you're experiencing the same problem and if so, the fix is already ready.
 
it works in my system too

ENTERPRISE 8.9 SP2, WIN2000 SP4, SQL2000 SP3a.
 
thank you to everyone

for all the support

muchas gracias a todos,

su amigo Junkpam de Mexico
 
KenM is correct -

Oracle gave us the jdeunicode.dll fix yesterday, and it works. We were told that the fix was also part of Tools release 8.94.I1. We are at 8.93.R1. What they said they fixed: a microsoft API call was being made which writes to a temporary directory. Over a period of days/weeks (from the time we rebuilt the enterprise server from scratch again and put in production), this API call to write to the temp directory(as defined by environment variable %TMP%) fails, and causes the UBE to error. Their fix was to use one of their own functions to write to the temp directory which is defined by the server jde.ini [JDENET] new entry "netTemporaryDir=<your temp directory path>".

I don't believe we are going to upgrade to the Tool release 8.94.I1 just yet, since the fix is in place and there are no other issues.

Hope this helps..

Vernon McDaniel
 
It appears that most everyone, possibly not everyone, but most everyone, was on 8.93.R1. I can appreciate JDE's stated reason for the problem and their solution, but my client had not rebuilt their machine since March. I realize that some of the rest of you had rebuilt your machines "recently", but my client had been running live 1,000-5,000 jobs per day since March without issue, then all of a sudden, this problem reared its ugly head the same week as many others' first experience with it. Why didn't anyone see this before now? Why were there, at my last count, a dozen or more all in one week when there hadn't been any since 8.93.R1 was released? No new Microsoft updates to Windows 2000 or SQL 2000 (I assume everyone with this problem is on Win 2000SP4 and SQL 2000SP3a) within the past week or two. Our %TMP% directory only had 20 files in it and the directory file itself is on par with a new directory.

I'm not a conspiracy theorist, but it does seem unlikely that the purported reason is the true reason for the problem, unless someone can convince me otherwise.
 
"Why were there, at my last count, a dozen or more all in one week when there hadn't been any since 8.93.R1 was released? "

As far our site is concerned, the above statement is false. We went live 7/25/05, and had our first episode with being unable to submit UBE to the server on 8/23/05. After a week of getting nowhere with Oracle support, we rebuilt the enterprise server. We decided to keep another enterprise server updated, ready and waiting since this problem occurred (which caused considerable loss of production). The second time this problem occurred, we switched over to the other server. After more time spent with Oracle, we arrived at the jdeunicode.dll solution.

"Conspiracy" MAY be a bit strong, although I'm sure they wouldn't be covering up something if Microsoft were to blame. By the way, we have not put on any Microsoft OS or SQL 2000 service packs or patches since our initial upgrade in Feb. We DID have a major issue with the initial upgrade failing table conversions when we used Tools Release 8.94.?(whatever it was at the time), and we had to to start over from scratch with 8.93.R1. If this jedunicode.dll fix was in 8.94.I1 then we, of course, weren't going to touch it with a 10-ft pole. I would certainly like some more feedback on this monstrous thread as to the conditions/scenario that other experienced with this problem.

Cheers,
Vernon McDaniel
 
Does this issue have anything to do with too many Acrobat files in the temp directory? If so - we saw this over a year ago. At that time we moved jobs to a secondary NT server. Same failure within a few weeks. I was fed up with it and consolidated everything to our UNIX Enterprise server. This was already in my plans so it was a convenient way to do it. I ultimately found that once 32,000 or so files were written to the temp directory - UBE's would start to fail upon submission.
 
..or was it 32,768?
smile.gif
Maybe a int variable overflow? Hmmmm..interesting. I'm not sure how many we had in our temp directory. KenM seemed to imply that his had much MORE than 32K and did nothing about the temp directory for months..

Vernon
 
Forgot to mention that we are at Windows 2000 SP4 and SQL 2000 SP3a.

Vernon
 
Exactly. 32,768 was the maximum. I mentioned it to someone at Oracle but never called it in for resolution. At that point I didn't care - too many other problems to worry about.
 
I thought the 32K files in the printqueue issue was an AS/400 issue, only - am I amiss in my belief?

On the AS/400 - there is a 32K limitation on the number of members (data files) that can exist within a Physical file....

So - is there the same limitation for the number of files that can exist in a intel/windows folder?

Hmmm - could be time to revamp that old PrintQueue clearing program... and make it downloadable.

(db)
 
NTFS allows more than 4 billion files per directory. This isn't practical, but it is the supposed limit. It seems more a self imposed application limit (related to Adobe PDF generation library, most likely).

Max files per directory
--------------------------
FAT - 512 files or folders per folder
FAT32 - 65,534 files or folders per folder
NTFS - 4,294,967,295 files or folders per folder
 
Good try, but we 70,854 files in our PrintQueue directory and has been higher in the past. Also have 38,704 files in the "TEMP" directory, but it has been as high as 52,000 or so. Windows 2000 SP4 SQL 2000 SP3a. Enterprise One 8.9 Tools Release 8.93.R1 and JDEUNICODE.DLL from 8.94.
 
Back
Top