KNT0000107 - Remote batch process could not be submitted

[Crazy_About_JDE]

Hello, list! In my test environment, DV7334, I have three users who can submit any UBE to print on our iSeries server, but one user who cannot.

The error message that appears on her screen after clicking Submit is: "An error occurred submitting batch job R55SHPINV1, AAA002RB to SERVERNAME."

The JDE.LOG shows this:

3376/2448 Wed Feb 15 12:24:33 2006 lanchube.c651
Submitting R55SHPINV1, AAA002RB to SERVERNAME (with Specs).

3376/2448 Wed Feb 15 12:24:36 2006 JDEKNUBE.C3322
KNT0000107 - Remote batch process could not be
submitted on SERVERNAME.


What I have checked:
- Tried adding this user to the same group as the others.

- Security Workbench records match the other users.

- System user matches the other users.

- Turned on debug logging, but found nothing of value.


The last two lines in this user's debug log are

Feb 15 14:02:07 ** 3324/3124 Entering JDB_AuditingOn
Feb 15 14:02:07 ** 3324/3124 Exiting JDB_AuditingOn with success

but the other users' log continues for another 91 lines.


Any ideas? This is on ERP 8.0 (B7334) SP 23.

 

[Crazy_About_JDE]

Hyper Item is being disabled in Security

Hello, list!

I haven't gotten any feedback on my original post, Remote batch process could not be submitted, so I've been digging around for any other remote details that might matter.

I found that a failing user has these entries in JDE.LOG, while a working user (including ALL newly added users) does not:

2524/2392 Tue Mar 07 10:25:02 2006 rt_form.cpp5397
A Hyper Item is being disabled in Security, the item no longer exists.
The Hyper Item is: ADD, the app is: P98305, and the form is: W98305D

2524/2392 Tue Mar 07 10:25:02 2006 rt_form.cpp5412
A Hyper Item is being disabled in Security, the item no longer exists.
The Hyper Item is: DELETE, the app is: P98305, and the form is: W98305D

>>>

Any ideas? This is an ERP 8.0 (B7334) SP 23 sandbox.

 

[Soul Glo]

Re: Hyper Item is being disabled in Security

From what Oracle told me this is normal especially if you upgraded from a previous version to Xe or 8.0. There is a work around for this message but I was told that it does not create any issues. A lot of my users get this in their log files and have no issues; I think it is just an annoyance.

Here is the Fix they gave me for Xe

The SAR that I believe you are seeing is 6237471 Fix ValidateER errors - P98220 which is fixed with ESU JD20200.

 

[Crazy_About_JDE]

Re: Hyper Item is being disabled in Security

Thanks, Glo, that will be helpful for cleaning up log files.

I was hoping my find might give someone an idea of why certain users can submit UBEs and some -- including all newly added users -- can't. The security records for P98305 (Batch Versions) are suspicious.

Out of desperation, I tried clearing select P98305 security records, but that gave gave me the exact same result -- including entires in JDE.LOG!

Argh!

 

[Crazy_About_JDE]

Re: Hyper Item is being disabled in Security

Don't you think it's also suspicious that I only get the Hyper Exit security message for users who can't submit UBEs?

 

[Soul Glo]

Re: Hyper Item is being disabled in Security

That is interesting.....so these users cannot submit any UBE? Is this conventional client or TS or Web? Also can you try to move one of these users to your group and see if they can submit.

Also did you make any update to your system lately and is this random.

One more thing....can these users go to submitted jobs and view jobs on the server they are trying to submit to?

 

[Crazy_About_JDE]

Re: Hyper Item is being disabled in Security

Yes, that is correct: They cannot submit *any* UBE from either conventional client or thin client. I have tried moving them to a different group, but got the same result. I just tested the Submitted Jobs application, and they can indeed see others' jobs there.

It sure does seem random. We upgraded the environment September 2004 then abandoned the project until Summer 2005; I installed SP 23 and applied ESU JE8597 (Database Password Encryption for Multiple Foundation Environments), so I could add a new user. We haven't had any trouble with that user, nor with the ones that were migrated from Xe.

Since then we have only done several additional spec merges (R98700).


Now...Since my last post, I ran R98403/XJDE0051 and XJDE0023 to refresh the F98OWSEC and related files from System - B7333 to System - B7334, hoping this would clear up the problem. It didn't.

I hope that helps!

 

[Segfault]

Re: Hyper Item is being disabled in Security

Turn on debug logging on the server, UBEDebug=6, and then submit. When you get:
3376/2448 Wed Feb 15 12:24:36 2006 JDEKNUBE.C3322
KNT0000107 - Remote batch process could not be
submitted on SERVERNAME.

