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

Setup.  To accomplish this lesson, you must have access to JOPES with the standard permissions associated with JD94TNG.  The Person ID must have access to both hosts.  In addition, you must have file space at both hosts and tape access at the primary host.

Overview.  This lesson introduces you to the system and discusses how to analyze its performance.  You will discover methods to fix problems your analysis may find.  These tools aid you in maintaining the synchronization of the database.  You can use these tools to conduct audits, manage JOPES files, transfer files between sites, and load records into an OPLAN.  Finally, you discuss how to manage a tape system and JOPES reference file update procedures.

For you to provide service to your users, it is imperative that you first understand what the system is, how it works, and how to analyze the performance.

OBJECTIVE.  From a list of capabilities, select those which are an accurate portrayal of the mainframe's operating characteristics.

Mainframe System Characteristics.  To analyze mainframe system performance, you must first understand the design (parts of the system) that make up the whole system and some system characteristics.
Overview of System.
DPS 8(000).  The Honeywell Information Systems (HIS) Series 8000 computer system is the standard ADP equipment for WWMCCS.  WWMCCS standard disk drive packs provide on-line storage.  Users access the mainframe through DOS-based personal computers (e.g. WIS-CUC, IBM, Zenith, etc.) running G-LINK software.  The following terms apply to the mainframe environment.  The General Comprehensive Operating Supervisor (GCOS) is the operating system on the Honeywell.  It functions like DOS on your DOS PC.  It manages the system's resources and provides the basic service and control functions used by all other software and user programs (the applications).  Some of the major functional characteristics, besides resource management, are:  job scheduling, File Management Supervisor (FMS), security control, job flow, and on-line system development.
Job Scheduling.  Job scheduling of interactive and batch jobs are executed by the user through Job Control Language (JCL).  The computer processes these jobs according to job priority and processor availability.  The priority is either set in the job control language or controlled by the priority given the project code.  A user may request a higher priority on a job by having the FM call the computer systems operator.

File Management Supervisor.  The FMS serves the user in a combination of ways to automatically sustain files in a readily usable, reliable condition, while providing the user with the degree of security for stored information.  It provides file protection capabilities that maintain recovery details during system operation.  It is an automatic system that controls where files are stored and protects them from being overwritten.

Security Control.  Each user must have a valid PER, PJ, and PIC to log into the system.  The system keeps a list that verifies the login attempts for security purposes.  This verification compares the PER and the PIC to ensure it is valid.  Once signed on, the system prevents you from accessing any program or file that you are not authorized to access.  The system keeps track of your login security classification code (SCC) and prevents you from accessing files higher than your login SCC.

Job Flow.  One of GCOS' functions is to ensure orderly and timely throughput of jobs.  It manages this with Job Flow, which provides an orderly sequence of events.  It uses priority codes to control when it executes, as well as controls the passing of information to the peripheral devices. 

On-line System Development.  The user is able to manipulate files, access other subsystems such as Convert, and run jobs using the Time Sharing System (TSS).  TSS operates under the direction of GCOS and is a major dimension of an integrated, multidimensional information processing system.  This means the system is capable of handling several users doing multiple jobs at the same time.

Networks.  JOPES relies on WIN and Automatic Digital Network (AUTODIN) for data communications.  A dedicated packet-switching data communications subnetwork interconnects WIN sites.  It includes store-and-forward interface message processors (IMPS) and medium and wide-band communications circuits.  The JDS Interface Processor (JDSIP) interacts with WIN to route and manage database updates between the primary and backup sites.  Figure 10-1 depicts the network.

Other WIN software utilities support terminal-to-computer, computer-to-computer, and terminal- to-terminal communications.  They are listed below:
Telecommunications Network (TELNET).  TELNET, although still an active piece of software, has relatively little use in the TS3 environment because both OPLAN database hosts are accessible from the users' terminal.  It provides access to computer resources of another host in the network.  This allows use of a remote WWMCCS host computer as if the user's local terminal were directly connected to that site.  It could be used between the host at Kirtland and the OPLAN database hosts.

File Transfer Service (FTS).  FTS allows the exchange of files containing all types of data between the host computers.

Teleconferencing (TLCF).  TLCF allows planners to confer, exchange textual information, or assist in planning and decision making.

Mainframe Network Characteristics.  The WWMCCS TS3 JOPES network currently consists of two Honeywell computers connected by the WIN Communications System.  JOPES software provides real- time transaction processing, specifically the JDSIP and the JDS Update Processor (JDSUP) as shown in Figure 10-2.

Network Transaction Flow.  Transaction flow is controlled by the system through the JDSUP and JDSIP.
The JDSIP software provides the communications link between the hosts, transmitting JOPES update transactions, including network transaction routing controls, between JOPES WIN computers.

When a user sends an activity to the mainframe database, the JDSUP takes the transactions and updates the local files.  It then places the transaction, with routing header information, on the WIN send queue.  The JDSIP reads the transaction from the send queue, writes it to the transaction database (TDB) file, and gives it a number for tracking purposes.

The next transaction (as numbered) is selected from the TDB by the JDSIP and transmitted over the WIN.  The remote JDSIP receives the transaction and places it on the WIN receive queue so the JDSUP can process it.

A network status file (NSF) update acknowledges the transaction transmission across the network to assist the TDBM in tracking transaction progress.

Note:  If the site is out of the system, the TDB is held in storage until the site comes back up.

Transaction Progress Monitors.  JOPES management software has a hidden subsystem called the JOPES Control File Update (Subsystem T).  The TDBM uses two of these, S/F T5 and T8, to monitor transactions as they transit between the two hosts and see any error messages that may be generated.  The transaction status and error messages are in the UPCNTRL file.  Anyone with QRY permissions can use these monitors.  The FM should know what information is available in these two functions.  The two transaction types are:
Transaction Service Module (TSM).  The TSM is a transaction entered by the user that effects the database.  The TSM executes quickly, is normally a small high priority job, and will run continuously to completion.

