E9.2 new 9.2 install, full package troubles

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

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

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

Active 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

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

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

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

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

Active 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?
 
Top