jtls-2019-14357 move from oracle to postgresqljtls-2019-14357 move from oracle to postgresql zafer...

Design Plan JTLS-2019-14357 ROLANDS & ASSOCIATES Corporation

JTLS-2019-14357 Move From Oracle To PostgreSQL

Zafer Aktan, Jose Torres, Steve Tang, Jane Wu, Ellen Roland

1.0 Summary of Model Change Request

For a variety of reason, the U.S. Government has required that JTLS-GO should move completelyaway from the Oracle Relational Database Management System (RDBMS) to PostgreSQL.

2.0 Design Summary

Oracle will be replaced with the PostgreSQL for all database related functions in JTLS-GO. Theseinclude:

• The Database Development System

• Scenario Data Repository which includes the After Action Review (AAR) Database.

3.0 Detailed Design

3.1 Basic Background

PostgreSQL is a powerful, open source object-relational database system. It has more than 15years of active development and a proven architecture. It runs on all major operating systems,including Linux, UNIX and Windows. It is fully Atomic, Consistent, Isolated and Durable (ACID)compliant to ensure data integrity. PostgreSQL has full support for foreign keys, joins, views,triggers, and stored procedures (in multiple languages).

It includes most SQL:2008 data types, including INTEGER, NUMERIC, BOOLEAN, CHAR,VARCHAR, DATE, INTERVAL, and TIMESTAMP. It has native programming interfaces for C/C++,Java, .Net, Python, Perl, ODBC, among others and its own PL/pgSQL, which is similar to Oracle'sPL/SQL. PostgreSQL also supports storage of binary large objects, including pictures, sounds, orvideo.

PostgreSQL source code is available under a liberal open source license: the PostgreSQLLicense. This license gives users the freedom to use, modify and distribute PostgreSQL in anyform they like, open or closed source. Any modifications, enhancements, or changes you makeare yours to do with as you please.

PostgreSQL is not only a powerful database system capable of running the enterprise, it is adevelopment platform upon which to develop in-house, web, or commercial software products

JTLS 6.0.0.0 113 25 May 2020

ROLANDS & ASSOCIATES Corporation Design Plan JTLS-2019-14357

that require a capable RDBMS. ROLANDS & ASSOCIATES Corporation (R&A) first proposedutilizing PostgreSQL to support our JTLS-GO database tools in 2004, but given that there weresecurity related concerns at the time, we continued to use Oracle as the database server.

Unlike Oracle, which can only be obtained from one source, there are many versions ofPostgreSQL available and several sources from which it can be obtained. The R&A Design Teamseriously considered two options before selecting the Amazon containerized version ofPostgreSQL.

The options considered were:

• The company EnterpriseDB claims that their EDB Advanced Server product, which isbased on the core PostgreSQL with added custom tools, utilities, capabilities of their own(such as EDB*Loader, EDB*Plus, EDB*OCI, EDB*Wrap, PL/SQL native support, etc.),provides 90% Oracle compatibility and therefore, faster migrations.

However, EDB Advanced Server product has a special universal core based licensingmodel. It has a 4 minimum core requirement need to be licensed and there is acontinuing cost associated with using the product. Although using EDB Advanced Servermight have shorten the migration time significantly, switching from one commercialdatabase product to another commercial database, was contrary to the basic reason formaking the change.

• The Amazon containerized version of PostgreSQL, called PGSQL, which allows the freedistribution of PostgreSQL, and the easy installation of the capability without the need forsystem administration support. The following summarizes the Amazon containerizedversion of PGSQL:

a. PGSQL is a true container Open Source solution, developed and maintained by theAmazon Web Services (AWS) PostgreSQL group.

b. It is pure PostgreSQL, with no third-party software.

c. Installation is much simpler compared to the repository-based alternatives. It is assimple as unzip the distributed tar file into a subdirectory called pgsql and theninitializing the PostgreSQL and configure basic settings which is required by JTLS-GO.

JTLS-GO Version 6.0 will be delivered with the PGSQL containerized version of PostgreSQL 11.7.This version has met the Defense Information Systems Agency (DISA) Security TechnicalImplementation Guides (STIG) and can be loaded and run on U.S. Department of Defense securecomputer system without any requirement for Internet access.

We currently utilize Oracle RDBMS in two separate segments in JTLS-GO:

25 May 2020 114 JTLS 6.0.0.0


• The JTLS‐GO scenario building process, known as the Database Development System (DDS),which is used prior to game execution.

• The JTLS‐GO Scenario Data Repository (SDR) that is used to hold data generated during gameplay, such as After‐Action Review (AAR).

Each of these capabilities are discussed in the following sections.

3.2 Supporting JTLS-GO Scenario Building Process

The current DDS is a combination of Linux shell scripts, Oracle SQL scripts, a customized moduleof the Oracle GlassFish J2EE application server (DDSAS), and a Java Rich Internet Applicationclient Database Development System Client (DDSC) which is deployed through the Java WebStart. This system interacts with a certified Oracle database server and requires an Oracleaccount to be provisioned for the corresponding JTLS-GO scenario. This entire process is shownin Figure 1.

Figure 1. Current DDS Process Diagram

The new DDS will operate in exactly the same manner. The only difference being the underlyinguse of PostgreSQL. As shown in Figure 1, the following processes and procedures need to bealtered to use PostgreSQL.

• Database Load

• Database Unload

• Interaction between GlassFish and the PostgreSQL server.

JTLS 6.0.0.0 115 25 May 2020


• The JTLS Integrator (JINN) which uploads database changed created using the JTS Orderof Battle Editor (JOBE).

• Management of JTLS-GO Scenario accounts

The changes required to each of these procedures are discussed in the following sections.

3.2.1 Database Load Procedure

Currently we use an Oracle proprietary capability called SQL*Loader® to upload a JTLS-GOscenario into Oracle. Since SQL*Loader is no longer an option, the load procedure needs to beredesigned.

PostgreSQL has the COPY command, which enables the fast ingestion of bulk data into databasetables. This COPY command capability provides much better performance compared topopulating the data via SQL insert statements.

The basic flow of loading the ASCII JTLS-GO scenario data into the related PostgreSQL tables issimilar to the previous versions of JTLS-GO. For each JTLS-GO table, there is a load control filethat describes the SQL COPY command specific instructions. These files are located in the$JTLS/script/dds/<jtls_version>load subdirectory. The following is an example of the loadcontrol file, named. az.ctl, for the “altitude_zone” data table.

copy altitude_zone (az_name, az_maximum) FROM az.tbl WITH DELIMITER '/' NULL 'NONE';

The load process consists of the following steps:

• The ASCII data files are copied into the load subdirectory under the $JTLS/data/scenario/<scenario_name> directory with a “.tbl” file extensions. For example the Altitude Zonedata to be uploaded are held in a data file named <scenario_name>.az. This file will becopied into the load directory and given a name of az.tbl.

• Next the load procedure invokes the PostgreSQL command line utility “psql”, which is thereplacement of Oracle’s “sqlplus” utility, to execute every single control file (*.ctl) in thespecific order as listed in the “load_ctl” main load control file. This main control file islocated in the same directory as the individual table control files.

• The scenario data loading process, “. bad” files and related “.log” files are created underthe log subdirectory under the scenario, for those failed scenario ASCII files. Users canview these “.bad” files and the related ".log" files, to determine the cause of the errors, fixthe errors and re-load the scenario.

There is one major difference between the SQL*Loader process and the PostgreSQL COPYprocedure. Previously, if SQL*Loader found an error while executing the load procedure, it

25 May 2020 116 JTLS 6.0.0.0


continued to load the remaining records in the ASCII file. The encountered bad record wasreported in the “*.log” file and the bad record was placed in the “*.bad” file. This is not true forthe PostgreSQL COPY command procedure. Once a bad record is encountered, the remainingrecords in that ASCII file are skipped, and the process moves to the next file in the load list.

Given that the JTLS-GO data structures are highly related and inter-linked, encountering one badrecord will have significant consequences on the load procedure. Consider the followingexample. Assume that the fifth Targetable Weapon (TW) record in the <scenario_name>.tw file,which is only used by certain Surface-to-Surface Missile (SSM) Sites, was incorrectly changed byhand. This change makes it impossible to load the record into the database. Both the oldSQL*Loader procedure and the new COPY command would fail to load the record.

