E9.2 new 9.2 install, full package troubles

Alex_Pastuhov

Alex_Pastuhov

Legendary Poster
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?
Yes and no: it goes to 10,758 - just once more again now after updating E1LOCAL's F9860 as I mentioned above.

But if I check out F00165 in DEP920 (one of the missing objects), it adds 1 more, etc. It's just that there are so many missing ones, that I cannot possibly check them out one by one like this. I don't think it's a corruption.

I can try debuglog'ging it next and see where it's getting that list from - it happens within a minute from the build start...
 
Alex_Pastuhov

Alex_Pastuhov

Legendary Poster
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?
Logs look fine, at least no errors for this stage, lots of BSFN errors later, because the files are missing. I do not have a package to install a client ;-)
 
Alex_Pastuhov

Alex_Pastuhov

Legendary Poster
F9860 is apparently the driver:

Apr 14 15:22:23.724049 - 5588/1012 WRK:Starting jdeCallObject SELECT * FROM OL920.F9860
Apr 14 15:22:23.724050 - 5588/1012 WRK:Starting jdeCallObject ORACLE dballInitRequest OCIStmtPrepare for 329a0428 stmthp
Apr 14 15:22:23.727000 - 5588/1012 WRK:Starting jdeCallObject Exiting JDB_SelectAll with Success
Apr 14 15:22:23.729000 - 5588/1012 WRK:Starting jdeCallObject [PKGBLD] - Wed Apr 14 15:22:23 - Start the insert of objects into the Repository Tables: F98780R and F98780H.

So it's not immediately obvious what exactly in F9860 it checks to decide whether to include an object or not.

It then checks status in F9861 and finally does this, per object:

Apr 14 16:00:52.274009 - 5588/1012 WRK:Starting jdeCallObject SELECT * FROM OL920.F9861 WHERE ( SIOBNM = 'B0000011' AND SIPATHCD = 'DV920' AND SISTCE = '1' ) ORDER BY SIOBNM ASC,SIMKEY ASC,SIPATHCD ASC

And the last one, for instance, it does for B0000011 & B0000013, but not for B0000012, so it's missing from the final F98760* tables as well it's sources are not in the package folders.

There's not a single mention of B0000012 in the entire ~3GB log.

I'm intrigued by SIOLCD04 here. But I do not see what's different between B0000011, B0000013 and B0000012 looking at F9860 alone ;-( Apart from SIOLCD01 value, but how can this matter??? - I have the same data in another E920/TR924x and it does not cause such issues.

Baffling...
 
TFZ

TFZ

Well Known Member
I had an issue where I was short F9862 records (i.e. I forgot it completely on a copy) It wouldn't really throw an error beyond stopping the inserts the repository tables. B000012 is in the F9862, do you have a record for it? You may see something in the work folder under your package build if I remember right.
 
Alex_Pastuhov

Alex_Pastuhov

Legendary Poster
I had an issue where I was short F9862 records (i.e. I forgot it completely on a copy) It wouldn't really throw an error beyond stopping the inserts the repository tables. B000012 is in the F9862, do you have a record for it? You may see something in the work folder under your package build if I remember right.
Yes, thanks, checked - it's all there. From JDE debug log, it reads all F9860 and then never looks at some objects, so it seems F9860 is the only thing that controls it. It's skipping many tables too, so F00165.h and F0092L.h, etc. are missing and these are very frequently included in BSFN's, so most fail to build as a result.
 

JMR

VIP Member
Any chance the objects in question were checked-out / associated with a project that was created/assigned with a different E1 release level than your current install?

More specifically, is F98762.JDEVERS field != <target release>
 
Last edited:
craig_welton

craig_welton

Legendary Poster
Bizarre stuff, mate. I upgraded our lab to the same TR, set the F00942T to rebuild and kicked off a full package. Everything that should got added to F98780R. Sorry.
 
Alex_Pastuhov

Alex_Pastuhov

Legendary Poster
Any chance the objects in question were checked-out / associated with a project that was created/assigned with a different E1 release level than your current install?

More specifically, is F98762.JDEVERS field != <target release>
Nope: brand new install, no prior activity. I think JDE mostly ignores those anyway and I do have a small bunch objects there with blanks, but I have seen sites running with actual wrong release there forever and never saw any issues.
 
Alex_Pastuhov

Alex_Pastuhov

Legendary Poster
Bizarre stuff, mate. I upgraded our lab to the same TR, set the F00942T to rebuild and kicked off a full package. Everything that should got added to F98780R. Sorry.
I think I'll try a few different TR's next. And then x64. It would be a pity to have to scrap it and redo the whole thing ;-(
 
TFZ

TFZ

Well Known Member
I know this may be a long shot but I think it's suffice to say you are in long shot territory, are all of the files in central objects set to autoextend?
 
Alex_Pastuhov

Alex_Pastuhov

Legendary Poster
I know this may be a long shot but I think it's suffice to say you are in long shot territory, are all of the files in central objects set to autoextend?
Yes, thanks for the suggestion, they are: I usually do that up-front.
 
Alex_Pastuhov

Alex_Pastuhov

Legendary Poster
An update: I have abandoned that installation, but found an old TR923 system sitting around, so I have updated it to TR9253 + latest planner, found 1 object in F9860 with a blank SIGTFFU1 that was initially causing some small package build issues, updated it to 1 and had a clean package build with no errors.

Initially it was at U2 level in terms of updates, so I thought I'd go the whole way and updated it to U5, plus the latest tools roll-up and a couple more ESU's. Now, the package fails with the same symptoms.

There's got to be something else there that's causing all this grief and it's not probable that I'm the only one hitting these issues. It's not a production system, so I'm slacking on details and it's entirely possible that I missed some "special instruction" somewhere. Yet, all instructions focus on those 2 tables - 9860 & the T table. And it's clearly not all there is to it. Any more ideas?
 
Alex_Pastuhov

Alex_Pastuhov

Legendary Poster
But now that I updated F00942T setting both EMDBSRCFLG and EMENVFU2 to 0 and re-run the package, it came clean again. Which was not the case in my original system. Weird. But it's not an issue for me any longer, thanks to all who replied.
 
Top