BOX - beginning of expedition
EOX - end of expedition

About BOX

The incoming programmer(s) is(are) responsible for all BOX activities. And for some of the EOX activities. 

Ship-based activities are described. In many cases pre-expedition preparation is required.

For a repository of shipboard programmer resources see the Developer space on shipboard Confluence.  

Checklist / Overview

1. Make sure you are connected in your new home.

2. Relieve your counterpart. Take charge.

3. Courier duties: transfer and deliver any IT content in your possession.

4. Apply database and web-service updates.

5. Reset database defaults for expedition and projects.

6. Create user accounts, manage application roles & privileges.

7. Review what database accounts will be expiring soon. Let those folks know--set expectations.

8. Clean & preen the database. Includes summary data cache in OVERVIEW application.

9. Check that database triggers are enabled.

10. Programs to run.

    1. Remind the Publications specialist to start the Virtual Photo Table compositer.

    2. Start the iRIS Collector utility on the physical host in the MCS office. Or otherwise confirm it is running.

    3. Enquire with the Ops Manager and the Drillers that their iRIS interfaces are up and running.

11. Pull the current list of core catcher types LIST_ENTRY where LIST='CC_TYPE'. Chat with the Core Techs. - Do we still need this. Can we retire this?

12. Check with the DESC tech to see if DESC value list entries need to be made available to the SEM uploader. - Do we still need this. Can we retire this?

13. Replace GEODCAT with the latest definitions from shore (LIMSHQ.GEODCAT--under normal circumstances this is the primary catalog).

14. Honor moratorium. Assist other technical staff with this expedition preparation.

15. Expedition readiness. Assist other technical staff with expedition readiness concerns.

Reset your credentials for your DBA account on SHIPTEST. See if your credentials will expire before you return. The conventional name is now yourname_dba--as a reminder that you are wearing that hat.

1. Make sure you are connected

Your duties require information technology connectivity. A lot of change happens in our environment between expeditions. Verify your tools and access:

• Laptop connectivity to the network? Internet?

• Email account on ship active?

• Able to access file systems? Printers?

• Can you get to the password safe? The database?

• Can you get to your account on the BUILD box and DEV workstation? The dev account (for as long as we continue to do that).

• Can you get to Nexus and Subversion?

• Is the Subversion sync process still running? - BUILD (c:/srv/rsync/rsyncd.log)

• Are your software distribution credentials still functional? Development, Test, Production?

• Are your database access credentials still functional? Development, Test, Production? Can you reach shore too (in case required)?

• Can you access your Confluence accounts?

2. Relieve your counterpart

Read the tech report. Exchange information. What's changed? What's broke? Is there anything outstanding that should be taken care of for laboratory readiness or shipboard operations for the new expedition? Swap war stories.

3. Courier duties

Deliver all transported media and equipment to their responsible parties. Stage any software-related components and tools in the appropriate locations. Make sure our own content survived the trip by connecting the media.

Examples

• If shore sends out desktop/server software distributions with you, ensure the media is turned over to the MCS.

• If you have Moisture and Density container information, make sure it is staged in a location you can find when you are ready to process those containers.

• If the science party requested legacy data to be available for the on-coming expedition, you should have that data and a plan for making it available.

• If you have software updates for development or laboratory support, stage them under here: \\NOVARUPTA\VOL3\DML\

4. Apply database and web-service updates

Perform any database upgrades to implement changes from shore. Do this on the test system FIRST. This will confirm the scripts are good before you work on the ship databases.

Perform any web service updates to implement changes from shore. Do this on the test system FIRST. Run applications which use these services to confirm nothing is broken before upgrading the ship web services.

Upgrade any applications for changes from shore. Typically this should be done by the developer on the ship as these changes are created, but sometimes the incoming developer brings new things with them. Follow build, deployment, distribution procedures that exist--create documentation for those procedures if they don't exist--follow existing patterns.

Thoroughly test all upgrades and changes.

5. Reset database defaults for expedition and projects

Use SQL Developer to make these database changes for the newly started expedition. As soon as possible. Technical staff are running instrument and lab readiness procedures on the first day on-board. Laboratory standards (calibrations, checks, controls, blanks, etc.) do not follow a geophysical hierarchy so depend on some of these settings to be associated with the current expedition.