Transaction Independent Service Module (TISM).  A TISM is also a transaction entered by a user that effects the database.  It carries a lower priority for execution than a TSM and consequently takes longer to complete.  TISMs start and stop as system resources allow.  Because they take longer, there is a way to monitor a TISM's execution, the T5 Subsystem/Function.

Note:  Specific TISM code is used if you only want to check on a delete or C-Day reset.  A C-Day transaction should not be in this system because execution will not happen in TS3.  They are your only options for the specific choice.

TISMs (T5).  This function permits the user to monitor the progress of a TISM or to examine a TISM history by date/time a reset began, requirement update ended, and/or reset ended.  T5 is used to investigate out of synchronization conditions by determining what transactions may not have completed and could be responsible for the condition.  It also provides the quantity of ULNs, CINs, and PINs processed.

JDSUP Error Messages (T8).  This monitor is used to track JDSUP error messages created in the UPCNTRL file.  It can be used by anyone with QRY permissions to JOPES, but is often used by the FM and TDBM.  It allows the user to monitor only error messages created in the JDS UPCNTRL file.  Users may <RETURN> to review messages sequentially or enter specific selection criteria.  Through the use of masking, the user is able to enter all or part of the data requested.  For example, enter a date in the YYMMDD fields and $ in all the other fields to display all error messages since that date (one message at a time).  The requester must page through all the messages until "End of Requested Messages" is displayed or exit the subsystem.  Entering the User ID and host name will display all error messages generated by that user at that host that are still stored in the system.  The line "Occurs [  ]" will show the number of times that error message occurred.

JOPES Database Characteristics.  FMs should be familiar with the unique features of the JOPES database.  The FM must understand the physical and practical system limitations and how the volume of information affects system performance.  Prior to adding a TPFDD to the system, the FM should be familiar with the impact on system performance.  The following are basic considerations:

Note:  Database fill levels are not currently critical in the TS3 environment because there are presently so few OPLANs on the database.  The information is presented to enhance your understanding of the system and not because it is critical to your duties.

JOPES Databases.  The current JOPES database is split into two parts:  real world and exercise.  Each database is unique.

JOPES Subfiles.  These two databases are further subdivided into eight (8) subfiles.  These divisions are similar to the cat/file string you use when saving data.  It is simply a way of organizing information.  They are a permanent part of the database and are accessed by S/F or JSIT commands instead of a string of commands.  The subfiles are (record series shown in parenthesis):

Access Control/Sync (0-99).  This subfile controls the plan.  It includes the security classification, type of plan, access, etc.  Primarily this file contains any information that does not fit in the rest of the files but is necessary to the plan's existence.

Plan Information (200).  This subfile is related directly to the A subsystem.  The data entered through S/F A1 or A6 screens goes to this file.

Unit Information (400).  This subfile is related to the C subsystem and is the file that holds unit (SORTS) information for sourced records in the plan.

Requirements (500).  This subfile is directly related to the B subsystem.  It holds the information as to what the requirement is, timing for movement, etc. 

Scheduling and Movement (600).  This subfile is directly related to the E subsystem and would contain all the carrier, schedule, and manifest information if the system were used for execution.  It should be empty.

Nonstandard Cargo (700).  This subfile is directly connected to the B subsystem, specifically the 7 and K functions.  When you tailor cargo, it places that information in a separate location from the standard cargo.

Note:  A standard UTC is often used many times within a plan.  It only needs to write that information one time for all copies.  If you write a nonstandard cargo detail, it is unique and needs a separate place for the information.

Not Currently Used (800).  At one time this was used for the movement tables.

Force Module (900).  This subfile is tied directly to the D subsystem.  It is used to store force module information to include the chains that link individual requirements to the FMID.

Database Fill Levels.  Figure 10-5 depicts the database fill levels.

The standard size in littlelinks (each littlelink is about five OPLAN records) for a JOPES database is approximately 215,000.  The JOPES software is specifically written to address that size database, so expansion by the addition of more diskpacks has no effect.  System overhead requires 10 percent of the available space, while the rest is reserved for the users.  This 90 percent is divided into the subfiles described above.  Each subfile or group of subfiles is a specific size and cannot share space with others.  The requirements subfile is the largest and is generally the one that gets filled first because plans are requirements based, with all other data dependent on the number of requirements.  This subfile's size is calculated so that the real world and exercise requirements space comprises approximately 60 percent of the site's user capacity.  The other three groupings of files:  Plan Information and Force Modules, Unit Information and Nonstandard Cargo, and Scheduling and Movement comprise 10 percent, 20 percent, and 10 percent, respectively, of the users' file space.  Sixty to 65 percent in any subfile is considered the point at which performance begins to degrade.  Either the FM or the TDBM can run a program called DBSTAT to check the fill levels.

Management Considerations.  The JOPES networked database is an Integrated Data System (IDS) structure.  At 65 percent file saturation, the system response begins to slow down.  At 80 percent, it degrades dramatically and a system crash becomes highly possible.  At 90 percent, a crash is imminent.  These critical levels apply to the individual subfiles, not total file space (does not share).

Note:  Normally the DBSTAT Report is a TDBM function, however, we will briefly introduce it here.  It can be run from the time sharing prompt by typing <FRN JDTDB/WIN/STATS/DBSTATS,Q,> and pressing <RETURN>.  Then answer the dialogue screens that follow.  Be advised that this program takes a long time to run.  See Figure 10-6 for an example of the report.

