If you've encountered a problem in assigning an SI mode or dropping a chip, this page lists some common types of problems and recommended actions, starting with the most basic and building from there.

Basic Checks

• Did you start from a clean terminal window? There can be environment interaction problems between SACGS and other packages.
• Are you logged in as yourself (not acisdude) and does your setup procedure source "sg_env_source"?
• Check that you didn't skip any steps in the normal procedure. The "make setup/clean/start" at the beginning ensures that you're not looking at old setup data.
• Check for typos in the initial "ocatByObsid" call, particularly in the ObsID and in the order of "-drop obsid drop#"
• Could you have mistyped your password? Look back at the messages printed to screen. A bad login will look something like this:
  

  Server message:
  10/28/2020 11:55:09.983006 Message number: 4002 Severity: 14 State: 1 Line: 0 Server lsqlocc
  Message String: Login failed.
  
  Open Client Message:
  10/28/2020 11:55:09.984452 Message number: LAYER = 4 ORIGIN = 1 SEVERITY = 4 NUMBER = 44
  Message String:
  ct_connect(): protocol specific layer: external error: The attempt to connect to the server failed.
  ERROR: Couldn't connect to sybase server
  Failed to connect to server ocatsqlsrv
  ocatByObsid: Unable to find an obscat record for obsid 23823
  

After you've checked for the above, try again from a clean terminal window in a clean directory. If the problem was a simple one or a transient issue with connecting to the OCAT, you may be successful.

Configuration Issues

• Are you allowed to update the SI mode for this ObsID?
  • Check whether the "Status" of the ObsID is "unobserved" or "untriggered". If the status is anything else ("scheduled", "observed", "archived"), ACIS ops cannot change the SI mode. (More on fast TOO replans below.) You can find the status by looking at the OCAT entry on the web, or by looking at the output <root> file from "ocatByObsid".
  • Check that the instrument is "ACIS" and not "HRC". ACIS ops does not have permission to change the SI mode for non-ACIS observations.
  • TBD: Locks go here. Need example output, then point to the "unlock" instructions. Unlocking instructions (which also need editing) Short form step 6.1, running apr2smt.pl creates the smt file and locks the OCAT entry for these ObsIDs so that no one but you can change them. Step 6.2 updates the SI modes in the OCAT and then unlocks the ObsIDs. If this process is somehow interrupted, the ObsIDs can stay locked.

Issues with fast TOO replans

Fast TOOs which interrupt an already running command load present a special case. You may be asked to review a preliminary schedule which consists almost entirely of ObsIDs in the already running schedule. These ObsIDs have a status of "scheduled" and their OCAT entries cannot be changed by ACIS Ops.

If you are asked to drop chips in a TOO interrupt schedule, first check the review of the preliminary schedule of the load that will be interrupted. In most cases, the TOO interrupt schedule will be nearly identical to the running load, with the same chip drops. In that case, you do not need to redrop the chips (in fact, you cannot). After the load is approved and arcops unschedules the ObsIDs from the running schedule, the SI modes for the chip drops will be blanked out. At that point you will need to redrop the chips.

An example of this is the OCT1920 schedule which was interrupted by OCT2120. Both preliminary schedules request one dropped chip from ObsID 24474. At the time of the OCT2120 preliminary schedule review, ObsID 24474 had a status of "scheduled" and the OCAT lists the correct SI mode and drop count for one dropped chip. No action is needed by ACIS Ops since the chip is already dropped and attempting to drop the chip again would fail due to the status of "scheduled".

If you are asked to drop chips in a TOO interrupt schedule and the chip drop list is not identical to the load that will be interrupted, there are four scenarios:

• An ObsID with chip drops in the original schedule does not appear in the chip drop list for the interrupt schedule because it has already been observed before the interrupt schedule begins. No ACIS ops action required.

• An ObsID with chip drops in the original schedule does not appear in the chip drop list for the interrupt schedule because it has been removed from the schedule. After the ObsID has been unscheduled, ACIS ops will need to re-assign the SI mode with 0 dropped chips.

• An ObsID was added to the interrupt schedule that was not in the original interrupted schedule. ACIS ops should drop the requested chip as usual.

• An ObsID is in both the original and the interrupt schedule but with a different chip drop number. (I do not believe this has happened in real-life, but am including for completeness.) In this case, ACIS cannot change the dropped chip count or the SI mode at the preliminary review stage. You should contact SOT MP immediately to make sure they are aware. SOT MP can edit their OR list to have the requested chip drop SI mode (they already do this regularly), which will be propagated to FOT MP and the command load. ACIS reviews of the OR list and the load will show that the SI mode in the OCAT and in the load do not agree, so special care will need to be taken to confirm the commanding is correct. After the load is approved and the ObsID is unscheduled, ACIS ops can assign the correct chip drop SI mode in the OCAT.