Then look at the UBE Kernel they were talking to, and attach logs from it, as it should have better details on why the submission was denied.

 

[Soul Glo]

Re: Hyper Item is being disabled in Security

You are on an AS/400 DB2 Correct?

Have you looked at the 400 to see if any log files are being generated for those users is there anything on the server log side. Also have you tried clearing SQL packages and bouncing services? I am sure you must have tried these but I thought I might just mention it.

 

[Crazy_About_JDE]

Unable to change temp file owner

Thank you, Glo. Yes, we're on OS400 and DB2. We delete all SQL Packages nightly -- OBJ(*ALLUSR/*ALL) OBJTYPE(*SQLPKG) -- AND bounce services.

The only interesting thing I could find in the kernel log was:

156307 Tue Mar 7 16:00:14 2006 jdeknube.c1157
Unable to change temp file owner

but maybe you guys can find something in these logs, attached in a single text file:

JDENET_K job log
JDE_974528.LOG, JDEDEBUG_974528.LOG
JDE_974525.LOG, JDEDEBUG_974525.LOG
JDE_974526.LOG, JDEDEBUG_974526.LOG

 

[Segfault]

Re: Unable to change temp file owner

I'm gonna take a stab at it and say the user who can't run has a different iSeries proxy user id in their oneworld user config, and for some reason the ONEWORLD iSeries user id that the UBE kernel runs as doesn't have proper access to the problem user's iSeries proxy user profile, and hence can't change the access to the spec pak files that were sent over to enable a PRINTUBE process running as the iSeries proxy user id in question to read them.

See if you can enable an iSeries job log on the jdenet_k that is a UBE Kernel and look at it, I imagine there will be some more relevant iSeries error in that, if what I said above doesn't help with resolution.

 

[cassh1]

Re: Unable to change temp file owner

Couple of suggestions.
1. We had a problem with a user that had a blank in their password. Somehow that did not translate well when submitting UBEs. I would imagine that other 'special' characters might do weird things too.

2. I would check the setup of their system id (assuming that you are not using JDE for all of them) as it looks like permissions on the temp file created by the UBE. We have had the same problem but it is not consistently one user - it is multiple UBEs colliding over the same temp file.

I hope it's the password as that's an easy fix.

Sue
Xe Sp23i1 Coexistent iSeries V5R3 all client platforms

 

[Crazy_About_JDE]

Re: Unable to change temp file owner

Hello, Seg, and thank you for the suggestion. All of our users are using jde as the system user. User 'ONEWORLD' has *ALLOBJ authority. If the proxy user was the problem, I would think all users--not just a handful--would experience this problem.

Regarding the job log files: Is there another way to generate job logs than the ones I posted with my previous update? (I did a 5 on the JDENET_K job, then 10 to display job log.)

Thanks in advance!

 

[Segfault]

Re: Unable to change temp file owner

So much for my different proxy user theory.

CHGJOB JOB(629330/ONEWORLD/JDENET_K) LOG(1 00 *SECLVL)

Will cause everything (all iSeries activity from level 00 mesages on up) to be generated into a job log, and you can do it for a single jdenet_k, the UBE kernel the user is attached to. The log will be there even after stopping services, and if you do a

WRKJOB JOB(629330/ONEWORLD/JDENET_K)

and the hit 4 you can see the spoolfiles. Those files can be moved from the queue they are in to a PC via OpsNav (I believe even while the service are up this is possible) which you could then attach here, or send to Oracle if you have to open a case with them.

 

[Crazy_About_JDE]

Fixed: KNT0000107 - Remote batch process could not be submitted

Though, it's like burying an old friend, this mystery is now solved. Cleo , Sue , and Segfault were all on the right track, so you get honorable mention. Thank you all for your input and moral support!


I discovered that the JDE.INI in B7334SYS had been reset after installing Service Pack 23 in June 2005, undoing a significant change I made to the INI in September 2004: The SecurityServer entry was BLANK!!!!!

To fix, I set it to my iSeries server name, and voila!

The job log has these additional lines in it that were not there before:

<ul type="square">[*]Ownership of object QACXSN1QTV in B7334SYS type *FILE changed.
[*]Authority *ALL or *AUTL revoked from *PUBLIC.
[*]Object authority revoked.
[/list]


The common denominator among those users who could submit UBEs? They all happened to have user profiles on the iSeries server! (Ironic sidenote for the truly curious: It didn't even seem to matter if the iSeries profile's password matched the OneWorld user's password! ?!?)


This change also fixed what I thought were unrelated problems with our modified Sales Order Entry and Purchase Order Entry applications. The ExecuteExternalProgram business function (B34AA1030) was timing out and failing to run the external programs, but those are now also working again, like a charm.