SP23_W1 AS/400 installation

A couple of beauties from this simple upgrade:


I noticed that the install instructions for SP23 are wrong, and I thought that I would tell you. There is a section which says that if you are upgrading from < SP22, you need to FTP the printqueue members from the old to the new.

The CD and LCD commands in that section are mixed up.

You need to:

CD B7334SYSBK
LCD B7334SYS
BIN
MGET PRINTQUEUE.*

The instructions say:
LCD B7334SYSBK
CD B7334SYS
BIN
MGET PRINTQUEUE.*

Note that GET does get from CD (foreign dir) to LCD (local dir)


And another one:

Users could not run jobs after applying the new servicePack. Note that this was really strange. The Jobs WERE running, but they could not write to the F986110 or select from the F986111.

The other very strange thing was that the first one DID work. This must have been because the selection to the F986111 failed to get a next number, and it inserted a record with a blank job number in the F986110. Ironically I could see the record, because this was the only record in WSJ for this user. I did not notice that the job number was blank (i.e. no sequencing for 1 record!!). Totally fortuitous that it worked the first time, crazy.

Got error OS40002001 -803 in the UBE kernel jde log files.

1) Add the following line in JDE.INI on server to disable
CLI SQL Server mode-
[DB SYSTEM SETTINGS]
sqlServerMode=0
NOTE: If the customer is not running vertex or running
older release of vertex which does not require CLI SQL
server mode and the customer is running 8.11 SP1 and
below
application release, customer can disable server mode
using
the sqlServerMode = 0 in the jde.ini
2) Stop E1 services on enterprise server (ENDNET).
3) Stop Extended Dynamic Remote SQL (EDRSQL) server (
i.e.
ENDTCPSVR SERVER(*EDRSQL)
4) Start all services: EDRSQL, i.e. STRTCPSVR SERVER(*EDRSQL
) and EnterpriseOne Service (STRNET).

Might have found the answer to the above, you'll never believe it

so, I told you that it was strange... I also told you that I thought I've seen it before (not too sure about that now).

https://metalink3.oracle.com/od/faces/secure/km/DocumentDisplay.jspx?id=659174.1&h=Y
SOLUTION:
The NIC driver on the deployment svr was out of date. After updating it to the latest version of the driver from the vendor svr pkg's can now be built successfully from the deployment svr.

Case #SRX070813601731 was opened with Microsoft and SAR # 8729592 was created for this issue.

It was found that problem was with the network card. Customers need to update the network card. This was the issue where system try to send data, but the OS call send() would return failure even when all the data had been received on the other side of the socket. In 5 separate customer cases, each of the customers updated their network card drivers and it appears to have resolved the issue. The 2 network cards in issue are Broadcom BCM5708S NetXtreme II GigE and HP NC373i.

Full package only sending 10 header files

Man, this is a good one. The full server package is not sending all of the header files, just 10. I think that the problem is that I'm running the package from a web server and there are some conflict with all of the ports - well 6014 to be precise. I've changed all of the listener ports and I still get the same problems.

I've got a very strange feeling that I've had this problem before... Very strange feeling... And when I find it, I'll probably regret posting this...