JDE Object Analysis

Have you ever wanted to know which module in JDE is the most complex?  Which one has the most modules, the most complexity or the most code?

No…  Neither have I.  But not that I’ve created the report, I find it pretty interesting.

You can go here and slice and dice some default data using my interactive dashboard:

https://datastudio.google.com/open/12saO6vlYu7NQGV5SbgGyLJjYzIVvvewd

Make sure that you look at the report, there is so much more data in the interactive report, allowing you to filter and control the results.

This report does a lot more than what the surface indicates.  As it's actually created a unique hash of the code behind the scenes, so this allows me to compare the code between pathcodes or back to JDE to see what has actually changed at my site.  This is going to prepare me for continuous delivery.

But, this also shows the power of dataStudio from google and how a moving report is SO much more valuable than a static one.

This has 4 main pages;

The first page compares the amount of code (yes, I really want to tell you how I got this), the number of controls – yes, I also want to explain how I did this.  Take the size of code to be relative, but I’s a sum of all the “code” like objects that are stored as blobs – this includes source code for BSFN and BSSV.

I could have used a logarithmic scale to see the control count better.  I put this on page 4.

There was actually some SQL over the top of the all of the central objects files (F987*) to determine all of this.  Looking at BLOBs.

The second page is all about how many objects in each system code, try the filters out, very cool.

Finally, I have a pie chart, just because I like pies.  You'll need to go and look at that one.

This is a good summary of relative complexity of modules in JDE.  No amazing and actual value, but if you were to compare with what you actually use, then it started to get interesting!

If you want to look at your data, which can include custom system codes, this is a fairly trivial task to execute.

JDE PrintQueue using EFS? Sure, but how much space do I have?

Think I have enough room in my printqueue?

We store the printqueue in EFS for a number of reasons, but are we going to run out of space?

df-km

Filesystem                                         1M-blocks  Used     Available Use% Mounted on

/dev/nvme0n1p2                                         30708 19233         11476  63% /

devtmpfs                                                7690     0          7690   0% /dev

tmpfs                                                   7711     0          7711   0% /dev/shm

tmpfs                                                   7711    17          7695   1% /run

tmpfs                                                   7711     0          7711   0% /sys/fs/cgroup

tmpfs                                                   1543     0          1543   0% /run/user/1001

fs-0be57732.efs.ap-southeast-2.amazonaws.com:/ 8796093022207 10166 8796093012041   1% /jdedwards/e920/EFSPrintQ

tmpfs                                                   1543     0          1543   0% /run/user/1002

tmpfs                                                   1543     0          1543   0% /run/user/1000

8796093012041 Mb, or 8796 petabytes

That is going to take a while to fill my PrintQueue!

never underestimate the power of stderr

JDE debugging is lots of fun, especially on Unix based environments.  No irony, I seriously like it.

What especially rings my bell is the fact that the OS is nice and basic and you can find things easily.  I want to talk about 2 specific items that CNC people often miss when dealing with logging on Linux / Unix.

Firstly, the root dir for anything dodgey is $SYSTEM/bin64 ($SYSTEM is an environment variable that is defined for the user that runs the JDE services).  So if you are looking for output files that are not in the correct place or other strange things (see below)

-rw-rw-r--.  1 jde920 jde920   29639 Mar 18 15:25 \JDEdwards\E910\output\WorkOrders\CPG\WO_20500305_20190318_152535.csv
-rw-rw-r--.  1 jde920 jde920   29639 Mar 18 15:25 \JDEdwards\E910\output\WorkOrders\CPG\WO_20500305_20190318_152539.csv
-rw-rw-r--.  1 jde920 jde920   29639 Mar 18 15:25 \JDEdwards\E910\output\WorkOrders\CPG\WO_20500305_20190318_152543.csv
-rw-rw-r--.  1 jde920 jde920   29639 Mar 18 15:25 \JDEdwards\E910\output\WorkOrders\CPG\WO_20500305_20190318_152546.csv
-rw-rw-r--.  1 jde920 jde920   29639 Mar 18 15:26 \JDEdwards\E910\output\WorkOrders\CPG\WO_20500305_20190318_152608.csv
-rw-rw-r--.  1 jde920 jde920   29639 Mar 18 15:26 \JDEdwards\E910\output\WorkOrders\CPG\WO_20500305_20190318_152612.csv
-rw-rw-r--.  1 jde920 jde920   29639 Mar 18 15:26 \JDEdwards\E910\output\WorkOrders\CPG\WO_20500305_20190318_152616.csv
-rw-rw-r--.  1 jde920 jde920   29639 Mar 18 15:26 \JDEdwards\E910\output\WorkOrders\CPG\WO_20500305_20190318_152630.csv
-rw-rw-r--.  1 jde920 jde920   29639 Mar 18 15:26 \JDEdwards\E910\output\WorkOrders\CPG\WO_20500305_20190318_152636.csv
-rw-rw-r--.  1 jde920 jde920   29639 Mar 18 15:26 \JDEdwards\E910\output\WorkOrders\CPG\WO_20500305_20190318_152637.csv