1. Set the default expedition for LIMS.

   update lims.lims_constants set constant_value='&currentExp' where name='EXPEDITION';

    

2. If legacy data has been loaded run the appropriate compute procedure to generate display content for the OVERVIEW report.
   
   In SQL Developer browse LIMS.LIST_ENTRY where LIST='MENU'. Edit the record with NAME set to the previous expedition. Change the expedition name in the NAME column from the previous expedition to the current expedition. Change all the instances in the VALUE column from the previous expedition to the current expedition.
   
   
   

3. Add a new project list entry for PROJECT.
   
   

   In SQL Developer browse LIMS.LIST_ENTRY where LIST='PROJECT'. Edit the existing record to reflect the current expedition or add a new record.

    

4. Auther privileges - requested by the LIME team, particularly

   • All scientist accounts are removed (just like with Oracle).

   • New scientist accounts are added.

   • No changes will be made to "tech" accounts.

   • New scientist accounts will have only the generic Scientist Role assigned.
     Any special roles needed are handled by Curator.
     
     
     

5. Are there any new personnel?

   • Do they have the necessary lab application access privileges?
     Curators manage Auther roles and privileges. Give a hand as-needed to new Curators.

   • Check-in with the individual(s), MCS, ALOs to ensure email, storage, Confluence resources have been allocated and are accessible.
     If there's an on-boarding check list, we should follow it.

   • Ensure appropriate GEODESC operator privileges are applied.
     
     
     

6. Changes in application authorization

   • SampleMaster

     • If a new ALO or Curator is participating, ensure they have the SampleMaster curatorial role.

     • If a new Driller is participating, ensure they have the SampleMaster driller role.

   • GEODESC

     • Participant roles for GEODESC users are managed by the GEODESC Admin.

     • If a new GEODESC Admin is participating, ensure they are setup with the necessary permissions and training.

   • Desclogik - This application is "not quite dead yet". The infrastructure will be maintained until the Thin Section Report Writer is brought current and confirmed to not need to be fed by any Desclogik worksheet constructions.

     • Participant roles for Desclogik users are managed by the Desclogik Admin.

     • If a new Desclogik Admin is participating, ensure they are setup with the necessary permissions and training.

   • Catwalk

     • If a new ALO or Curator is participating, ensure they have the CURATOR role. This ensures access to the Template Manager and Settings.

   • Other accounts - Crossover with off-going developers to verify if any significant access changes were made. See the development password safe for credentials . If you make any credential change relevant to development work, please update the safe to reflect the change.

6. Manage laboratory application accounts

See Subversion for the last created versions of the script: https://build.ship.iodp.tamu.edu/svn/wapps/Database/DbScript/participants

Best source of user names: the expedition science party email list maintained by the EPM (expedition project manager) for on-going project communications. Obtain the list from the MCS as they routinely receive it before we do. The expedition participant list may also be retrieved from the Crew N Cruise application. Permission and authorization required.

• Create accounts for new participants - participants_add.sql

• Delete the accounts for those who are leaving or have left the ship.

• Adapt the script in Subversion to our current needs - participants_remove.sql.

7. Review Oracle accounts for expiring users

Review Oracle for accounts that are locked or pending expiration.

Send notifications to those whose accounts expire soon. Assist those whose accounts are locked.

8. Clean the database

Remove previous expedition content. Maybe remove 999 (play core content). Ask Technical Staff and ALOs first.

CONFIRM WITH THE OUTGOING DEVELOPER THAT WE HAVE A GOOD COPY OF THE PREVIOUS EXPEDITION EXPORT. Review the EOX export (and spot-check import) logs.
CONFIRM THAT THE MCS HAVE A GOOD COPY OF THE EXPEDITION EXPORT, ASMAN FILES (OLYMPUS), DATA1 content, and CONFLUENCE spaces on TAPE.

DO NOT PROCEED UNTIL CONFIRMATION RECEIVED.

OVERVIEW. Review menus and content: remove items no longer carried on ship.
GEODESC. Remove prior project schema and associated authorizations, roles, permissions.
LIMS. Remove the one (or more) expedition(s) content not pertinent to current expedition work.
OPS. Remove IRIS related data from the previous expedition--on the order of 125 GiB for 65 days; ~5 million records.

