Publication Date:  17 February 1996
System Version:  GCCS 2.1/Update 4
Web Page Created:  20 March 1996

Setup.  To accomplish this lesson, you will need GCCS connectivity and access to the JOPES database and JOPES applications (Session Manager, System Services (SS), Requirements Development and Analysis (RDA), Scheduling and Movement (S&M), and Transportation Component Command External System Interface (TCCESI)).  Your USERID must have Create (CRT), Update (UPD), and Network Functional Manager (NFM) permissions.  Your USERID must also be able to execute the functions in the TCCESI application.

Overview.  For the next few hours, you will cover a lot of information.  You begin this lesson with an introduction on how to support an operational deployment.  You will use the tools available to you to upload a plan to the JOPES database, merge additional records into it, and add some transactions to it as well.  You will also modify some of the basic OPLAN characteristics, such as access, C-Day, and networking.  Next, you will build and use a force module as the entering argument to the Transportation Component Command External System Interface (TCCESI) application to perform the validation through manifesting process.  Upon completion of the deployment, you will clean up the files associated with the plan.

With that in mind, you will begin with how the FM can create a database on the local server using TPFDD or transaction data from several different sources.

OBJECTIVE.  Given a JOPES environment, load an exercise, restricted access, local, unclassified OPLAN on the local server.

Loading JOPES Information/Data.  Most JOPES TPFDDs are not created from scratch using RDA.  The usual starting point is last year's exercise, perhaps last year's plan, or even something that was similar a couple of years ago.  The starting point could also be some other piece of software such as a different or service unique application.  Dynamic Analysis and Replanning Tool (DART), Joint Flow and Analysis System for Transportation (JFAST), or Marine Air Ground Task Force II (MAGTF II) are three other applications that come immediately to mind.
OPLAN Loading.  OPLANs or TPFDDs that have been stored on tape or in a file or that have been created on some other system can be entered into the JOPES database using various options in the System Services application.
OPLAN or TPFDD.  The SS application uses the words OPLAN and TPFDD.  Within this application, those words mean two different things.  An OPLAN is in transaction format and can contain both requirements data and scheduling and movement data.  A TPFDD is in TPFDD format and contains only requirements data.  This is important to you because an OPLAN cannot be uploaded to the JOPES database using one of the TPFDD options and, conversely, if your data is in TPFDD format, the OPLAN options will do you no good.

Tape/Disk or File.  The source of your OPLAN or TPFDD, if not already on the JOPES database, will usually come from one of two different locations.  The information could be external to the system, that is, on a magnetic tape or a floppy disk stored in a vault or in a safe somewhere.  It could also be stored in someone's personal file on the system somewhere, just not in the JOPES database.

It doesn't really make any difference where it is, your task is to get it from its current location into the JOPES database.  That is called Loading the Plan.

Loading a Plan.  TPFDDs can be imported into the JOPES database from tape/disk or file media via the System Services' Load Plan from TPFDD option.  OPLANs can be imported into the JOPES database from tape/disk or file media via the System Services' Reload Plan option.  Both options are available from the Plan Management tear-off menu.  Both are similar in operation.
Load Plan from TPFDD.  The Load Plan from TPFDD option allows you to reload a TPFDD text file.
This type of file was created or can be created by the System Services Create TPFDD File option, JFAST, and MAGTF II.

This option will initialize an OPLAN shell in the database to receive the records.

Reload Plan.  The Reload Plan option allows you to reload an OPLAN file.

This type of file was created or can be created by the System Services Offload Plan option or by DART.  A future version of MAGTF will also create a transaction file.

This option will initialize an OPLAN shell in the database to receive the records.

Requirement.  Use the Reload Plan option to reload OPLAN 9096M into the database.  OPLAN 9096M contains only Army records and it is the one that you previously offloaded to a file in your user storage area.  You will reload it into a new OPLAN (909XT).  During the reload process, you will be required to initialize 909XT as an exercise, restricted, local, and unclassified OPLAN.

After you select the media type and location, you can type the number of the OPLAN to be loaded in the plans column or have the program list all available plans on the media selected.

You can reload all the plans back into the database or identify plans to remove from the list by clicking on the Remove From List toggle.

Set C-Day.  If this toggle is selected, then you will receive a follow- on screen allowing you to set C-Day.

Reset Carrier Names.  If the carrier names are reset, the reloaded carrier information will be renamed according to the following convention:  the first five characters are retained; followed by the OPLAN ID; followed by a five character sequence number.  Duplicate carrier transactions are always rejected because the JOPES database does not allow duplication of carrier names.  However, if a carrier's characteristics and itinerary did not change while the OPLAN was stored in the file, the reloaded OPLAN movement requirement records are relinked to the existing carrier's itinerary.

Reset SSF/PIF Flags.  If this toggle is selected, then these fields in the database will be set to null.

Print Error Log.  If you want a printed report of the errors that occur during the reload, then you would depress this toggle.

This window allows you to modify the characteristics for the new OPLAN ID you will create during the reload.
Database Area (Exercise/Real World).  OPLANs have a database area assigned:  real world or exercise.  The database is not split into two parts.  The area distinction is just a data field associated with each OPLAN to facilitate information retrieval.

Plan Type (Normal/Restricted).  There are two types of OPLANs:  normal and restricted.

A normal OPLAN is accessible by everyone who has permission to that particular OPLAN number series.

A restricted OPLAN is accessible only by those individuals who have been specifically granted access by USERID.  When you initiate a restricted OPLAN, a follow-on window displays to identify the USERIDs for access.  Either type can be initiated by someone with CRT, SFM, or NFM permissions.

Note:  To change a local plan's type, the operator must be the creator, Site FM, or Network FM.  To change a distributed plan's type, you must be the creator or Network FM.

Granting Access.  Because you are initializing a restricted OPLAN, an additional window will display allowing you to copy USERIDs from another plan, import them from an ASCII file, or you may specify the specific USERIDs to have access to this OPLAN.  Your USERID will automatically post to the first USERIDs field.  It cannot be changed or deleted.

Plan Distribution.  An OPLAN can be resident on the local server or it can be distributed (networked) so that it is also resident at other sites' servers as well.

You must have the Network FM permission assigned to distribute (network) OPLANs.

A follow-on window appears to identify site servers to receive the OPLAN.

When processing is complete, note if there were any processing errors and also note the directory/file location of the error report.  You can use the FTPtool application to view the report on-line.

Your new OPLAN, containing only Army records, is now available in the database for editing and manipulating as required.  The Merge TPFDD option also imports plan data.  To execute the Merge TPFDD function, return to the GCCS System Services tear-off.

OBJECTIVE.  Given a JOPES environment, use the System Services capabilities to merge JOPES TPFDD files.

Requirement.  Use the Merge TPFDD option to add the Marine TPFDD that you previously uploaded from a floppy disk into a file in your user storage area.  Add this Marine TPFDD into your OPLAN (909XT).

