Daily Releasing of the LRP

The PCs need to have a current LRP to determine if their visits are in need of prepping, are schedulable, as well as to determine if the visits already prepped still have valid plan windows. Every morning, the LRPG determines if the previous night's batch-LRP was successful and examines any differences between the last released LRP and the current LRP.

Typically, releasing is done first thing in the morning. The earlier the start, the better, since if there are any problems, they will delay releasing. All commands for all steps currently are executed on the VMS side of the fence. As of 1997-03-12, use non-Alpha machines for this process.

• Was the nightly LRP run successful? And if so, what SUs still have problems? Generate a diff report on the nightly LRP run.

  1. From an LRP window:

     $ do latest_lrps

     check that an "AUTO" LRP was created for the most recently run nightly batch-LRP process. The most recently created "AUTO" LRP will be indirectly used in the next step along with the 'last released LRP'.

     If the timestamp for the most AUTO LRP is not in accord with the other AUTO LRPs (i.e., is significantly later), this is a possible indication that there might have been a problem during the nightly LRP and may not have been properly created, although, it is not assured. You may look into why it took longer, although it is not essential to releasing.

     If LRP was not created successfully, then ----> notify lrpg. If you need to try debugging it yourself, go to LRP-crash diagnostic document.

     One way to see if there were any problems is to go to /data/aphotic1/lrp/ and look at the "batch_log."xxx file for the previous night. To look for problems, egrep -i fatal or egrep -i dbdead. If this happened then there was probably failure by the batch to successfully load proposals (one possibility).

     From a unix window:

     unixprompt> nightprob

     This runs a script from ~lrp/bin/ which 'egrep's through the current /data/aphotic1/lrp/batch_log file searching for instances of "DBDEAD" or "FATAL" which would indicate the batch jobs did not finish correctly from the overnight run.

     If LRP was created, then proceed:

     $ do submit_nightly_work <latest released LRP> <working lrp name>

     Creates log file & difference report. The <latest released LRP> was noted in an above step, and <working lrp name> is by convention taken from the name of the most recently generated 'AUTO' LRP noted above. For example, if the most recent AUTO LRP was called 97070AUTO, then, you should specify the 'working LRP name' to be 97070-, where the '-' is by convention labeled 'A'. Daily working LRP names are alphabetically sequenced (A, B, C, ... under normal circumstances, often only A will get created and later released). By specifying 97070A, the submit_nightly_work command file goes and looks for the "AUTO" version and diffs using <latest released LRP>.

     When complete, get the dif report output to the laser printer and go over it looking for problems. (This may take a while-- carefully check each SU.) Ecopies of the output may be found in SPSS_DATA_DK3:[LRP.WEEKLY] on the VMS side. For each run, two files are generally created. For example, a run differencing the 97070A released LRP and 97071A 'new' LRP would produce 2 new files here:

     					97070A_97071A.DIFFERENCE;1 
     					NIGHTLY_WORK.LOG;237
     

     Tip: if any problems occurred, it is advisable to check the nightly_log file:

     $ nightly {LRP logical places you in the [lrp.nightly] directory}

     $ type nightly_work.log;

     The batch job isn't submitted if there are no visits to be submitted for replanning. By doing a

     dir/sin=tod SPSS_DATA_DK3:[LRP.REPLAN_SUS]

     you will be able to see if there were no SUs actually submitted for replanning. If there was a log file, then there was a problem and the log file should be examined.

     ---

  2. Check the differences between the LRPs.
     • Pay particular attention to the SUs which are set to scheduling.

     • Proposals dropped between LRPs:

     • SUs dropped between LRPs:

     • SUs that lost PWs:

     • SUs picked up between LRPs that don't have PWs:

     • SUs that gained PWs:

     • Differences between statuses:

     • SUS with changed flight ready dates:

     • Differences between PWs:

     To resolve questions about these individual reports, refer to the Analysis and Resolution documentation in the weekly baselining procedures

     ---

  3. Once all issues with SUs from the diff report have been resolved, release the LRP. From a PLANNING window (currently only on an old VAX):

     $ @[lrp.tools]release_lrp.com <working lrp name>

     where <working lrp name> is the same as used in previous steps.

     Warning! There can be problems as to which LRP is 'accepted' as the most currently released if LRPs are created within 6 hours of each other. When submit_nightly_work is run, it creates a new LRP from the contents of the 'AUTO' LRP generated from the nightly batch runs. This newly generated 'A' LRP is given a UT time stamp of when submit_nightly_work was run. If you then create a new LRP later that day, say for baselining by writing out the plan using SPIKE, it will have only a EST or EDT time stamp. If these are created within 4 or 5 hours of each other, there will be a misordering by time and the newly created SPIKE LRP will not be picked up as the currently released LRP.