Package Build Issue

[DaveBarber]

I have an issue with a business function header file being overwritten during the package build process. I wonder if anyone can help?

I have a function called N5555256 (NER). It has a data structure called D5555256I. When it was created this structure originally looked like this:

/*********************************************************************
* TYPEDEF for Data Structure
* Template Name: LMS - Get Callout Config and Submit
* Template ID: D5555256I
* Generated: Thu Sep 18 10:25:29 2008
*
* DO NOT EDIT THE FOLLOWING TYPEDEF
*
*********************************************************************/

#ifndef DATASTRUCTURE_D5555256I
#define DATASTRUCTURE_D5555256I

typedef struct tagDSD5555256I
{
char szXMLWorkItemType[3];
char szXMLWorkItemSubType[11];
char szXMLOutboundMessage[2049];
MATH_NUMERIC mnUniqueKeyIDInternal;
char cCallingMode;
} DSD5555256I , *PDSD5555256I , *LPDSD5555256I;

#define IDERRszXMLWorkItemType_1 1L
#define IDERRszXMLWorkItemSubType_2 2L
#define IDERRszXMLOutboundMessage_4 4L
#define IDERRmnUniqueKeyIDInternal_5 5L
#define IDERRcCallingMode_6 6L

#endif

Notice that szXMLOutboundMessage = [2049]. This was the length of the data item when the data structure was created.

Since then I have changed the length of this data item to 16384. Here is the updated definition:

/*********************************************************************
* TYPEDEF for Data Structure
* Template Name: LMS - Get Callout Config and Submit
* Template ID: D5555256I
* Generated: Fri Sep 19 09:27:25 2008
*
* DO NOT EDIT THE FOLLOWING TYPEDEF
*
*********************************************************************/

#ifndef DATASTRUCTURE_D5555256I
#define DATASTRUCTURE_D5555256I

typedef struct tagDSD5555256I
{
char szXMLWorkItemType[3];
char szXMLWorkItemSubType[11];
char szXMLOutboundMessage[16385];
MATH_NUMERIC mnUniqueKeyIDInternal;
char cCallingMode;
} DSD5555256I , *PDSD5555256I , *LPDSD5555256I;

#define IDERRszXMLWorkItemType_1 1L
#define IDERRszXMLWorkItemSubType_2 2L
#define IDERRszXMLOutboundMessage_4 4L
#define IDERRmnUniqueKeyIDInternal_5 5L
#define IDERRcCallingMode_6 6L

#endif

This definition was changed locally on my fat client and checked in successfully. The check in location on the dep server is updated with the correct definition in the include directory.

I promoted the project to 26 and the include directory on the dep server in PY is also correct and reflects the include in DV and on my fat client.

When I created both an update and full package I am finding that the .h file in the include directory in the package folder is created with the old definition as below:

/*********************************************************************
* TYPEDEF for Data Structure
* Template Name: LMS - Get Callout Config and Submit
* Template ID: D5555256I
* Generated: Thu Sep 18 10:25:29 2008
*
* DO NOT EDIT THE FOLLOWING TYPEDEF
*
*********************************************************************/

#ifndef DATASTRUCTURE_D5555256I
#define DATASTRUCTURE_D5555256I

typedef struct tagDSD5555256I
{
char szXMLWorkItemType[3];
char szXMLWorkItemSubType[11];
char szXMLOutboundMessage[2049];
MATH_NUMERIC mnUniqueKeyIDInternal;
char cCallingMode;
} DSD5555256I , *PDSD5555256I , *LPDSD5555256I;

#define IDERRszXMLWorkItemType_1 1L
#define IDERRszXMLWorkItemSubType_2 2L
#define IDERRszXMLOutboundMessage_4 4L
#define IDERRmnUniqueKeyIDInternal_5 5L
#define IDERRcCallingMode_6 6L

#endif

My understanding has always been that the package build process creates the package dirs for the path code under the \PY7333\PACKAGE\PYFnnnnnn (where nn is package name). In this folder the include dir is created and then the .h file is copied in from the py7333/include and then the functions and built in the busbuild of the package build process.

I cannot find any reference to this legacy definition of the .h file on the dep server, so where is it coming from and how is it being created and overwriting my valid checked in definition?

Any help would be greatly appreciated.

thanks
Dave

JDE OW XE SP22 on Oracle

 

[Sebastian Sajaroff]

Hi,

Have to built the BSFN before checkin?
The correct sequence is :

1. Checkout BSFN and DSTR
2. Correct or modify its source code
3. Build BSFN
4. Checkin BSFN
5. Checkin DSTR (if it was modified)
6. Build update package
7. Deploy update package
8. Promote

 

[DaveBarber]

Hi Sebastian,

Yes - the function was built in DV7333 before check-in and promotion.
I also undertook all of the steps you mention (several times) but still the same issue.

The question is why is the function being rebuilt with the old definition, and where is it getting it from when py central objects has the correct version?

 

[Sebastian Sajaroff]

Hi,

That's weird...
Have you tried building your full package from another
machine (other than the Deployment)?

 

[klwong]

Something I wanted to ask, just for my own clarification of your issue, did you modify the NER source file (meaning the .h and .c files) directly on your fat client before checking in, and not through the Event Rule editor?

Part of the package build process that I think you may be missing is that while all the include and source code is copied to the new package's subdirectory, that only applies for B### and X### type BSFNs. The code for the NERs is generated from the specs, which is why any existing source code is "wiped out."

 

[DaveBarber]

Hi,

Yes I edited the source and checked in. The change was not through NER.
This is what I suspected - the .c and .h files would have been held in the specs and despite the file being promoted they will always revert to the NER as this is what is held.

In short - what you are saying is that what is in the source is not necessarilly what is in specs.
Useful to know - i spend too much time working in c.
I will look to find a way round this in NER now i'm clear.

many thanks

 

[Sebastian Sajaroff]

Hi,

Oh..oh... yep, you have to edit and modify your NER
through OMW Toolkit, not directly on the C source.
That's why it's regenerating the original code.

 

[Zoltan_Gyimesi]

Hi Dave,

Ken is right.
BusBuild re-generate the source code.
As far as I remember, if you run BusBuild for a DLL manually e.g. on a fat client, then you have a check-box option "Generate Source".
I am doubt about, whether does this option available somewhere in the Package Build process.

Regards,

Zoltán

 

[jdemen]

Hi Guys,

I agree with Sebastian and Zoltan. You NER spes would be different from your .C and .H components. When you try resubmitting the package from P9622, it would ask for Generate NER?? You would need to click yes for enabling it to build the source and NER's from scratch. That should solve your issue.

JDEMEN
B7333-8.12/AS400