Merge TPFDD File.  Merge TPFDD will merge TPFDDs into an existing OPLAN.  The process merges the TPFDD data by inserting new data or modifying existing data.  The merge capability is limited to tapes or disk files as a source of TPFDD information.
To perform a merge, you must have UPD, SFM, or NFM functional permissions for the target plan and read permissions to the file.

To begin the process, you must specify the target OPLAN and up to three TPFDD source files on disk and/or up to three on tape.

You can specify the processing order for the merge.  The last unique record to merge will overwrite the previous ones.

You can run the job in the foreground (wait for the job to complete) or background (have the system give you a Process Identification (PID) number).

You can also limit the records selected for the merge.

The merge will not update protected data fields of a locked target OPLAN.

Note:  The locked plan's data fields are only protected for the records that have a Schedule Status Flag (SSF) field entry.

Note:  The Merge Report is sent to a file on the server.  The default pathname is /h/SM/data/user_files/{userid}/Merge_Report_{date}_{time}.  You must access the server via FTPTool or telnet to view the contents of this file.

The Merge TPFDD option is only one of a number of ways to transfer files from a system into the JOPES database.  The merge works with a TPFDD formatted tape/disk or file.

OBJECTIVE.  Given a JOPES environment, execute the process for updating a JOPES OPLAN using transactions from an external source.

Requirement.  Use the External Transaction Processor option to add Air Force requirement records (transaction format) that were created and manipulated using an external or unique application, such as DART.  This is the other file that you previously loaded from a floppy disk into your user storage area.

Transaction Updates.  The JOPES database can be updated by entering a series of transactions (a transaction file) into the local JOPES database and the Send Queue using the External Transaction Processor capability.  The name of the OPLAN in the JOPES database and the name of the OPLAN in the transaction file must be the same.  This series of transactions or a transaction file could have been generated by a stand-alone version of DART, by the System Services Offload Plan option, by the next version of MAGTF II, or some other external application.  You must have at least update (UPD) permissions to the plan identified within the transaction file.
File Identification.  The top portion of the window requires the operator to enter three file names.
Transaction File Name.  You enter the full path and file name of the file that contains the transactions.  In most instances this would probably be the users home directory.

Message Log File Name.  You enter the full path and file name for the message log that will store information concerning valid and invalid generated transactions.  If the file name already exists, then the existing file is overwritten.

Report File Name.  You enter the full path and file name for the file that will contain the final summary level report.

Processing Option.  The center portion of the window allows the operator to select three different processing options.

Validate Only.  If you select the Validate Only option, then the XTP will process the transaction file and provide you a report concerning the validity of those transactions.  None of the transactions are applied to the JOPES database.

Update Database With Valid Transactions.  If you select the Update Database with Valid Transactions option, then the XTP will process the transaction file and forward the valid transactions to the JOPES database and the Send Queue.  A report on the validity of all of the transactions is generated.

Update Database Only If All Are Valid.  If you select the Update Database Only If All Are Valid option, the XTP will process the transaction file.  If all the transactions are valid, the transactions are sent to the JOPES database and the Send Queue.  If even one transaction is invalid, then no transactions are forwarded for OPLAN update.  In either event, a report on the validity of those transactions is generated.

Process Transactions In.  The last option on the window allows the operator to execute this process in the foreground or in the background.

Foreground means that the system will provide an XTP Messages window to monitor the progress of the transaction update after you click on Transmit. 

Background means that the system will provide a PID number in the message line after you click on Transmit.

System Identifier.  This four character field is to be used for future external systems such as COMPESS.  Each transaction will be identified by its source system.

Output Options.  By clicking on the Print Report File toggle, a hard copy of the report would be generated at your default printer.

You now have an OPLAN on the database that has the required forces in it.  However, before an OPLAN goes into execution, the operators, of which the FM is one, may have to go through several processes.  This could include changing the plan's type, distribution, and access, as well as setting C-Day.

OBJECTIVE.  Without references, set or reset an OPLAN C-Day and L-Hour, change a plan's type and status, and modify its distribution.

Requirement.  Use the Plan Maintenance option to prepare an OPLAN for execution by modifying the plan characteristics.  Specifically, set C-Day and L-Hour to 1 January 1996 at 0001Z, modify the Plan Type from Restricted to Normal, confirm that the plan is in an unlocked status, confirm an appropriate classification, and distribute the plan to other sites, as appropriate.

Plan Maintenance.  The initial Plan Maintenance display provides the user three options with respect to a specific plan.  The PLAN ID you enter and the toggle you select determines which options will appear next.  If it is an existing PLAN ID and you select modify, then the follow-on options will display administrative data fields to modify the characteristics of that specific OPLAN.  If you select delete, you will receive a confirmation pop-up.  If it is a new OPLAN and you select initialize, then you will be shown the applicable data fields required to initialize a new OPLAN.

OPLAN Modification.  Given the appropriate functional permissions, you can modify most of the information on this or the following windows.  If you do not have the appropriate permissions or specific options are not possible, then one or more options will be dimmed out (not available).  In some cases, you are able to select an option, but will receive an unable to execute message based on USERID.

In addition to changing what you selected when loading the plan, you can now select other fields/toggles to change the Plan Title, enter or change C-Day and L-Hour, reset C-Day to a blank, lock or unlock the plan, or reset the TCC indicators and movement schedules for AMC, MTMC, MSC, and organic carriers.

Plan Title.  The plan title was automatically entered when you initially uploaded your plan.  It is modifiable on this screen.

C-Day and L-Hour.  The C-Day and L-Hour fields allow you to set or change the C-Day and L-Hour for a plan and update the database with the changes.  You must be the plan creator or the Site/Network FM to set or change C-Day and L-Hour.

Reset C-Day.  If there are entries in the C-Day and L-Hour fields, then the Reset C-Day toggle causes the C-Day and L-Hour fields to be grayed out.  Upon selecting Transmit, a confirmation pop-up will appear.  Execution of the Reset C-Day option causes these fields to go back to blanks.  It also deletes all the movement requirement carrier allocations and manifests for the plan and deletes any carriers associated with this plan that are not associated with any other plan.

Plan Type.  The Plan Type controls the accessibility/releasability of the plan.  Individuals needing access to a Restricted access plan must all be specifically identified by USERID.  A normal access plan is accessible by everyone who has access to that specific series of OPLANs.  The plan type can be changed from restricted access to normal access.

Plan Status.  Only the plan creator or an FM can modify the Plan Status of a Local plan.  To lock or unlock a Networked plan, you must be a Network FM.

Plan Distribution.  Plan Distribution can only be changed from local to distributed by the Network FM.

If the OPLAN is to be distributed to all database sites, click on the Enter All Sites toggle and all of the site identifiers will post to the window.  A distribution list can also be copied from another existing plan or you can simply type in the identifiers for the sites to which the plan will be distributed.

Classification.  The plan's classification can be changed, as appropriate.

TCC Indicators.  Selecting the TCC Indicators toggle displays a second window to reset TCC indicators for all or selected carrier schedules.  The indicators are changed and carrier allocations/manifests are deleted as defined by the selections chosen on the window.

Note:  TCC indicators show the Status to the POD as Part(ial) or Full(y) allocated/manifested for each requirement record.  These indicators are visible when using the S&M application.

