E9.2 new 9.2 install, full package troubles

[Alex_Pastuhov]

I’m sure I’ve seen this issue before, but after searching KG for a while I cannot find anything definitive ;-(

Doc ID 2277694.2, Troubleshooting section, “Scenario 1: Full or update package builds failing because of missing .h and .c files” says:

“the F9860 records had a blank value in the SIGTFFU1 column” – I can confirm that, but the proposed solution did not work for me:

Workaround/Solution:

If there are only a few objects, check them out via OMW and then check them back in, which should reset that flag. Or, you could backup the F9860 table and manually update the SIGTFFU1 to have a value of '1'. Make sure the .h and .c files exist before checking the object back in.

If there are many objects it may be best to update the record in the F00942T, for the path code you are building packages for:

1. Before doing this, be sure all of the .h and .c files actually exist on the Deployment Server under the path code\include and \source because that's where the process will get the files from. See note below for more information.

2. Backup the F98780H and F98780R tables

3. Update the record in the F00942T for the path code where packages are being built, set the EMDBSRCFLG value to a '0'

4. Build a new full package. This will cause all of the files to be inserted into the database again and reset the values in the F9860 table to a '1'.

Once you get a good package build, subsequent packages should build successfully.

I may be using wrong table instances – these instructions do not say if F9860 supposed to be the one in the System or the Planner Local, but in any case I cannot get this to work. What am I missing? It’s a brand-new install and I went to TR9253 with Planner & U5 right up-front.

Surely it’s supposed to work and probably is documented somewhere…

 

[craig_welton]

Alex, do the "missing" .c and .h files exist in the path code on the dep server?

 

[TFZ]

You can also sql delete the objects in question from the F98780R/H (if they're there at all) and set EMDBSRCFLG to 2. That should only update the missing records.

 

[Larry_Jones]

If not the local DB then F9860 (on SQL Server) will be in the JDE920 DB as OL920.F9860

 

[TFZ]

I probably replied to fast... and thus my first post is useless. Are you loading the F98780R/H at all? Since its a new install, did the OCM's get created for the F98780R/H in Central Objects / do the tables exist? On the deployment server end, you should see the load happening in the package log there before it ever gets to the enterprise box you're building on. And technically, it would be the F9860 on the database end. Also, anything odd bitness related since you're going 9.2.5.3?

 

[Alex_Pastuhov]

Alex, do the "missing" .c and .h files exist in the path code on the dep server?

Craig, yes, they all do. But it fails to copy half of them into the package folder - same as with F98760R.

 

[Alex_Pastuhov]

You can also sql delete the objects in question from the F98780R/H (if they're there at all) and set EMDBSRCFLG to 2. That should only update the missing records.

I was typically clearing F98760* and setting EMDBSRCFLG to 0. If 2 only does missing, it would probably not improve it. That's EMDBSRCFLG in the E1LOCAL on the Dep Server, right? Or the one in SY920 schema (where I did not actually have a row, but I have also tried creating a row there - no difference)?

 

[craig_welton]

What happened when you updated F00942T, setting EMDBSRCFLG to '0', and then built the full package? It should have loaded F98780R with the files from the dep server path code.

 

[Alex_Pastuhov]

If not the local DB then F9860 (on SQL Server) will be in the JDE920 DB as OL920.F9860

Larry, set it to 1 everywhere, all records, but the package build ignored it anyway. No difference.

 

[Alex_Pastuhov]

What happened when you updated F00942T, setting EMDBSRCFLG to '0', and then built the full package? It should have loaded F98780R with the files from the dep server path code.

It has repeated the same thing exactly. And my F98760R count went up to 10,758, same as before. It should have been >24k or so.

 

[craig_welton]

I wasn't aware the F9860 SIGTFFU1 flag had a play in this. It will be the OL F9860. Are there BSFN records with SIGTFFU1 != 1? Is the count of records where SIGTFFU1 = 1 at 10758?

 

[Alex_Pastuhov]

I wasn't aware the F9860 SIGTFFU1 flag had a play in this. It will be the OL F9860. Are there BSFN records with SIGTFFU1 != 1? Is the count of records where SIGTFFU1 = 1 at 10758?

Initially yes, that what it was. Now it's all 1, but it had no effect. Perhaps I need to set it to 1 in E1LOCAL there, I'll try that next...

 

[craig_welton]

Hmmm. wouldn't think so. OL F9860 should be the master. perhaps an OCM issue.

 

[craig_welton]

Are you logging into DEP920 to build the package?

 

[Alex_Pastuhov]

Hmmm. wouldn't think so. OL F9860 should be the master. perhaps an OCM issue.

I think the initial F98760R inserts are done by the Dep server. And it has to somehow decide which objects to insert. I thought that's where F9860 comes into play, but it does not seem so. It must be reading something else for this and I cannot see what ;-(

 

[Alex_Pastuhov]

Are you logging into DEP920 to build the package?

Sure ;-) Good one ;-)

 

[craig_welton]

Sorry, I didn't mean to offend.

 

[craig_welton]

I think the initial F98760R inserts are done by the Dep server. And it has to somehow decide which objects to insert. I thought that's where F9860 comes into play, but it does not seem so. It must be reading something else for this and I cannot see what ;-(

Anything in the package build log? it usually shows a count of objects it inserts into the repo table. The jde.log of the dep server?

The same process should happen if you run the package build from a fat client. Perhaps try that?

 

[Alex_Pastuhov]

Sorry, I didn't mean to offend.

No offence. Done that ;-) JDE is actually smart now and would check it most of the times, I think.

Anyway, I also see things like:

Wed Apr 14 13:04:03 - File Mismatched, Object Name N7003720
Wed Apr 14 13:07:54 - File Mismatched, Object Name B1800320

and

Wed Apr 14 13:03:13 - 710 - Not inserted: DN0500015, Type: DSTR
Wed Apr 14 13:03:15 - 714 - Not inserted: DX310911A, Type: DSTR
Wed Apr 14 13:03:15 - 716 - Not inserted: DLM4601, Type: DSTR
Wed Apr 14 13:04:03 - 796 - Not inserted: P08601PT, Type: APPL
Wed Apr 14 13:04:06 - 806 - Not inserted: D7003740, Type: DSTR

But as I never got to the end of a successful built yet, I'm not sure if these are problematic at all.

 

[craig_welton]

No offence. Done that ;-) JDE is actually smart now and would check it most of the times, I think.

Anyway, I also see things like:

Wed Apr 14 13:04:03 - File Mismatched, Object Name N7003720
Wed Apr 14 13:07:54 - File Mismatched, Object Name B1800320

and

Wed Apr 14 13:03:13 - 710 - Not inserted: DN0500015, Type: DSTR
Wed Apr 14 13:03:15 - 714 - Not inserted: DX310911A, Type: DSTR
Wed Apr 14 13:03:15 - 716 - Not inserted: DLM4601, Type: DSTR
Wed Apr 14 13:04:03 - 796 - Not inserted: P08601PT, Type: APPL
Wed Apr 14 13:04:06 - 806 - Not inserted: D7003740, Type: DSTR

But as I never got to the end of a successful built yet, I'm not sure if these are problematic at all.

Does it always insert the same # of F98760R records? So, could the next record from F9860 be corrupt in some way that causes the process to fail, leaving you with 10758?