Okay, so we have found the missing export files, they are using the windows \ not / and therefore are created under the root directory.

Secondly, $SYSTEM/bin64/jdenet_n.log is a valuable place for stderr.  What is stderr you ask?  Well, I refer to google for a good answer.  But in simple terms it's all of the OS errors that you generally do not see in stdout.

For example, I was recently chasing a little problem around about an OSA.  And specifically whether JDE could load a 32bit OSA using a 64 bit version of  JDE...   Any guesses?

LoadLibrary - dlopen: No such file or directory
/jdedwards/e920/system/lib/libFSosa.so: wrong ELF class: ELFCLASS32: No such file or directory
libFSosa.so: No such file or directory
LoadLibrary - dlopen: No such file or directory
/jdedwards/e920/system/lib/libFSosa.so: wrong ELF class: ELFCLASS32: No such file or directory
libFSosa.so: No such file or directory
LoadLibrary - dlopen: No such file or directory
/jdedwards/e920/system/lib/libFSosa.so: wrong ELF class: ELFCLASS32: No such file or directory
libFSosa.so: No such file or directory
LoadLibrary - dlopen: No such file or directory
/jdedwards/e920/system/lib/libFSosa.so: wrong ELF class: ELFCLASS32: No such file or directory
libFSosa.so: No such file or directory
LoadLibrary - dlopen: No such file or directory
/jdedwards/e920/system/lib/libFSosa.so: wrong ELF class: ELFCLASS32: No such file or directory
libFSosa.so: No such file or directory
LoadLibrary - dlopen: No such file or directory
/jdedwards/e920/system/lib/libFSosa.so: wrong ELF class: ELFCLASS32: No such file or directory
libFSosa.so: No such file or directory
LoadLibrary - dlopen: No such file or directory
/jdedwards/e920/system/lib/libFSosa.so: wrong ELF class: ELFCLASS32: No such file or directory
libFSosa.so: No such file or directory

Well, that would tell you the answer - NO!

The interesting thing that you need to remember is that this is NOT in the jde.log for the UBE nor was it in the debug logs, all we got was:

Apr  3 12:28:27.740781  winansi.c1737    -      LoadLibrary("/jdedwards/e920/system/bin64/libFSosa.so")
Apr  3 12:28:27.740793  winansi.c1737    -      LoadLibrary("/usr/java/jdk1.8.0_192-amd64/jre/lib/amd64/server/libFSosa.so")
Apr  3 12:28:27.740799  winansi.c1737    -      LoadLibrary("/usr/java/jdk1.8.0_192-amd64/jre/lib/amd64/libFSosa.so")
Apr  3 12:28:27.740803  winansi.c1737    -      LoadLibrary("/jdedwards/e920/system/lib/libFSosa.so")
Apr  3 12:28:27.740826  winansi.c1737    -      LoadLibrary("/jdedwards/e920/system/libv64/libFSosa.so")
Apr  3 12:28:27.740830  winansi.c1737    -      LoadLibrary("/oraclient/product/12.2.0/client_64/lib/libFSosa.so")
Apr  3 12:28:27.740836  winansi.c1737    -      LoadLibrary("/oraclient/product/12.2.0/client_64/lib/libFSosa.so")
Apr  3 12:28:27.740840  winansi.c1737    -      LoadLibrary("/usr/java/jdk1.8.0_192-amd64/jre/lib/amd64/server/libFSosa.so")
Apr  3 12:28:27.740845  winansi.c1737    -      LoadLibrary("/usr/java/jdk1.8.0_192-amd64/jre/lib/amd64/libFSosa.so")
Apr  3 12:28:27.740849  winansi.c1737    -      LoadLibrary("/jdedwards/e920/system/lib/libFSosa.so")

As you can see the debug logs were not enough.

The wonderful command that spits this source of truth is found in RunOneWorld.sh
...
print "     Starting jdenet_n..." >> $LOGFILE
cd $SYSTEM/$BIN_FOLDER
$SYSTEM/$BIN_FOLDER/jdenet_n > $SYSTEM/$BIN_FOLDER/jdenet_n.log 2>&1 &

Awesome, see the 2>&1  that is the important line.  This is saying that any OS errors, please send them to the $SYSTEM/$BIN_FOLDER/jdenet_n.log file.

Awesome.  Because runube is essentially started from the environment of a kernel, then it inherits the same settings, despite being a separate PID.

See more here https://www.computerhope.com/jargon/s/stderr.htm

Stderr, also known as standard error, is the default file descriptor where a process can write error messages.
In Unix-like operating systems, such as Linux, macOS X, and BSD, stderr is defined by the POSIX standard. Its default file descriptor number is 2.
In the terminal, standard error defaults to the user's screen.

So, as someone funnier than me just said, we don't have a big problem - we have a bit problem!  We need a new OSA for this bad boy to work.