Now that this plan has the records in it that are required and the plan characteristics have been modified as appropriate, it is time to begin your study of the validation through manifesting process and the TCCESI application.

Before launching the TCCESI application and exploring the screens, you should first be familiar with its purpose and what it is supposed to do.

OBJECTIVE.  Given a random list of the steps in the validation through manifesting process, put them in the proper order.

Validation Through Manifesting Process.  The TCCESI application software was designed to assist with the problem of stabilizing and coordinating, to the maximum degree, the ever changing movement requirements during OPLAN execution.  This is the validation through manifesting process.

You will also be exposed to procedures the JPEC could follow and the roles and responsibilities of the Site Validator.  Additionally, this lesson covers the effects of this process on the JOPES database, what TPFDD data fields are involved, and the software tools available.  It concludes with the use (hands-on) of the TCCESI application software to demonstrate the validation through manifesting process and the characteristics and capabilities of this particular application.  You will also be introduced to the JOPES interface with the TCC automated systems.

Validation Process.  The validation process begins with the Supported Commander identifying requirements for sourcing and subsequent validation.
Purpose of the Validation Process.  The validation process allows the Supported Command to reaffirm the types of forces it wants and the Supporting Commands to confirm the readiness of the units they select to fill those requirements.  The process includes confirming database accuracy before USTC and the TCCs begin the scheduling process.
Verify Correct Forces.  The Supported Command checks the TPFDD and ensures that the types of units in the database are, in fact, the types needed to counteract the threat that is currently being faced.  The staff verifies both the types of units and the planned timing of their arrival in the AOR.

Ensure the Accuracy of the Data Relative to Deploying Forces.  The Supported Command ensures an increment of strategic movement requirements; normally, the air validation increment is by the earliest arrival date (EAD) and six days from the current C-Day, while the sealift validation increment is by the latest arrival date (LAD) and for 30 days.  The Supported Command verifies that each field that has any transportation significance is complete and accurate.  The CINC has a couple of automated tools to assist him, primarily the Transportation Pre-Edit Report and the Logical Errors Report.

Principal Validation Players.  The primary JPEC players in the validation process are listed below.

Supported Commander.  The supported commander identifies requirements for sourcing, validation, and movement.

Supported Commander's Components.  The supported commander's components work with the Services and other force providers to ensure the proper forces are available to support the dates in the OPLAN.

Supporting Commanders.  The supporting commanders provide forces to support the OPLAN.

Force Providers.  This group provides forces to support the OPLAN.

Pull Process.  The pull process begins with USTRANSCOM recognizing the records that the Supported CINC has identified as ready for scheduling.

Purpose of the Pull Process.  The pull process starts the movement planning for the strategic move.  It takes supported command validated movement requirements and begins assigning lift capability.  USTRANSCOM does two things:
Identify the First/Next Increment of the Supported Commander's Movement Requirements.  USTRANSCOM identifies that requirements have been verified as being ready for scheduling.  It also pulls the requirements that have an impact on Air Mobility Command, Military Sealift Command, and Military Traffic Management Command.

Verify Database Accuracy.  USTRANSCOM ensures the accuracy of the transportation significant portions of the records in the database.  It also verifies that the requirements have no transportation errors and are ready to be scheduled by the TCCs.  A Transportation Pre-Edit Report will assist in detecting those types of problems.

Principal Player.  USTRANSCOM is the major player in the pull process.

Allocation Process.

Purpose of the Allocation Process.  The allocation process identifies required lift assets, develops carriers, and disseminates schedules.
Identify Required Lift Assets.  This step analyzes the lift requirements and allocates enough lift assets to move them in the time allowed, i.e., get the forces to the AOR before the LAD.

Develop Carriers.  This step develops carrier names, itineraries, and lift capacities.

Disseminate Schedules.  This step adds carrier schedules for specific planned movement requirements into the JOPES database where they are available for all to see.

Principal Players.  All three of USTRANSCOM's components have a role in the allocation process.

AMC.  AMC gets the movement requirements from USTRANSCOM, puts them through their automated scheduler (ADANS and then into GDSS), and then through an automatic interface into GTN.  From there, the scheduling information is fed into JOPES.  Allocated requirements to scheduled air missions are then identifiable in the database.
Automated Scheduler.  Airlift Deployment Analysis System (ADANS) is AMC's tool for creating airlift schedules.  Schedules include the carrier names, itineraries, and the lift capacities.  The ADANS schedule is fed into the Global Decision Support System (GDSS), AMC's command and control system.

Automatic Interface.  From GDSS, the schedules and any changes to previous airlift scheduling information is passed through GTN into JOPES.  The JOPES database is automatically updated.

MSC.  MSC receives its movement requirements (ports and volumes) from USTRANSCOM via MTMC.  MSC builds the ships schedules and can manually enter them in JOPES via the S&M application.  Requirements are then allocated and subsequently manifested to scheduled sealift missions by MTMC for CONUS ports and the Supported Commander's port authority for Non-CONUS ports.
Automated Scheduler.  MSC can use an automated scheduling system called Strategic Planning and Analysis System (SEASTRAT) to determine the number of ships required early on (gross planning).  However, SEASTRAT is a planning system only and not used during execution.

Automatic Interface.  Presently there is no direct interface between SEASTRAT and JOPES.  All sealift schedules are hand jammed into JOPES using the S&M application.

MTMC.  MTMC gets its movement requirements from USTRANSCOM via an Ad Hoc Query retrieval and puts them into their automated scheduler.  The schedules (trucks and trains) can then be put into JOPES via the S&M application.

Automated Scheduler.  MTMC uses an automated scheduler called Strategic Deployment System (STRADS) to create intra-CONUS schedules for MTMC movement responsibilities and to develop stow plans for ships.  Note that STRADS is a planning system only and not an execution system.

Automatic Interface.  Presently there is no direct interface between STRADS and JOPES.  All MTMC derived information must be manually entered into JOPES.

Manifesting Process.  Many organizations have a role in the manifesting process.

Purpose of the Manifesting Process.  The manifesting process reports actual carrier loads and assists the supported commander in planning onward movement of deploying forces (POD to destination).
Report Actual Carrier Loads.  The manifesting process is used to report which specific cargo and/or passengers are actually on a specific carrier.

Plan Onward Movement.  The Supported Commander can use the manifest to plan the onward movement of his passengers and cargo and determine feasible unit closure dates.

Principal Players.  The following are major players in the manifesting process.

Force Providers.  Force providers are partially responsible for sequencing and monitoring the force/sustainment deployment.  For example, FORSCOM has a major role of supplying and manifesting the majority of the Army forces.

Supporting Commander.  The supporting commanders have a similar responsibility to that of force providers.  They are responsible for supplying combat ready forces in the sequence the supported commander requests.  They must work to get them to the port on time via the selected mode of transport and see that they are manifested to a carrier.

Supported Commander.  The supported commander has a vital interest in the arrival of forces in the theater.  He/She must plan onward movement from POD to destination and employ those forces within the concept of operations.

