by knowing the limitations of the existing system, you can project what additional equipment will be needed to handle the future workload of the command. This  may  include  additional  network  drops  and terminals  located  throughout  the  command,  spare  parts, backup media, and personnel. The most important thing to remember when projecting the future growth capabilities  is  to  take  your  time  when  doing  the research. You don’t want to come up short when requesting the additional materials that you expect to need  later  on. BACKUP OPERATIONS Backup operations fall into two categories: normal and special saves. Normal saves. Normal saves are the ones worked into  the  monthly  production  schedules.  These  saves  are normally done every day or night and are the most important recovery tool available to you. Special saves. Special saves are the ones that need to be done before and after the implementation of a software  upgrade  and  during  monthly  and  yearly production runs. The saves that are done in association with a software upgrade are not covered on your production  schedule,  since  upgrades  are  not  released  on any published schedule. CONTINGENCY PLANS AND DISASTER RECOVERIES The most important part of disaster recovery is having  a  contingency  plan  and  current  backup  files. The AIS facility’s contingency plan covers what is required to get the facility back online as soon as possible.  Your  contingency  plan  should  include emergency response, backup operations, and recovery plans. To have current backups, we must ensure that normal saves are done as scheduled. The saves can be categorized as either whole system or data file saves. The  AIS  facility’s  resources,  schedule,  and  instructions will be the governing factors as to which category of saves and the frequency with which the saves will be done.  For  further  guidance,  as  to  the  minimum frequency and the category of saves, refer to the local type commander’s (TYCOM) instructions. Another part of the recovery process is making sure that   replacement   parts   are   available.   There   are constraints  as  to  the  number  of  parts  maintained onboard your activity. Before a major deployment (or periodically for shore activities), it is important to take an inventory of the parts so if the parts are not on board, they can be ordered. EMERGENCY  RESPONSES The last major area we are going to look at is emergency response. When a problem occurs, such as a job aborts or the system goes down, the steps you and your AIS staff must follow are: 1. 2. 3. Log   the   problem.  A  good  rule  is  to  log everything; this can save time and help to identify  problems  early. Notify   management,   users,   and   the maintenance   technician.   By  notifying management,  you  provide  them  the  information they  need  to  answer  questions  and  make decisions concerning the system. If the users are kept informed, they won’t be as apt to keep calling  the  operators  when  the  operators  are busy trying to get the system back up and running.   In   notifying   the   maintenance technicians, whether hardware or software, you need to tell them what you were doing, exactly what happened, and what you have tried to do to fix the problem. Adjust  staffing  when  possible.  Adjusting staffing works in two ways. If the system is going to be down for an extended period of time, it is a waste to keep all the operators there with nothing to do. Likewise, there are times when additional expertise will have to be brought in to help get the system up and running. Either way, this will be your decision as the AIS facility manager. You will have to analyze the situation and  decide  what  skills  are  needed  to  solve  a problem, who has the skills, who is available, how many personnel are needed, and so on. EMERGENCY URGENT CHANGE REQUESTS Occasionally, the best-laid plans will have to be changed. One of these times is when an emergency urgent   change   request   (priority   job)   comes   in. Normally, there is a good reason for each emergency urgent change request. These change requests cover both application and system programs. For application programs, some reasons for urgent change requests are a special report needed for a meeting, last-minute corrections before starting a monthly or yearly job, and a deadline that is moved to 1-27