Now assume there are 100 Targetable Weapon records in the scenario database.

• In previous version of JTLS-GO the single bad record would have not been loaded, but theremaining 95 records in the data file would have been loaded. When loading the Surface-to-Surface missile “Can Fire” records, any records referring to the one bad TW recordwould have been reported as “bad” because the referenced TW does not exist in thedatabase.

• In JTLS-GO Version 6.0, the single bad record will also not be loaded, but the remaining95 TW records will also not be loaded. These weapons probably represent weapons thatcan be fired by not only SSM, but also by Combat Systems, and Aircraft. The result will bethat all:

a. SSM TW records referring to one of these 96 TW will not be loaded.

b. CS TW “Can Fire” records referring to one of these 96 TW will not be loaded.

c. Aircraft Loads TW records referring to one of these 96 TW will not be loaded.

As can be seen, one bad record results in a much large number of “bad” records being reportedduring the load process. The DDS download process should not create any bad records. Thissituation can only occur, if the end user creates scenario ASCII data files using a tool other thanthe tools delivered with JTLS. Still, once the record which caused the very first bad record is fixed,re-loading the scenario will fix the rest of the load. This should be repeated if there are more badrecords listed.

This new load procedure depends on ever table record existing on a single line using a CharacterSeparated Value (CSV) construct, the format of each of the over two hundred JTLS scenarioinitialization files must be changed. The slash (/) is already an illegal character within JTLSdatabases since it is the typical field divider character for United States Message Text Format(USMTF) messages which are supported by JTLS-GO. Figure 5 is a portion of the TargetableWeapon and Depth Zone data.

JTLS 6.0.0.0 117 25 May 2020


Figure 2. Sample New JTLS-GO Version 6.0 Scenario File Structure

This data file has three entries per record:

• The name of the Targetable Weapon

• The name of the Depth Zone

• The emplacement time modifier when emplacing the Targetable Weapon mine in thespecified depth zone.

Some text fields in JTLS-GO 5.1 allowed the use of “/”. This character can no longer be used as alegal character in JTLS-GO 6.0 since it will be mistakenly treated as a delimiter. Table 1 lists thefiles and text fields where “/” was allowed in JTLS-GO 5.1.

The program used to convert a JTLS-GO Version 5.1 database to the JTLS-GO Version 6.0 is calledthe Version Conversion Program (VCP). VCP will check the characters entered in each field. If a “/” is encountered, it will be replaced by the underscore character “_”. The VCP is fully discussed inSection 3.4.2.

3.2.2 Database Unload Procedure

In previous versions of JTLS-GO, the Oracle Unload process was accomplished by executing aseries of SQL scripts, one for each table, and spooling the results to the data files. This process,although possible with PostgreSQL, does not result in the spooled files having the required CSVfile format with the slash (/) character delimiter.

The required file format can be obtained by also utilizing the PostgreSQL COPY command, whichenables spooling the data from data tables into ASCII CSV format files that use the slash (/)character delimiter.

Table 1. JTLS-GO Version 5.1 Text Fields Allowing the Slash Character “/”

FILE FIELD

Aircraft Real World Data (<scenario_name>.arw) Aircraft name used by TADIL-J

LOGFAS RIC (<scenario_name>.ric) Reportable Item Code

Targetable Weapon (<scenario_name>.tw) Weapon name used by TADOL-J

25 May 2020 118 JTLS 6.0.0.0


There is one limitation associated with this COPY command download procedure. UnlikeSQL*Loader where each field within a record could have its own string that represents a NULLdata value, the COPY command can specify only one string for the entire record. The word“NONE” has been selected to represent null values in all JTLS-GO Version 6.0 database records.Although this is considered a limitation, the consistency that this “limitation” enforces can beconsidered a benefit.

The basic flow of the downloading ASCII scenario data using the PostgreSQL COPY command issimilar between the previous versions of JTLS-GO and the JTLS-GO 6.0.0.0 version. The downloadof each table is controlled by a download control file located in the $JTLS/script/dds/downloaddirectory. For example, the control file for the “altitude_zone” data table is located in thisdirectory with a name of az.dnl. The contents of this example control file looks like:

copy (SELECT az_name, az_maximum FROM altitude_zone ORDER BY az_maximum) TO az.out WITH DELIMITER '/' NULL 'NONE';

The entire scenario data downloading process can be summarized as follows:

• The existing ASCII scenario data files are moved into a time-stamped subdirectory underthe scenario directory.

• The download_loop.sql script, also located in the $JTLS/script/dds/download directory, isaccessed.

• The process loops through each download control file listed in the download_loop.sqlscript and execute the COPY command contained within the download control file utilizingthe PostgreSQL command line utility “psql”. The end result is the new ASCII CSV data files,one for each PostgreSQL data table, are located in the $JTLS/data/scenario/<scenario_name> directory.

3.2.3 Interaction Between GlassFish And PostgreSQL

From the user perspective, none of the underlying server side changes will affect the look andfeel of how a user builds a JTLS-GO scenario database. Although making the server side changesto interact with the underlying PostgreSQL database are significant, the use of an intermediatelayer Open Data Base Connectivity (ODBC) will reduce the complexity of making these changes.

The most complicated of these changes is the concept of “Flashback”. This was an Oracleproprietary concept in which a change to a specific data item could trigger a notification to theserver to inform other users that the data cell value had been changed. The end result was that ifDDSC User 1 and DDSC User 2 each were looking at the same Table, and User 1 made a changeto a Table value, User 2 would almost immediately see the new data value on the Table display.

PostgreSQL has no equivalent capability, Through server side manipulation, the R&A team had tospecifically write code to implement the same capability. The new code procedure depends on

JTLS 6.0.0.0 119 25 May 2020


what PostgreSQL refers to a a “Row ID”. Within a given database, there is a limit to the number ofrows and therefore “Row IDs” that can be in a given scenario database.

Within PostgreSQL Version 11, which is being used for JTLS-GO Version 6.0, the maximumnumber of “Row IDs” is approximately 2.1 billion rows, well above the number of records in aJTLS scenario database. Still procedures needed to manage “Row IDs” when a user loads a givenscenario database several times. These administrative procedure to properly manage “Row IDs”do not need to be discussed within this design, but need to be well documented within the DDSUser Guide.

During the Beta Test, the plan is to hold a information class concerning some of these requiredadministrative procedures.

The use of “Row IDs” is only needed to properly implement the equivalent Oracle “Flashback”capability. The AAR PostgreSQL data, briefly discussed in Supporting JTLS-GO SDR Applications,Section 3.3, does not need a “Flashback” capability; therefore, it will not use “Row IDs” whichresults in no row limitations for the AAR database. This allows the user to run the AAR even forlarge scenarios over a long period of time.

3.2.4 Required JOBE Changes

The JTLS Order of Battle Editor (JOBE) is a system that can be used to transfer the responsibility of building an exercise Order of Battle (OB) to various exercise participant agencies. The system is made up of two components, the JOBE Interface Navigator (JINN) and the JOBE itself. Figure 3 summarizes the JOBE process.

Figure 3. The JOBE System Concept

Exercise Relational Database

JINN

JOBE

JOBEXML

ZIP File

DDSC

GlassFish

25 May 2020 120 JTLS 6.0.0.0


• The JOBE Interface Navigator (JINN) is accessed from the DDSC Tools menu. The user,through the DDSC decides what OB units should be transferred to another agency. Theseunits are specified by accessing a Command Hierarchy like tool from the JINN DDSCinterface.

• When the assignment task is complete, the DDSC user indicates to create a “zip” file thatcontains all needed information for the exercise participant agency. This includes thedefinition of the units, their targets, and the combat systems owned by each unitprototype.

• This XML ZIP file is then transferred by some computer-to-computer means to the exerciseparticipant agency.

• A user at the exercise participant agency uses the JOBE, which is a DDSC similar Java-based program, that accesses the XML file instead of an RDBMS, such as Oracle orPostgreSQL.

• Once the changes are complete, the file is re-zipped and sent back to the primarydatabase agency via the same computer-to-computer path.