USTRANSCOM.  USTRANSCOM is interested in the manifesting process for two reasons:  to ensure sufficient lift has been allocated to meet the CINC's actual requirements, and to answer intransit visibility questions.

OBJECTIVE.  Given a list of the possible effects of the validation through manifesting process on the JOPES database, identify those that are true.

Locking/Unlocking the OPLAN.
Purpose for OPLAN Locked/Unlocked Status. 
Locked.  An OPLAN can be put into "Locked" status to preclude uncoordinated changes to the transportation significant data fields of the validated ULNs.  Any change must then be coordinated with the supported command and/or USTRANSCOM.

Unlocked.  From a software point of view, if the OPLAN is left in an unlocked status, then immediate or uncoordinated changes can be made by anyone with "update" permissions.  Procedurally, users should only change the specific fields for which they are responsible.

Effect on the database.

Locked/Unlocked Status.  In order to determine if the OPLAN is in locked or unlocked status, you can check the System Services Plan Maintenance window for the specific OPLAN in which you are interested.
The System Services Plan Maintenance window will show a Plan Status of Locked or Unlocked.  You can also check on the RDA Main Menu window which displays a list of the OPLANs to which your USERID has access.

The RDA Main Menu Window will show a Status of Locked or Unlocked.

Note:  An OPLAN's status is also visible on the RDA OPLAN Summary Window.

Protected Fields.  When an OPLAN is in a locked status and there is an entry in the SSF field, then the following data fields are protected and the entries cannot be changed without special permissions or coordination.
Quantities (passengers and cargo).

Strategic leg info (time, location, mode, and source).

Schedule Status Flags (SSF), Problem Indicator Flags (PIF), and Data Flag Last Set Date fields. 
Schedule Status Flags. 
Purpose. 
Identify records with protected fields if OPLAN is in locked status.

Identifies the record's current scheduled status.

Valid Entries. 

V - Validated.  The "V" is system assigned when the supported CINC executes The Supported CINC Validation Menu option on a set of records that are ready to be scheduled for movement.  The "V" indicates that the requirement has passed the edit checks and can be scheduled by the TCCs.  Movement requirements not passing the edit check will automatically be identified with a PIF of "E."

T - TRANSCOM Accepted.  USTRANSCOM provides its components the validated supported CINC movement requirements via the USTC Requirements Pull Menu option.  This option also has a built-in edit check.  The edit checks this increment of records to make sure no "fatal" errors (errors which preclude TCC scheduling) have been introduced since validation.  The system assigns a "T" (replaces the "V") to ULNs passing the edit (accepted for movement), and a "Pull file" is created.

A - Allocated.  Requirements that are allocated (planned) against scheduled missions are system assigned with an "A" (replaces the "T").

B - Both Allocated and Manifested.  If the ULN has been allocated, then upon manifesting, the system generates a "B" flag to replace the "A."

M - Manifested.  If ULNs are manifested on a carrier but have not been through the allocation process, then the SSF will be changed to an "M" (manifested without allocation).  If the record has not even been validated, it will also get an "N" as a PIF code.

Z - Manifested, but Some Data Fields may be Changed (Required Passengers/Cargo).  If transportation significant changes need to be made to allocated "A" and/or manifested "M" records, then the SSF code must be manually changed to a "Z."  This unlocks the quantity fields so users can correct those fields after allocation/manifesting (even in a locked OPLAN).  USTRANSCOM is the only agency that can enter the "Z."

Space/Other.  There is no scheduling status associated with this record.

Problem Indicator Flags.

Purpose.  Identifies "validated" for scheduling records with problems that preclude complete scheduling.

Valid Entries.

E - Machine generated code indicating failure of the transportation pre-edit check.

C - Manually entered code by the supported CINC to allow modification of the "quantities" field of previously validated ULNs.

P - Manually entered code indicating transportation problem identified by AMC.

M - Manually entered code indicating that the SPOE and/or SPOD can be or has been changed by MSC.

X - Manually entered code indicating transportation problem identified by USTRANSCOM.

N - Machine generated code indicating requirement was manifested before validation.

Space/Other - No problems associated with this record.

Data Flag Last Set Date.  The Data Flag Last Set Date shows the latest change date for the SSF or PIF.

Now that you are familiar with the validation through manifesting process and the SSFs, PIFs, and Data Flag Last Set Date fields, you will turn your attention to the primary application that supports the process and effects the flag changes.

OBJECTIVE.  Given an operational JOPES environment, use the validation through manifesting supporting software contained in the TCC External System Interface application.

TCCESI Menu Options.

Note:  There are six options that are available from this window, however, not all options are always available.  For example, of the options listed below, the TCC Problem Indicator Flag Override option does not appear on this window.  Only those options available to you will be displayed.  The options displayed are controlled by your USERID.  In this specific instance, your USERID begins with JD which is not the first two letters of either an AMC, MTMC, or MSC USERID.

Supported CINC Validation.  Performed by the supported command when it is satisfied the requirements are ready for movement and that the ULNs contain no errors that would preclude TCC scheduling.  Any ULNs passing this pre-edit check will be flagged with a "V."

Supported CINC Status Flag Override.  This function allows the supported command to "invalidate" any previously validated ULNs.  This will set the SSF to a space on the database or set the PIF to a "C" which allows the quantities fields to be modified.

Reports and Utilities.  The Reports and Utilities function provides a limited reports capability and some database management capability.

USTC Requirements Pull.  This function allows USTRANSCOM to pull ULNs that are flagged as "Validated."

TCC Problem Indicator Flag Override.  This function allows an AMC user to identify a ULN as having a problem that should be solved prior to scheduling.  It also provides MSC the ability to set the PIF to an "M" which allows the SPOE and/or SPOD fields to be changed.

USTC Status/Problem Flags Override.  This function allows a USTRANSCOM user to set the SSF and/or PIF for a specified ULN, FM, or OPLAN.

Now that you are familiar with the validation through manifesting process, the SSFs and PIFs, and the agencies who have various responsibilities for setting those flags, please complete the following short practical exercise.

Requirement.  The Supported Command has locked the OPLAN.  However, after the command has validated a ULN for movement and USTRANSCOM initiated a USTC Requirements Pull, the situation in the AOR changed.  The commander now wants an A-10 unit moved up in the flow (it has not been validated) to replace a validated Hawk unit.  The Hawk unit will be delayed approximately 30 days.

Permission Requirements.  Several permission safeguards are built into the TCC External Systems Interface application.  In order to access and execute the TCCESI menu options, the user must have the following permissions:
Access to the OPLAN.  If it is a normal access plan, then access to the series is required.  If it is a restricted access plan, then your USERID must be granted access.

Site Validator Functional Permission.  In Version 2.1, these permissions are granted by the SA at system level.  In a future version, the granting of this permission is migrating to the FM via the Permissions Window of the SS application.

USERID Controlled Options.
To be able to execute specific options in this application, the users' USERID must reflect that specific role.  Specific OPLAN Supported CINC roles are determined by the first two characters of the USERID and the OPLAN Series.