Note:  0 = Exercises, 1 = Real world in the first column of the DBSTAT file.  As FMs, you are interested in only four of the listed subfiles, PLANFM, REQ, SCHED, and ASMUNM (nonstandard cargo and unit information).  In the report, you are only interested in the fourth column.  When the column reaches 65 percent, the FM should take action with the users to find data in that subfile that could be removed/eliminated.

So far, you were introduced to system fundamentals to include design, characteristics, and some performance of the mainframe.  As this lesson continues, you will use some tools to analyze your current situation.  Is your OPLAN on the backup host current?

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

JOPES Data Synchronization.  With many people needing access to the same information, there are several things to take into consideration, such as:  do they all need access at the same time, does the information need to be exactly the same, what should each one be allowed to do to the data, etc.  The FM, as the system problem solver, is not responsible for those decisions, but is responsible for keeping the data consistent, i.e., the same for all to see and use.
Synchronize a Mainframe Database.  In the 70's and early 80's, the planner's number one problem was the lack of a common database available to all participants.  The solution to the problem was the creation of the IDS/I database.  This networked database was resident on the WIN at each of the host sites, available to all users with proper permissions to view and use.  This allowed everyone to review the same information simultaneously, or did it?  This database was only the same if each database on each mainframe was the same, that is, synchronized.  Under normal circumstances data and files that are shared between the two sites will be in sync, i.e., a carbon copy of each other.  However, there are some situations when this may not be true.  For example, if a site is out of the network while a transaction is traversing the system, it is possible that the transaction could hang up in the queues or get deleted before it completes the circuit.  Another possible situation is that it simply does not make it to the other site.  When this occurs, the FM needs to use the appropriate methods of identifying the condition and selecting the proper tool to solve it.

Methods of Synchronization.  The method of synchronization used by the FM depends on the circumstances.  On the mainframe, the SYNC subfile can be automatically or manually updated.  We will cover the steps for both.

Automatic Synchronization.  The system automatically updates certain information (PID, plan type, distribution, status, etc.,) that are maintained in the SYNC subfile (part of the 10 percent overhead space).  This is an automatic update that occurs when a user executes the related JOPES functions.  Table 10-1 is a list of those automatic transactions related to the SYNC subfile.

These are the types of transactions in the SYNC subfile that are automatically updated.  You will use the subsystem/function codes the FM uses to monitor and synchronize the database.

Note:  Return to the Master Menu and ensure the PID is blanked out.  The PID should be entered on the S/F HV screen because an OPLAN may be in delete status or hung somewhere, but deleted from your current site.  Entering the PID at the Master Menu could result in an "OPLAN does not exist" message.  Entering the PID at the HV level will show all sites the plan is deleted from, plus the action at the hung site.

OPLAN Network Status (HV).  The IRM H subsystem function V can be used to display or generate network synchronization data for a specific or 'ALL' OPLANs on the database.  The local/network FM/TDBM uses the S/F HV to check OPLAN synchronization.  The Network TDBM also uses S/F HV to reset or report on specific network and local synchronization data, User IDs, and subsystem/function codes for a specific OPLAN or 'ALL' OPLANs.  You will concentrate on the functions a Site or Network FM could perform using HV.

Display Network Synchronization Data At Terminal, Option A.  This option allows for the comparison of 18 specific pieces of information in networked plans to check for synchronization.  If any of these items at any site do not match, then the plan is potentially out of sync.  A discrepancy in these blocks indicates that further research is required.  It may be that the update has not traversed the system yet or the transaction did not complete its course.  It can also be used to check the status of plans that are in delete/load status, but have not completely deleted from the network, i.e., find plans hung in delete status.

Note:  There are three options available at Enter OPLAN Number:  (1) an OPLAN, (2) All, or (3) Count. If a specific OPLAN is entered on the OPLAN Network Status screen (IF-V01), the user must be authorized access to the OPLAN.  The All option can only be used by the Network FM.  The Count option can only be used by the Network TDBM to review and reset S/F and User ID counts and other TDBM functions.

Both sites will display the plan status, type, network indicator, C-Day L- Hour, ULN/CIN/PIN counts, and number of carriers by the four types.  However, this is only half of the network display, or part 1 of 2.  To get to the second part, put a 'c' into continue.  If a space/xmit is used without a 'c', you will return to the OPLAN Network Status screen, IF-V01-1.

This screen provides DTG plan was initiated, DTG load began, percent of load, DTG of percent plan load, OPLAN originator, and as of date.  These are the 18 separate items that can be checked for synchronization.  If they do not match for both sites, then further research is required.  The "as of date" is the last time the synchronization was done.

Generate Batch Network Synchronization Exception Report, Option B.  The site FM may want a written report of the type of information that Option A displays.  The Exception Report lists synchronization data at both sites for a single OPLAN.  This report provides all synchronization data for the comparison site and gives only values that are different at other sites.  If the values for the comparison site and the other site are the same, dashes (--) are printed in those fields.  Line numbers are printed before each site to show the number of sites that have the OPLAN.  The comparison site will be the first host listed on the Exception Report.  Only the plans that the Project Code has permissions to will be printed on the report.  The Network FM can use 'all' in the Enter OPLAN Number field to produce this report for the entire set of networked OPLANs to which the FM has permissions.  This report provides a hardcopy of what was available on the screen using Option A.

Note:  An example of the report is shown in Figure 10-10.

Request Update To Network Synchronization Data, Option C.  This option has two suboptions associated with it:  a single plan or all plans.  The single plan and all plans commands are used to update out of sync OPLANs.  This option starts the SYNC subfile updates that were discussed at the beginning of this section (Table 10-1).  If after performing this option the plan(s) is still out of sync, recovering individual lost transactions becomes the next step.  This option can be run by a user (with IRM permissions) for a specific OPLAN or by the Network FM for all OPLANs.  This is not a Spawn Batch Job option.