• Again the user, accesses the returned XML file, using the DDSC Tools menu to integratethe changes back into the database system that holds the exercise database.

The method used by the JINN to access and create the XML OB file and the method used by theJINN to upload the returned XML data file into the exercise databases needs to updated tointerface with PostgreSQL vice Oracle. None of the functionality of the JINN will be changed as aresult of this ECP, but it does need to be modernized to properly interface with PostgreSQL.

3.2.5 Required JSYMS Changes

Each JTLS-GO scenario has its own set of symbols that can be used to display map objects inboth the WHIP and DDSC. The JTLS Symbol Support (JSYMS) Tool is used to create and alterthese symbols. If the user adds, deletes, or changes the name of a symbol, this informationneeds to be uploaded into the exercise database so the database builder can alter the databasefields that reference the names of the symbols. The function of the JSYMS program will notchange as the result of this ECP, but the method used to upload symbol name changes needs tobe modernized to properly interface with PostgreSQL.

While reviewing the JOBE process, R&A project management concluded that the current logic used to generate OPM data with the transferred “zip” file has some flaws and lacks efficiency. This review will most likely result in a change to that process. The JOBE tests suggests that for test speed the JOBE OPM generation capability not be used, but the tester should generate OPMs independently.

JTLS 6.0.0.0 121 25 May 2020


3.2.6 Required Alterdata Changes

Within JTLS-GO there is an option called “Alterdata”, which consists of a series of tools developedover the years, as needed, to help alter data in an exercise database. These tools do not interactdirectly with the database, but create scripts of Standard Query Language (SQL) statements thatare then submitted and executed in Oracle’s “sqlplus” capability. This tool allows for commandline entry changes to an existing database. PostgreSQL has a similar capability called “psql”. The“Alterdata” tools need to be reviewed and altered as necessary to work with “pqsl”.

There are two levels of alter database options:

• Main Options. These are tools were specifically funded by the Government and areconsidered to be configuration managed capabilities.

• User Options. These tools were developed on an ad hoc basis as needed for specificdatabase tests or exercises. They are not configuration managed and are specificallydocumented or maintained. At some point, either these alter database tool shouldelevated to the main options or removed when they are no longer useful.

Table 2 lists the current “Alterdata” functions. The table is color coded using the followingmeaning:

• Entries highlighted in “Green” create SQL scripts, and need to be tested as part of thisECP.

• Entries highlighted in “Yellow” do not use the SQL script capability and technically do notneed to be tested as part of this design, but should be tested as part of other regressiontesting for JTLS-GO Version 6.0.

• Entries highlighted in “Red” should be considered for removal from the JTLS-GO codebase. The Government should consider this option.

Table 2. List Of Alterdata Functions

OPTION STATUS FUNCTION

Main Create Joint Deployment Logistics Model (JDLM) Unit - Sub-Unit Unit Identification Code (UIC) File. Although the JDLM link to JTLS-GO has not been used in years, the function still exists.

Main Automatically create a UIC for each unit in an exercise database. This capability builds the needed unique UIC following a consistent algorithm.

25 May 2020 122 JTLS 6.0.0.0


Main Create the initial Entity Level Simulation (ELS) templates for each prototype held in the database. The created templates are a starting point for the proper placement of Combat System entities needed by the ELS. These automatically created templates can then be altered using the JTLS-GO Entity Template Builder (ETB) tool to place the Combat Systems in a tactically meaningful position. This option will be tested under the GlobalSim improvement ECP.

Main Update ELS Templates. After the ELS Templates are created, as mentioned, a database builder can refine the positions of the entities using the ETB. If the database builder goes through this effort and then a change is made to the Combat Systems that are in a given unit prototype, it would require a great effort to start over by creating a new initial ELS template for the prototype. This option takes an existing template and alters it based on the current Combat Systems in the template’s prototype. This option will be tested under the GlobalSim improvement ECP.

Main Create an XML file needed for the link to a C4I system called the RunTime Database (RTDB). The link to the RTDB has not been used for years and it is possible that the RTDB tool no longer exists.

Main Assign Bridges and Tunnels to road or rail arcs.

Main Generate the XML files needed to initialize the Theater Battle Management Core System (TBMCS).

Main Generate exercise targets from data downloaded from the Master Integrated Database (MIDB). This option will be removed as part of JTLS-2020-14789 Update MIDB Tool For JDPI.

User Covert Naval Location. Given that this option is not configuration managed, and there is absolutely no documentation why the capability was even built, it will be removed from the code base. Since the capability is no configuration managed, there is no need to get permission from the Government to remove this function from the code base.

User Generate DIS Code Report. This capability was needed for linking to a tactical level model. As part of JTLS-2019-14400 GlobalSim Improvements, this needed report was converted to a DDS Report accessed directly from the DDSC. This code is no longer needed, but we have decided to keep it in case we need the report and the scenario is not loaded in the database.



JTLS 6.0.0.0 123 25 May 2020


3.2.7 Geographic Information System (GIS) Tool

JTLS-GO is delivered with a tool that builds the terrain data needed by JTLS-GO from real-worldavailable GIS data. This tool is known as the GIS Tool. This tool is capable of creating thefollowing terrain objects:

• The multi-layered terrain grid system that includes terrain type, road type and elevationdata.

• The node and arc data for road, rail, river, sea-lane, and flight path networks. It properlymarks arcs that cross rivers as bridges.

• National Boundaries

User Generate Federation Initialization Data. This capability was used for the old Joint Multi-Resolution Model (JMRM). It took a JTLS database and formatted a database for JCATS. This resulted in the exercise audience only needing to create one database for a JMRM federation event. The current code is of no current use, but R&A suggests that it be maintained in the code base as a user function. It did not result in any updates to the JTLS database. The function is not affected by this design.

User Assign Target Arcs - This option is a duplicate of the Main option Assign Bridge and Tunnel targets mentioned above. This will be removed from the User Code menu option to correct the error.

User Automatically Create Bridges - The GIS tool marks road and rail that cross rivers as bridges. This option takes all the bridge arcs that do not have an associated bridge target and creates a target. This allows the exercise audience to target the bridge and reduce mobility over the river. An SQL Script is created and needs to be tested with PostgreSQL. The Design Team has also elevated this to the main menu meaning that it is part of Configuration Managed JTLS-GO as part of JTLS 6.0.0.0.

User The purpose of this option is to take a GESI generated Character Separated Value (CSV) file that contains their bridge targets creates the same bridge targets in the JTLS-GO database. This is done by generating an SQL file and executing the file to automatically create the bridge targets. Although this capability is part of JTLS-2019-14400 GlobalSim Improvements, it will be tested as part of this ECP. The Design Team has also elevated this to the main menu meaning that it is part of Configuration Managed JTLS-GO as part of JTLS 6.0.0.0.



25 May 2020 124 JTLS 6.0.0.0


• Shorelines

The tools works as shown in Figure 4. The GIS tool does not interact directly with the PostgreSQLdatabase; instead, it generates properly formatted data files. Once generated there is a tool thatuploads the newly generated files into the exercise PostgreSQL database.

Figure 4. GIS Tool Conceptual Design

3.3 Supporting JTLS-GO SDR Applications

Currently the Open Access Programs, Scenario Data Client (SDC), the Order Entry Client (OEC),and After-Action Review Client (AARC) use an Oracle database to store game data while the gameis executing. This entire optional database is known as the Scenario Data Repository (SDR) andis shown in Figure 5.

JOBEXML

ZIP File

Real World GIS Data

GIS Tool JOBEXML

ZIP FileTerrain Data

Files

Terrain Data Load Scripts

Exercise PostgreSQL Database

SDR JODA Current Data

Order Entry

AAR Data

JTLS 6.0.0.0 125 25 May 2020


Figure 5. JTLS-GO Scenario Data Repository (SDR)

• The Scenario Data Client (SDC) is responsible for populating and updating the SDR withthe current game information provided by the JTLS Object Distribution Authority (JODA).Any object information provided by the JODA is available in the SDC data tables. Thisprogram will be converted to properly place the data into the SDR Runtime Database.