To be able to execute the specific USTC or TCC options, the first two characters of the users' USERID must reflect a USTRANSCOM or TCC user.  All permission checks are performed by the system before the user is allowed into the specified option.

Requirement.  The supported command staff has created a TPFDD to support a deployment of forces.  An Execute Order has been received and you (the Supported CINC Site Validator) are the individual responsible for validating the movement requirements.  Coordination with USTRANSCOM and the JNOCC has been accomplished.  USTRANSCOM is expecting you to validate the first six days of airlift movement requirements to be followed by a daily verification cycle.  You have already coordinated with your components and have been assured the data for the first six days of airlift requirements is accurate.

Validation Process.  The entire validation process is the responsibility of the Supported Command with assistance from the components.  The components do the required coordination with the organizations that provide the forces, i.e., source the records.
Prepare Records.  The supported command is responsible for preparing the OPLAN and identifying the records for scheduling actions.
OPLAN Lock/Unlocked Decision.  One of the first decisions the supported command should make is whether to execute this plan in a Locked or Unlocked status.  Coordination with your components, USTRANSCOM, and the JNOCC has been completed, and this OPLAN will be executed in a Locked status.  To do this, use the System Services application.  The user must be the Plan Creator or have Site or Network Functional Manager permissions to execute this function.  In addition, the restrictions shown in Table 5-1 apply.

At this point, you have not yet protected the fields of any specific records.  All that you have done is determined that when you begin validating records as being correct, then certain transportation significant fields will be protected.
Identify Records.  The next step you must accomplish is the identification, in the database, of the records that are to be processed through the verification process.

Force Module Creation.  To initiate that process, in order to use the TCCESI application, you must first put the specific records you wish to validate in a force module.  The creation of that force module and the identification of the records to put in that force module can be done using RDA.

Now that you have the appropriate records identified, it is time to put them in a force module.

Now that you have identified the records that should/need to be validated, you are ready to proceed to the actual validation step using the TCCESI application.

Note:  Iconify the two RDA windows.

Demonstrate Supported CINC Validation Option.  The options displayed on this window are a function of the first two characters of your USERID.
Perform Requirements Validation.  The OPLAN identified on this window becomes the active OPLAN and is carried forward to the subfunctions of this application with one exception, which will be pointed out later.

The Supported CINC Validation option provides the supported command Validator with two options regarding the force module about to be validated.

Note:  All reports generated by the TCCESI application will be in the landscape format and will be automatically printed at your default printer.

Reports only:  the validator can generate reports for the records, identified by a specific FM, being considered for validation.  In this instance, no entries are generated for the SSF or PIF fields in the JOPES database.  There are two reports that can be produced.
The first report is the Transportation Pre-Edit Report which is identical, in edit checks, to the report generated by the RDA and Reports application option Transportation Pre-Edit Report.  The records included in this report are those records in the identified force module plus (if this is not the first time that this menu option is being executed) all records in the OPLAN that already have a V or T in the SSF field.  This Transportation Pre-Edit Report will be separated into two parts.  The first part will be the report concerning the records that had the "V" or "T" indicator, and the second part will be the report concerning this specific force module.

The second report that is generated is the Plan Compare Report, which is identical to the RDA Plan Compare and the Reports application PID Comparison reports.  This report will include all records with an "A," "T," or a "V" in the SSF field and displays everything that has changed since the last validation cycle.

Actual Validation and Reports:  the validator can produce those same reports, mentioned above, (by default, a copy is always printed at USTRANSCOM) as well as mark the records in that force module as having passed (SSF Code - V) or failed (PIF Code - E) the Transportation Pre-Edit check.

The execution of this option also creates seven empty TPFDD files in pathname /h/data/local/esiflatfiles/validate/{OPLAN}/RQMNT01 through RQMNT07 and runs a System Services Create a TPFDD option in the background.  The records that were marked with a "V" in the SSF field are copied to the first TPFDD file.  The next time, and all subsequent times that a force module is validated, the Transportation Pre-Edit Report is generated, records are marked with a "V" in the SSF field or an "E" in the PIF field, a Create a TPFDD option copies all records in the database with a "V", "T", or an "A" entry in the SSF field to the next TPFDD file, and a Plan Compare Report is generated.

The maximum number of TPFDD files created is seven.  When the Supported CINC Validation option is executed for the eighth time, it will overwrite the first TPFDD file.  The ninth time will overwrite the second, and so forth.

Note:  When the Reports Only option is executed, the records in the force module and those with a "V", "T" or an "A" in the SSF are put into a temporary TPFDD and the Plan Compare Report is generated.  After that report is generated, the temporary TPFDD file is deleted.  When the Actual Validation and Reports option is executed, the seven permanent TPFDD files are used.

Produce a Transportation Pre-Edit Report.  By choosing the Actual Validation and Reports option, you not only produced a Transportation Pre-Edit Report, but also marked records in your OPLAN as having passed or failed that edit check.  Your copy of the report will print on the default printer as designated by your SA.
The Transportation Pre-Edit Report comes in three sections.  The first section contains all the errors induced to records that have been previously pulled by USTC (i.e., all records that had an SSF of "T" prior to this validation cycle).  The second section contains all the errors that exist in the force module currently being validated.  The third section is a summary of ULNs processed, passed, failed, and ignored.  Ignored ULNs are records that are parents, on-call, etc.  Figure 5-20 provides a sample report.

The second report generated is the Validation Compare Report.  This report comes in six sections.  Section 1 will list all ULNs that have an SSF of "V" or "T" when a transportation significant (protected) field has been changed.  The changes (before and after) will be displayed.  Section 2 will contain a list of all ULNs validated this cycle.  Section 3 will list the ULNs manifested this cycle.  Section 4 will list all ULNs that were previously validated and that have been deleted from the OPLAN.  Section 5 will list the ULNs that have been removed from validation but are still resident in the OPLAN.  Section 6 is a summary page.  The Validation Compare Report is generated the second (and all subsequent) time(s) that this menu option is executed.  Figure 5-21 provides a sample report.

Two records (ULNs 9AAD and 9AGH) have fatal errors.  Given this report, those two records should have an "E" in the PIF field while the rest of the records should have a "V" in the SSF field.

Review the Records.

The "E" in the PIF field was system generated as was the Flag Date entry of today.  This record failed the Transportation Pre-Edit Check because it was not sourced.

The "V" in the SSF field was system generated as was the Flag Date entry of today.  This record passed the Transportation Pre-Edit Check and is ready for scheduling action.

Note:  Two records (9AAD and 9AGH) have an "E" in the PIF field while the rest of the records in force module 9A1 have a V in the SSF field.  The records with an "E" in the PIF field are not ready to be passed to USTRANSCOM for scheduling.  The Supported Command should contact the Army component (the two are Army records) and ensure they coordinate with FORSCOM to complete the sourcing of those records.  After the two records have been repaired, the Supported CINC Validation option of the TCCESI application must be run to validate those two records.  If the two records are critical to the operation, then those records should be repaired now and the validation rerun.  If the two records can wait until the next time that validation will be executed (our scenario says every 24 hours), they can be added to the next increment.

