Monday, 23 January 2017

F98780R F98780H and the case of the missing BSFNs

We recently upgraded a site to 9.2.1, I kinda wish I did not.  There are a lot of changes here.  Most significantly from a change management point of view there is significant changes to:

  • media objects and them being stored in the database
    • Hopefully you have no mods in this area, you cannot turn this off!!
  • source files for C and H and BSSV being stored in the database.
    • Hmm, also needs some refinement.

This post focuses on the latter and the problems that I had with it.

I’d been bought in on the upgrade (where a couple of full packages has been built), but there was some OL integrity issues.  Central objects were okay, because this was a simplified upgrade.  This means that the original central objects were the base – phew – good news.

But some missing OL records was causing grief.  We were getting the following in the logs of the server package build:

Mon Jan 23 12:14:22  -  spkgutil.c:8516 PKGUTL0113 ERROR: Command CPY OBJ('/Packages/UA7012100/checkin/source/b5501820.c') TOOBJ('/Packages/UA7012100/source/CCUSTOM/b5501820.c') SUBTREE(*ALL) REPLACE(*YES) failed. Failed to copy the directory.

Mon Jan 23 12:14:22  -  spkgclnt.c:268 PKGCLT0033 ERROR: Failed to transfer file /Packages/UA7012100/checkin/source/b5501820.c to CHIJTD42. Error Error in file I/O

Mon Jan 23 12:14:22  -  spkgclnt.c:1179 PKGCLT0054 ERROR: Failed to transfer /Packages/UA7012100/checkin/source/b5501820.c to the server.

This is frustrating.

The source files are there in the UA920\source dir, but they are not being transferred.  Note that I’m familiar with the F98780R and also the F00942T and the F9860.SIGTFFU1.  I know that the package build (full) looks at the F9860 to see if there is a record in the F98780R for the object, and if there is a 1 in the SIGTFFU1 field, then it’s assumed that there is a file ready in the COUA920.F98780R file.  But – what if you needed to patch OL a little bit, merge a few extra records in because the package build was not working?  You have a problem.

It seems that the F98780R only contains 1 row per object, this is either based upon a package built or an OMW transfer:

image

See above one insert as a result of the package build and 3 due to object transfers.  So if there is a 1 in F9860 and it’s a full package, it seems that if there is no record in F98780H for your object – it’s not going to build.  So – how are you going to fix this?  Well, it seems that the best method is to put your objects into a project and promote them.  This is going to ensure that they are going to have records in F98780H when it’s build time.

select * from ol920.f9861 where simsar = '' and sipathcd = 'UA920';
select * from ol920.f9860 where siobnm = 'B5500001';
select * from sy920.f00942t;
select table_schema from qsys2.systables where table_name = 'F98780H';
select * from coua920.f98780h where ahpid <> 'UA6122300';

My other option would be to reset the F00942T so that it did not think it had processed all of the files, and probably deleted the contents of F98780H – that might have sorted things too?

image

You can also see a new field in the pathcode master application too, which correlated to the F00942T

I’ve been a bit lackadaisical in this post with my dichotomy between F98780R and F98780H, so let me define:

F98780H       Object Librarian Archive History                               
F98780R       Object Librarian Archive Repository                            

You can refresh these tables (as I needed to do), by updating F00942T and then running your build again.

update sy920.f00942t set emdbsrcflg =0 where empathcd = 'UA920';

You’ll see the following in the D:\JDEdwards\E920\UA920\package\UA920FD\serverPkgbuild log file:

Tue Jan 24 06:40:16  -  Check where the file repository is located, Deployment Server or Database.
Tue Jan 24 06:40:17  -  For each object, a record will be inserted into F98780R/F98780H table.
Tue Jan 24 06:40:17  -  This is where package build will retrieve the include, source and bitmap files.
Tue Jan 24 06:40:17  -  This process will only run once for each pathcode.
Tue Jan 24 06:40:17  -  This might take a while so be patient.
Tue Jan 24 06:40:17  -  To monitor the progress, the logs in the work directory should increase in size.
Tue Jan 24 06:40:17  -    Logs directory: \MACHINE\E920\UA920\package\UA920FD\Work\.
Tue Jan 24 06:40:18  -  Clearing the F98780R and F98780H tables.
Tue Jan 24 06:40:20  -  Start the insert of objects into the Repository Tables: F98780R and F98780H.

Instead of (once this is done)

Mon Jan 23 11:44:03  -  Check where the file repository is located, Deployment Server or Database.
Mon Jan 23 11:44:03  -  Source/Include/Res files will be retrieved from the F98780R repository.
Mon Jan 23 11:44:03  -  Check is complete, package build will continue.
Mon Jan 23 11:44:03  -  Files will be retrieved from Database Repository.

This is where the additional 2GB of storage is needed for your first full package in 9.2.1 tools release – all of your source and include.

1 comment:

Reeti said...

Hi,

I have the same issue of missing BSFNs and so my Full package build fails. I understand that we need to reset the flag in F00942T. Can i directly run the updates statement for this in SY920 database? or is there any other way to do this?

Sorry, I am just 3 months old in JDE E1 and trying to understand things.

Regards

Extending JDE to generative AI