• The Order Entry Client (OEC) checks database tables within the SDR for orders that havebeen placed for submission to the CEP. The OEC is responsible for retrieving, formatting,verifying and submitting these orders. This program will be converted to properly get thedata from the SDR Scheduled Order database and send those orders to the game.

• The After-Action Review Client (AARC) program is responsible for populating the SDR withCEP objects, object history, and object interaction data. These data constitute a history ofthe running model, which can be used for AAR queries (tracking combat system losses,for example) or for run-time reporting or analysis.

As the result of the movement to PostgreSQL, the AARC can be completely redesigned tomake use of the fact that there are no longer any data limits to the information that canbe held and collected during an exercise or analysis cycle. These changes are discussedin ECP JTLS-2019-14353 Convoy Data In AAR.

3.4 Management Of JTLS-GO Scenarios With PostgreSQL

One of the more esoteric changes will be the concept of a JTLS-GO scenario. Within Oracle, eachscenario was an Oracle User Account. There was a one-to-one relationship between Oracle UserAccount and JTLS-GO Scenario. Each User Account, i.e. scenario, owned its own set of tables andoccupied a specific tablespace. These concepts are different than the manner in whichPostgreSQL manages its space.

Within PostgreSQL, there are two concepts, a User and a Scheme that should be used by theuser. Each JTLS-GO scenario held within PostgreSQL, must have a User with the name of theJTLS-GO scenario and the User must use a Scheme that also has the name of the JTLS-GOscenario.

The difference between the old JTLS-GO Oracle database implementation and the JTLS-GOPostgreSQL database implementation can be summarized as follows:

• Oracle: user name = JTLS-GO scenario name

• PostgreSQL: user (role) name = schema name (for that role) = JTLS-GO scenario name

During the installation process, there are four procedures needed to prepare PostgreSQL forJTLS-GO scenario data. These are:

25 May 2020 126 JTLS 6.0.0.0


• Create a directory to hold the PostgreSQL scenarios. The directory is equivalent todefining an Oracle Tablespace.

a. In Oracle, the administrator needed to assign a size to the Oracle Tablespace becausethe Tablespace was a physical file. If the space was filled by scenario data, the Oracleadministrator needed to physically increase the size of the Tablespace or define a newTablespace and manage which scenario’s used the different Tablespace files.

b. In PostgreSQL, a directory is created to hold the various scenarios within PostgreSQL.This directory should be created on a disk that has sufficient space to hold thescenario data. The Installation Manual suggests that this directory be called jtls_tbs,but any desired name can be used. If the disk on which this directory resides iseventually filled, then the system administrator needs to mount an addition disk andcreate a new directory, with a different name on that disk. When a scenario is createdwithin PostgreSQL, the scenario is assigned to a specific directory.

• Create a default scenario roll, called jtls_role. This default role will be developed to haveall privileges necessary to use the DDS, DDS Migration, and DDS Synchronizationcapabilities, and meet all of the existing PostgreSQL Security Technical ImplementationGuide (STIG) requirements.

• Create a database to hold the scenarios. When create the database, the owner will bespecified as the default jtls_role and it will be assigned a tablespace by entering the nameof the selected directory. For example, the following PostgreSQL command would beentered:

create database jtls_db owner = jtls_role tablespace = jtls_tbs;

• Update the default jtls_role to recognize the jtls_db. This will be accomplished by enteringthe following commands:

grant connect on database jtls_db to jtls_role; grant create on database jtls_db to jtls_role;

3.4.1 Creating JTLS-GO Scenario Users in PostgreSQL

To create a new scenario within PostgreSQL, the following steps would need to be accomplishedby the PostgreSQL database administrator. A detailed example will be placed in the DDS UserGuide, but the purpose of this section is to simply explain to the reader what needs to beaccomplished to create a new scenario user in PostgreSQL.

1. Login to the pgsql PostgreSQL database server machine as the PostgreSQL OS user. Thisis an account different than the JTLS-GO account.

2. Ensure that the pgsql PostgreSQL database server is running.

JTLS 6.0.0.0 127 25 May 2020


3. Test the PostgreSQL admin connection by executing.

4. Create the JTLS-GO specific database user called <scenario_name>. For example, tocreate the user for the wespac60 scenario, the following command would be entered.

create user wespac60 password 'jtls60';

5. Have this new user inherit its privileges from the default role (jtls_role), created duringPostgreSQL installation. Enter the following command:

grant jtls_role to wespac60;

6. Create the database schema for the newly created wespac60 role (user). This is not donefrom the PostgreSQL admin account. This step accomplish by logging into the scenario’suser account. Remember that both the PostgreSQL user name (role) and the schemename must be the same as the JTLS-GO scenario name. Thus, when logged into thewespac60 account, the following command would be entered:

create schema wespac60;

Once these steps are accomplished, the user will be able to load the ASCII scenario files into thePostgreSQL database.

3.4.2 Converting Existing Scenarios

In previous versions of JTLS-GO which used Oracle, an automated database format conversioncapability was delivered with JTLS-GO. This capability looked at the JTLS-GO database versionattribute in the Oracle tables, and decided which Oracle table format changes needed to beexecuted.

For example, assume that a user loaded JTLS-GO Version 5.1 and using this code installationaccessed an existing JTLS Version 4.0 database. The delivered code recognized the differenceand automatically applied all database table format changes to convert the:

• JTLS Version 4.0 database to the Version 4.1 table and attribute definitions.

• The resulting JTLS Version 4.1 database to the JTLS-GO Version 5.0 table and attributedefinitions.

• The resulting JTLS-GO Version 5.1 database to the JTLS-GO Version 5.1 table and attributedefinitions.

This was all done by the Oracle conversions scripts delivered with each new version of JTLS andJTLS-GO. Given that JTLS-GO Version 6.0 will not use Oracle, the normal database conversioncapability cannot be implemented. Instead a new Simscript III program, called the Version

25 May 2020 128 JTLS 6.0.0.0


Conversion Program (VCP) will be developed to read in a JTLS-GO Version 5.1 database andconvert it to the format needed for JTLS Version 6.0.

The program was written in Simscript because it could simply use the Simscript read code fromJTLS-GO Version 5.1 and the Simscript American Standard Code for Information Interchange(ASCII) checkpoint write code from JTLS-GO Version 6.0.

This means that all existing JTLS databases that need to be converted into the JTLS-GO Version6.0 format must first be converted to the JTLS-GO Version 5.1 format. Follow the JTLS-GO Version5.1 documentation to get all databases moved into JTLS-GO Version 5.1.

Once that is done, the entire conversion process of moving a JTLS-GO Version 5.1 database intothe needed JTLS-GO Version 6.0 format is outlined in the steps described below.

• Step 1. From the JTLS-GO 5.1 account run the script copyscenario <existing scenario><new scenario>. If the new scenario already exists either enter another new scenarioname, or use the -f switch to force overwrite of that scenario.

This step is accomplished because it is the easiest way to change the name of thescenario. For example, when the R&A Engineering Team converted the wespac51scenario to the scenario called wespac60, this step was the easiest way to accomplishthe task. When converting an exercise database that does not include the version of JTLS-GO, such as cg20 (Cobra Gold 20), this step is not necessarily needed.

If this step is not accomplished, then the resulting JTLS-GO Version 6.0 will have the samename as the JTLS-GO Version 5,1 scenario.

• Step 2. From the JTLS-GO 5.1 account run the SVP to check the new scenario. Fix anyreported errors. The VCP may not work properly if the database has any errors. Do notproceed to the next step until all errors have been fixed. Warnings are acceptable for theprocess to continue.

• Step 3. Copy the new scenario from the 5.1 account's <JTLS 5.1 home>/data/scenariodirectory to the 6.0 account's <JTLS 6.0 home>/data/scenario directory.

• Step 4. From the JTLS-GO 6.0 account run the VCP. This is accomplished from either theJava Menu or the jtlsmenu, under the Database Development Menu. Note that the VCPwill overwrite the 5.1 files with the 6.0 formatted files. Also, if a 5.1 Non-ConfigurationManaged Data file (<scenario>.ncm) is present, the VCP will delete it after the conversionis completed.

• Step 5. Load the 6.0 files to the PostgreSQL database.

