This guide tells you how to install and configure DP4 for Unix or Linux, and other similar operating systems such as AIX. It also covers operational considerations particular to the Unix environment, such as program development with QA Build and DP4 C, working with Unix printers and copying files to and from Unix. In general this document's use of the name Unix should be taken to include all of the supported Unix-like operating systems. Similarly the name DOS is used to refer both to MS-DOS, and all (Intel based) varieties of Microsoft Windows including Windows NT)
Please note that if you are upgrading from release 4.523 to release 4.525, any C applications you have built yourself need to be recompiled and relinked with the new DP4 C Libraries. 4.523 DP4 binaries will not run against a 4.525 DP4 for Linux installation, because of fundamental changes to various parts of the DP4 architecture. There are no source code incompatibilities.
If you are used to using DP4 for MS-DOS or Windows, you will not have any problems running on Unix or Linux. However if you are not used to Unix or Linux at all the underlying operating system may be rather daunting. You may like to refer to our Novice's Guide to Unix and Linux.
DP4 is available on a wide range of Unix and Linux platforms.
On Intel processors, the complete DP4 toolset is available as below:
As of release 4.525 support for Unixware 2 and NCR3000 variants is dropped, and SQL support is included in base DP4 so there are longer any SQL packages. Open Server 5 software will be supported on current ibcs 2 compatible flavours of Unix, but not on obsolete versions of Unix. As far as we know none of our current Intel variants run on Intel Solaris platforms.
On non-Intel processors, DP4 'MixNet' server implementations are available. These provide the database server components, networking interfaces and selected utility programs only (usually including QAB, Report Writer and Importer). Other DP4 utilities can be accessed from workstations using the network facilities.
We discourage you from writing your own DP4 C programs to run on non-Intel servers as DP4 programs must adhere to strict standards to work correctly in such environments. Nevertheless the C programming libraries are available if required on such platforms. ADCs are not officially supported on non Intel platforms.
Versions of DP4 exist for the Sun Solaris, DG Aviion and various other machines.
All the DP4 Unix packages are supplied on the DP4 CD ROM.
Up to and includeing release 4.523 DP4 must be installed in /usr/datafit/ and associated sub-directories. After installing, it is possible to move most files elsewhere and use the DP4 system setup utility, DFSETUP, to match the new directory structure. From release 4.525 there are no restrictions on where you install DP4. We suggest that you use a suitable subdirectory of the opt directory, for example /opt/dp4.
DP4 Unix packages are supplied as tar archives. The tar command is used to read the DP4 files from the install media.
On the DP4 CD ROM individual Unix/Linux packages are supplied as tar files with the same name as the package in
the Unix sub directory for the version of DP4 being installed. For example the
4.520 programs are contained in \520\unix. Any Unix machine should be able to read the DP4 CD ROM directly (if you can
work out how to mount the CD ROM!*). However, you may well find it easier to
transfer the files to the Unix machine via the
ftp
utility, (assuming the target machine is configured as an ftp server).
If you do this remember to set the transfer mode to binary with the
bin
command before transferring files.
If you are using the standard Windows version of ftp it is a good idea to
specify the filename twice when using the put command like this:
put linxsuse.tar linxsuse.tar
If you do not do this the file will probably be transferred as UNXSCO.TAR.
*Typical commands for mounting the CD ROM would be
mount −o ro /dev/cd0 /opt/dp4/cdrom (on Unix)
mount −o ro /dev/cdrom /opt/dp4/cdrom (on Linux)
You will probably need to login as root in order to do this, and you will need to use mkdir to
create the /opt/dp4/cdrom directory if it does not already exist.
It is essential that you perform the installation procedure in the correct order, as outlined here:
You must export the User list from the existing system database. This is the list of users and their passwords as set up using MENUUSER.
Run menuedit -db systemPrint the user list to a file, so that you can re-load the information when the new system is loaded
Print the device information to a file
It is advisable to log in as root prior to installing DP4. If you do not do this it is possible that certain files may not be installed, or that permissions will not be set correctly. Make sure no DP4 programs are running before upgrading an existing installation.
This step is only required when installing 4.523 or an earlier DP4 release, and should be skipped if you are installing 4.525 or a later release.
Using system administration procedures, add a new user called "datafit", whose home directory is /usr/datafit/ . You do not need to give this user special privileges. A typical procedure would be as follows:
To create an account for a new user, type:
useradd −m −d /usr/datafit/ datafitThis creates a login account for a user logging in as "datafit". The −m and −d command tails define and create a default home directory called " /usr/datafit/ " for this user.
On some versions of Unix the default home directory for a user called datafit may not be /usr/datafit. It may be /home/datafit or something similar. It is not absolutely necessary to install DP4 in the /usr/datafit directory. However the DP4 licence file for release 4.523,datafit.sys, file MUST be acceible using the name /usr/datafit/datafit.sys. You can use the ln command to make it appear that DP4 is installed in /usr/datafit (e.g. ln −s /opt/dp4 /usr/datafit ).
If you are installing DP4 for the first time on a machine you need to install a DP4 licence file (dp4.sys from release 4.525, datafit.sys in earlier releases). For subsequent installations you can continue to use your existing licence file. The licence file must be present for DP4 to function correctly. If you are planning to install DP4 in an identical configuration on many machines you may prepare a modified licence file that has been suitably preconfigured, which can be installed by any means you choose provided the licence file is created in the correct location with appropriate permissions.
You may have been supplied with a Unix format diskette containing your DP4 licence. Such diskettes were supplied at a time when the DP4 licence file had to be installed as /usr/datafit/datafit.sys. Therefore the following instructions assume you are installing DP4 in /usr/datafit. If you are installing release 4.525 and don't want to install in /usr/datafit we suggest you follow these instructions, and then use mv to move the licence to the correct location.
If your licence diskette is readable on a DOS or Windows PC, then you do not have a Unix licence diskette, and you should use FTP to transfer the DP4 licence file to the appropriate location on the Unix machine.
To install a DP4 licence from a Unix format licence diskette proceed as follows:
Log in as "root" (or another user with similar privileges). Change directory to /usr/datafit/
Insert the diskette that holds the DP4 licence file into the diskette drive and use the appropriate command to extract the tar file containing it, e.g. tar -xv on Unix or tar -xPvf /dev/fd0 on Linux. Files on this disk are restored to /usr/datafit/ . Among these is datafit.sys
Now DP4 licence files will normally supplied via e-mail, or possibly on an MS-DOS format diskette, and you should use binary mode ftp to transfer the file to the appropriate location on the Unix machine, i.e. /usr/datafit if you are installing 4.523 or an earlier release, or the directory where you wish to install DP4 if you are installing 4.525 (e.g. /opt/dp4).
You can convert a DP4 licence file for another operating system to one for Unix/Linux by the following method:
Transfer the modified licence file to the appropriate directory on the Unix machine, e.g. using binary mode ftp.
Once the DP4 licence file is installed (and the datafit user has been created if necessary) you can install the base system, including the DP4 for Unix programs and the system and base dictionary databases.
If you are installing from the tar files on the DP4 CD ROM and have already transferred the appropriate tar file to your Unix machine extract it like this:
tar −xvf filename.tar
If you are installing files downloaded from the DP4 FTP site you will have probably downloaded .gz files. Use gunzip to extract the .tar file from the .gz file.
You can omit the v option if desired, (v causes the filenames to be echoed to the screen as they are restored). Replace filename.tar with the package name of the appropriate set of DP4 programs for your computer, e.g. unxuw7.tar or linxsuse.tar. If you are installing release 4.523 or earlier on Linux (and possibly some versions of Unix), you need to use this command instead.
tar −xPvf filename.tar
The P option prevents the tar utility from removing the leading / from the absolute paths stored in the TAR files. If it is not used tar will restore files to the wrong location.
If you are installing 4.525 or a later release the .tar files contain only relative path names such as bin dbs, so tar must be run from the DP4HOME directory, and there is no need to specift the -P option.
In either case the files are installed into the following subdirectories of your base installation directory:
bin/ Contains the DP4 Unix or Linux programs.
For release 4.523 or earlier you are recommended not to change the location of the terminal manager (trm3) and database manager (srv3) files if you have a requirement to run programs converted from MS-DOS using EXE2UNIX. Such programs expect these files to reside in /usr/datafit/bin/
dbs/ Contains the database data and index files (system and base dictionary). N.B. These databases are always installed into these directories. If you decide to keep databases elsewhere you will have to move them manually to the correct locations after the installation. It is particularly important to remember to do this if you upgrade an existing installation to a new version of DP4, otherwise you may end up using an out of date version of the system database.
If you are installing on Linux and want to install support for large database files, then transfer the linlfs.tar file to your installation directory and extract it, exactly as you did the linxsuse.tar files.
Once you have installed the base set and before installing any other DP4 packages you must run the dp4install program by typing:
./dp4install
All DP4 packages come with a dp4install program, which generally just tries to ensure that file permissions are correct. Up to release 4.523 all files are changed to be owned by the datafit user. From release 4.525 the dp4install file does not change the ownership of files, so you may need to run chown and chgrp after the installation has completed to set an appropriate owner for the files - (the tar files on the installation media cannot have the correct owner as they are created on another system).
For release 4.523 the dp4install provided with the base system also checks you have correctly created the 'datafit' user and, if you have, creates a number of subdirectories, for the different classes of DP4 files:
dp4install also sets up your environment, like this:
The /usr/datafit/.profile file is updated to include the path for the DP4 Unix programs directory, and to set the environment variable, DATAFIT, to specify the location of the licence file, datafit.sys . These lines are added:
DATAFIT=/usr/datafit; export DATAFIT
PATH=$PATH:/usr/datafit/bin; export PATH
The DATAFIT environment variable is not currently used by DP4! The licence file datafit.sys must be in the /usr/datafit directory! It includes the name of your organisation and licence number. It also contains the pathnames of the location of the database files, and the location of the SYSTEM database.
sysdb /usr/datafit/dbs/system
It is not an especially good idea to leave a hard coded pathname in the system database setting like this, as one or two DP4 utilities may have problems with this. However it is a useful means of forcing DP4 to run regardless of datafit.sys settings.
USERDATA is now run to create the DP4 terminal configuration file, userdata.sys . You must select a terminal type that matches your current terminal from the list of terminals it presents by typing the corresponding letter.
DFSETUP is run to configure DP4 for use. Your licence file may have been pre-configured with sensible values so you can use it immediately, but you should check the various directory assignments match your requirements in any case.
A shell script file named .dp4 is created. It modifies PATH, LD_LIBRARY_PATH, and defines DP4HOME
for the new installation. If users want to be able to run DP4 programs they should add the line:
. dp4 install directory/.dp4
to their .profile login files. For example if DP4 is installed in
/opt/dp4 the line should read:
. /opt/dp4/.dp4
In this case DP4HOME points to /opt/dp4, and PATH and LD_LINRARY_PATH contain /opt/dp4/bin. Both the DP4 licence file, dp4.sys, and the DP4 configuration file, dp4.ini, should be kept in the $DP4HOME directory. (Purists may like only to store links to these files in the DP4HOME directory, and to place the actual files in a directory such as /etc/opt/dp4)
The licence file dp4.sys contains the name of your organisation and the licence number. It also contains the pathnames of the location of the database files, and the location of the SYSTEM database.
sysdb $DP4HOME/dbs/system
It is not an especially good idea to leave a hard coded pathname in the system database setting like this, as one or two DP4 utilities may have problems with this. However it is a useful means of forcing DP4 to run regardless of current settings.
USERDATA is now run to create the DP4 terminal configuration file, userdata.sys . You must select a terminal type that matches your current terminal from the list of terminals it presents by typing the corresponding letter.
DFSETUP is run to configure DP4 for use. Your licence file may have been pre-configured with sensible values so you can use it immediately, but you should check the various directory assignments match your requirements in any case.
More information on running USERDATA and DFSETUP as part of Unix installation can be found here and on running them generally in the Configuration Utilities section of the Guide to DP4 Configuration.
Re-load the user list
Specify the filename you used when you saved the user information in place of users.prn:
mappost -db system users.prn
Re-load the device information. Specify the filename you used when you saved the device information in place of devices.prn:
mappost -db system devices.prn
If you are upgrading from quite an old version of DP4 it may be the case that some of the standard print devices have changed and should not be preserved. In this case you need to follow a slightly different procedure.
This will ensure that any "standard" devices will be defined as issued by Itim Technology Solutions.
Having installed the base system, you may install any additional products in the same way, for instance "UNIX C Programming Tools". If you are installing 4.523 components run dp4install after installing each product to ensure the file ownership is set to "datafit" (the dp4install file works by changing the ownership of files listed in the file /usr/datafit/packlist restored with each product you install.) In fact you can skip this step as long as you remember to set ownership and permission on all the files in the installation directory and subdirectories appropriately after installing all the products required.
Unix users are assigned various limits, such as a limit for the maximum number of blocks that they can write to a single file, and a limit on the number of files that can be simultaneously open. If, for example, the file size limit is set too low the DP4 database manager could report an error:
Fail error reported by DP4, code 25
Error in writing file - check disk space
Any key to continue
These limits can usually be set with the ulimit program. The default values may be too low for DP4 to work properly. Please consult your Unix documentation and set appropriate hard and soft limits as follows:
DP4 attempts to remove all such limits on itself when it loads, but it may well not be able to do so.
In Unix and Linux a variable called umask, helps define the permissions files created by programs are assigned. The permissions specified by a program are masked by the umask value to restrict access to the file. In some versions of Unix the environment variable, UMASK, can be set in the user's .profile to setup the read/write attributes for new files created by that user. In Linux, and most versions of Unix the umask is set by running in the program of the same name. It is advisable to set umask to 0. If umask is set so that one user cannot access a shared file created by another user, the database server may report a system error message:
Fail error reported by DP4, code 18
Unable to open file
Any key to continue
Where relevant the UMASK value can be set in the /usr/datafit/.profile file, with this syntax:
UMASK=0
Or by running the umask program like this:umask 0
Unix will XOR the UMASK setting with, 666, the mode specified by all DP4 programs when they create files. An important implication of this is that you must not rely on the default setting of UMASK, which is 022. When Unix XORs 666 with 022, the permissions are reduced to 644. This will deny write access to g(roup) and o(ther) classes of user
The <Esc> key will often not work with DP4, because it is generally used as a "lead-in" to the sequences generated when "grey keys" are pressed, (though pressing it two or three times in succession will work). The <F3> key is usually assigned instead. You may change this using the DP4 utility DFSETUP. The Esc key will work normally with terminal type U, which you can use if your terminal emulates a DEC VT220 in 8 bit mode.
On Linux it may be necessary to load a different keyboard mapping to get the "grey" keys to work properly if you run from a console rather than from an xterm. On SuSe Linux install ibcs support and try the following: When you install iBCS it should create a file called /usr/doc/packages/ibcs2/PROD.Patches/SCO.map If you copy this file to directory /usr/lib/kbd/keymaps/i386/ then loadkeys SCO will reprogram the keyboard so that it works properly with DP4. You can restore the default keyboard behaviour by typing loadkeys uk (or whatever the appropriate abbreviation is for your country). This file may not be provided with other Linux distributions. However if you can get hold of a copy of it it will probable work on your distribution.
An X Windows version of trm3 is available for Linux. If you use this then you should use a Windows userdata.sys (created with userdata -os windows). All grey keys work properly with this.
By default, database backup and restore is made to the bkp subdirectory of your DP4 installation. You may change this to be other locations on the file system, but you cannot make this a device (for example /dev/fd0). DP4 expects to find a file system, not a device.
The kill command is used to send a signal to specified processes. It can be used to terminate a process which appears to have hung. Most DP4 programs will respond (by terminating cleanly) to the default signal , which is signal 15 (SIGTERM). The signalled process must belong to the current user unless the user is the super-user. Refer to your Unix manual for a full description of the kill command. When you kill a DP4 program it will attempt to clean up - for example by killing its terminal manager and logging off from the database manager. In 4.523 killing a trm3 process will attempt to kill the program it belongs to (there are no trm3 processes in 4.525). You should allow up to 6 or 7 seconds for the kill to succeed. If the process has still not terminated by then you can use kill -9 to force it to terminate immediately. In this case you will need to manually clean up the program's terminal manager, and its IPC channels.
If you load any of the server or networking programs in the background, you can shut them down using the kill command, but DO NOT use kill −9 . This will terminate the processes and leave IPC channels open that will stop further DP4 programs from loading correctly.
If you are using release 4.525 you are recommended to use dbdaemon -start and dbdaemon -stop to start and stop DP4 services. dbdaemon uses the [preload] and [startup] sections of the DP4 Configuration file to decided which DP4 components to run as part of the DP4 service. If DP4 services are running under dbdaemon, either running dbdaemon -stop, or running kill against the dbdaemon pid will cleanly terminate all DP4 processes and clean up all DP4 IPC channels. For more information on dbdaemon refer to the Guide to DP4 Networking and Resilience, and relevant portions of the Guide to DP4 Configuration.
DP4 for Unix uses the inter-process communication (IPC) facilities of the operating system to pass messages between the the application programs and the database manager/terminal manager.
If your programs abort, you may need to perform tidy-up operations for processes and inter-process communication structures, as explained in this section. The DP4 C library attempts to catch signals that commonly cause programs to abort and then to clean up IPC information that could cause problems to other programs, but in some circumstances this may fail for one reason or another.
You can use the ps command to check what processes are running on Unix or Linux. ps −e prints information about every process that is running. On Linux the ps command is rather different from standard Unix, and you use ps ax instead (you can probably get away with just ps a so long as no DP4 programs are running without a controlling terminal).
You can use the ipcs command to display information about IPC, and the ipcrm to delete resources from programs that have aborted.
The details of this section are specific to release 4.523, For a version of this section appropriate to 4.525 read IPC Example(4.525). However, the 4.525 example does not cover using ipcrm in so much detail (mainly because it should hardly ever be necessary to use it.)
This example shows a DP4 application, my_app , running under Unix. To run my_app on a database called "test", you use these commands:
my_app −db test
my_app loads and executes in this sequence:
my_app loads and initialises the database server (if it is not already running)
my_app loads and initialises the terminal manager
The my_app program is ready and starts executing its own code calling the DP4 database manager or terminal manager as appropriate.
You may (on Unix and AIX) examine the process state with the following command:
ps −fu datafit
This then displays information about every process now running for the datafit user:
UID PID PPID C STIME TTY TIME COMMAND datafit 198 160 0 14:12:20 console 0:00 -ksh datafit 212 198 0 14:48:12 console 0:00 my_app /usr/datafit/applics/my_app datafit 213 212 0 14:48:12 console 0:00 srv3 -nodetach datafit 214 212 0 14:48:12 console 0:01 trm3 |
PID is the process identity, and PPID is the process identity of the parent process.
Run ipcs to display the IPC status:
Message Queues: T ID KEY MODE OWNER q 200 0x33565253 -Rrw-rw-rw- datafit q 1 0x334d5254 -Rrw-rw-rw- datafit Shared Memory: T ID KEY MODE OWNER m 400 0x33565253 --rw-rw-rw- datafit m 401 0x00000000 --rw-rw-rw- datafit Semaphores: T ID KEY MODE OWNER s 40 0x33565253 --ra-ra-ra- datafit s 41 0x00000000 --ra-ra-ra- datafit |
If my_app hangs, the system can be restored as follows:
Kill the my_app executable process:
kill 212
Wait 6-7 seconds. Check with ps if the terminal manager has terminated. If not kill the associated terminal manager process:
kill 216
Remove associated inter-process communication facilities. To do this, on Unix use the following command:
ipcrm -s 41 -s 40 -m 401 -m 400 -q 200 -q 1
where:
-q 200 and -q 1 Remove the message queue identifiers, 200 and 1, from the system and destroy the message queues and data structures associated with them
-m 401 and -m 400 Remove the shared memory identifier, 401, from the system. The shared memory segment and data structure associated with it are destroyed after the last detach
-s 41 and -s 40 Remove the semaphore identifiers, 41 and 40, from the system and destroy the set of semaphores and data structures associated with them. The various ids will vary. The DP4 IPC can usually be recognised by the key or owner.
Care should be exercised when killing processes and inter-process facilities. ipcrm should never be used when other DP4 programs are still running as you may accidentally delete information used by these programs.
Refer to your Unix manual for a complete description of the ps(1) , kill(1) , ipcs(1) and ipcrm(1) commands.
On some versions of Linux the ipcrm command works differently and you may well have to invoke it several times deleting one item at a time. Instead of -s -m etc you specify IPC objects by type name (e.g. shm). See your Linux documentation for full details
When DP4 programs are closed down cleanly almost all DP4 IPC is removed. In release 4.523 two very small items, a queue which usually has key 0x334d5254 and shared memory with key 0xdaafade3 are never deleted once created, as to do so could cause problems if two or more DP4 programs start or stop simultaneously.
This example shows the DP4 application, dfsetup , running under Linux in a user account named dp4user.
dfsetup loads and executes in this sequence:
dfsetup loads and initialises dbdaemon (if the DP4 service is not already running)
dfsetup starts executing its own code calling the DP4 database manager or terminal manager (which is a shared library and not a separate process as in earlier releases) as appropriate.
You may (on Linux) examine the process state with the following command:
ps x
This then displays information about every process now running for the logged on user:
PID TTY STAT TIME COMMAND 13788 p0 S 0:00 -bash 13801 ? S 0:00 dbdaemon -start 13803 ? S 0:00 errlog -start 13805 ? S 0:00 srv3 -AUX 13807 ? S 0:00 tcpmgr -DISPLAY_ADDRESS -AUX -DEBUG_CONNECT 13808 ? S 0:00 tcpmgr -DISPLAY_ADDRESS -AUX -DEBUG_CONNECT 13810 ? S 0:00 tcp3 -DEBUG_CONNECT -SERVER_NAME localhost 13815 p0 S 0:00 dfsetup 13817 p1 S 0:00 -bash 13832 p1 R 0:00 ps x |
PID is the process identity, and TTY is the controlling terminal of the process. None of the dbdaemon processes have a controlling terminal so they will not show up without the x option.
Run ipcs to display the IPC status:
------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x34504433 17792 dp4user 666 144 6 0x00000000 17793 dp4user 666 8320 2 0x00000000 17794 dp4user 666 9816 2 0x00000000 17795 dp4user 666 3080 2 0x00000000 17796 dp4user 666 8320 1 dest 0x00000000 17797 dp4user 666 8320 2 0x00000000 17798 dp4user 666 8320 2 0x00000000 17799 dp4user 666 8320 4 ------ Semaphore Arrays -------- key semid owner perms nsems status 0x00000000 30464 dp4user 666 1 0x00000000 31105 dp4user 666 1 0x00000000 30594 dp4user 666 1 0x00000000 30979 dp4user 666 1 0x00000000 30724 dp4user 666 1 0x00000000 30725 dp4user 666 3 0x00000000 30726 dp4user 666 1 ------ Message Queues -------- key msqid owner perms used-bytes messages 0x34504435 6528 dp4user 666 0 0 0x34504432 6529 dp4user 666 0 0 0x34504430 6530 dp4user 666 0 0 |
If you compare this information with the corresponding information for the 4.523 example, you will see that it is considerably more complex. There are two reasons for this:
Another point to note is that most of the 4.525 IPC uses private keys. Only the Message Queues and the control shared memory segment have non-private keys. This may make it quite difficult to work out which shared memory segment is which. The -p option of ipcs may help with this.
If DFSETUP hangs, the system can be restored as follows:
Kill dfsetup executable process:
kill 13815
Wait 6-7 seconds. Check with ps if the process has terminated. If not repeat the kill with kill -9
It is probably a very bad idea to try to clean up any DP4 IPC while the DP4 service is still running - any orphaned shared memory segments and semaphores will not be interfering with the operation of DP4. If you are sure there is a significant amount of IPC that has not been cleaned up when it should have been use dbdaemon -stop to kill dbdaemon, or kill the dbdaemon process (kill 13801) in this case). Wait several seconds for the DP4 service processes to terminate. If there were any other running programs they will get FAIL error 9 when they next access the DP4 database manager, but should terminate cleanly. After this you can use ipcrm to remove any remaining IPC for DP4, in the same way as was described for the 4.523 example.
If you are absolutely determined to remove IPC for DP4 programs while leaving other DP4 programs running you may find it useful to note the following points:
Traditionally DP4 used hard coded keys from its IPC. This is considered to be bad practice as there is a remote possibility of a clash with other software. In 4.523 you can make dp4 use system generated IPC keys by creating a file called dp4ftok in the /etc/ directory. A simple one line text file should be enough - the contents of the file do not matter, except that it should not be of zero size. Make sure that the file has read write access for all users (chmod 666 /etc/dp4ftok). You must make sure all your Unix programs have been rebuilt with 4.523 libraries before using this facility, as old programs will stop working.
Because IPC for release 4.525 is completely different from that for release 4.523 a different set of IPC keys are used for DP4. The default, hard-coded, keys all begin with 0x345044 on Intel computers (this is DP4 backwards). To use system generated IPC keys create a file called edp4ftok, either in the $DP4HOME directory, or in the /etc directory. As with the corresponding file for 4.523, the file can be a one line text file, but must not be of zero size, and must acccessible to all users.
When a DP4 program prints under Unix, it issues an lp command. This command is hard-coded into the terminal manager ( trm3 ); you cannot change this. It is possible to create a customised lp command that must be located in your PATH before the directory for the Unix system version of lp . Note that any such replacement must be a binary file - a shell script does not work.
The terminal manager issues the following command when sending a file to the printer:
lp -c -s -d device_name <spool_file>
device_name is either prnX (where X is an integer, 1 to 7), or user-supplied, used if you define an environment variable of the form PRNX .
In this example, DFSETUP has been configured such that a DP4 "device group", called HP_LASER_II, is attached to prn3.
DP4 SYSTEM SET UP Device Group description DG name HP_LASER_II Soft form feed ? Yes Device number 115 Null character ! Description HP LaserJet (Single Bin) Special device ? No Page length 64 Hidden device ? No Page width 78 Printer port PRN3 |
All printing through HP_LASER_II uses a Unix printer called 'prn3'.
In this example, you are installing DP4 on a Unix system that has two printers 'hplaser1' and 'hpinkjet' already configured. The DP4 programs should use the existing printers.
The terminal manager allows you to alias printer names by creating suitable environment variables in your .profile , as in:
PRN3=hplaser1;export PRN3
PRN4=hpinkjet;export PRN4
You then define suitable DP4 print devices which print to PRN3 and PRN4 respectively.
The DP4 C/C++ Programmer's Reference and QA Build Developer's Guide describe how to develop application programs. For information specific to application development under Unix and Linux see the following notes:
This section describes a number of ways to copy files between Windows/DOS machines and Unix. Some work on all variants of Unix, whilst others do not.
All DOS text files use a carriage-return/line-feed combination, CR-LF (hex 0D and 0A), to indicate a new line, and sometimes a CAN (hex 1A) at the end of the file. Unix system text files use a single LF character to indicate a new line, and sometimes an EOT (hex 04) at the end of the file. (On any platform the DP4 editor DP4ED can read files that use either convention. DP4ED always saves files in the native format for the operating system it is working on. Some Unix C compilers reject MS-DOS format files.
Some, but by no means all, Windows/DOS text editors can also read Unix text files (e.g. edit can, but notepad cannot).
In the absence of any other suitable utilities, you can use DP4 network facilities to transfer files with the NETCOPY command. See the DP4 Network Resilience Developers Manual for full details. However it is usually easy to configure Unix and Linux machines to act as ftp servers, and you can use the ftp program supplied with Windows to transfer files. There are a large number of Windows based ftp programs with a simple user interface that you can use instead of the traditional command line ftp.
The FTP program can convert files between DOS and Unix formats, and so can the DP4 version of the tar utility.
DP4 databases are identical on all platforms - you can transfer a DP4 database between any two platforms and it will work identically. If using a program such as ftp you must ensure that database files are transferred in binary mode
Itim Technology Solutions can supply a DOS or Win32 Console version of the tar utility for reading and writing tar archives. This gives an easy method of transferring files to and from a Unix file system as it can perform the conversions required for text files, and transferring one tar archive, is usually easier than transferring many small files. It also allows date and time information for the file to be preserved. We use this program to prepare all the Unix packages we issue, and to transfer the source code of DP4 onto Unix and Linux machines. The utility is fully described here.