Note:  The standard "Transaction Queued, System Load May Cause Delays" message will appear when transmitting after putting an appropriate entry in the OPLAN block and selecting Option C.

Reset S/F Code and User ID File.  Another possible input on the HV screen is the word Count in the Enter OPLAN Number field.  It is executed by the Network TDBM only and requires special permissions.  The Count option permits the Network TDBM to generate special SYNC transactions that update specific subsystem/function code and User ID files.  These files are used to track how many times, when, etc., an S/F is used, and what transactions are generated by specific User IDs.  It also permits the TDBM to generate reports of those transactions for audit and system maintenance.

Manual Synchronization.  When the automatic sync does not solve the "out-of-sync" condition, the Network FM may need to do a selective site data recovery, S/F HU.  This procedure is usually reserved for repairing a site after a complete recovery process, but may be used to fix missing individual or groups of ULNs, CINs, PINs, and carrier records.  This is a network FM management function and will be covered in more detail during site recovery in Lesson 12.

That is TS3 mainframe synchronization.  It is generally the responsibility of the Network FM, but as a site FM, you may find yourself assisting.  With synchronization done, the next step in analysis is the audit, or who did what to whom!  If something caused the network to get out of sync, it is in the best interest of all to find out why it happened so you can prevent it from happening again.

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

Journalling.
Automatic Process.  The journal collection files and tapes contain all of the information required to conduct an audit.  The journal collection process is fully automated through the UP.  It first writes to one disk file until it is full, then switches to another.  At that point, the system directs the disk file to archive to tape, making the disk file ready to take over when the other disk file fills up.

Tape Maintenance.  Normally there are five tapes assigned to the journal function, but up to 40 tapes can be assigned.  S/F HM provides a method to add, replace, or remove a tape from the journal index file.  It is restricted to the site TDBM and requires UPD and IRM permissions.  HM also allows the TDBM to produce a display of all tapes in the tape index file.

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

Conduct a JOPES Audit.  The primary analysis tool for the FM is built into the system as automatic saves of user inputs (journalization).  The FM produces reports that show who has been doing what to whom.  This is referred to as auditing.
Purpose.  Users sometimes make mistakes.  When the FM encounters an error, like the inadvertent deletion of critical requirements, the FM must respond quickly to minimize the damage.  Mainframe JOPES provides historical records for this purpose.  These records can be used for research and repair.  They can also be used for prevention.  That is what the audit process is all about.

Note:  Navigate to the JOPES Master Menu in the exercise database.

Process.  The audit retrieval process allows authorized users (with IRM permissions) to review the transaction flow through JDSUP by processing the Journal Collection File (JCF) and Journal Collection Tape (JCT) maintained by JDSUP by ordering the required report.  The user can specify a transaction date/time range to retrieve and filter by specifying additional options.  What this means is that you can review all plan(s) transactions, at a host(s), during a specific time frame.  These transactions are then put into a file for access by the specified retrieval.  The local FM or Network FM can specify the type of transaction(s) selected from the JCT and JCF using various options.  S/F HO provides the FM with three different reports in four options.  Options A, B, and C are transaction oriented.  Option D is data oriented and will be discussed later in the lesson.
Transaction Report, Option A.  The Transaction Report (entitled Partial Transaction Report) lists just that, transactions.  It is a condensed report showing User ID, OPLAN, DTG, transaction entry and update, host, and database updated.  It does not show transaction details, i.e., actual number of PAX, etc.  (What action occurred, not what changed.)

Transaction Dump, Option B.  The Transaction Dump is a bit more expanded than the Transaction Report.  It shows all qualifying transactions in unformatted 132 character lines.  It is not very easy to read and requires some practice to learn how to find information quickly.  Again, solely transaction oriented.

Transaction Dump and Report, Option C.  This option produces both of the above reports.  You will use this option to review the transaction oriented audit reports.

Note:  "X" in All Except block excludes the preceding entries from the report.  In this case, the two plans, the USERID, and Host listed would not qualify for this report.

Note:  Entering an "X" at All Except will exclude the information selected in the bottom half of the screen.

Note:  An example of the report is shown in Figure 10-14.

The Partial Transaction Report provides the FM with a list of all transactions that updated the system within the input parameters.  The report provides the User ID (PJ) of the operator who executed a module against a plan.  No specific actions like changes to cargo or passengers are listed.  (The first three columns are JDSUP generated numbers used for control and auditing).  Of more use is the Dump Report.  The Transaction Dump Report is a transaction oriented Report in unformatted 132 character format.  Functional data can be found there but with some difficulty in being certain exactly which information it is.

Data Transaction Report.  This option permits the FM to run reports that are data element oriented vice transaction oriented.  The FM can review what transactions have occurred to a ULN, CIN, PIN, and/or carrier/manifest.  It also allows you to further limit your review by specific User ID(s)/host(s).  This report displays the transactions for a specified period.

Note:  An example of the report is shown in Figure 10-16.

ULN Transaction Report.  This report provides information on what was done to all ULNs in that plan by that User ID for the specified period of time.  This can also be done for CINs and PINs.

Audit Subsystem Data Qualification.  The Audit subsystem has an additional capability to further limit (qualify) the amount of data that appears on the report.  If on the HO screen, after selecting any of the four options, you place an "x" in the Enter 'X' to Select Specific Requirements and/or Carriers block, the IF-005 screen displays.

Data Qualification.  This allows the user to limit the report content by date, type of requirement or carrier, specific requirement(s) or carrier(s), User ID(s), and/or host name(s).

