BOX - beginning of expedition
EOX - end of expedition

About BOX

The incoming developer(s) is(are) always 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 repository of shipboard developer resources see Developer space on shipboard Confluence:  http://confluence.ship.iodp.tamu.edu:8090/display/RAADND/Random+Access%3A+Application+Developer+Notes+and+Documentation+Home

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. Clean & preen the database. Includes summary data cache in OVERVIEW application.
8. Check that database triggers are enabled.
9. Programs to run.
   1. Remind the Publications specialist to start the Virtual Photo Table compositer.
   2. Start the IRIS-Collector.exe on the Ops office engineering station.
10. Pull the current list of core catcher types LIST_ENTRY where LIST='CC_TYPE'. Chat with the Core Techs.
11. Check with the DESC tech to see if DESC value list entries need to be made available to the SEM uploader.
12. Replace GEODCAT with the latest definitions from shore (RTLIMS.GEODCAT, or Blum source spreadsheet).

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 access your Confluence accounts?

2. Relieve your counterpart

Read the tech report. Exchange information. What's changed?

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 it 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: \\CLEVELAND\VOL3\AD\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 SQLDeveloper to make these database changes for the newly started 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 SQLDeveloper 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 SQLDeveloper browse LIMS.LIST_ENTRY where LIST='PROJECT'.
Edit the existing record to reflect the current expedition or add a new record.

Auther privileges

Per the LIME team.

• 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..

Are there any new personnel who require updates to application access privileges?

Curators manage Auther roles and privileges. Give a hand as-needed to new Curators.

Change 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.

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.

Catwalk

• If a new ALO or Curator is participating, ensure they have the CURATOR role. This is to provide 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. Update user 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 staff scientist for on-going project communications. The MCS will have a list of the accounts the created and since we use the same names get their list when they are done.

Delete the accounts for those who are leaving the ship. Use - participants_remove.sql.

7. Clean the database

Previous Expedition. Maybe play core data (999)--ask first.

CONFIRM WITH THE OUTGOING DEVELOPER THAT WE HAVE A GOOD COPY OF THE PREVIOUS EXPEDITION EXPORT.
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 & content: remove items no longer carried on ship.

Prior expedition content is to be removed to enforce moratorium. Use this reference until you are comfortable with the process.

8. Check that database triggers are enabled

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

9. 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 Ops Engineer station. This should be the ONLY location that runs it.

10. 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.

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

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]).

12. Replace GEODCAT with the