General instructions on updating a JFORCES development system.

There are two parts to updating a JFORCES development system,

  1. Code and support data

  2. Database updates.

Most users will only want to update the code and will want to update their database structures directly. For this reason this document is devided into two parts.

Updating Code & Support Data

Basically this consists of updating everything from CVS and then rebuilding the system. To do this:

  1. Update your CVS modules. Hopefully you know which modules these are, but the following command should generally work:

cd; cvs update; cd $BITMAP_DIR; cvs update

You should watch the cvs update results and verify there are no conflicts. These are marked with a "C" at the beginning of the line. If there is one or more conflicts you'll have to fix them manually. Generally this means that editing the file and fixing the code. CVS leaves markers for code with conflicts in the following format:

( code without conflict)

>>>>>>>

(code snipet 1)

=====================

(code snippet 2)

<<<<<<<<<<

(continuing code without conflict)

It's up to you to decide which code snippet to use (1 or 2), or to merge them together however you think needs to happen.

Occasionally you'll find that CVS finds huge conflicts in files that you didn't intentionally modify. This most often occurs in the autogenerated files found in the scripts directory. Specifically, these are C_FOR_DECLARATIONS, C_FOR_STRUCTS, DA_TABLE_FIELDS, DA_TABLE_LIST, DATA_DICTIONARY, ENTITY_RELATIONSHIPS, ICD_MASTER and TCL_FILE_DESCRIPTIONS. If you see a conflict in one or more of these and you know that you haven't updated the file try this instead

cd ~/scripts; rm C_FOR_STRUCTS; cvs update C_FOR_STRUCTS

If one of the other files is at fault, replace C_FOR_STRUCTS with the offending filename. This will remove your version of the file and get a fresh copy (with no possibility of conflict) from CVS.

  1. Rebuild the system. Typically, start with the simplest approach by just typing:

    big_make

Wait for the sysetem to rebuild and then try to run. If you have a problem do the following.

First, make sure the definitional tables are properly loaded. To do so, make sure the source files are available by typing :

cd ~/scripts; wc [A-Z]*

If any of the files are empty, you've got a problem. Usually the solution is to reload the offending file from CVS by removing your copy and updating. For example:

cd ~/scripts; rm C_FOR_STRUCTS; cvs update C_FOR_STRUCTS

If all of the files look OK, test that you didn't have a problem loading the files into the database. To do this type:

copy_definitional_tables restore

This should generate a lot of output but no errors. If there's an error this must be corrected before proceeding.

Finally, check the make in the key directories. To do this verify there are no errors in any of the following four steps:

To test the simulation build:

cd sim; make

To test the receiver build:

cd rcvr; make

To test the menu build:

cd ~/wn; make

To test the map build

cd ~/forcesMap; make

Hopefully this will isolate the problem.

Database Updates

If you don't have any data on you machine you care about you can just replace the databases on your machine with the databases on the FORCES server. To do this

  1. Download the databases from the JFORCES server. To do this type:

ftp (Get Current Site From JFORCES Rep)

user username anonymous, password (your email address) when prompted.

Change the source directory by typing:

cd pub/postgres_support

checkout the available databases by typing:

ls *.gz

Download them by typing:

hash

prompt

mget *.gz

Then log off the ftp session

bye

  1. Then load each of the databases into your installation. To do this perform the following for each downloaded database (replace tactical in the following lines with the database you want to load).

Guzip tactical

dropdb tactical

createdb tactical

psql tactical < tactical > /dev/null

  1. Remember to confirm that you have defined an ODBC entriy for each database in your ~/.odbc.ini file. Click here for more information.

Updating a database

More typically you'll want to update the structure of your database without overwriting the contents. To do this download and execute the appropriate patches. Hopefully you received emails describing each of the updates and the implications. If so, review that data before blindly executing the updates. In general, the approach for downloading and installing the patches is

1) download the patch. To do this type:

ftp (Get Current Site From JFORCES Rep)

user username anonymous, password (your email address) when prompted.

Change the source directory by typing:

cd pub/postgres_support/patches

checkout the available databases by typing:

ls

The files ar organized by date and database table(s) impacted. For example the file "2001_11_8_tankinglist" was created on November 8th, 2001 and impacts the tankinglist database table.

Download any selected patches by typing:

hash

get (patch name 1)

get (patch name 2)

...

Then log off the ftp session

bye

  1. Review the patch. If you're lucky theres a description of the patch in the patch header - you'll be able to recognize it because each line will start with a '--'. But more likely the only patch documentation was sent with the original email. If you don't have this you'll have to review and evaluate the patch yourself.

  2. Install the patch. Generally (unless directed otherwise by the patch documentation) you'll run the patch against the database using psql; for example:

psql tactical < 2001_11_8_tankinglist

Remember that patches against the master database (adilib) should be run ONLY against the adilib database and scenario databases (like the example) must be run against EVERY scenario database. Remember that to get a list of all databases (assuming you're running psql) just type:

psql adilib

\l

This will provide you with a list of currently loaded databases. Presumably you'll konw which ones are scenario databases.