The style of the three reports is identical.  The only difference is in the information that qualifies for the report.

FM's Role.  The FM uses these tools to solve problems.  They can identify out of synchronization plans and audit activities to determine the cause.  From the cause, corrective actions can be implemented and work assigned.  (If you messed it up, you may be required to fix it.)

Up to this point, you have learned what the FM does and some TDBM functions to use when necessary to achieve objectives.  We will now discuss the JOPES Monitor Subsystem (M), which allows you to watch transaction data processing within and between two sites.  The permission needed to view these functions are QRY, and RPT if you wish to generate a report.

OBJECTIVE.  Given a WWMCCS environment, monitor the JDS Update Processor and Interface Processor activities.

JOPES Mainframe System Monitors.  The JOPES Monitor Subsystem (M) allows the system manager to monitor JOPES JDSUP and JDSIP activities.  Problems typically arise with transaction data processing or information flow between sites (JDSIP) or within a specific site (JDSUP).  Problems can occur because of support systems such as WIN.  These monitors are often used by the TDBMs and the FMs.  Often, experienced users will use specific subsystems as well.

In general, the M Subsystem looks at two types of activities:  those of the JDSUP and JDSIP.  Functions 1, 5, and 6 are JDSUP monitors that report on what is happening internal to the site.  Functions 2, 3, and 4 report on JDSIP activities, i.e., what is passing between the two sites.  Each monitor allows the user to either (p)eek at the screen or (m)onitor the screen.  The peek option allows you to temporarily view activity.  Monitor brings up the screen and keeps it there, refreshing every few seconds, until the user enters $*$B.  In the case of the JDSUP activities, the user gets a specific number of sweeps.  If the function monitors the IP, the peek has a selectable number of sweeps.

You will review each function.

Note:  Entering P will display five refreshed screen displays and then return to the M subsystem menu.  Entering M will put the monitor in continuous display.  If continuous display is selected, then enter $*$B to stop monitoring.

JDSUP Status Monitor (M1).  This monitor shows the JDSUP status and allows the user to determine whether the JDSUP is processing transactions.  If the numbers are not changing, the JDSUP is experiencing problems, and the user should contact the local TDBM for assistance.  Table 10-2 describes each of the fields displayed.

Now you will look at the local JDSUP activity monitor (M2).

Note:  Enter P to display five screens/displays, M for continuous display, or 1-9 (sweep count to see a given number of screens/displays).

Local JDSIP Status Monitor (M2).  This monitor displays JOPES transaction movement through the WIN to include IP-related information.  The JDSIP is the only processor that interfaces with the TDB.  By monitoring transaction status in the TDB, the user can determine if the JDSIP is doing its job.  Table 10-3 describes each of the fields on this screen.

Now you will look at the Network Site Status monitor (M3).

JDS Network Site Status Monitor (M3).  This general system monitor tracks transaction activity between the local JDSUP and JDSIP and monitors the NSF for network activity.  From this monitor a user can determine the status (up or down) of the UP, IP, and backlogged transactions in both the send and receive queues.  Additionally, it displays the time when activity stopped at a JOPES WIN site and whether a hung gate within the JOPES software is preventing further processing.  Table 10-4 describes each of the fields displayed on this screen.

Like M3, M4 also gives additional information on the JDSIP activity.

There are four options for viewing this screen:  connected, list, reporting, and all.  Since all screens look alike and will include the same data, you will only access one screen.

Note:  The four options were useful when there were 20 sites in the network and GCCS JOPES did not exist.

JDS Network Status File Monitor (M4).  This monitor displays JOPES transaction movement through the WIN.  The NSF records JOPES transaction data from each JOPES WIN site.  Each transaction is numbered and tagged with the originating site ID.  As each JOPES site receives the transaction, the site checks whether the transaction number is the next sequence number from that site.  If it is, the JDSIP logs the transaction into the NSF and changes the file to reflect the new site transaction number.  Table 10-5 describes the data elements displayed on this screen.

JDS NETWORK STATUS FILE MONITOR (M4)
Item #	Field Description
1	Originating site.
2	Receiving site.
3	Last transaction number sent from the originating site. Last transaction number received from the originating site.
4	USERID that entered monitor.

Like M1, M5 also gives JDSUP activity.

Note:  This is a timed screen, no other user entries.

Transaction Activity Monitor (M5).  This monitor displays the JDSUP activity by transaction type for all plans being processed by a site.  The M5 Transaction Monitor provides a functional language view of transactions processed by UP.  Table 10-6 explains the fields displayed on this screen.

Like M1 and M5, M6 also monitors JDSUP activity.

Update Queue Status Monitor (M6).  This monitor displays local transactions in the Update Queue awaiting JDSUP processing.  The other two JDSUP associated monitors are Transaction Activity Monitor (M5) and JDSUP Status Monitor (M1).  M5 looks at internal JDSUP transaction processing, and M1 monitors the Trace File which JDSUP updates as it processes transactions.  Table 10-7 explains the entries on this screen.

That completes your tour of some of the basic analysis tools that are available to the FM and TDBM.  You will next turn your attention to the usage of files in support of JOPES activities.

OBJECTIVE.  Given a WWMCCS environment, manipulate personal JOPES TPFDD files.

