Subsystem Record Could not be Submitted

dcurran

Member
Hi,

We have just finished cloning our Production environment into a new Training environment...so far everything is checking out with the new TR environment except for a hand full of subsystem jobs. As an example, we have a P5542SOE (custom P4210) setup to submit work through subsystem R5542520 (custom R42520)...this all works in PD, no problem, but when we try to do the same processes in the new TR environment we get a message:

4968/3780 Mon Sep 24 11:29:20 2007 K2Subsys.c737
UBE0000050 - Subsytem Record could not be submitted on ELLIE.

The really weird thing is that several other subsystems are running just fine in the TR environment.

The debug log for the above was not much help. Also, when we look into the R986113 there are not entries for the work we are trying to process.

Help!!
Dave

OneWorld XE B7333, iSeries V5R3, SP23A, Update 1
 

Attachments

  • 125181-jdeTR.zip
    99.2 KB · Views: 93
Make an update package with the report data structure for the report interconnect that subsystem uses, and make sure it is in the startup environment (the jde.ini startup env in the security section) that the subsystem kernel is using. Otherwise, it will not validate the datastruct and will deny the add record.

Alternatively, change the env in the security section of the JDE.INI to an env where the struct already exists.
 
[ QUOTE ]
Make an update package with the report data structure for the report interconnect that subsystem uses, and make sure it is in the startup environment (the jde.ini startup env in the security section) that the subsystem kernel is using. Otherwise, it will not validate the datastruct and will deny the add record.

Alternatively, change the env in the security section of the JDE.INI to an env where the struct already exists.

[/ QUOTE ]

Hi,

Not sure I fully understand your response...when you say to 'change the env in the security section of the JDE.ini to an env where the struct already exists' can you be more specific...

Maybe some more info on my setup would help...our TR environment runs on a shared system with our PY environment. The two environments share kernels, batch queues and AS/400 subsystems in order to run...from that, I think (not sure) that I already have this setup. The Security Section of my AS/400 JDE.INI file is as follows:

[SECURITY]
SECURITYMODE=2
DataSource=System - B7333 - DNT
User=jde
Password=xxxxxx
DefaultEnvironment=PY7333
SecurityServer=JETHRO
ServerPswdFile=TRUE
History=1

Thanks for your help,
Dave
 
Dave,
Excuse my lapse. but your servers are named after the Beverly Hillybillys?
 
Yep...we have Jethro (Production / security server), Ellie (Test/Training Server) and Granny (Development). The initial project way back when to implement OneWorld was called JED.

My company is in oil and gas so I guess at some point in the past all this made sense to someone (or was a good joke on the reliability of OneWorld...we were an early adopter)...before my time here.

Dave
 
If both servers have DefaultEnvironment=PY7333, then turn on logging on the server where it fails, try it, and see what the subsystem kernel logs say.
 
The Datastructure suggestion sounds like the right direction...the Subsystem Kernel logs had the following:

[ QUOTE ]
Sep 26 15:43:16 ** Entering JDB_FreeUser
1896 Wed Sep 26 15:43:16 2007 combined.c344
RDEL0000045 - Could not open tables for reliable event delivery (F90703 and F90704). Reliable event delivery will be disabled

Sep 26 15:43:16 ** Entering JDB_InitUser with commit mode 0.
Sep 26 15:43:16 ** Entering JDB_BeginTransaction
Sep 26 15:43:16 ** Locking /PY7333/specfile/dstmpl.ddb in READ mode.
Sep 26 15:43:16 ** LOCK: Total READ locks after operation: 1
Sep 26 15:43:16 ** Unlocking TAM file /PY7333/specfile/dstmpl.ddb
Sep 26 15:43:16 ** UNLOCK: Total READ locks after operation: 0
1896 Wed Sep 26 15:43:16 2007 k2subsys.c109
UBE0000079 - --UBE--SS:Mismatch in DataStruct Length.

Sep 26 15:43:16 ** Sending a message, Receive Host=<190.1.1.81>, flags=0x0
Sep 26 15:43:16 ** putQueue Net1895Q,msg-4,msgType-3501
Sep 26 15:56:43 ** getQueue Krnl1896ReqQ,msg-4, msgType-3501
1896 Wed Sep 26 15:56:43 2007 k2subsys.c109
UBE0000079 - --UBE--SS:Mismatch in DataStruct Length.

Sep 26 15:56:43 ** Sending a message, Receive Host=<190.1.1.81>, flags=0x0
Sep 26 15:56:43 ** putQueue Net1899Q,msg-4,msgType-3501

[/ QUOTE ]

Based on that, we are going to clone our PY environment into the server rather than the PD environment and see where that gets us...ultimately it would have been much better to have the Training Environment based on our Production environment, but we can live with having it based on PY.

Testing on this will happen later tonight...I'll update this post tomorrow with our results.

Thanks again for your help,
Dave
 
Yep...it was the data structures being mismatched between the two environments that share this partition...

Thanks again for everyone's help.

Dave
 
Back
Top