• Step 6. Unload the PostgreSQL database to write the ELS files in the proper format.

JTLS 6.0.0.0 129 25 May 2020


The ELS data files are based on the scenario data files, so there is no reason tospecifically convert the files. The unload process will automatically place the needed datain the proper format.

The VCP data change logic is not discussed within this design. The data changes required foreach ECP that is included in the JTLS-GO Version 6.0 release are discussed in the ECP thatrequires the data change. The JTLS-GO Version 6.0 Version Description Document (VDD) willsummarize all data changes needed for the database conversion process,

4.0 Data ChangesI

The format of each data file changes as a result of this ECP, but the data held in the databasedoes not need to change for the movement from Oracle to PostgreSQL. The format of the newscenario files was described in Section 3.2.1.

5.0 Order Changes

No order files need to be changed as a result of this ECP.

6.0 JODA Changes

No JODA changes are required as a result of this ECP.

7.0 Test Plan

An all inclusive Test Plan would be difficult to write. There is no way to test that the PostgreSQLdatabase server is functioning as it should any more than users could test that the OracleRDBMS is functioning properly. The only JTLS-GO programs that can be tested are:

• Database Development System Client (DDSC)

• The Scenario Data Client (SDC)

• The Order Entry Client (OEC)

• The AAR Client (AARC)

• The Total Recall Interactive Post-Process.

25 May 2020 130 JTLS 6.0.0.0


As a result of moving to PostgreSQL, R&A has the opportunity to expand the current AAR toaccomplish cross-run data collection and data comparison. Although PostgreSQL has opened thedoor to this major improvement, the actual design for all changes to the AAR capability in JTLS-GO Version 6.0 is described in ECP JTLS-2019-14353 Convoy Data In AAR. The AARC is closelyrelated to the SDC and the OEC. The testing of the full Scenario Data Repository (SDR) is coveredin ECP JTLS-2019-14353 Convoy Data In AAR.

For this reason, this test plan simply covers the testing of the DDSC.

7.1 Test Installation Of PostgreSQL

Purpose: The purpose of this test is to ensure that the PostgreSQL installation procedures areaccurate and easy to understand.

Step 1: Using the Installation Manual install the containerized version of PostgreSQLdelivered with JTLS-GO 6.0 called pgsql.

Step 2: Using the Installation Manual create the tablespace directory and the defaultjtls_role.

Expected Results: The installation should progress as indicated in the documentation.

7.2 Convert Existing Scenario

Purpose: The purpose of this test is to ensure a JTLS-GO Version 5.1 database can be convertedto the JTLS-GO Version 6.0 format. This test also ensures that the documentation tocreate a new user in PostgreSQL found in the DDS Users Guide is accurate and easilyunderstood.

Step 1: Select a JTLS-GO Version 5.1 database to convert.

Step 2: Select a new name for this scenario that will be held within JTLS-GO 6.0.

Step 3: Following the steps in the DDS User Guide, create a new PostgreSQL user that willeventually hold this converted scenario.

Step 4: Follow the steps outlined in Section 3.4.2 to convert the database.

Expected Results: The conversion should occur and the database should properly load andunload from the newly created PostgreSQL scenario user.

Step 5: Run the Scenario Verification Program (SVP) on the newly converted scenario.

Step 6: Run the Scenario Setup procedure for the newly converted scenario.

JTLS 6.0.0.0 131 25 May 2020


Step 7: Run the Online Players Manual generation for the newly converted scenario.

Step 8: Run the Interface Control Program (ICP) for the newly converted scenario.

Step 9: Bring up the Web Services Manager for the newly converted scenario.

Step 10:Start the Combat Events Program (CEP) for the new converted scenario.

Step 11:Bring up several WHIPs for the newly converted scenario.

Step 12:Run the game forward for at least one day.

Step 13:Take a Stop Checkpoint

Step 14:Restart the game from the Stop Checkpoint

Step 15:Run the game forward for at least one more day.

Step 16:Take a Running Checkpoint

Step 17:Regenerate the OPMs from the running checkpoint.

Expected Results: Each step should execute without incident. The scenario should look likethe scenario as it did in JTLS-GO Version 5.1.

7.3 DDSC Regression Testing

Purpose: The purpose of this test is to conduct regression testing of the basic SDC capabilities.

Step 1: Using the DDS Configuration Program (DCP), setup GlassFish.

Step 2: Start GlassFish

Step 3: Start a DDSC and execute the tasks outlined in Table 3.

Table 3. Regression DDSC Functions

FUNCTION

Bring up three tables and view the data.

Change a value of an integer field in any selected table.

Change a value of a real field in any selected table.

Change a value of a text field in any selected table.

25 May 2020 132 JTLS 6.0.0.0


Change a value of a field that references another field in any selected table.

Using the keyboard, change a location field.

Using the map, change a location field.

Change a field that points to a unit using the keyboard. For example, change the airbase at which a squadron is located using the keyboard.

Using the map, change the same field to another unit using the map.

Select any record in any table, and copy the record.

Select any record in any table that has a “Deep Copy” capability, and do a “Deep Copy”.

Delete a record from any table.

Highlight several records from any table, and delete the records

Attempt to delete a Targetable Weapon that is references in an Aircraft Load.

Highlight several Targetable Weapon records, some that are referenced in an Aircraft Load and some not referenced anywhere else. Attempt to delete the highlighted group of weapons. Only the weapons not referenced elsewhere should be deleted.

From any table that was used to make the changes up to this point, view the table history table.

Sort any table on an integer field.

Sort any table on a real field.

Sort any table on a text field.

From any table, move columns.

Sort on the moved column.

Bring up the DRM help for any field in any selected table.

Select any table and using the filter capability to filter out some records. The filters should be:

• Single filter parameter

• At least three compound filter options in one filterspecification.


FUNCTION

JTLS 6.0.0.0 133 25 May 2020


From any table, hide a column using the mouse right click and the column heading

From any table, hide a column using the Configure Menu.

• Hide single columns

• Toggle all columns on and off

Using the map search capability, find a unit.

Using the Command Hierarchy, find a unit.

Click on any unit to see its data in the SITREP window. Click on a unit:

• In the Command Hierarchy

• On the Map

From a unit on the command hierarchy, right click to bring up the context sensitive menu and execute the following options:

• Find on map

• Find in table

• Find prototype

• Copy

• Delete

Using the Move Unit Map Capability, to the following:

• Click on one unit and click on a new location.

• Drag the mouse to create a rectangle around a group of units.Once highlighted, click on a new location.

• Using the filters, bring up targets. Find a group of units thathave several owned targets. Highlight the group of units andclick on a new location.

Using the Range Ring filter, display the unit radius for a unit that owns a target.

Click on one of the owned targets, and move it to a location outside of the unit radius. It should be refused.

Find a unit that has a prototype owned target, and attempt to move it outside of its owning unit’s radius.


FUNCTION

25 May 2020 134 JTLS 6.0.0.0


Using the Map Filter capability, check the following:

• Filtering by Object Type

• Filter by Echelon

• Filter by Land Unit Symbol

• Filter by Naval Unit types

• Filter by Command Hierarchy

Bring up the Logistics Hierarchy. View:

• The regular support unit logistics hierarchy.

• The initial support unit logistics hierarchy

• A specific Supply Category logistics hierarchy.

Select a Supply Category, and create data to alter the support unit for several units for that specific Supply Category. View the logistics hierarchy for that specific Supply Category.

Using the tables, create or alter the following capabilities:

• OPAREAs

• Weather Systems

• Terrain Barrier

• National Boundaries

• Integrated Air Defense Systems (IADS)

• Railroad

• Roads

• Air Path

• Sea-lanes

• Rivers

• Pipelines

Enter the Map OPAREA Edit mode. Change the following:

• Move a vertex

• Add a vertex

• Delete a vertex

• Move the entire OPAREA


FUNCTION

JTLS 6.0.0.0 135 25 May 2020


From the Map and using the Weather Front edit mode, create a new Weather Front. Once created change the following:

• Move a vertex

• Add a vertex

• Delete a vertex

• Move the entire Weather Front

From the Map and using the Terrain Barrier edit mode, create a new Terrain Barrier. Once created, change the following:

• Extend the barrier from the start

• Extend the barrier from the end

• Show the barrier in the table.

From the Map, delete a different Terrain Barrier.

From the Map and the National Boundary edit mode, create a new National Boundary. Once created, change the following:

• Move a vertex

• Extend the barrier from the start

• Extend the barrier from the end.

Bring up the new National Boundary in the table and set the side specific object moved restrictions for the new National Boundary.

From the Map, edit the IADS editing Mode. Do the following:

• Add a link from an existing network to a new target.

• Delete a link to a different target.

From the Map, enter the Railroad editing mode. Do the following:

• Edit a node

• Move a node

• Delete a node

• Add an Arc to an existing node

• Add an Arc to a new node

• Show the node in the table

• Edit an Arc

• Delete an Arc

• Find an Arc in the table

• Find the railroad record in the table.


FUNCTION

25 May 2020 136 JTLS 6.0.0.0


From the Map, enter the Pipeline editing mode. Do the following:

• Edit a node

• Move a node

• Delete a node




• Edit an Arc

• Delete an Arc

• Change the direction of the Arc



From the Map, enter the Road editing mode. Do the following:

• Edit a node

• Move a node

• Delete a node




• Edit an Arc

• Delete an Arc



From the Map, enter the Road editing mode. Do the following:

• Edit a node

• Move a node

• Delete a node




• Edit an Arc

• Delete an Arc




FUNCTION

JTLS 6.0.0.0 137 25 May 2020


From the Map, enter the River editing mode. Do the following:

• Edit a node

• Move a node

• Delete a node



• Add a branch


• Edit an Arc

• Delete an Arc



From the Map, enter the Sea-lane editing mode. Do the following:

• Edit a node

• Move a node

• Delete a node



• Add a branch


• Edit an Arc

• Delete an Arc



From the Map, enter the Terrain Modification Utility. Make the following changes:

• Using the single point change, change the land terrain type.

• Using the line change mode, change the road type betweentwo points.

• Using the area change mode, change the altitude of an area.

• Using the paintbrush change mode, change the depth ofseveral ocean grids.


FUNCTION

25 May 2020 138 JTLS 6.0.0.0


Expected Results: Each of the capabilities tested should operate as it did in JTLS-GO 5.1

7.4 Test Flashback Capability

Purpose: The purpose of this test is to ensure that the newly developed “Flashback” capability isworking.

From the Map, enter the Flight Path editing mode. Do the following:

• Edit a node

• Move a node

• Delete a node



• Add a branch


• Edit an Arc

• Delete an Arc



Submit an order request for the following reports:

• Air Asset Report

• Airbase and Squadron Report

• Combat System Roll-up Report

• Command Hierarchy Report

• Force Side and Faction Summary Report

• Target Report

• Unit Vehicle Report

• Tactical Unit Prototype Report

• Ship Unit Prototype Report

• High Resolution Prototype Report

• DIS Code Report

View the generated reports

E-mail one of the reports


FUNCTION

JTLS 6.0.0.0 139 25 May 2020


Step 1: Bring up several DDSC interfaces on different machines.

Step 2: Repeat the tests highlighted in “Green” in Table 3. For each test, random select whichuser is making the change and have the other two users view the same data either onthe map or in a table.

Expected Results: Once the change is complete, the other users should see the data changeon their screen.

Step 3: Have all three users bring up a single table. Have each user execute the followingcommands from this single table:

• Have User 1 create a new record

• Have User 2 delete an existing record

• Have User 3 alter a single database parameter on a different record in the same table.

Expected Results: Each suer should end up with seeing all of the resulting data changes.

Step 4: Have all three users bring up a different single table. Have each user simultaneouslyexecute the commands listed in Table 4.

Table 4. Simultaneous Command Execution

COMMAND EXPECTED RESULTS

Create a new record. Each record should be created and everyone should see all three records.

Copy an existing record and have each user give the record the same name.

One user should successfully create the record. The other two users should get an error message. All three users should see the new record.

Deep Copy an existing record and have each user give the record the same name.

One user should successfully create the record. The other two users should get an error message. All three users should see the new record and all the newly deep copied records.

Delete the same record. One user should successfully delete the record. The other two users should get an error message. All three users should not see the deleted record.

Change the value of the same attribute. Each user should enter a different value.

The last change processed by the server will win out. All three users should see the same value for the attribute. Look at the history table, and all three changes should be listed.

25 May 2020 140 JTLS 6.0.0.0


7.5 Test SVP Auto-Correction Capability

Purpose: The purpose of this test is to ensure the auto-correction capability of the ScenarioVerification Program (SVP) tool, a component of the DDS Client program, is working.

Step 1: Bring up a DDS Client for a copy of wespac60 scenario. Then bring up the SVPR(Scenario Verification Program Report). If the scenario has never been verified, theSVPR will display the message to select the “Run SVP” menu option from SVPRcomponent's Tools menu.

Expected Results: A separate window will pop up to display the process of first downloadingthe database; followed by running the SVP program. After the SVP program completes, clickthe “Done” button to dismiss the window and the SVPR browser should now display theverification results.

Step 2: Find an Error or Warning that has an auto-correction option. For example, there maybe a Warning 1227 that has such options, i.e. “Set the Supply Category to a desiredamount for a SUP's Bring to Theater.” There should be a couple of Warning 1227listed, select the first one, and click the auto-correction option, a dialog will pop up toconfirm the action.

Step 3: Click OK to perform the auto-correction.

Expected Results: The issue should be marked as resolved.

Step 4: Bring up the Ship Unit Prototype table, select the SUP in question, and bring up itsSUP Supply Category table, find the Bring to Theater amount of the Supply Categorythat was just auto-corrected, and verify that the amount is now correct.

Expected Results: The value should be set to the value indicated in the auto-correct message.

Step 5: Find another Error or Warning that has an auto-correction option. For example, theremay be a Warning 1449 that has such options, i.e. “Set the Prototype, SupplyCategory BASIC LOAD of the SUP to a desired amount. Ensure to update capacity asnecessary.” There should be several Warning 1449 listed.

Step 6: Use the mouse highlight several 1449 Warnings and click the auto-correction option.

Expected Results: A dialog will pop up to confirm the action.

Step 7: Click OK to perform the auto-corrections.

Expected Results: The selected issues should all be marked as resolved.

JTLS 6.0.0.0 141 25 May 2020


Step 8: Bring up the Ship Unit Prototype table, select the SUP(s) in question, and bring up itsSUP Supply Category table to verify the Supply Category's Basic Load amount hasbeen changed.

Expected Results: Each SUP's value should be changed as indicated in the auto-correctionmessage.

7.6 Test DDS Migration Capability

Purpose: The purpose of this test is to ensure the Data Migration tool, a component of the DDSClient program, is working.

Note: The repository60 is already setup as the source and the blank60 as the destination databases for this test. At the start of this test, both scenarios' GlassFish servers should be up.

Step 1: Launch a repository60 DDS client.

Step 2: From there, select the Tools->Data Repository->blank60 option to bring up theRepository Tool.

Step 3: Click the ORBAT Migration button on the tool to bring up the ORBAT Data Migrationwindow.

Step 4: Click and select the top unit from a force side that does not exist in the destinationscenario. Drag the unit from the left panel to the right to migrate the selectedORBATs.

Expected Results: A confirmation dialog should pop up asking “Do you want to migrateselected data and create new force side(s) as needed?”

Step 5: Answer “Yes” to start the migration, and wait for the migration to complete.

Expected Results: This may take awhile, but in the meantime, messages would show up inthe Status area below stating “Success addrecord...” etc. There maybe some “Failed...”messages, however if the fails are due to violating composite unique key, then it's a “falsepositive” because it means the data already existed in the destination. While data is beingmigrated, there should be a progress bar at the lower right corner showing the percentage ofcompletion. At the end of the migration, a dialog should popup stating “ORBAT MigrationCompleted!”

Step 6: Click OK to dismiss the dialog.

Expected Results: In the ORBAT Data Migration window, on the right side where destinationdatabase's ORBAT hierarchy is shown, the newly migrated ORBAT hierarchy should bedisplayed.