Mainframe File Usage.
Files Management.  Any database needs organization or it becomes useless.  If the library did not have the Dewey Decimal System as a standard file system, then each library would need to establish its own way to place the books on the shelves.  Therefore, every time you try to access the books at a different library, you would have to use a different system.  An even worse situation would be if the library decided to just put the books on the shelf in the order they came into the library.  It would be impossible to find any information efficiently.  The JOPES database is no different from a library in that it has lots of information that needs to be accessed often and quickly.  Instead of the Dewey Decimal System, JOPES has file systems.  We will review JOPES files by discussing file attributes, usage, management, and construction.
Review File Attributes.  If you are to use files successfully, you should have an understanding of the structure of the files.  Files created on the mainframe are used to store data generated by the user or the system.  The default file type is sequential, but the user may also create random files.  The attributes are the characteristics of the file and are shown in Figure 10-25.  Files on the mainframe can be manipulated using the access subsystem at the timesharing prompt.

This figure displays the attributes of a specific file such as:  its creator, size, location, and permissions to access the file.  Also depicted are the date it was created, the number of times the file has been used, and when it was used.  File type will be either linked (sequential) or random.

File Usage.  Below are some of the reasons a functional user or the FM may consider creating files on the mainframe.

As a Storage Device.  Files can be used to store user or system data required on a permanent or repetitive basis.  (Reference files, JDS subfiles, etc.)

As a Working Medium.  Files may be used as a temporary working medium to manipulate or change data.  This is probably the most frequent usage of files for all of the JOPES application.

As a Transfer Vehicle.  On the mainframe, files are more efficient than tapes when transferring data between or within a JOPES site.  The user does not have to rely on the system operator at both ends to load tapes with those associated delays.  However, users should ensure that files are constructed properly, are large enough, and have the correct security classifications (correct attributes) when transferring data between sites.  Files are also used to transfer data from the mainframe to the hard drive on your PC workstation or from your workstation to the mainframe.

As a Save/Archive Vehicle.  As long as there is ample disk space, the disk can be used as permanent storage.  Users should consider making backups of critical data for out-of-system storage since disks do occasionally crash.

Now that you have reviewed the attributes of files on the mainframe, you will transfer a file from the primary host to the backup host.

OBJECTIVE.  Given a WWMCCS environment, use the FTS software to copy a file from one host computer to another host computer.

Transfer a File.
Between Sites.  On occasion you may have to move data between sites for such things as recovery of lost or destroyed data, teleconference transcript files, TPFDDs, or ASCII data.  These are only some examples of the reasons you may need to use FTS to move data between sites.

Note:  From the timeshare prompt, type "jdac fts" to navigate to the FTS prompt.

Note.  A TPFDD file is resident on the primary host for you to transfer to the backup host.  The file, the last item in the cat/file string, does not need to exist at the receiving host, but a catalog (and subcatalogs if desired) must.  Those catalogs do exist at the backup host for your use.  The files at the primary host are {instructor created}.  The catalog at the backup host is {instructor created}.  FTS is used to transfer files.

Note:  The "exec ps m" command tells the system to execute the job, post its status, and monitor the job until completion.  After the job completes, the screen will post with the FTS prompt.

Note:  Screen will display the job's progress as it goes through each required step, keeping you informed as to what is happening.  Upon completion, the screen returns to the FTS prompt.  Type "dac tss" to return to time sharing.

Within a Site.  To transfer a file within a site, simply use the TSS copy command.  Remember to clear the AFT after copying files if you plan to use them immediately after copying.  If this is not done, the user may get a files busy message.

Note:  The rc command is for "remove and clear files."  This will unbusy the files. 

Now that you have reviewed file creation and transfer, let us turn our attention to some aspects of tape management, the other source of data storage or transfer.

OBJECTIVE.  Given JOPES operating in a WWMCCS environment, save an OPLAN to a tape.

Tape Management.  Before computers, information was commonly stored on paper or film.  The computer age brought its own special needs for data storage.  It needed to be of a nature so the systems could react efficiently with the computer.  Information needed to be easily saved and loaded into the computer when necessary.  One medium commonly used is magnetic tape.  Tapes can hold a large amount of data for extended periods in a readily retrievable manner and can be easily stored.
The Tape Medium.  Tapes are generally used to store large amounts of data that may not be needed on a regular basis.  Tape storage is an easy way for the tape libraries to establish and maintain an out-of-system storage (archive).  In the following paragraphs, you will learn some other possibilities the FM may want to consider for tapes.
Backup.  This is the traditional way for the FM to store the JOPES database.  In the JDS software, the FM may use the H3 function to store to tape in JDS transaction format.  This format permits the FM or user to take a snapshot of an OPLAN.  Another method to backup to tape is the B8 function.  This method will save OPLAN TPFDDs in JOPS format, which can be used in JDS or JOPS applications.

Transfers.  Another aspect of tape use is the ease it provides the FM/TDBM to transfer large amounts of data between sites.  Many of the reference files and site recovery files are transmitted in this way, either electronically or manually (handcarried).

Archives.  This is the same as backup, but there is another option, H4, which is restricted to the TDBM.  This function permits the TDBM to backup several OPLANs onto the same tape.

Perform a Tape Save.  Most of the tape saves accomplished by the FM involve the saving of data that is resident on the IDS/I database.  The H3 Subsystem/Function of (JDS) JOPES saves information in JDS transaction format, while the B8 Subsystem/Function saves in TPFDD (JOPS) format.

Note:  You may monitor this job via the JMON command at the TSS prompt.

Now that you have been through the steps for saving data to a tape, you will reload the OPLAN from the tapes.
Perform a Tape Load.  In this section you will create a new OPLAN with the data from the offloaded tape.  After you enter the H3 function, the system will automatically switch you to the H1 plan initialization function.  You may reload the plan with the same PID as the tape or you may reload it as a different PID.  In either case, the PID you are creating cannot exist on either host.

Note:  There are some special rules or conditions that apply when initializing an OPLAN with H1 and/or loading with H3 or HK.  Quite often, people are surprised when these conditions occur because they are not familiar with the design.  Tables 10-8 and 10-9 summarize the possible conditions.

