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

Setup.  To accomplish this lesson, you need GCCS connectivity and access to the JOPES database and applications (Session Manager, System Services, IMS, RFM, and FTPtool).  USERIDs should have Plan Creator (CRT), Update (UPD), Site Functional Manager (SFM), and Network Functional Manager (NFM) permissions.  USERID (user account) must be a member of the UNIX groups (site specific - it's GCCS and JADMIN for the JTO server) to execute the Journalling subsystem, the TP/TDS Management subsystems and the Local OPLAN Database Cleanup (DBA function).  You will also need access to an XTerm and run remote window.  For the audit section of this lesson, the instructor must add ULN 9BLCK (Service = F) to OPLAN 9096M and ensure auditing is active.  The instructor can use RDA or the Merge a TPFDD of SS to accomplish the action.  It must be done early enough (prior to the audit portion of this lesson) so that the Journalling subsystem performs at least an Auto Journal operation prior to teaching audit.  The user's account must also have Telnet system permissions.  One blank 8mm cassette for the class and a formatted DOS 3.5" floppy disk for each student must be available to archive plans/TPFDDs.  A GCCS IBM compatible PC with PC-NFS will be used to transfer files to a floppy.  Master training OPLANs must be available in the site's JOPES database.

Overview.  This lesson examines the current System Services capability to monitor the activity level of the Transaction Processor, Transaction Distribution Services, and check the synchronization of the JOPES database.  Then you will explore journalization.  With JOPES, this means you will create history files and use the auditing capabilities to view the history files.  Next, you will use the tools available for moving data, such as OPLANs, throughout GCCS.  This lesson concludes with a review of the UNIX environment where you will use several UNIX commands that might be helpful to you as you troubleshoot a problem. 

Now that you have an idea of what the subject under discussion will be, the lesson continues by laying some basic groundwork for understanding how transactions are processed.

OBJECTIVE.  From a list of possible definitions, select the one that best describes the way that updates to the JOPES database are processed.

Transaction Oriented JOPES Processing.  Different type transactions update the JOPES database and each type of transaction affects a specific part of the JOPES database.  When you enter a command into the system using one of the GCCS applications, such as System Services or Requirements Development and Analysis, that command is translated into a number of transactions.

The more complicated the command, the greater the number of transactions.  For example, setting C-Day or modifying the LAD of a requirement will generate a small number of transactions (maybe only one).  If you were to use the merge capability and the TPFDD being merged contained 600 to 700 requirement records, then the merge command would generate a large number of transactions (maybe thousands) requiring processing.

For now, you need to get the "big picture" for database transaction processing.  As the lesson continues you will receive additional detail.

Transaction Handling Overview.  JOPES transactions can affect only your local JOPES database or many databases across the GCCS network.  When you make a change to an OPLAN, that transaction is sent directly to your database and to the send queue, as depicted in Figure 4-1.
Send Queue.  The send queue and the database coordinate with each other so that if the transaction fails at one location it will also fail at the other.  The send queue is a waiting area.  Transaction Distribution Services (TDS) queries the send queue when TDS process more transactions.

TDS.  TDS reads the send queue transactions and forwards those that require distribution and stores those that do not.  The TDS also receives transactions from other sites for disposition.

Outgoing TDS Transactions.  TDS sends outgoing transactions over the SIPRNET where they will be received by a remote sites' TDS for processing.

Incoming TDS Transactions.  The local TDS will handle transactions sent from a remote site to your site.  This is how a remote site updates a network OPLAN resident at your site.

Receive Queue.  Like the send queue, the receive queue is a holding area. 

Transaction Processor.  The receive queue stores transactions until the Transaction Processor (TP) is ready to process the transactions.  The TP then sends the transactions to the local JOPES database.

Now that you have the big picture of transaction processing, you should be ready to review the types of transactions processed by JOPES.

Types of Transactions.  The TP and TDS, as well as the Send and Receive Queues, keep track of transactions by type.  There are 24 different types of transactions.  Each transaction is tracked by a six character alpha code (Table 4-1).

Now that you have a reasonably good idea of how the database gets updated from an operator's perspective, you will next learn a little bit more about the TP and then view the activity level of the Receive Queue.

OBJECTIVE.  From a list of capabilities, select those which are an accurate portrayal of the JOPES Transaction Processor monitoring capabilities.

Transaction Processor.  The TP is one of the components that handles the proper routing of transactions and the use of those transactions to update the JOPES database from external sources.  There is only one TP for each JOPES database.
Purpose.  Specifically, the TP is responsible for applying networked transactions to the locally resident JOPES database.  Those transactions could have been generated anywhere on the system, except at your site. 

Receive Queue.  The TP gets its transactions from the Receive Queue.

The size of the Receive Queue is controlled by the System Administrator.  The greater the disk space assigned, the greater the number of transactions it can hold.

The number of transactions in the Receive Queue awaiting processing can be monitored.  If you wish, you can also check on the number of transactions that were in the Receive Queue that the TP attempted to process, but the update failed.

The Receive Queue also tracks the average time required for the TP to process transactions.

OBJECTIVE.  Given a GCCS environment, display the JOPES Receive Queue activities.

Receive Queue Activity.  The Receive Queue windows are available to everyone with access to the System Services icon on the Launch Window, as long as they are also members of the JADMIN UNIX group.  No specific functional SS permissions are required.
Window Modes.  There are two versions of the monitors subsystem:  the character-mode version and the graphical-mode version.
The character-mode version is for those operators who do not have a graphics capable computer/communications line.  The character based version updates the window totals only when the operator transmits.

The graphical-mode version is available to anyone who has a graphics capable computer/communications line.  The graphics mode display is updated automatically every 15 seconds and every time the operator transmits.  You will be using the graphical-mode throughout this lesson.

Receive Queue Detail Monitor Window.  The Receive Queue Detail Monitor window monitors transactions by type.  It will display the total number, type, and processing status of both backlogged and completed transactions.  The Receive Queue Detail Monitor window is accessible through the Monitors option of the System Services tear-off menu.

The Receive Queue Detail Monitor window consists of two parts:  the top portion where fields display transaction processing information, and the bottom portion that contains a list of transaction types and processing details.
The fields that appear on the top portion of the window are the ones that display transaction processing information.
Receive Queue Detail Monitor at {Host Name}.  Site identifier of the system that contains the JOPES database and receive queue.

Row.  A two part field, the first part displays the number of the row that is displayed on the top line of the transaction details list.  The second part displays the total number of rows available.

Note:  Ten rows of transactions appear on the window.  More transaction types may be available as indicated in the second part of the Row field.  Enter a number other than one in the first part of the Row field and transmit to display the desired information in the first row on the window.

Current (Last Journalled).  Date/time of the last journalling, this will be the starting date and time for calculation of current information totals.  The journalling process records each transaction for historical purposes.

Total Processed.  Total number of transactions processed (with status "success" or "success with warning") since the Last Journalled date/time.

Total Queued.  Total number of transactions waiting to be processed.

Total Failed.  Total number of transactions that failed during processing since the Last Journalled date/time.

Note:  The sum of the Total Queued and Total Failed fields is the total number of transactions currently in the Receive Queue.

Historical (TP Restarted).  Date/time of the last Transaction Processor restart, this will be the starting date and time for calculation of historical totals.

Total Processed.  Total number of transactions (successful and failed) since the TP Restarted date/time.

The columns that appear on the bottom of the window contain a list of transaction types and processing details.

Trans Type.  Name of the transaction for which processing information is displayed.  (Refer to Table 4-1).

Current Queued.  The number of transactions waiting to be processed.

Current Failed.  The number of transactions that failed during processing since the Last Journalled date/time.

Current Proc'd.  The number of transactions processed since the Last Journalled date/time.

Historical Proc'd.  The number of transactions processed since the TP Restarted date/time.

Historical Ave Proc (Secs).  The average number of seconds required to process each transaction since the TP Restarted date/time.

Note:  The standard Message Line is below the transaction details list.  This field displays responses to the operator from the system concerning operator input.

The Detail Monitor window displays transactions identified with their six character code; the Receive Queue Summary Monitor window will display the transactions grouped by their functional names.

Receive Queue Summary Monitor Window.  The Receive Queue Summary Monitor window monitors transactions aggregated into functional categories of transaction types.  It will display the total number, type, and processing status of both backlogged and completed transactions.
The field names on this window are identical to those on the Receive Queue Detail Monitor window.  In addition, the entries in the various fields mean exactly the same as they did on the detail window except for one field.

The only field that has different entries is the Transaction Type field.  Instead of a six character code displayed, you now see all of the 24 codes grouped into six functional categories.

Now that you know how to get to the windows where you can view the level of activity for the Receive Queue, you should be able to make an estimate of how well the Transaction Processor is operating.

OBJECTIVE.  Given a GCCS environment, investigate the local JOPES Database Server's processing performance and status.

Investigate Server Performance and Status.  There are several items that are of interest to JOPES users, Functional Managers, and Database Administrators on these two windows.  There are three that appear to be the obvious ones.
Transactions Queued.  The number of transactions in the queue waiting to be processed is indicative of the number of operators currently using the JOPES applications and making changes to the database.
The number of transactions can be viewed in either the Total Queued field or they can be viewed by their six character code or functional category.

The greater the number of transactions, the longer it may take for the TP to get to the ones that you personally entered.

Transaction Failures.  The number of failed transactions can also be observed.  You again have the options of viewing the Total Failed field, or you can look at the fields displaying the number of failed transactions by functional category or their six character code.

Transaction Processing Time.  The system keeps track of how long it takes to actually process a transaction.  While there is no "standard" processing time currently established, you could compare the Queued column with the Avg Proc (Secs) column to estimate how long it will take for those transactions currently in the queue to be processed.

Now that you are on speaking terms with the TP and the Receive Queue, the next item on your agenda is the TDS and the Send Queue.  The Send Queue navigation also starts from the Monitors tear-off, so you will have to go back to the previous menu.

OBJECTIVE.  Given a GCCS environment, monitor the JOPES Send Queue activities.

Transaction Distribution Services.  TDS is one of the components that handles the proper routing and flow of transactions to the locations requiring those transactions.  There is only one TDS for each JOPES database.
Purpose.  Specifically, the TDS keeps track of where the various JOPES databases reside and what is in them.  The TDS serves two functions:  it sends networked transactions to other servers and it receives networked transactions from other servers.
Networked transactions from other servers are sent to the local Receive Queue for database processing.

Networked transactions going to other database servers are read from the local Send Queue to determine the appropriate destination.

Send Queue.  The Send Queue receives transactions from the client applications.  (Refer to Figure 4-1).

The size of the Send Queue is controlled by the System Administrator.  The greater the disk space assigned, the greater the number of transactions that it can hold.  There is only one Send Queue for each database.

The Send Queue monitor keeps track of the number of transactions in the queue waiting to be forwarded and the number of transactions that have already been sent.  It keeps track of the 24 types of transactions by the same six character codes used by the TP.

The level of activity in the Send Queue can be monitored using the Send Queue monitoring subsystem.

Send Queue Detail Monitor Window.  The Send Queue monitoring capability is accessible by following the same path as the TP monitoring capability.

The Send Queue Detail Monitor window consists of two parts:  the top portion where fields display transaction summary information, and the bottom portion that contains a list of transaction types and processing details.
Except for Total Sent, the fields in the top part of the window are the same as the ones you saw in the Receive Queue Detail Monitor window.  The Total Sent field is the total number of transactions sent since the Last Journalled date/time.

Note:  The term "sent" refers to the condition that a transaction has been sent to all other systems.  The sum of the Total Queued and the Total Sent fields is the total number of transactions currently in the Send Queue.

The columns that appear on the bottom of the window are also very similar to the Receive Queue Detail Monitor window.

Investigate Transaction Distribution Performance.  To assess the status of TDS's ability to forward transactions to the other databases, simply check the number of transactions queued and the number of transactions that have been sent.

Now that you are familiar with the Send Queue, it is time to check on the connectivity between the various database servers.  You can go back to the Monitors tear-off where you will select the TDS Monitor function next.

TDS Monitor.  The option labeled TDS Server, on the Monitors tear-off, provides a way to check on the status of database servers around the network.  The TDS monitor checks on the accessibility of the various servers and the processing status of the TDS and TP at those sites.

Server Monitor Screen Window.  The Server Monitor Screen window consists of a single window.  You may input a specific row number in the Row field to move that row to the top of the display.  This will display the information relevant to any additional servers not currently displayed.  The display consists of five columns.
The first column (Server Name) will display the servers that are registered at this site by name.

The second column (Server Address) will display the servers by specific IP address.

The third column ("Ping"), the fourth column (TDS), and the fifth column (TP) will be either blank or will display a time in hours and minutes.

The "Ping" column displays the accessibility of a server while the TDS and TP columns display the processing status of the TDS and TP at that site.

If time values display in the window, they represent the earliest continuous time that a particular server became inaccessible or a process at that server did not respond.

Blanks displayed in these columns indicate that server connections are established and that the TDS and TP processes are executing.

Note:  The information on the screen will be periodically refreshed.  The Transmit key can be pressed to immediately query the system and display the current status.  The query and response takes approximately five seconds per server if they are accessible and operating, and 10 to 15 seconds per server if a negative response is encountered.

Investigate System Status.  To assess the operating status of the database server network, check to see if there are any entries in the "Ping", TDS, or TP columns of the Server Monitor Screen window.  If any times are displayed there, then that particular server became inaccessible at that time or that process ceased operating at that time.

Now that you are comfortable with monitoring the operating status of the various database servers in the network, you can exit this window.  The lesson will now describe another monitoring capability, the OPLAN database synchronization monitoring capability.

OBJECTIVE.  Given a GCCS environment, monitor the synchronization of a distributed OPLAN on the JOPES database and explain how to rectify an out-of-synchronization condition.

OPLAN Database Synchronization.  Two OPLANs are said to be synchronized when each is a carbon copy of the other.  That is, both of them are always identical to each other.  Under normal circumstances, data and files that are shared between sites will be in sync.  However, there could be times when this may not be true.
Purpose.  You (only if you have SFM or NFM permissions) can use the Plan Network Status display to examine whether or not the JOPES OPLAN databases are in sync.

Verify OPLAN Synchronization.  Use the Plan Management cascade from the GCCS System Services menu to verify OPLAN synchronization.

Upon function execution, the system will verify that the Plan Id exists and that you have been granted access to that Plan Id.  If both conditions are met, then synchronization information will be displayed.
The Last Sync Request field displays the last date a sync request was issued by any site for this particular plan.

The body of the display will contain the synchronization information.  The local server will always be displayed on the first line.

The Sync Date will be the last date that the server calculated the numbers displayed in the Requirements and Carriers Counted columns.

The In Sync column displays a Yes/No flag indicating whether or not the remote server reports the same record count as the local server.

If the Last Sync Request date is not recent enough, then an update to the synchronization information displayed can be requested by depressing the Generate New Sync Requests toggle and depressing Transmit.
By activating this toggle and depressing Transmit, new synchronization requests will be issued across the network thereby prompting responses from each server to all other servers in the network.

The generation of a new sync request will update every site with the most current information.

Note:  This could generate a significant number of transactions throughout the network.

Analyze OPLAN Database Synchronization.  To determine whether or not a specific OPLAN is synchronized, check the In Sync column for a No value.  If one is present, the specific record counts of requirements or carriers can be compared with the local server to determine where the discrepancy lies.

Database synchronization has been described and you know how to tell if the database is synchronized.  But what can you do if your database is still out-of-sync and all the monitors show that there are no records left to be processed?  The next portion of the lesson will show you how to do a partial site recovery for a local site.  Keep in mind that a healthy site (one that is fully synchronized) is used to update the site that needs to be recovered.  But first, you can exit the window and close the Monitors tear-off.

VERIFY DATABASE SYNCHRONIZATION
4	Press <F10> or <POINT AND CLICK (left)> on F10-Back to go back to the previous menu.	Previous menu displays.
5	To close the Monitors tear-off, <POINT AND DOUBLE CLICK (left)> on the Window Menu button  in the upper left corner of the tear-off.	The Monitors tear-off closes.

Partial (Selective) Site Recovery.  A partial site failure is when you lose records from your networked OPLANS, but the entire database has not failed.  To repair this condition, the Site Data Recovery option provides the Network FM a way to recover from a partial site failure condition.  The Site FMs, the Network FM, and perhaps the site DBAs should work closely together to accomplish the repair.

The Selective Data Site Recovery window allows Network FMs to recover portions or all of a networked OPLAN.  This is done by building transactions from a providing site's database and routing them to a file or to a receiving site for update processing.  You can also create OPLAN delete transactions.
You should first identify the Plan ID to be recovered and determine the type of record(s) to be recovered:  ULN/CIN/PIN, carrier/manifest data, or plan delete transactions.

After you enter the Plan ID, the system will check to determine if you have access to the plan.  Then you depress one of the Recovery Type toggles to display additional options.

You must then identify and enter the type of requirement to be recovered, either ULNs, CINs, or PINs.

Selecting an entry method adds additional fields to the window for entering specific values or a range of values.  A wildcard (*) is permitted when working with ranges.

Clicking on Transmit returns the first window with additional toggles added to designate a file or the site(s) to receive the selected transactions.

If you depress the Specific Sites toggle, then a panel displays in the lower part of the window where you enter the names of the servers requiring update.

If you depress the File toggle, then a panel appears in the center of the window where you must enter a UNIX file name to receive and store the generated transactions.

If you had selected the Carrier/Manifest Data toggle on the first Selective Site Recovery window (Fig. 4-7), a different window appears where you enter carrier names for recovery.  Again you return back to (Fig. 4-9) to select the file or site(s) to receive the information.

If you initially select the Plan Delete toggle on the first Selective Site Recovery window (Fig. 4-7), no additional options are added to the window.  The Plan Delete toggle is used when a networked plan is deleted but does not completely delete from every site around the entire network.

To actually execute the Selective Site Recovery option, you would depress the Transmit button.  However, you do not have a direct need to start the recovery process so you can go back to the previous menu.

Now that you are familiar with how to repair an OPLAN out-of-synchronization problem using the site JOPES database partial recovery capabilities, you will next tackle the journalization function.  Before you get into the mechanics of how to do it, you should become more familiar with the purpose of journalling and have an idea about who will be doing the work.

OBJECTIVE.  From a list of possible answers, select the sequence of events for journalization and the conducting of audits for his/her site's JOPES server.

Journalization and Auditing.  Journalization and auditing are tied closely together.  Briefly, journalization is the saving of transaction data, while auditing is researching that data for specific answers.
Journalization.  The Journalling subsystem is responsible for saving all the database transactions received by and sent from a particular JOPES database server.  The Journalling subsystem is also responsible for tracking the processing status of each of these transactions.  What that really means is that the Journalling subsystem keeps track of the activity that has occurred in the Receive Queue and in the Send Queue.  You are already familiar with those two queues.
Purpose.  You already know that there is only one TP, Receive Queue, TDS, and Send Queue per database.  It logically follows that journalization only occurs at each of the database servers.  It occurs on a periodic basis and is accomplished for two purposes.
The primary purpose of the Journalling subsystem is to clear transaction histories from the Send_Queue, Receive_Queue, and TP_Error_Log ORACLE tables in the database and save them to a separate text file for each table (More on the TP Error Log later in this lesson).  Processing time is inhibited if too much information is stored in the queues.

Another purpose for journalling is the preservation of information.  Each time that journalization occurs, the text file is time stamped for later reference and contains those transactions processed since the last time that journalization was performed.  This preserved information can be accessed by the Audit Reports subsystem.

Personnel Involved.  Journalling requires UNIX execute permissions to the Journalling subsystem.  The UNIX permissions are granted by making the USERID (user account) a member of the UNIX group responsible for Journalling activities (usually the JADMIN group).  The user account and group name are established by the System Administrator.

Each database site must establish procedures to execute and control the journalization process.  Procedures will probably vary by site.  It could be a Functional Manager responsibility, a System Administrator responsibility, or a Database Administrator responsibility (if one is specifically designated).

Auditing.  The Audit Reports subsystem works in conjunction with the journalling function.  Reports are generated with data taken from the journalled information.

Purpose.  The Audit Reports subsystem provides the ability to generate reports concerning the incoming and outgoing transactions.  These reports can provide the who, what, when, where, and how a specific record in the database was modified.

Personnel Involved.  There is one option on the System Services menu that provides access to the JOPES database auditing capability.  Everyone who has access to the Systems Services icon has access to the windows that generate the audit reports.  No specific functional permission is required to access and execute an audit report.  There are some procedural issues that will have to be addressed between the generator of the audit report and the keeper of the journalized information.

Note:  These procedural issues are addressed during the generation of an audit report later in this lesson.

Now that you have an appreciation of what journalization and auditing are, you will access the window that controls the journalization process.

OBJECTIVE.  Given a GCCS environment, access the window which controls the JOPES journalizing function and explain the options available.

System Journalization.  The actual journalization process can be split into two parts:  the saving (and cleaning out) of the Receive and Send Queues to three separate disk files and the archiving of those disk files to an external tape.  Both activities are accomplished from the same window.  In addition to those two parts, there is also a reports option.

Note:  This is the real system!  Selected functions are carried out when you select "Transmit."  Do not "Transmit" any information on the Journalling subsystem window unless you are the designated individual responsible for accomplishing the Journalization function.

Save to Disk.  Two of the toggles on this window control the saving (and cleaning out) of the information in the Receive and Send Queues.  They are the Set Auto Journal and the Terminate Auto Journal toggles.
The Set Auto Journal toggle allows you to initiate automatic journalling of the database transactions.
It also allows you to establish the interval between automatic journalling operations.  Your choice of interval length will affect system processing times.  Longer intervals result in larger queue sizes, which inhibit transaction processing times.

If you select the Set Auto Journal toggle, enter an interval in hours and minutes and <POINT AND CLICK (left)> on Transmit.  The system will immediately journal and then automatically repeat the operation at the interval specified.

If you select the Terminate Auto Journal toggle and <POINT AND CLICK (left)> on Transmit, the Journalling subsystem will stop automatic journalling after any currently active journalling operation concludes.

The current status of journalling is displayed in a field above the message field.  This status can be either "Auto Journal Inactive" or a message indicating the current journalling interval.

Archive to Tape.  Four of the toggles on this window control the archiving (and cleaning out) of the information stored in three journal disk files.  They are the Archive Journal Sets to Tape, Append to Tape, Overwrite Tape, and Eject Current Tape toggles.

Note:  The three journal disk files containing the information obtained from the Receive and Send Queues should periodically be archived to tape in order to conserve disk space.  The System Administrator or Database Administrator can access these files from system level to check/verify their size.

Note:  The tape drive used by the Journalling subsystem is a default tape drive identified by the System Administrator (SA) during initial installation.  The default tape drive can be modified by the SA.

Archive Journal Sets to Tape, Append to Tape, and Overwrite Tape.  The first three toggles (Archive, Append, Overwrite) work in conjunction with each other.
If you select the Archive Journal Sets to Tape and the Append To Tape option, then the system will transfer three journal disk files to tape.  The newly archived files are added to the tape.  The functions are carried out when you select Transmit.

If you select the Archive Journal Sets to Tape and the Overwrite Tape option, then the system will transfer three journal disk files to tape, overwriting all files on that tape.

Eject Current Tape.  If you select the Eject Current Tape and <POINT AND CLICK (left)> on Transmit, the tape in the default tape drive is ejected.

Note:  As of this writing, there is no tape management system/procedures promulgated.  If you save something to a tape, you should make arrangements to put the tape in the tape drive, keep track of what is on that tape, and store it or know where it is stored.

The archiving to tape process does not keep track of the tapes to which journalling information has been saved.  As of this writing, the system does not keep track of which journalling time frames are saved to specific tapes.  You must manually insert the tape in the default tape drive and record on the tape label what you saved to that specific tape.

Journal Reports.  There are three report options available to the individual responsible for journalling operations.  They are the Print Journal Status, Print Journal Log, and Print Journal List options.  These three reports print the contents of three of the files that the journalling system uses for processing.

Note:  These three files are not the contents of the Receive and Send Queues.  They contain information concerning the proper operation and the care and feeding to the Journalling subsystem.

The Journal Status Report (file) summarizes the current status of journalling.

The Journal Log Report (file) records time stamped status messages such as start and stop times as well as error messages recorded during processing.

The Journal List Report (file) lists all the files in the Journal directory.

Reset Journalling Subsystem.  The Reset Journalling Subsystem toggle is used when the Journal Log file grows too large or when the Journal List file becomes inconsistent with the actual files in the Journal directory.

Note:  If you select the Reset Journalling Subsystem toggle and <POINT AND CLICK (left)> on Transmit, then the Journal Log file is emptied and the Journal List file is updated to the current contents of the Journal directory.

Now that you are familiar with how the system keeps track of the changes being made to the JOPES database and perhaps who is responsible for maintaining that information, you will proceed to retrieving and viewing the journalled data using the Audit Reports subsystem.

OBJECTIVE.  Given a GCCS environment, conduct a JOPES audit.

Conduct an Audit.  The Audit Reports subsystem provides anyone who has access to the System Services icon the ability to generate reports from the transactions that were journalled from the Receive and Send Queues.  These reports can provide the who, what, when, where, and how a specific record, a group of records, or an entire OPLAN was modified or deleted.

Requirement.  For your information, OPLAN 9096M contains (and should only contain) Army records.  However, there is now an Air Force record in your JOPES database.  The ULN is 9BLCK.  Your task is to discover who and when that record was added to your OPLAN.

The generation of an Audit report is a three step process.  The first step is the selection of a date range of transactions to load.  The second step is the selection of the report to be generated, and the third step is the identification of the transactions to be included in the report.  Access to the Audit Reports subsystem is from the System Services menu.
Load Transactions.  Transactions are loaded from the journalized files.  Transactions can be loaded from the disk files and/or from the archived tape files.

Note:  If a transaction has recently occurred and journalization has not yet happened, then auditing of that transaction cannot occur.

The Load Selection window (Figure 4-11) requires you to identify the transactions from which audit reports are generated.
The top two fields are system generated.
The first field reports the last time the journal files were archived from the journal disk area to tape.

The second field reports the last time journalling was performed (database transaction information was transferred from the transaction queues to the journal disk area).

These fields are blank if the Journalling subsystem has been reset and neither activity has occurred since the reset.

The Load Date Range section contains two fields you must complete to access the appropriate transactions.  The "To" field defaults to the current date and time.  A time frame is specified by entering the earliest time in the From field and the latest time in the To field.  The format for entering the date is displayed in the window.

You then specify the source of journalled information that should be loaded.  The sources of information correspond to the three journal files that were created by the Journalling subsystem.  Any combination of these three files can be loaded.  The choices are:

Incoming -- loads the transactions that were processed by the TP in conjunction with the local Receive Queue.

Outgoing -- loads the transactions that were processed by the Transaction Distribution Services in conjunction with the local Send Queue.

Errors -- loads information that was resident in either the Receive or Send Queues about transactions that failed or generated warnings during their application or execution.

Once both the date range and transaction sources to be loaded have been identified, the transactions must be retrieved from either disk and/or tape.  The F9-Load button loads the journalling information.

During the loading sequence, if there are no transactions found on disk with a date earlier than the date in the From field, the system assumes there may be transactions from the specified range that have been archived to tape.  If this situation is encountered, the system will prompt you as to whether or not transactions should be loaded from a tape.

Note:  If transactions must be loaded from a tape, then you must coordinate with the individual who has access to those tapes to insert the "appropriate" tape into the "default" tape drive.  The "appropriate" tape can be identified by the dates written on the tape label when archiving was accomplished.  The "default" tape drive is identified by the System Administrator.  In many cases, it will probably be the same one as the one used by the Journalling subsystem.

After the transactions are loaded, a message appears in the message field indicating either a successful or unsuccessful load was accomplished.

If desired, you may enter another date range and file selection.  The new date range and file selection are appended to the transactions already retrieved.

Note:  If this window is exited and subsequently re-entered, then all previously loaded information is dumped.

Once the desired transactions are loaded, you select the Transmit button to proceed to the next step.

Report Selection.  The date fields define the time frame the report will cover.  These fields will default to the date range specified on the Load Selection window.  You may only narrow these dates to further restrict the time frame covered by the report.

The reports may be printed only, or they may be printed and saved to a file.  The default pathname is /h/SM/data/user_files/{userid}.  Toggling either of the "after printing" options untoggles the other.

The lower portion of the window allows you to select the type of reports you want.  The reports above the separator line are the non-detailed reports, while those below the line are detailed reports.

Note:  The detailed reports can be restricted to specific types of information such as Plan Status, ULN, or carrier.  You cannot limit the non-detailed reports to specific types of transactions.  You cannot request both detailed and non-detailed reports at the same time.  You can, however, select any combination of detailed reports or any combination of non-detailed reports.  The choice of detailed or non- detailed reports determines the windows that are subsequently displayed.

Non-detailed Reports.  A Partial Transaction Report provides the transaction type code name, OPLAN function code, USERID, and date-time.  A Transaction Dump Report provides a full text of all transactions.  The Transaction Error Report provides information about transactions that failed while being applied to the database.

Note:  A separate report is generated for each option (report) selected.

Detailed Reports.  The Detailed ULN Report and the Detailed CIN/PIN Report provide information about the records, to include nonstandard cargo transactions.  The Detailed Plan Report provides information concerning the status of the plan.  The Detailed S&M Report includes only transactions directly related to scheduling and movement activities.

Transaction Selection.  The identification of a specific OPLAN area or restricting the report to specific USERIDs limits the scope of the report.  If neither the Exercise or the Real World toggles are depressed, then the report will include both.  If a specific USERID is not identified, the report will include all of them.

The options available on this window are a function of the choices that were made on the previous windows.  The scope of the report can be further limited to a specific OPLAN and specific ULNs or specific carriers.  The report can also be sorted by date/time or by ULN/Carrier.

Note:  The report will print on the default printer for your workstation as previously configured by the System Administrator.

After returning to the Report Selection window, you may create any additional reports from the journalled information that was previously loaded.

The topics under discussion during the last hour have been journalization and auditing.  Journalization was the transfer of information from the Receive and Send Queues to a disk area on the server and the subsequent transfer of that information to a tape.

The next portion of the lesson covers JOPES file transfers.

Overview of Importing and Exporting Data.  Figure 4-15 is the big picture for file transfers to include OPLANS, TPFDDs, and reference files.

In general, the graphic represents server functions (computer programs, JOPES/GSORTS database, disk files) on the left side and client functions (computer programs, disk files, tape) on the right side.

The lesson first describes the System Services functions used to upload and download OPLAN/TPFDD information into and out of the JOPES database.  They are the Create TPFDD File, Offload Plan, Reload Plan, Load TPFDD, and Merge options.

That will be followed by a description of three other functions called the Information Management System (IMS), Reference File Manager (RFM), and the File Transfer Protocol (FTPtool) used to transfer TPFDDs and reference files between application files and computer files.

OBJECTIVE.  Without references, identify, in specific terms, the method(s) used to export and/or import JOPES OPLANs/TPFDDs.

Exporting OPLANs/TPFDDs.  OPLANs/TPFDDs can be exported from the database to a magnetic tape or to a file on the server's hard disk.
Create TPFDD File.  You can copy a TPFDD from the database to tape or disk using the Create TPFDD File option.  With the Create TPFDD File option you can copy the entire TPFDD or limit the types of records to be copied to the new media.

This Data Limitation Selection window and another follow-on window allow you to selectively extract records from the source TPFDD for export to the target tape or disk file.

The window also allows you to specify the offload media and pathname for disks or the device name for local tape drives.  To use a tape drive, a blank tape must already be installed in the drive.

The pathname tells the UNIX program where to store the information file within the GCCS file system.

The file system pathname consists of the root directory, followed by optional (sub)directory names, ending in the filename itself.

For example, the directory path to your user account is /h/USERS/{USERID} where {USERID} is a variable that represents your USERID.  Additional directories, like User_Storage, can be added to the path to provide additional file locations.

You will use the Create TPFDD File option to extract Marine records from an OPLAN and put them on a disk file in your user account.

Requirement.  Extract all Marine force and nonunit records from the 900XT OPLAN and store the records on a disk file in your user account's User_Storage directory.

Note:  The "X" in 900XT is a placeholder.  Your instructor should provide you with the appropriate number or letter to use to replace the "X".  For example, for 900XT the "X" is usually the last digit of the current fiscal year.

An additional data limitation window displays when you select any one of the first four "Limit by" options.

This window provides an additional data limitation capability.  You can only specify one date range, either EAD or LAD.