25 May 2020 142 JTLS 6.0.0.0


Step 7: Launch a blank60 DDS client and bring up the Faction Country table to verify that theLeader column for the newly migrated Faction(s) is blank. This is necessary to avoidcircular references during migration.

Step 8: Now go back to the source repository60 DDS client's Data Repository Tool and clickon the “Data Repair” button to bring up the Migration Data Repair window.

Step 9: From that window, make sure the “Repair Nullified Data” tab is selected. On thispanel, there are several tables whose selected columns were set to “Null” duringORBAT migration. By default, each of these columns repair option is set to repair“Only if existing in the destination.” Make sure that is the case for “Faction Leader”column of the “Faction Country” table, and click on the “Repair” button located onthe lower right corner of the window.

Expected Results: When the repair is done, a “Repair Done” dialog will popup. Click “OK” todismiss the dialog.

Step 10:Now go back to the “Faction Country” table of the blank60 DDS client.

Expected Results: The “Leader” column should now be repaired and the faction that wasmigrated during Step 1 should have the top unit of that faction assigned as the leader.

Step 11:Go back to the source respository60 DDS client's Data Repository Tool and click onthe “Data Repair” button to bring back the Migration Data Repair window.

Step 12:This time, select the Post-migrate Parametric Data tab from that window. Thereshould be a list of parametric data tables already displayed in the Selected list on theright. These parametric data were intentionally not migrated during the ORBATmigration mostly due to performance concerns. To repair them all will take sometime, so for the purpose of this test, click the “Remove All” button to shift all tablesfrom “Selected” list to “Available” list.

Step 13:Find the phl_tgc, and pkl_tgc tables in the “Available” list and click the “Add” buttonto move these two tables back to the “Selected” list.

Step 14:Click the “Post-migrate” button at the bottom right corner to start the post-migrationparametric data repair.

Expected Results: The Status area down below should start to display messages that datarepair is being started, there might be a little pause, followed by “Success addedrecord...”messages indicating the parametric data is now being migrated to the destination database.Because there are quite extensive data in the parametric data table, this may take awhile tocomplete. After all the necessary data is being migrated, there should be a “Repair Done!”dialog popup. Click the “OK” button to dismiss the dialog.

JTLS 6.0.0.0 143 25 May 2020


Step 15:Go to the destination blank60 DDS client and bring up the Probability Hit Lethality(PHL) table and select a PHL record and click the "Prob. Hit Leth Data" quick linkbutton to bring up the Probability of Hit Lethality Data table.

Expected Results: Before the data repair, because blank60 was blank before the migrationstarted, there was no phl_tgc data; however, after the data repair, there should be somephl_tgc data listed.

Step 16:Do the same check for Point Kill Lethality data.

Step 17:Go back to the source respository60 DDS client's Data Repository Tool and click onthe “Non-ORBAT Migration” button to bring up the Non-ORBAT Data Migration window.From that window's “Tables” menu, select a table.

Step 18:Find a record in the source table on the left that does not exist in the destinationtable on the right. Right click the selection to bring up a popup menu and select the“Migrate row” option to migrate the record to the destination.

Expected Results: The Status area down below should start to display message indicating theselected record is being migrated to the destination database. Also the destination tabledisplayed on the right should display the record being migrated if the status message said therecord is successfully added.

Step 19:Launch a destination DDS client and bring up the DDS table from which the recordwas migrated in Step 18.

Expected Results: The new record should exist in the destination DDS and the data valuesshould be identical.

Step 20:From the destination DDS, change some of the values in the selected record.

Step 21:Go back to the Non-ORBAT Migration table in the source DDSC.

Expected Results: The newly migrate record should still show in both the source side and thedestination side of the Non-ORBAT Migration section, but the destination side should showthe different values that were just entered.

Step 22:Select that record in the source table on the left and right click to bring up the popupmenu. This time select the “Update row” option to update the data in the destinationto the values from the source database.

Expected Results: The corresponding record in the destination database table on the rightshould now be updated.

25 May 2020 144 JTLS 6.0.0.0


7.7 Test Alter Database Functions

Purpose: The purpose of this test is to ensure that all of the alter database functions thatinteract with the database still work as needed.

Step 1: Run each of the alter database functions described in Table 2 that are highlighted in“Green”.

Expected Results: The function should execute as documented and the database should beupdated without error.

7.8 Create Symbol

Purpose: The purpose of this test is to ensure that the JSYMS program creates a new symbol setin the selected scenario and loads the created symbol to the database when saved.

Step 1: Run the JSYMS program for a scenario that is loaded in PostgreSQL.

Step 2: Add a new symbol to the database.

Step 3: Save the new symbol set.

Expected Results: A confirmation window should be displayed requesting whether the newsymbol set should be uploaded in the data.

Step 4: Select the “Yes” option

Expected Results: The symbol data set should be uploaded properly.

Step 5: Bring up a DDSC for the selected scenario and look at the Graphics Symbol databasetable.

Expected Results: The new symbol should be listed in the drop-down menu for the prototypessymbol field.

Step 6: Assign the new symbol to a unit prototype that is used within the database.

Expected Results: The new symbol should be set and the symbol icon should appear next tothe field.

Step 7: Download the database and setup, and run the new database.

Expected Results: All should work normally and the unit or units that uses the changedprototype should have the newly created symbol.

JTLS 6.0.0.0 145 25 May 2020


Step 8: Bring up the JSYMS program again, and delete the newly created symbol while it isstill assigned to one of the database prototypes.

Step 9: Save the symbol data set and have it upload the changed data to the database whenasked for that option.

Expected Results: The update should occur without incident.

Step 10:Bring up a DDSC user interface for the scenario and look at the symbol table.

Expected Results: The recently deleted symbol should no longer be listed in the table.

Step 11:Look at the prototype that used the symbol that was just deleted.

Expected Results: The prototype that referred to the deleted graphics symbol should beblank. If you download the scenario and verify, the SIP will report the error.

7.9 Test The JOBE Capability

Purpose: The purpose of this test is to ensure that the JOBE process and specifically the JINNprogram works with PostgreSQL. For time considerations, it is best if you do a databasesave, setup, and run the OPMs before running the test. Generating the OPMs in themiddle of the test, which is a capability of the JOBE packager will result in a long testtime.

Step 1: Start the DCP and configures your scenario.

Step 2: Bring up a DDSC user interface.

Step 3: Select Tools from the top menu and select jinn to start the JINN program.

Step 4: Following the instructions in the DDS User Guide, create a new organization andassign a portion of the unit hierarchy to the new organization. Note that the larger theunit hierarchy that is created, the larger the file that will be created. For reasonabletest time purposes do not go overboard or under-board in assigning a unit hierarchyto the new organization.

Step 5: After selecting units and assigning them to the JINN, select the Export option.

Expected Results: The word [Exported], date and time should be displayed. Now, you can nolonger select additional units for this organization.

Step 6: Select the “Setup Online Player’s Manual” from “Actions” in the top menu.

Step 7: Package this organization from the “Actions” menu.

25 May 2020 146 JTLS 6.0.0.0


Expected Results: When the packaged zip file is complete, the user is notified the process is“Done” and the OK button can be clicked to close the package action window.

Step 8: Distribute the generated package on a non-JTLS-GO server machine. Unzip thepackage file.

Step 9: Bring up the JOBE on the user client machine following the instructions listed in theshort special instruction manual distributed with the package.

Expected Results: The JOBE should come up as expected.

Step 10:Have a user make some changes to the organization using the JOBE. The changesshould be a combination of:

a. Create new unit and put in the hierarchy

b. Deleting units from the hierarchy

c. Changing the name of a unit in the hierarchy

d. Moving units within the hierarchy

e. Changing locations of units on the map.

f. Change type of aircraft for a squadron

g. Change other unit attributes as allowed by unit type

h. Copy a unit

i. Deep copy a unit and its subordinates

j. Create a new target

k. Delete an existing target.

l. Change the name of an existing target.

m. Move an existing target.

Expected Results: All should work as expected.

Step 11:After you finish editing, click the save button under the main menu.

Expected Results: A message window will pop-up to confirm the [scenario-name]_[organization]_dynamic.xml, comment log and upload log are saved. Click ‘OK’button.

