Results 1 to 9 of 9

Thread: Header file not copied to /include - PKG fails

  1. #1

    Header file not copied to /include - PKG fails

    Hi all,
    we have this issue on our current production environment (9.2.2.6 with E900) that we have to manually copy a custom header file F59xxxxx.h from the pathcode's /include folder to the package's /include folder on dep and ent server once we start the package build. Can be done by script of course, but it's still pretty annoying. When we setup the new environment (9.2.3.3 with E920) for testing first i encountered the same issue and now i really feel like fixing it.
    SO reading through MOS there's lots of those errors, mainly on specific header files that can be fixed with a manual edit or an ESU. Since ours is a custom file i had to dig deeper. Found some other scenario about file permissions but they are fine. Then i read something about the header file not being used by any function and is therefore not being copied - but why does the package build fail then?

    It's under CCUSTOM and the work/buildlog entry looks like this:
    D:\JDEdwards\E920\DV920\package\DVFULL\source\N59x xxxx.c(28): fatal error C1083: Cannot open include file: 'f59xxxxx.h': No such file or directory

    Any ideas?
    EnterpriseOne 8.12 to 9.2
    AIX, Linux, Windows, IBM i
    Oracle DB, MSSQL, DB2
    WAS, WLS

  2. #2
    Senior Member
    Join Date
    Mar 2004
    Location
    Fort Worth, Texas
    Posts
    1,580
    It's only your PD920 environment? You don't have this issue in PY or DV?
    Brian Oster
    Application Development Manager
    E1: 9.0 (TR9.1.5.1) / 9.2 (TR9.2.2.2)
    JAS/BSSV: Weblogic 12.1.2 / Weblogic 12.2
    ES: Win2008 / Win2016
    DB: MSSQL 2014 / 2016
    WebDev Client: Win7Pro / Win10Pro

  3. #3
    Quote Originally Posted by BOster View Post
    It's only your PD920 environment? You don't have this issue in PY or DV?
    i have that issue in DV900, PY900, PD900 and now DV920
    EnterpriseOne 8.12 to 9.2
    AIX, Linux, Windows, IBM i
    Oracle DB, MSSQL, DB2
    WAS, WLS

  4. #4
    Senior Member craig_welton's Avatar
    Join Date
    Oct 2000
    Location
    Litchfield, CT
    Posts
    1,027
    I had a similar issue in our lab environment after taking an ESU. The new releases store the function source in a table (I forget if it's configurable) and the package build will pull the source from that table. In our case, the source code in the table was not updated with the change yet the DS pathcode folder was. There is a flag in a path code table that signals the function source is in the database. We had to clear that and run a full package, which re-loads the table with the source code from the path code. Perhaps you are seeing something similar where the table source did not get into the database. Of course, I'm assuming you are setup that way.

    Craig
    Craig Welton
    PatWel Group Inc.
    http://www.patwel.com
    Home of the FREE JDE Object Browser, JDETrace, NERDup and BusBuild+ Tools

    E1 9.0 8.98.4.2 Wintel SQL 2008
    E1 9.2 9.2.1.4 iSeries

  5. #5
    Senior Member craig_welton's Avatar
    Join Date
    Oct 2000
    Location
    Litchfield, CT
    Posts
    1,027
    A little more on this … the svrpkgbuild.log on the deployment server in the full package directory will explain where it is getting the files from:

    Wed Apr 17 08:42:15 - Header structure initialized successfully.
    Wed Apr 17 08:42:15 -
    Wed Apr 17 08:42:15 - Check where the file repository is located, Deployment Server or Database.
    Wed Apr 17 08:42:15 - Source/Include/Res files will be retrieved from the F98780R repository.
    Wed Apr 17 08:42:15 - Check is complete, package build will continue.
    Wed Apr 17 08:42:15 - Files will be retrieved from Database Repository.

    There are several MOS articles about it and how to reset the pathcode flag if things get out of synch.

    Craig
    Craig Welton
    PatWel Group Inc.
    http://www.patwel.com
    Home of the FREE JDE Object Browser, JDETrace, NERDup and BusBuild+ Tools

    E1 9.0 8.98.4.2 Wintel SQL 2008
    E1 9.2 9.2.1.4 iSeries

  6. #6
    I actually know about all this already, but for some reason i didn't make that connection, haha!
    Yeah there's the F98780R and H tables now, that build the repositories for each pathcode now. It's not configurable, it's by force.

    I'll definetly try that but still the main question remains: why do i have to manually fill the whole repository again for just one missing object and why is it not being updated?
    EnterpriseOne 8.12 to 9.2
    AIX, Linux, Windows, IBM i
    Oracle DB, MSSQL, DB2
    WAS, WLS

  7. #7
    You could try sql deleting the object in F98700R and H, then doing a check out / check in in DV920, but being you've had it everwhere...are you sure the records for that custom table aren't borked in Central Objects / F9860/F9861?

  8. #8
    Quote Originally Posted by TFZ View Post
    You could try sql deleting the object in F98700R and H, then doing a check out / check in in DV920, but being you've had it everwhere...are you sure the records for that custom table aren't borked in Central Objects / F9860/F9861?
    Hi - why would i find a table (header) in F98700R/H? From my understanding (and having a look at my table) it only contains web objects like E1PAGE, FORMAT etc.
    For the central objects, i'm not sure, the table is in there but with a reeeally old timestamp (112nnn), which is weird. IIRC we didn't have this build problem since back then, maybe since two years, but not seven!

    Any other ideas more than welcome. I also emailed our developers if they know anything about it...

    EDIT:
    got it - i guess you just made a typo and meant F98780R/H
    i'll try deleting it there and see how that goes
    Last edited by schojo44; 07-02-2019 at 10:44 AM.
    EnterpriseOne 8.12 to 9.2
    AIX, Linux, Windows, IBM i
    Oracle DB, MSSQL, DB2
    WAS, WLS

  9. #9
    Whoops, yep, F98780H/R and not the UDO repository tables, sorry. Glad you found it.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
The legal restrictions and terms of use applicable to this site are available here.
Use of this site signifies your agreement to the terms of use.
JDELIST is NOT affiliated with JD Edwards® & Company, Oracle or Peoplesoft. Contents of this site are neither endorsed nor approved by JD Edwards® & Company and, or Oracle.