10.4 is D3 Windows FSI architecture over Linux, not Windows. The main differences:
1) Almost everything is stored in the local file system (FSI = File System Interface) and not the VME blob. A good consequence of this is that you no longer have to allocate a disk partition or logical volume for D3. In the Linux file system there would be a /usr/lib/pick/database directory with subdirectories for each D3 account, each containing subdirectories for each dict-level file in that account, each containing subdirectories for each data-level in that file, each containing the D3 data file itself in main and overflow files with indexes in separate files (.D3C, .D3T, .D3O, .D3X). The data structure within those files is extremely similar to the 10.3 VME blob where you have frames containing your data hashed to the appropriate frame.
2) D3 is a single multi-threaded Linux process instead of each PIB being a separate Linux process. This actually makes it faster, but introduces some problems, like memory leaks, LOGOFF (XK vulnerabilities, et al. This also means that all the PIBs share the same environment, meaning some commands like "cd" and "environ" affect ALL PIBs, not just yours. Doing this in a program may not work on 10.4, as it did on 10.3. Example:
cfunction unix.builtin
include dm,bp,unix.h fcntl.h
execute "cd /mypath"
fd = %open("myfile" ,O$RDWR)
n = %write(fd,"Stuff",5)
During the execute of this program, if another PIB does a CD after your PIB does the CD but before your PIB does the %open, your program will open the file in the unexpected path. A better solution in this example would be to NOT use CD and rather fully-path the %open statement:
fd = %open("/mypath/myfile" ,O$RDWR))
It is a good idea not to change the current working directory of the d3vme process. The same issue is true with UNIX environment variables, as they are all shared by all PIBs.
3) A consequence of the this new architecture is that the VME is much smaller since it does not contain the bulk of the user data. Also, there are workspace leaks like in D3 Windows, which often necessitates VME restores to recover surrendered VME workspace. A VME save & restore does not take a long time, not nearly as long as a traditional D3 Linux save & file-load, but it does require scheduled downtime for D3 Linux customers who may or may not be accustomed to that necessity.
4) Entering D3 from a Linux prompt is now different. Instead of "d3" from a Linux prompt, you use "d3tcl". This is not a big deal unless you have a gazillion scripts using "d3". NOTE: auto-xinet has been modified to use "d3tcl" instead of "d3" for 10.4.
5) Triggers (callx, callr, et al) and/or any programs containing %cfunctions (%read(), %write(), et al) must be flash-compiled. For programs containing %cfunctions, the list of built-ins (include dm,bp,includes) has changed:
Supported built-ins include (10.3):
• unix.builtin
• common.builtin
• socket.builtin
• py.builtin
• user.builtin
• nt.builtin
• fsi.builtin
• fsicli.builtin
Supported built-ins include (10.4):
• unix.builtin
• common.builtin
• socket.builtin
• py.builtin
• user.builtin
• gm.builtin
6) When upgrading ANY version to ANY version, you need to run compile.flash.all (ow from TCL in the DM account, then take the "all" option when prompted for an account. This will find all programs on the system that were flash compiled and re-flashes the P-code. The "w" option eliminates the original compile of source, so source does not need to be loaded on the system.
7) Compressed pseudo floppies are not yet supported, so you need to use a standard-density single-file pseudo tape device which impacts Linux disk space as the compressed are about 4 times smaller. This also affects migrating data from an earlier version of D3 Linux, in which case you would need to create a standard-density file-save on the system from which you are upgrading. Also, tape devices are now stored at the end of the /usr/lib/pick/D3Vme.ini file in this form:
[d3vme.tapes.1]
name = /backup/monday
type = p
density =
fixedblocksize =
8) You can now manually alter other settings, like the number of PIBs, in the /usr/lib/pick/D3Vme.ini file. NOTE: the "telnetrange" and "serialrange" concepts are not supported yet, but work is being done to include that functionality.
9) Make sure your /usr/lib/pick/database directory is mounted in a logical volume.
10) Hot-backup architecture is now FSI hot-backup like D3 Windows. This is all-pull architecture where the primary logs transactions in a queue file and the secondary has phantom processes that pull those transactions from the primary to the secondary, apply those transactions, then delete the transactions from the primary's transaction queue file.
11) Regarding FlashConnect, two issues:
• The latest version of the WWW account (3.9.1) must be loaded in the FSI, not the VME.
• Programs must be flash-compiled. They will not run non-flashed on 10.4 Linux (or Windows for that matter). When you restore the latest version of the WWW account to the FSI and log thereto, you will be asked if you want FlashConnect to run flashed. Be sure you take that option. Also make sure that any of your programs/subroutines called in a FlashConnect context are flash-compiled.
12) Some VME commands have not (yet) been implemented in the FSI. CHECK-FILE is one of them. There is no formal list of these commands, but as part of your upgrade testing, you should log into an FSI account and try some of the TCL commands that you're used to using or are executed from PROCs or BASIC programs to make sure you're not vulnerable.
13) Currently there is a LIST-LOCKS timing issue that can cause aborts. This will be fixed in the 10.4.1 release (along with other things), so it is recommended that the current installer (10.4.0.1) be run on a test environment, but not go live on that release. 10.4.1 is expected to be released in September 2026.