Note:  If you initialize an OPLAN (H1), it will be in the above status depending on the OPLAN type and distribution selected.  Under any of the above circumstances, HK can load the plan.  If, however, you reset the plan type (H2), you may or may not be able to use HK to load.  For example, if a close hold OPLAN is changed to normal, it will change to available status and not accept an HK load (Table 10-9).

As you can see, tapes still have their place in the information arena.  However, once you have several tapes to manage, it may be a good idea to establish a tape library of your own.

Establish a Tape Library Plan.  The tape librarian at the computer operations center maintains a library of tapes with internal and external labels.  But if you work with tapes on a recurring basis, one of the ways to manage these tapes is to request a block of tapes from the library and have them labeled exclusively for your User ID.  If you have a personal library, you will need to keep track of what you have on the tapes.   You should review and validate the need for the tapes periodically.

You have covered some of the aspects of file and tape management and you have built an OPLAN.  Now you are going to add those Marine records that are in a file at both hosts.  Using the merge capability to add them to the database.  Merging data is something that can happen often.  TPFDDs are usually built by the service components of the supported CINCs and then combined into a single database.  The combining of those service TPFDDs is usually done by the FMs at the supported command.

OBJECTIVE.  Given a TS3 WWMCCS environment, merge a JOPES TPFDD file into an OPLAN.

Merging Records in JOPES.  The merge capability exists in JOPES to permit users to combine large amounts of data.  The key word is combine records, not overwrite like copy does.
Sources of Records.  You have covered some of the sources of records in the basic users' course.  This lesson will be a brief review of those sources.
OPLANs.  OPLANs currently on the IDS/I database are often the primary source of updated records.  These records are easy to transfer back and forth.

Files.  Data may reside on an archived or personal file, and you may have to extract it from its storage location before merging it with another plan.  You could also be "air-gapping" records that had been created or manipulated in one of the other JOPES applications such as JFAST.

Tapes.  Tapes are generally used to store large amounts of data and provide out of system storage.  Many functions in JOPES make use of the archival capability of tapes.  Provisions are made for merging these tapes directly into the database.

That was a very brief review of some of the sources of data for a merge.  You previously transferred a file from the primary host to the backup host, so it is resident at both places.  You will now merge that file into your OPLAN.

Perform a Merge.
In JDS.  Records to be inserted into the IDS/I database via B3 must be in TPFDD format.  The following steps will show you a method to merge a file in TPFDD format at a local site into a local OPLAN.

Note:  Ensure that each student's plan has had sufficient time to load.  You can check the status with A3, then, when the plan has completed loading, go to the B3 S/F in the exercise database.

You have just reviewed one way to merge records in JOPES.  The JOPS F71 module is another method, but is restricted to TPFDD formatted tapes.  Some of you will find yourself working with planners who insist on working in the JOPS portion of JOPES.
In JOPS.  The reasons for merging TPFDD format data are the same as above.  A key difference is that there is no database per se, but a series of separate magnetic tapes.  These separate tapes can all be merged together into a single master OPLAN.  The module to use is called F71 and will require you to answer a series of questions concerning your tapes.

Now that you know how to add TPFDD formatted data to your OPLAN, what do you use to add transaction formatted data?

OBJECTIVE.  Given a WWMCCS environment, describe the process of updating a JDS OPLAN using transactions from an external source.

Transaction Formatted Updates.  Transaction formatted updates can be generated by the DART application and by the next version of the MAGTF application.  Those transactions can be loaded into a file on the host and then added to your OPLAN.
Transaction Editor (S/F U2).  The transaction editor is the subsystem and function code required to complete the process.  After the transactions are stored in a file on the host, the JOPES Transaction Editor (TE) S/F U2 can use that file to update the JOPES IDS/I database.  The TE is a transaction based interface between the IDS/I database and any JOPES or non-JOPES application that does not write "directly" to the database.  That is, if your keystrokes, as in BL, go directly into the database as you key them, it does not go through the TE.  Any other activity that updates the database goes through the TE.

Note:  All data entered into the mainframe database is edit checked.  If you fill out a BL screen, each data entry is checked for validity or accuracy, i.e., does the GEO exist, is the UTC valid, etc.  All of these edit checks were included in the U2 TE process, so external information entering the database via other means is as stringently checked.  Certain JOPES S/Fs that take plans off the database, reenter plans into the database, merge plans into the database, or make mass changes to the database (H3, H4, HK, B3, and F6) are required to go through a minimal reedit when executed.  The minimum check includes service, PROVORG, cargo category code, and alpha/numerics/invalid characters.

Permissions.  To execute U2, QRY and UPD permissions are required.  The system then controls the execution with no further input from the user.  The transaction editor designers built all the standard edit checks into U2 that are used for any of the mainframe JOPES input screens.  Therefore, the transaction editor checks the validity of the update and rejects invalid entries (e.g., GEO does not exist) with no further input from the user.

Execution.  TE addresses the following individual JOPES subfiles:  scheduling and manifesting, change/diversion, unit requirement, nonunit requirement, nonstandard cargo, unit movement data, change data, force module, and aggregated CIN transactions residing in user files.  The transactions are passed into the TE in one of three ways:  by U2 execution from a screen entry, automatically by the other S/F (B3 or HK) you use, or by building a transaction file to execute manually.  By entering S/F U2, the Edit a Transaction File appears (Figure 10-33).  The user then enters the cat/file string of the location of the data and lets the system do the work.

