Server Package Not Building from new Machines

PAULDCLARK

Well Known Member
Got a bizarre issue. I have a couple of new Windows 2003 SP2 Std edition servers for use on a multifoundation tech upgrade project (Oracle 9.02 to 10g, 8.95 to 8.95, WS5 to WS6 etc), to be used as testbed jas gen servers.

I am experiencing server package build problems with these machines regardless of the SP and host in use, so I know the issue doesn't lie at the Enterprise Server end.

They will happily build a package with just Specs, whether full or update packages, and will initilaise the package at the server end run paktotam etc and complete normally. But whenever I introduce BSFNs its a completely different story. The server package initilises, creates the folder structure, it even creates a STS and TXT file, and transfers up 1 or 2 BSFN .C and .H files and then stops dead in its tracks. The ent server appears to send a message to the build machine, and it doesn't seem to get there. All network config, anti-virus, firewalls, drivers, updates etc etc all seem to be fine. I've even configured HOSTS files, but nothing seems to have helped at all.

I must have build hundreds of client machines over the years, and never seen anything like it. The Server support team think that the machines are fine, and everything I've suggested checks out.

Anyone got any ideas of where else I should look? The machines are HP servers with a teamed adpater which is forced to 100Mbps, full duplex...

Thanks

P
 
Your post is a little confusing. You mention trying to launch server package builds, but also say "testbed jas gen servers".

That said, if you are trying to build server packages containing BSFN, and it's stopping, the first things to look at are the Visual C++ installation, the JDE.INI file on the server(s), and the environment variables.

1) Do you have the proper Visual C++ compiler installed? Silly question, but I had to ask. For 8.95, it should be Visual Studio .NET 2003, with SP1.
2) Do the JDE.INI on the server(s) have the proper path to point to where your compiler is installed?
3) Does the PATH environment variable contain the proper path to the Visual C++ compiler? Also, do the "include" and "lib" environment variables exist and point to the right place?

Just a starting point. If none of these help, I guess it's time to progress to debug logs.
 
Effectively the issue is with a couple of client machines, both being used for a technical upgrade, but for the purposes of this test, they are client machines running 8.95.

The JDE.INI file, complier, paths etc all check out OK, the machines will happily build a client package, they will also happily build a server package, but only if it contains Specs only. The minute it contains BSFNs it falls over, it looks, judging from the logs that the server sends a message to the client but it never gets there...
 
Sorry, I misunderstood what was happening. Anything on the server debug logs? Does your R9622 just sit there and hang, or does it just stop running?
 
I believe I have the same issue that I am seeing now. The last line I have in my svrpkgbuild.log is:

Wed Dec 19 10:46:31 - Copy Table, UBE, and data structure header files from the deployment server to the enterprise server.

It looks like it is able to copy files to the IFS on my AS/400, but the process stops after that. There is no logging that shows any errors. It just stops.

Clark does that sound like what you are seeing? We host JDE customers here and we have seen this one other time. The only way around this was to build a new standalone deployment server, whereas the one that did not work was in a blade chassis.

HTH,
Winston
 
Hi Winston,

It seems similar:

From the client side log:

Mon Dec 17 15:54:57 - Creating server.inf file for server cbyaxjdbtqs.
Mon Dec 17 15:54:57 - Server INF file created.
Mon Dec 17 15:54:57 - Transfer all BSFN related (.c, .h, .hxx) objects to server cbyaxjdbtqs.
Mon Dec 17 15:54:57 - Transferring business functions for DLL CFIN to server.
Mon Dec 17 15:54:58 - \\CBYMSE1DEP\E811\QA811\package\QABSFNTEST\source\b0100001.c transferred successfully to server.
Mon Dec 17 15:54:58 - \\CBYMSE1DEP\E811\QA811\package\QABSFNTEST\include\b0100001.h transferred successfully.
Mon Dec 17 15:54:58 - \\CBYMSE1DEP\E811\QA811\package\QABSFNTEST\source\b0100084.c transferred successfully to server.
Mon Dec 17 15:54:58 - \\CBYMSE1DEP\E811\QA811\package\QABSFNTEST\include\b0100084.h transferred successfully.
Mon Dec 17 15:54:58 - \\CBYMSE1DEP\E811\QA811\package\QABSFNTEST\source\b0100086.c transferred successfully to server.
Mon Dec 17 15:54:58 - \\CBYMSE1DEP\E811\QA811\package\QABSFNTEST\include\b0100086.h transferred successfully.
Mon Dec 17 15:54:58 - \\CBYMSE1DEP\E811\QA811\package\QABSFNTEST\source\b0125031.c transferred successfully to server.
Mon Dec 17 15:54:58 - \\CBYMSE1DEP\E811\QA811\package\QABSFNTEST\include\b0125031.h transferred successfully.
Mon Dec 17 15:54:58 - Transferring spec dependent header files to server.
Mon Dec 17 15:54:58 - Transferring business functions for DLL COPBASE to server.
Mon Dec 17 15:54:58 - \\CBYMSE1DEP\E811\QA811\package\QABSFNTEST\source\b4000040.c transferred successfully to server.

And from the server side:

Mon Dec 17 15:54:57 - Server initialized now sending message back to the build machine.
Mon Dec 17 15:54:57 - Message sent.
Mon Dec 17 15:54:57 - Creating detail file for object CFIN in package QABSFNTEST.
Mon Dec 17 15:54:57 - Source and obj directories created for the DLL CFIN successfully
Mon Dec 17 15:54:57 - Creating text file for CFIN
Mon Dec 17 15:54:57 - Created detail file /app/peoplesoft/e895/packages/QABSFNTEST/text/CFIN.sts successfully.
Mon Dec 17 15:54:57 - Detail file created successfully.
Mon Dec 17 15:54:58 - Creating detail file for object COPBASE in package QABSFNTEST.
Mon Dec 17 15:54:58 - Source and obj directories created for the DLL COPBASE successfully
Mon Dec 17 15:54:58 - Creating text file for COPBASE
Mon Dec 17 15:54:58 - Created detail file /app/peoplesoft/e895/packages/QABSFNTEST/text/COPBASE.sts successfully.
Mon Dec 17 15:54:58 - Detail file created successfully.

And it just stops dead in its tracks...

The only difference I can see on these machines is that they are running Windows 2003 Server SP2, whereas the existing machines are running SP1. However SP2 is supposed to be support for 8.96 which is the one I'm testing.

Before I get the machine rebuilt again, I'll try removing SP2 and see what happens...

Paul
 
The Fix:

Reason : In HP servers there is a utility called Network Conectivity Utility which is a virtual network. With this we can create a team from two physical networks for high availability.

In this case when the Windows SP2 is installed its installing some advanced settings in the Virtual Network properties and those are causing problem with the connection to the database.

Fix : Disable all the advanced settings which were created when SP2 is installed. To do this open NCU in the server click on HP Network Team and click the properties and click the settings tab.

1. 802.1p Qos Packet tagging - Uncheck
2. Recieve - scaling - Uncheck.
3. Large send off load. - Uncheck
 
Back
Top