Requirement.  You have contacted your Army component personnel to inform them about the two records requiring repair and they are taking it for action.  In the course of your conversation, they indicate that they want to change the EADs to two other records (ULNs 9AGD and 9AGE) that have already been validated.  However, the OPLAN is locked and that is one of the protected fields.  You concur with the need to change these EADs and will modify the two records to allow your Army component to modify those records.

Demonstrate Supported CINC Flag Override Option.  The supported command has the ability to remove the "V" from the SSF field.  The supported command can also override the locked rules by entering a "C" in the PIF field.
Remove the "V" from the SSF Field.  This is done using the Supported CINC Status Flag Override option on the TCCESI Menu.  By removing the "V", the transportationally significant fields that were protected for that particular record will become subject to modification.  It must be remembered that when the "V" is removed, that record is no longer validated and USTRANSCOM will not pull that record nor begin the scheduling process.  After changing the record, it must be run through the Supported CINC Validation option again if the supported command wishes to validate that record.

Add a "C" to the PIF Field.  This is also done using the Supported CINC Status Flag Override option on the TCCESI Menu.  By adding the "C", the transportationally significant fields that were protected for that particular record will become subject to modification.  It must be remembered that when the "C" is added, that record is still validated and USTRANSCOM will pull that record and perhaps/maybe begin the scheduling process.  After correcting the record, USTRANSCOM must be notified to start/continue scheduling this ULN.  In this instance USTRANSCOM would remove the "C" from the PIF field.

ULN or FM Capability.  The Supported CINC Status Flag Override option can be accomplished for either specific ULNs or for a specific force module.
The supported command can change the SSF of a maximum of 36 specific ULNs or a single force module from a "V" to a blank from this window.  The supported command can also change the PIF of a maximum of 36 specific ULNs, or a single force module, from a blank to a "C" from this window.  If a hard copy of the changed records is desired, write down the ULNs you modified.

Note.  As of Version 2.1, the ability of the TCCESI application to generate a "C" in the PIF is operational, however the Oracle database has not yet been modified to accept a "C" as a valid entry.

If you wanted to reset additional SSFs, you could do another 36 or a different force module at this time.

If you had used the force module option in lieu of the ULN option, then you would have gotten an FMID confirmation window after pointing and clicking on the Continue button.

Note.  Now that these records have been unvalidated, the Army component can manipulate the fields that had previously been protected.  After the EADs have been changed, the supported command is faced with the same decision faced earlier when the two earlier records failed the transportation pre-edit check.  Are the units represented by these two records important enough to the Concept of Operations to accomplish the Supported CINC Validation process again or can they wait until the next normal (in our scenario - daily) validation cycle?

What you have seen and done for the last few minutes is work with the JOPES software that has been developed to support the validation portion of the total process.  What you are about to do now is use the JOPES software which supports the Pull portion of the process.

Requirement.  You are now one of the individuals at USTRANSCOM who has Site Validator permissions.  You have been notified (either by a message (IRC, Newsgroup, or Autodin), phone call, or by looking at the OPLAN database) by the supported command that the first validation increment has been accomplished and the records have been so marked.  As the USTRANSCOM Site Validator, you must pull those requirements, verify their transportation accuracy, and pass them to the TCCs for scheduling lift.

Pull Process.  The pull process is initiated and accomplished by the Site Validator at USTRANSCOM.  The process includes the identification of the records ready for scheduling actions, verifying the accuracy of those records, and passing that information to the TCCs for action.  This portion of the lesson will demonstrate the USTC Requirements Pull Option.  The TCCESI option that assists USTRANSCOM in performing this function is the USTC Requirements Pull option.
Perform USTRANSCOM Requirements Pull. 

The mode and source entries on this window apply to the strategic leg (to POD) of the records in the OPLAN.  The user specifies the particular mode/source to be pulled (wildcarding is allowed).

The ULNs that have SSFs of "V" for validated or "T" for Pulled by USTRANSCOM and have the specified mode/source as their preferred routing to the POD will be identified for the Pull.

The identified ULNs are edited via the Transportation Pre-Edit to ensure they contain no errors that would preclude TCC scheduling.  Any ULNs passing the Pre-edit will be written to a Pull File (also located at pathname  /h/data/local/esiflatfiles/validate/{OPLAN}/{MS}PULL) accomplished by an SS Create a TPFDD option that runs in the background.  These ULNs will be displayed on the Pull Report.  Any ULNs passing the Transportation Pre-Edit and have the identified mode and source for their preferred routing to the POD will be flagged as "Pulled by USTRANSCOM" in the SSF field.

The site validator may execute this function with a "Reports Only" or an "Actual Pulled Requirements and Reports" option.  The "Reports Only" option will produce the Transportation Pre-Edit Report and the Pull Report; however, no ULNs will be flagged with a "T."  If the user chooses the "Actual Pulled Requirements and Reports" option, any ULNs failing the Pre-Edit Check will be flagged as an error.  ULNs passing the Pre- Edit Check will be pulled, and both reports will be produced.

This window displays the mode and source selected in words instead of codes.  This window also displays the default pathname to which the requirement records will be "pulled."  The actual name of the file is taken from the mode and source entries.  The Cancel button returns you to the previous window.

The reports (Transportation Pre-Edit and Requirements Pull) will print at the default printer and the appropriate SSFs and PIFs are added to the database.

USTRANSCOM CAT (Site Validator) personnel review these reports to ensure the records are transportationally valid prior to passing them on to the TCCs for scheduling.

Produce a Requirements Pull Report.  By choosing the Actual Pulled Requirements and Reports option from the USTC Requirements Pull window, you not only produced a Requirements Pull Report, but also a Transportation Pre-Edit Report.  Both reports are automatically printed.
The Requirements Pull Report displays a list of the requirements (identified by mode/source) that were pulled (assigned an SSF of "T") this cycle or that already had an SSF of "T".  It also has a summary page (by mode and source) for this pull cycle.  The last page is a summary of the OPLAN for this pull cycle.  Figure 5-28 provides a sample report.

The Transportation Pre-Edit Report is identically formatted to the one produced by the Supported CINC Validation option.  Figure 5-29 provides a sample report.

If records contained errors, coordination with the supported command would be required to resolve any difficulties.

USTRANSCOM Passes Requirements to Components.  After the difficulties (if any) have been resolved, USTRANSCOM will pass the requirements to the TCCs for scheduling actions.  AMC will be notified of the pathname that contains the requirements ready for strategic air movement.  AMC could then use the FTPTool application or FTP at the UNIX prompt to transfer that file to the AMC Host.  Personnel at AMC could use the ADANS software to generate aircraft schedules to be pushed into GDSS which is AMC's command and control system.

MTMC and MSC will also be notified that the supported command has verified an increment of requirements, USTRANSCOM has checked them, and they are ready for scheduling.  MTMC and MSC then pull hard copy requirements from the JOPES database for the increment of requirements that have been validated.  MTMC and MSC then manually enter schedules with those requirements.

