Building BSFN on Deployment gives unexpected results

Hello all

We encountered a strange problem. We created a BSFN (NER) which works fine on our fat clients, but when we build it on the deployment server, we get unexpected results (eg. commas are returned instead of numbers, but only in a few fields,...)

If we rebuild that BSFN again on our fat client, everything works again.

Looking at the logs, we don't see any obvious differences except for the returned values...

Did anyone encounter this already ? Or does anyone have a solution?
I would very much appreciate it!

XE SP21, V5R2

Can you post your NER code?

I guess I should clarify why you should post you NER code.

On several occasions - others have had similar issues, it runs on the FAT and dies on the server. On most of these occasions the developer has inadvertantly used client-side code or non-ansi code or code that cannot run on the server (unsupported syntax).

One of the original gotchas is using whack-whack (//) instead of whack-splat-splat-whack (/* ..... */).

Now you know - and knowing is half the battle (g.i. joe)

Daniel

Hello DBohner

I'm not sure if I attached all NER code you need or if I need to extract it another way, so please tell me if this is OK

I did notice that we use the whack-whacks but afaik OW does this itself?

Here's a thought.

Since you are fetching from a custom table (F55) - can you verify that the specs for the custom table are deployed to the server and are the most current specs?

IF the datastructure contains custom dd items - make sure that the server knows them, too. I forget which files - but there are six magic files that may need to be removed and jiti'd back... someone more versed can explain.

Can you provide your configuration? (intel, os400, unix, pc286 and service pack)

Hope I haven't caused more confusion than resolution!

Daniel

Have you tried assembling the pkg on a client, then running the build on the deployment server, in the DEP environment?

This should work assuming you have the same versions of the C compiler on both.

One further point, does the complie work on any fat client, or just the one where the development was made, as otherwise you may have objects on the development client that do not exist on the deployment server (i.e not checked in), which would account for the differences.

I was misleading, and I appoligize. when you export the NER code, comments are displayed as whack-whacks. However, if you look at the C code that is created - they are /*...*/... thus I created confusion.

Generally - A NER doesn't allow the type of syntax I was alluding to. But, there are functions that can be called within a NER that are client or servers-side only... that does not seem to be the case in your NER.

I am suspect to the F55 table and/or custom DD items. If they are different on your server than your FAT - thus the issue. Is there an opportunity to redeploy the file specs (not generate the file) to the server and the client?

Daniel

I think the build works on all FAT clients that we tested it on so far

Just to clarify, are you saying teh client build does not work when run on the deployment server or are you saying that it is a server build that is failing. I read it as being the client side is failing on the dep server but not when run from a client - is that right?

On a FAT client,evertyhing is fine

When it's built on the deployment server, then it doesn't work. If we do a get and then build it again on our FAT client, it works again

So it doesn't work when we build it on the deployment server

So the client build R9621 fails on the dep server but works on fat clients. I would suggest that you check your compiler versions for differences and also try to assemble on a fat and then build on teh dep server. Then check the logs for the build (i.e. the build.log and the jde.log) to see if anything untoward is reported.

If this still doesn't work, try the same thing again, but build when logged into the appropriate environment on the dep server (i.e. in DV7333).

Do other packages build OK on the dep server?

Hi DBohner
thanks for helping me out

my System specs:
Xe Coexistent(A73 12), Update2 SP21
Database DB2/400 & SQLServer
Enterprise/Application 2x AS/400V5R2 & W2K
DeploymentServer NT, Citrix and JAS(test).


I tried using the specs from deployment server to build on my FAT, but then the BSFN still worked and I got correct results... (those 6 files are glbtbl*2, ddtext*2 and dddict*2 ?)

Check for the presence of a "BusObj" folder under the path code directory on your deployment server. For instance if you are building an update package on the deployment server and are logged into the DEP7333 environment, you may find this folder under the PLANNER path code. If you are on the deployment server logged into the PD7333 environment, you may find this folder under your PD7333 path code.

x:\JDEdwardsOneWorld\B7333\PD7333
x:\JDEdwardsOneWorld\B7333\planner

This folder gets created and normally deleted on any machine where a package build is executed. Sometimes it is left hanging around. This has been known to cause BusBuild compile errors. It might be your issue.

Please refer to an old thread where I discussed this in further detail.

http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=OW&Number=31863&page=&view=&sb=&o=

This could account for the diffence between the fat client build and deployment server build.

Regards,

assemble on fat and build on dep server is the way we normally build our things, so this already happened

This is afaik the first package that we have this problem with, all others work great

For clarity - since we seem to be getting questions about build failures, and not the initial issue: The issue is that a BSFN provides one response on the FAT and a different response when run on the Server. It is not inherent to a build issue.

When you can - validate that all objects are in the package, rebuild / deploy to both fat and server. validating that all custom DD items are replicated, all custom files are deployed and the latest BSFN is the same.

regards,

Daniel

You also should check where that BSFN is mapped to run (OCM Mappings).

Just wanted to let you all know that testing will go on on monday...

BusObj wasn't empty and we changed some others things that were suggested in this thread, so we will see monday if anything helps.

Thanks for helping out so far!

Hello again all

We found a BusObj directory that was still there, but after deleting it and rebuilding, we still have the same problem *sad*

Why bother with the deployment server? You can really do everything from your FAT Client without even touching the deployment server. I do the builds and installs direct from a FAT Client Build PC and only go to the deployment server for ESUs. This applies for Full Builds as well as updates. I never touch the deployment server as there really is no need to.

The primary reason I will usually build full packages on the deployment server is performance. You are manipulating about 2 GB worth of spec files and accessing about 8,000 C source files and associated header files. This will always be faster using local disk than redirected network I/O. I can't give an exact speed improvement but my finger in the air measurement is at least 10% quicker. Sure its only an hour or so saved but and hour is an hour.