Step 12:Close the JOBE.

Step 13:Restart the JOBE.

JTLS 6.0.0.0 147 25 May 2020


Expected Results: The JOBE should reflect the changes made to the database so far.

Step 14:Make a few more database changes.

Step 15:Do another database save.

Step 16:Repackage the updated database by selecting the “Create Return Package” menuitem from the File menu.

Expected Results: A window will pop-up to confirm where the package is created. Click ‘OK’button.

Step 17:Exit the JOBE.

Step 18:Return the package file names ‘return_[scenario-name]_[organization-name].zip’ fileto the JTLS-GO Version 6.0 server system.

Step 19:Move the ‘return_[scenario-name]_[organization-name].zip’ file to $JDATA/<scenario_name>/JOBE/update/ directory.

Step 20: Unzip the file.

Expected Results: There should be three XML files extracted.

Step 21:From the DDSC JINN Tools menu, click Actions Import.

Expected Results: The Import JOBE Data window will pop-up. The returned organization namefile should be displayed in the selection window.

Step 22:Click the file and click ‘Open’ button.

Expected Results: A new tab appears with the organization-name on it front of the Databasetab and there is a rendered new tree a command hierarchy that the JOBE user has edited.

Step 23:From the main menu of the JINN, click View Database Log organization-name.

Expected Results: The database Log window should pop-up and display the log of what theJOBE user edited.

Step 24:From the main menu of the JINN, click Actions Upload to upload all work from theJOBE user.

Step 25:Examine the Database Log.

25 May 2020 148 JTLS 6.0.0.0


Expected Results: The success column check-box should all be checked. The time columnshould list the upload time. The result column should described what was accomplishedduring the upload procedure.

Step 26:Look at the updated data in the DDSC to verify the changed data is not reflected in thescenario database.

Expected Results: All updated data should not be in the database tables.

7.10 Test GIS Tool

Purpose: The purpose of this test is to insure that terrain developed by the tool can be exportedto JTLS-GO 6.0 scenario text format and then be loaded to the PostgreSQL database.

Step 1: This test will overwrite the terrain data of the database being used. Ensure you have abackup copy of the test database as required, Refer to the DDS Users Guide ifdetailed instructions are needed to run the GIS Tool.

Step 2: Start the GIS Tool using the Javamenu or jtlsmenu.

Step 3: Create a new GIS Tool Project.

Step 4: When prompted to define the import area, create an area that covers the Koreanpeninsula. That provides an area with sufficient amounts of roads, rail lines, andrivers.

Step 5: When the “Import” dialog appears, select “Import All”, “Import all air corridorsworldwide”, “Import all sea lanes worldwide”, and “Replace current features with thisimport”. Click the “Import” button.

Expected Results: The tool should zoom to the selected area. Keep this view for the entirety ofthis step.

Step 6: From the Edit menu select “Railroad”. Click on the map with right mouse button.When the pop-up menu appears select, “Trim Nodes in Current View”.

Expected Results: The “Enter Node Reduction Constraints” will appear.

Step 7: To get a reasonable reduction of nodes, enter a minimum arc length of at least10000 meters and a maximum deviation of 5000 meters. Also click on the “Removerailroad spurs” check box and enter a spur length of at least 10 Kilometers. Click onthe “Start” button. When prompted to accept the changes, click on the “Accept”button. Finally, close the “Enter Node Reduction Constraints” dialog by clicking on the“Cancel” button.

JTLS 6.0.0.0 149 25 May 2020


Step 8: From the Edit menu select “River”.

Step 9: Click on the map with right mouse button. When the pop-up menu appears select,“Trim Nodes in Current View”. The “Enter Node Reduction Constraints” dialog willappear. To get a reasonable reduction of nodes, enter a minimum arc length of atleast 10000 meters and a maximum deviation of 5000 meters. Click on the “Start”button. When prompted to accept the changes, click on the “Accept” button. Finally,close the “Enter Node Reduction Constraints” dialog by clicking on the “Cancel”button.

Step 10:From the Edit menu select “Road”.

Step 11:Click on the map with right mouse button. When the pop-up menu appears select,“Trim Nodes in Current View”. The “Enter Node Reduction Constraints” dialog willappear. To get a reasonable reduction of nodes, enter a minimum arc length of atleast 10000 meters and a maximum deviation of 5000 meters. Click on the “Start”button. When prompted to accept the changes, click on the “Accept” button. Finally,close the “Enter Node Reduction Constraints” dialog by clicking on the “Cancel”button.

Step 12:Create two layers covering the Korean peninsula as follows:

• Create a five-degree terrain layer covering the entire peninsula.

• Create a 1 degree terrain layer over a portion of the peninsula around the DemilitarizedZone (DMZ).

Step 13:From the Edit menu select “Terrain Layer” -> “Calculate Grid Parameters”. Click the“Select All” check box in the “Calculate Grid Parameters” dialog and click on the“Start” button.

Expected Results: The status panel should provide feedback and the terrain is computed.

Step 14:Export the Terrain and enter the name of the scenario.

Expected Results: The new data files will be written to the scenario’s $JTLSHOME/data/scenario/<scenario_name> directory.

Step 15:Save the Project.

Step 16:Load the Terrain to the PostgreSQL Database from the Javamenu or jtlsmenu “Alter aScenario Database” sub-menu.

25 May 2020 150 JTLS 6.0.0.0


Expected Results: The new terrain should be loaded without incident. Check the directory$JTLSHOME/data/scenario/wespac60/load for any *.bad files. If there are none, the loadwas successful.

Step 17:Download the scenario and run an SVP.

Expected Results: The SVP should complete without incident. There may be several terrainerrors such as targets in the water or ships on land. Do not worry about these because theterrain created was not well defined to keep the time needed to conduct the test to aminimum.

Step 18:, Setup the scenario, and bring up the game with the scenario.

Expected Results: The scenario should come up without and the terrain should look as it didin the GIS Tool.

7.11 Test Importing Checkpoint Into Database

Purpose: The purpose of this test is to ensure that the loading of a checkpoint back into thedatabase capability is working with PostgreSQL. O

Note: Only a single database scenario builder should be testing this capability, given that the testinvolves creation of the related PostgreSQL user (role) and schema creation and execution ofrelated database scripts. Once the checkpoint data files are loaded into the database, thenmultiple scenario builders can work concurrently to view and verify the loaded checkpoint datausing Database Development System Clients (DDSC).

Step 1: Select an existing JTLS-GO game (scenario) that includes a checkpoint. Thecheckpoint should have new units and targets created and change some initializationdatabase parameters changed.

Step 2: Determine the new target scenario name to be used. For example, ra6.

Step 3: Following the instructions in the DDS User Guide, have the Database Administrator tocreate the related PostgreSQL user (role) and schema for the new scenario name.

Step 4: Use the JTLS-GO javamenu “Database Development System Menu”, item 9 “Preparea Checkpoint for DDS. Select your game scenario from the “Scenario” pull down list,then select the checkpoint number you want to load back into the database from the“Checkpoint” pull down list and finally enter a new scenario name, which you decidedin Step 2 above. Click on the “OK” button.

Expected Results: This will invoke the “checkpointToDds” script and create a new scenariodirectory called “ra6”, for this example, under the $JTLS/data/scenario/ directory.

JTLS 6.0.0.0 151 25 May 2020


Step 5: Verify the new scenario prior to loading into the database. This step determines ifthere are any referential issues with the data.

Expected Results: The SVP should not crash or enter the debugger due to a “Logic Errors”. Ifthere are any, the test cannot continue because the load will not properly work.

Step 6: Load the new scenario into the database using javamenu “Database DevelopmentSystem Menu”, option 4.

Expected Results: The load should complete normally, and there should be no “bad” filesgenerated.

Step 7: Setup GlassFish for the new scenario.

Step 8: Have several user access the new database to verify the data looks as it did inCheckpoint 0005.

Expected Results: The DDS tables should have the data that existed in the selectedcheckpoint.

25 May 2020 152 JTLS 6.0.0.0

jtls-2019-14357 move from oracle to postgresqljtls-2019-14357 move from oracle to postgresql zafer...

Documents