After the TCCs have evaluated the movement requirements and generated lift schedules to move those requirements, the information will be entered into JOPES, which is the allocation process.

Allocation Process.  The allocation process is accomplished by the TCCs.
Effects of TCC ADP Support Software.  Only AMC currently has an automated method of entering schedules into JOPES.  MTMC and MSC manually enter their schedules into JOPES in the S&M application.
AMC.  GDSS automatically feeds scheduled and actual itineraries into JOPES via GTN.  GDSS updates JOPES via GTN on a periodic basis (generally every two hours, although this time is modifiable for each specific situation).  When GTN feeds a schedule into the database for a specific ULN, the SSF will change to "A".  The quantities (passengers and cargo) allocated to the aircraft will be displayed in the S&M application.

MTMC.  MTMC can use STRADS to begin the scheduling process, but must manually adjust those schedules for them to be usable.  As a reminder, there is currently no automated interface between STRADS and JOPES.  All MTMC generated information is entered manually in JOPES via the S&M application.  When MTMC manually enters schedules (trucks, trains, etc.) into JOPES, the SSF will change to "A" (allocated).

MSC.  MSC can use the SEASTRAT to do gross planning, but must also make manual adjustments to obtain useable scheduling information.  Its command and control system, Joint Visually Integrated Display System (JVIDS), does not interface with JOPES either.  All MSC generated information is manually entered into JOPES; again the SSF will change to "A" (allocated).

AMC is now in the process of generating several schedules and is entering them in their command and control system (GDSS), which, in turn, feeds that information into the JOPES system via GTN.  Those schedules, which were allocated to specific ULNs, will change the SSF from "T" (pulled) to "A" (allocated) for the ULNs that have been scheduled up to this point.  If AMC discovers a problem in scheduling a particular ULN, it does have the capability to flag that record.

Requirement.  You are one of the schedulers at AMC and are the individual having Site Validator responsibilities.  Two of the records passed to you from USTRANSCOM for scheduling, ULN 9B2AQ (three passengers) and 9B0C2 (one passenger), deploy to Sigonella which is a support location for forces operating near the AOR.  Those are the only requirements deploying to that location.  An aircraft stop for only four passengers is too small if a different transportation means is more timely and cost effective.  You have telephonically coordinated with USTRANSCOM and recommended that these two ULNs be deployed by the purchase of a commercial aircraft ticket.  USTRANSCOM has agreed to pass your recommendation to the supported command and requests that you flag the records in the JOPES database.

Note:  The USERID must be an AMC or MSC USERID to have access to this option on the TCC Interface Subsystem Menu (Fig. 5-30).

Demonstrate the TCC Problem Indicator Flag Override Option.  AMC and MSC both have the capability to manually flag (set the PIF) specific records in the database.

This window is used to manually set the PIF to "P" if it is blank or to "blank" if a "P" is present by AMC or to an "M" by MSC.  Access to this window is controlled by the first two characters of the USERID, so only AMC and MSC validators can access this window.  They can enter a single force module or up to 36 ULNs on this window.
The AMC user should identify a force module or any ULNs with problems by Selecting the Set Problem Indicator Flag to 'P' toggle and entering the force module or the ULNs on the window.  After the problem has been resolved, the AMC validator may set the PIF back to a "blank" by selecting the Remove Problem Indicator Flag toggle and entering the force module or the ULNs on the window.

The MSC validator should identify a force module or any ULNs with an SSF field entry when the SPOE and/or the SPOD needs to be modified to reflect the appropriate shipping itinerary.  By Selecting the Set Problem Indicator Flag to 'M' toggle and entering the force module or the ULNs on the window and using the Continue button, the PIF of those records will be changed to an "M".  This option is used by the MSC validator to override the locked OPLAN rules (regarding the SPOE and the SPOD) for the modification of validated requirements.

No other changes are authorized or available.  If hardcopy of this force module or these ULNs is desired, write them down.

Note:  If you were the AMC validator, then you would do the following.

In the JOPES database, the PIF for these records would now be "P".

If the Force module option is used, then a confirmation window (Fig. 5-32) requires the validator to reenter the force module for verification.

The window also displays the SSF and PIF fields.  If the validator enters a different force module or attempts to modify the SSF or PIF fields, then the previous window (Fig. 5-30) is displayed.

Now that those records have been clearly flagged to ensure that everyone knows which records are under discussion, USTRANSCOM will continue to coordinate with the supported command and pass on AMC's recommendation for deploying these four people.

Requirement.  You will now play the role of the USTRANSCOM Site Validator again.  Teleconference coordination with the supported command produces an agreement to move these four individuals by the most expeditious and cost effective method of transportation which is the use of a commercial airline ticket.  The appropriate mode and source code to the POD for these two records is "P" "C."  The supported command agrees to modify these two records to reflect that movement.

Demonstrate the USTC Status/Problem Indicator Flags Override Option.  Before the supported command can change the mode and source codes for these two records, someone must "unprotect" these protected fields in this locked OPLAN.  USTRANSCOM can do that using the USTC Status/Problem Flag Override option.
USTRANSCOM Options for Modifing Status/Problem Indicator Flags.

USTRANSCOM has two basic options on this window.  Flags can be modified by specific ULN or en mass by using the OPLAN or FMID options.
By Specific ULN.
When the USTC validator selects the Specific ULN toggle, then the 18 ULN and associated SSFs and PIFs on this window are active.  The USTC validator can identify the ULNs to be changed by entering the ULN on the screen with the desired values for that specific ULN in the SSF and/or the PIF fields.

This override capability will only let the USTC validator set the SSF to values of "V", "T", "Z", or space from an "A", "V", "T", "Z", or space.  Spaces, however, cannot be set to "Z."  Any PIF entry can be set to a "space," "P," "M," or "X." 

En Mass.

When the USTC validator selects the OPLAN toggle, then either or both the SCHD STAT and PROB IND fields can also be used.  In this case, the SSF and PIF for every record in the OPLAN are set to the values entered in those fields.  No modifications will be done to the flag if the field is not used.

When the USTC validator selects the FMID toggle, then the FMID field requires an entry.  The SCHD STAT and PROB IND fields function in the same way as for the OPLAN choice.

When using the OPLAN or force module options, the SSF for records that have been manifested will not change.  In order to change those records, demanifesting (changing the SSF codes of "M" or "B") must occur first.  PIF rules are the same as overriding by an individual ULN.

Supported Command Actions.  The supported command staff can now modify the mode and source codes to the POD for these two ULNs to reflect movement to be arranged by the supporting command.

Now that you have finished using the flag override features available in the TCCESI software, you should become familiar with how to retrieve records based on some of these flags.

Requirement.  GDSS via GTN periodically updates the JOPES database with aircraft itineraries and allocations.  CAT personnel at the supported CINC have begun organizing the shift changeover briefing and are desirous of knowing how many of the ULNs that have been validated have aircraft missions scheduled against them.  You have been asked to retrieve that information.