Action.  U2 edits all data coming from outside mainframe JOPES data sources for the same errors that it checks mainframe JOPES inputs.  After the edit checks are complete, all transactions that pass are sent to the update queue for the JDSUP to process into the database.  Those transactions that do not pass the edit checks are rejected and written to the JDS Transaction Editor Report.  A sample report is shown in Figure 10-34.

Note:  The report lists the transaction type in TDBM language, the OPLAN affected, the database item affected, and what caused it not to update.  Translation of the Type block can be found in TD 18-14-1, Vol 9, JDS Transaction Editor Users' Manual.

Report.  This list of rejected records is printed along with the reason the record failed.  A complete list of transaction error messages is in the JDS Transaction Editor Users' Manual, TD 18-14-1, Vol 9. 

Transfer Issues.  The transfer to JOPES requires the transactions to be in a specific format to match the receiving TPFDD in the IDS/I database.  Therefore, you need to make allowances for the following kinds of problems before using the S/F U2 Transaction Editor:

Force Module information changes done in DART, for example, are not processed correctly.  Avoid transferring TPFDD transactions containing force module related changes.

The U2 editor will reject incorrect TUCHA Status Indicator codes.

The initial B8 download from WWMCCS to DART may have added a bogus TUCHA Status Indicator, "2," to the TPFDD records during the download.

You can use DART to correct it (legal entry "blank" or "x") prior to passing the records back to the DPS 8000.

The U2 editor will also reject invalid CCCs.

The B8 download may have also added a bogus cargo category code, "TUC," if the level two cargo detail information was modified without changing level four data.

Again you can use DART to remove the invalid TUC code prior to the transfer.

The U2 process splits nonstandard cargo transactions for new ULNs into transaction types and processes them separately.  When the U2 processes the transactions out of order (changed before created), the record rejects.  Remember, an "add" transaction cannot happen to a record that already exists, a "change" or "delete" transaction can only occur to a record that already exists or it will be rejected.

The workaround is to create a ULN in one DART session, then process the "add" transactions through U2.  After the add is completed, make the cargo detail changes in a second DART session and process as "non-standard cargo" transactions.

Be advised, the TE performs a total replacement for non-standard cargo transactions.  All nonstandard cargo transactions for a ULN are edited by the TE.  In the process, if the transaction passes the edit, a "delete all" transaction is cut to remove all the current data that is there.  Then the update is processed.  The potential result is that only the last transaction ends up in the record.  If a user makes level four detail changes within DART, recommend using B3 vice U2 for the update in order to keep the level four detail modifications intact.  Merging an entire TPFDD takes longer, but you get all the changes that pass the minimum edit check.

The best way to troubleshoot U2 problems is to carefully review the Reject Report and adjust the TPFDD to compensate for the problems or do the straight B3 merge.

Now that you know how to get OPLAN records into the database, it is time to turn your attention to keeping the reference files that assist in building these OPLANs current.

OBJECTIVE.  From a list of possible answers, select those that reflect the FM's duties as they relate to the reference files.

Reference File Management.
Why Have Reference Files?  Reference files are the reusable libraries for the database.  They provide data standards of information for planners and other functional users.  You will review some of the reference files listed in Table 10-10 for the names and functions of the primary reference files.

Reference files are vitally important to the users of JOPES.  They permit planners to concentrate on building and executing plans without having to worry about the validity of some of the detailed and redundant information.  These files must be updated periodically.  DISA manages the update and distribution process and releases an update to many reference files on a quarterly basis.  You will look at the FM's involvement with the reference files.  When they need to be updated, several agencies get involved to ensure a quick and efficient upload is accomplished.
Reference File Update Procedures.
Files Arrive.  The reference files usually arrive at either site in tape form and are consigned to the WASSO.  These files are accompanied by a package of documents which the WASSO processes.

WASSO Processes Package.  One of the documents in the package is the transmittal slip.  The transmittal slip identifies which file is being updated, instructions for the TDBM on the number of records, a time frame for upload, and a brief description of changes that have been implemented.  The WASSO passes a copy of this document to the TDBM and sends the tape containing the file to the tape library.

FM Notified.  After the WASSO notifies the TDBM, the TDBM reviews the document and contacts the FM to schedule the appropriate amount of down time for JOPES.  JOPES must be unavailable to the users during the upload period for two reasons:

The users could easily cause files to be in a busy status when they are be needed by the system to accomplish the update.

In addition, the users may find that the information they are accessing on the system will change as the load is being conducted.

Users Notified.  After the FM is notified, he must coordinate with the TS3 users to determine the best time to have the files updated.  Usually the files are delivered with a window of opportunity from the source.  However, the FM must use tact and tenacity to ensure that the files get updated within that window.  Consideration should be given for critical and ongoing operations.  Do not forget, users may use the backup site to continue processing.  This may require some planning, especially if the user needs local plans.

TDBM Update Files.  The FM coordinates with the TDBM to accomplish the update.  Under most circumstances, the update will consume approximately four hours.

FM Notified of Completion.  If all goes well, the TDBM notifies the FM that the system is available.

Users Notified.  The FM then goes through the same channels to notify all users that the system is again accessible.  The responsibility of the users and the FM does not stop here.  Users and the FM should be keenly aware of any impact that the files may have on previous work.  A friendly reminder from the FM to the users to validate critical work that was previously done against the new reference file may be in order.

As you can see, the FM has limited involvement in the actual updating of the reference files.  You will now do a short review before beginning the next lesson.

Summary.  During this lesson, you have considered several topics.  You started out with some system analysis and used the monitoring subsystem to assist.  You also worked with some personal files saved on the mainframe and transferred a file from one mainframe to the other.  You also worked with tapes by saving an OPLAN to one and then reloading it back into the JOPES database.  You also reviewed the procedures used to update the reference files that are used to assist in creating OPLANs.