Prior expedition content is to be removed to enforce moratorium. Use this detailed reference to go through the process.

9. Check that database triggers are enabled

This step is dependent on the completion of (7). Via SQL Developer, log into the LIMS account. Ensure that no triggers, functions, procedures, views are flagged by a red 'X' (indicates invalid or disabled content).

A pattern to enable all triggers for a table. Must have appropriate privilege for the target tables.

This pattern is applicable to SAMPLE, TEST, RESULT, GEOD_DATA, etc.

If invalid triggers exist, track down why. Look for the Oracle-specific errors via SQL Developer. Give another DBA a holler.

10. Programs to Run

Start the Virtual Photo Generator

If not already present, help set it up on the Publications Specialist host. This should be the ONLY location that runs it.

Start the iRIS Collector

If not already present, help set it up on the dedicated iRIS Collector physical host. The physical host resides in the MCS office at the far back corner of the desk.

• This should be the ONLY location that runs it.

• Set the credential store for information on host access--device "iRIS Collector".

Check-in with the Ops Manager and Drillers to ensure they are able to access their respective user interfaces.

11. Core Catcher Types

Chat with the Core Technicians--are there any changes to the list of Core Catcher Types LIST_ENTRY where LIST='CC_TYPE'?
The goal is to keep the list short. Most often used items should be pushed to the top by use of the ORDER_NUMBER field.
Keep core entry simple. Drill-floor safety and core recovery take precedent over this small thing.

12. Check with the GEODESC tech to see if DESC value list entries need to be made available to the SEM uploader.

DESCLOGIK TOOLS ARE OBSOLETE. REVIEW FOR CHANGES.

The product LIVE has integrations for presenting some descriptive information. However, that entails an update to service code so that the correct templates and columns are read. This is presently an Ad Hoc process, not something the GEODESC specialist or participants can configure.

This step involves updating the DESCINFO2.X_SIEM_HERARCHY table.  If this is needed:

1. In SQL Developer, look at the table, sorted by HIER_KEY.  At the bottom, you might find one or more expedition-specific entries (they'll have an expedition number in their names).  Delete these.

2. This documentation describes the process of adding new values for your expedition:  SEM uploader X_SEM_HIERARCHY table.

3. If the above documentation is confusing, here are some notes:

   1. The data in this table represents a hierarchy, and the PARENT value for each record links back to the HIER_KEY of that item's parent.   

   2. For example, "igneous rock names", "sediment names" and "metamorphic rock names" (HIER_KEY = 80, 90, 100) all link back to "LITHOLOGY" (HIER_KEY = 10).  On expedition 396, we added three entries, with each one linking back to one of the three lithology items just mentioned, so their PARENT values were 80, 90, 100.

   3. If you've done this properly, you should be able to run the SEM uploader and (after selecting an image, which can be anything), see the name(s) you added when you pick the parents (e.g. Category = LITHOLOGY → General subcategory = igneous rock names → Exp. specific subcategory = [your entry or entries]).

13. Replace GEODESC catalog and projects with the latest definitions from shore

GEODCAT

Export a copy from LIMSHQ before the expedition. Bring it along (order of megabytes).

GEODP###

If prior work was done on shore, bring a copy out.

If no prior work exists for the GEODESC project, create a new one per the scripts at Create New GEODESC Project (GEODPnnn) Schema – Ship

• Be sure to catalog the new schema password in the shipboard safe.

• Spotcheck newly created or imported schemas to confirm operability and access to existing data: Do templates load? Can new samples be added to DataCapture working sets?

2/13/2024: Removed constraints  from the end of the drop user geodcat  command. Was causing the script to fail. Left it on for the project schema because I did not have to run that command. - df Incorporated above for project too.

14. Honor moratorium.

Assist other technical staff with expedition preparation.

Typically this involves ensuring prior expedition content is removed from lab workstation and instrument host local hard drives.

15. Expedition readiness

Assist other technical staff with expedition readiness concerns.

If something worked the previous expedition, it is expected to work for you. Port call is the time to re-check / re-test. Do what you can early. Being on-site and scrambling isn't worth it when it can be readily and simply avoided.