Note.  When the SSFs of "V" for validated and "T" for pulled were added to the database, they were basically done in blocks of records, either as force modules or all records meeting certain criteria for the mode and source to the POD.  When AMC schedules aircraft to satisfy movement requirements, the "T"s in the database will periodically change to "A"s as the missions are created and GDSS via GTN automatically updates JOPES.

That concludes our demonstration of the software that supports the allocation process.  In addition to using that software, we also demonstrated the use of the TCC and USTC Flag Override options.  The USTC Override option can be used when required.  The Override options are not necessarily a part of the allocation process, but can be used when necessary.  Now that ULNs and aircraft missions have been identified for each other, you will turn your attention to the manifesting process.

Manifesting Process.  Manifesting, in JOPES, consists of identifying the cargo and/or passengers that are actually on the carrier.  Passenger manifesting consists of the total number of passengers on a specific carrier.  Aircraft cargo is identified by STONs.  Sealift cargo is manifested in MTONs, square feet, or M barrels.  Trucks and rail are done in either STONs or MTONs depending on the method of transport for the strategic leg (air or sea).
Entered Manually into JOPES via the S&M Application.  Manifesting for TCC carriers is done in either the Add Group Manifests or the Add/Review/Modify Manifests menu pick in the Scheduling and Movement application.

Entered Automatically into JOPES via GTN.  Manifesting information can also be entered into JOPES via the GTN interface with JOPES.  GTN is the system that collects manifesting and movement data from numerous other sources.

SSF Changes.  After manifesting information is entered into JOPES (either manually or automatically), the SSF field would display the appropriate code.

If the ULN had gone through the entire process of "V" to "T" then, upon being manifested, the SSF code would change to a "B" for both validated and manifested.

If the ULN had not gone through the entire process, i.e., it had not been validated (V) and consequently not pulled, then the SSF code would be an "M," for manifested but not validated.

You have now completed a tour of all but one of the TCCESI application options.  Next you will take a look at the Reports and Utilities option.

Reports and Utilities.
Purpose.  The Reports and Utilities option provides a limited reports and file management capability.

OPLAN.  This is the only place, after proceeding beyond the TCC Interface Subsystem initial menu, where the user can change the OPLAN under consideration.

Delete/List Carriers.  This option provides a follow-on window that allows the user to delete or list various carriers on the database or on a specified OPLAN.

Delete TCC Interface Files for an OPLAN.  When the Supported CINC Validation Option and/or the USTC Requirements Pull Options were executed, they automatically created several files that were used to generate the Plan Compare and Requirements Pull reports.  This utility has been added to the TCCESI application to facilitate the management of these files by accomplishing their deletion after the deployment phase of the OPLAN is complete.

Demonstrate the Reports and Utilities Option.

Requirement.  Occasionally, GTN will successfully pass a mission schedule and itinerary to JOPES but the allocation or manifesting information associated with that ULN and that mission will be scrambled.  You are on duty at the USTRANSCOM CAT and have been asked to check to see if there are any missions of any type in the database that have no allocated ULNs, i.e., carrying no requirements.

Produce a List of Unallocated/Unmanifested Carriers.

Your options on this window are extensive, including identifying the type of carrier as well as dates and carrier names.  The end result of this window is the execution of a printed report or the deletion of carriers from the database.  There is no display to the window option.
Select Option.  The user must select only one of these toggles.  The first will select the carriers associated with this OPLAN, while the second will select all carriers on the entire database, regardless of their OPLAN affiliation.  The last option is a delete function for the carriers associated with this OPLAN.  It should only be executed by those users responsible for inserting or deleting carrier data into the JOPES database.

Carriers.  At least one of these options must be selected.  The user may also select any combination of manifested/unmanifested/allocated/unallocated.

Source(s).  At least one of these options must be selected.  Again, the user may select any combination of carriers.

Carrier Date Range.  Entries in this section are optional.  If desired, the user can enter a date range in Relative (C-Day) format by using the first two fields, or in Zulu (Calendar day) format by using the last two fields.

Carrier Name Range.  Entries in this section are also optional.  If desired, the user can enter a range of carrier names.  The only restriction is that the carrier names must exist.

Report.  The report that you generated would be automatically sent to the default printer for your review.  This particular report would list all the carrier names associated with this OPLAN sorted by carrier and the source of the carrier and its status with regard to allocation and manifesting.  Figure 5-38 provides a sample report.

Delete TCC Interface Files for an OPLAN.  Every OPLAN in execution has several files that were automatically created by the use of the TCCESI application.  Included are seven TPFDD files created by the use of the Supported CINC Validation option and some (possibly several) PULL files created by the use of the USTC Requirements Pull option.  When these files are no longer needed, they should be removed from the file system.

There are no verification windows or opportunities.  By entering your OPLAN, selecting the Delete TCC Interface Files for an OPLAN toggle and clicking on Continue, you get a "REQUESTED ACTION COMPLETED SUCCESSFULLY" message displayed in the message line.  At that time, all the files that were created by the use of the TCCESI application, and that are resident at your site, are deleted.

These files will be resident in two locations.  They will be on the servers servicing USTRANSCOM and the supported CINC involved with this OPLAN.

Now that you have a good working knowledge of the capabilities of the TCCESI application and what it does, it is time for you to demonstrate your capabilities.

Requirement.  The United Nations has reconvened and decided to impose economic sanctions against the aggressor.  The United States has agreed to delay any type of military action.  No US forces have arrived in theater (it is still early on 1 Jan 96).  All airborne aircraft are returning to their POEs.  You are the individual directed to return your OPLAN back to it's "on-the-shelf" status.  Your actions fall into three broad categories.

1.  Remove all carrier information from your OPLAN.

2.  Remove all SSFs and PIFs from your OPLAN.

3.  Remove all files created by the use of the TCCESI application for your OPLAN from your site.

In addition:

4.  Save your OPLAN to your user storage area.

Now that you have saved this OPLAN in a file (just in case it is needed again sometime) you can delete your OPLAN from the JOPES database.

OBJECTIVE.  Without references, delete an OPLAN from the database.

Delete an OPLAN.  Deleting OPLANs from the JOPES database is accomplished using the System Services Application.  The Delete option can be used for both local and networked plans, but the result depends on your assigned functional permissions.

Local OPLANs.  A local plan can only be deleted by its creator, or the Site FM, the Network FM, if the FMs have access.

Networked OPLANs.  A networked plan can be deleted from a specific site by its creator, the Site FM, or the Network FM, if the FMs have access.  It can be deleted network wide by the plan creator or the Network FM, if the FM has access.

This completes your lesson on actions that could be required to support a crisis situation.  You can now close all the open applications and return to the Launch Window.

Summary.  During this lesson you took a TPFDD from a floppy disk (or resident in a file) and loaded it into the JOPES database.  Then you concentrated on the Validation, Pull, Allocation, and Manifesting processes.  You became familiar with the effect of an OPLAN's Locked/Unlocked status and how the validation through manifesting sequence affects an OPLAN.  We talked about Scheduling Status Flags (SSFs) and Problem Indicator Flags (PIFs).  Then we demonstrated the TCCESI application as it supports the validation through manifesting processes.  You even deleted an OPLAN from the database after saving it to a file.