FPSBASE.GEN_SITE

ONE_ROW

NUMBER(1)

A column whose value is 1 which is the primary key of the table ensuring only one row.

ALLOW_RTG_PRDS_IN_OTHTAB

CHAR(1)

We have checks on the configuration of the RTG_PRDS table load as this is critical for RTG_ACTIVE_PRD_ROUTES. However at some older sites RTG_PRDS is loaded as part of another table so this flag causes us to ignore those checks which we will not do for new sites.

ARE_SYS_PRIVS_TEMPORARY

CHAR(1)

Setting this to Y indicates that the system privileges granted to FPSADMIN are temporary and will be revoked after an upgrade is complete. This tells BLD_PRIVS_AND_SYNONYMS to grant the proper standard privileges to FPSADMIN as if the system privileges did not exist. These privileges are unnecessary at the time but they will be in place when system privileges are revoked.

BLOCK_E_FOR_ECT

CHAR(1)

This flag determines the ect_state when the best tool is rank E for Emergency. If this is the default value of N then we set to WAIT1 or WAIT2 or WAIT3 based on the number of Emergency tools. If this is Y then we set to BLOCK-E.

CLIENT_NAME

VARCHAR2(5)

N

Short company name of the client. See site_name comment for client/site/facility example.

CLIENT_NAME_DISPLAY

VARCHAR2(24)

N

Longer display friendly client name.

CONSIDER_BEGIN_M_AS_DISPATCH

CHAR(1)

When set to Y, the WIP_EVENT_HIST_INSERT_BEF trigger will change EVENT_TYPE=BEGIN_M events to DISPATCH when the TOOL is expected to log a subsequent automated BEGIN event (based on EQP_TOOLS_PLUS.LOGS_AUTO_BEGIN). When set to N, the trigger will always leave BEGIN_M events as BEGIN_M events.

COUNT_JUMP_AS_ISKIP

CHAR(1)

Most sites want to count jumps recorded in WIP_JUMP_HIST with the move_type of ISKIP. But some sites specifically record their skips in WIP_EVENT_HIST and do not want to count jumps. This causes us to ignore jumps for these sites that set it to N.

CTM_FIN_PERIOD_MONTH_OR_WEEK

VARCHAR2(5)

Most sites uses our standard progression of recent months then quarters then years as the periods in Finished Lot Cycle Time but some sites prefer to use weeks. Therefore the default value here is MONTH but sites using weeks will set to WEEK.

DAYS_FOR_RTG_PRCS_RCP_TOOL

NUMBER(3)

Number of days of WIP_STEP_HIST to use in RTG_PROCESS_RCP_TOOL_7D table which is the base for RTG_PROCESS_RCP_EQPTYPES and EQP_TOOL_PROCESSFAMS. As anyone can guess from the table name, the default is 7 days.

DEFAULT_BUILDING

VARCHAR2(12)

N

For sites with multiple building, some of our MHS logic uses this as a default building if the building is unknown. Also create/update scripts might use this.

DEFAULT_FACILITY

VARCHAR2(6)

N

For sites with multiple facilities, applications will default to this facility upon opening. Also create/update scripts might use this.

DEFAULT_SYSMNTR_EMAIL_LIST

VARCHAR2(1000)

N

For SYSMNTR_P_CHK views which do not have specific configuration records in SYSMNTR_C_CHECKS we will send emails to this list. Typically it is fps-xxxdwhteam@inficon.com where xxx is the client or site name and obviously this must be a valid email address.

DEF_CAST_TRANSIT_SEC_DIFF_BLDG

NUMBER(5)

Default transit time for a cassette to move between different buildings.

DEF_POD_TRANSIT_SEC_DIFF_BLDG

NUMBER(5)

Default transit time for a pod to move between different buildings.

ENABLE_GTG_AND_FTR_UPDATES

CHAR(1)

The merge statement to update GTG and FTR information which is the entirety of the UPDATE_ETP_MNT_EPISODE_HIST procedure was found to be very fast at some sites and extraordinarily slow at other sites. This parameter allows us to disable this at the slow sites.

ETL_LINK_OR_APF_OR_MIXED

VARCHAR2(5)

This is the mode of ETL used for the site. LINK means all tables are populated via APD/REF views using a database link. APF means all tables are populated via APF using Load_FPS_DWH.sh. MIXED means that we use some of each.

FEEDBACK_FROM_EMAIL

VARCHAR2(128)

N

The email address to use as the From email when we send emails with the ADM_SEND_EMAIL procedure. We send emails via our Feedback application which is configured to do so for whatever restrictions we have at the site. This should probably be something like no-reply-dwh@client.com.

FEEDBACK_HOST_URL

VARCHAR2(500)

N

This is the host of the server where our Feedback application is configured. It should be something like http://fpsdev.client.com. We add /feedback/api/email to this host and use this URL to send emails via our Feedback application.

FLCT_REPEAT_DAYS

NUMBER(4)

There are two reasons why a lot would record a second finish event for the same lot/facility/prd. The first reason is that the lot id is reused which happens often for test wafers lots. To account for this, our default behavior is to only look for activity since the last finish event for this lot. But the second reason is that the lot was unshipped or unscrapped or the initial finish event was deleted in the MES or otherwise somehow reversed. In this case, we do not want to look for all activity since the start associated with the last finish event rather that since the last finish event. This parameter tells us to assume the second reason if the second finish event was within this many days of the first event. When the second reason occurs, the second event is usually just a few minutes after the first one but it can occasionally be longer. If your MES never reuses lot ids even for test wafer lots then you can set this to a big number without any concern.

GOAL_WIP_PCT_TO_TGT_BAY_PERF

NUMBER(2)

The plus / minus percentage of target WIP that is considered acceptable in the Bay Performance NMV pages. EG 20% gives acceptable WIP range of 80 to 120 on a target of 100.

HIST_CATCHUP_MINS_AFTER_DD

NUMBER(5)

The number of minutes of data we load during each run of WIP_EVENT_HIST. This is constrained to be at least 30 minutes. This value becomes important after the load gets behind, either due to a planned stop or due to a failure. Loading all of the missing data at once can overwhelm the database so we catchup this many minutes at a time.

HIST_OVERLAP_MINS_BEFORE_DD

NUMBER(3)

In a perfect world, we could just load all events newer than data_date into WIP_EVENT_HIST. But the world is not perfect. Instead events are loaded into the MES in an order which does not perfectly match the order in which they were logged. In other words, an event logged at 01:23:46 is inserted in the MES before another event logged at 01:23:45. In order to not miss any events, we have to go back at least a few seconds prior to data_date and then check if those events have already been inserted and insert only if not. This variable determines how far back we have to look. Usually it should be a minute or too but there is little cost in going back 5 or 10 minutes just to make sure. For debugging, we might set temporarily to a larger number but for normal running it should be no longer than an hour.

HIST_WEEKS_FOR_CTM_FIN_PERIOD

NUMBER(3)

If you choose to define finished period by weeks then this is the number of weeks to load into the CTR tables and show on the FLCT application. We store all data in the CTM_FINISHED_LOT_HIST table and purge that table based on the normal purge logic in CFG_TABLES so this is only for the CTR/FLCT.

IGNORE_BLANK_CHK

CHAR(1)

Certain sites have a known ETL condition that can lead to key columns temporarily populating blank! values in WIP_EVENT_HIST. Setting this to Y tells SYSMNTR_ERRORS to ignore its standard check for blank! values at this site.

IGNORE_WLRT_UPDATED_TIMESTAMP

CHAR(1)

This flag determines if WIP_LOTS_REALTIME_UPDATE_BEF should check if the Updated_timestamp is different or not. Most cases do want to check that the updated_timestamp is new, but at some sites where they ETL runs really fast and the database lacks high timestamp precision (3 vs. 6 places) it may be beneficial to suppress preventing updates to wip_lot_realtime for having the same update_timestamp.

INCLUDE_EST_TRANSIT_IN_XFACTOR

CHAR(1)

We automatically calculate the estimated transit time for each route-step in the RTG_EST_TRANSIT view and we write this to CTM_SUMMARY in the est_transit_sec column but this flag tells us whether to include this in the processing time denominator of the X-Factor calculation in DCTA, FLCT, and PERF.

INITIALIZE_INST

DATE

This is the time when this DWH started logging events. When we insert entities into the DWH we set their state to SBY-DEF starting at this time. When lot events are logged we will set the step_ent_inst to this inst. While this is a helpful reference over the entire life of the DWH it is only used for the startup event logging. We like this to be the start of a work week so we can get summary information for entire weeks.

IS_DISP_RQD_TO_INSERT_WWH_WEH

CHAR(1)

When the first wafer begin event is logged in WIP_WAFER_HIST for a lot, we consider whether to copy this event as a lot BEGIN event in WIP_EVENT_HIST. If this flag is set to Y then we require the proc state to be DISP (meaning that the lot has been tracked in) in order to copy. Copying the event to WEH will set the proc_state of the lot to PROC and the etp_state of the tool to PRD.

IS_ETL_ON

CHAR(1)

This flag allows us to turn off ETL temporarily for either APF or DBLINK sites. Unlike most columns in GEN_SITE, this column should only be set by a procedure and not set manually.

IS_ETL_UNDER_DEVELOPMENT

CHAR(1)

Set to Y if the ETL is still under development to hide errors including no rows and disabled constraints that are acceptable.

IS_MSO_CONFIG_COPY_ENABLED

CHAR(1)

For sites using MSO, this flag allows the site to enable or disable the MSO rule configuration copy to this database. Usually this would be on to keep primary and secondary databases in sync, but in cases where and upgrade or planned failover is scheduled this can disable the auto copy job from executing.

IS_MSO_ON

CHAR(1)

Set to Y if the Metrology Sampling Optimizer application is being used. This will enable the triggers in WIP_EVENT_HIST_INSERT_BEF and EQP_EVENT_HIST_INSERT_BEF.

IS_NMV_ON

CHAR(1)

Set to Y if the NextMove application is being used in production. This will enable SysMonitor alerts for NextMove checks

IS_PRIMARY_MSO_DWH

CHAR(1)

Set to Y if the MSO the DWH is the primary MSO database that should be writing decisions to the cleint MES.

IS_TOOL_RQD_FOR_COMP

CHAR(1)

Set to Y if we only want COMP events to have move types of COMP when an entity is logged with the event. If N then all COMP events will count as completes.

MAX_DAYS_FOR_MNT_INSTANCE

NUMBER(3)

The maximum days in the future that we will show subsequent instances of maintenance events. Note that the next instance is not affected by this maximum. See comment on mnt_instances_per_event column for example.

MAX_MSO_DECISION_STEPS

NUMBER(4)

The maximum number of steps away between a MSO main process step and metrology step can be so that the MSO can make a skip/tag decision. If this value is null then the limit is not applied otherwise the steps must be within range when evaluating a process link for an MSO rule.

MAX_NUM_TO_FIX_EQP

NUMBER(5)

Maximum number of entities allowed to be fixed automatically by ADM_FIX_EQP_STATUS. Typically if this procedure wants to fix a large number of entities this indicates a significant problem with the load which should be addressed.

MAX_NUM_TO_FIX_WIP

NUMBER(5)

Maximum number of lots allowed to be fixed automatically by ADM_FIX_WIP_EVENTS_CURR_STEP. Typically if this procedure wants to fix a large number of lots this indicates a significant problem with the load which should be addressed.

MAX_SEC_ADM_FIX_WSF

NUMBER(3)

This is the time limit for the ADM_FIX_WIP_STEP_FUTURE procedure. To avoid locking, updates to WIP_STEP_FUTURE must be made serially with inserts to WIP_EVENT_HIST therefore this procedure must be in the RealTime job. Most of the time it does nothing but after a particularly big change we might have a bunch of lots to fix. When this happens, we fix as many lots as possible in the time limit and then save the rest for the next job in order to not make the RealTime data get too far behind. The default setting is 60 seconds and if you repeatedly go over this limit then we recommend scheduling CHK_WSF_LOTS_TO_FIX more frequently.

MINS_NO_WEH_TO_LOAD_HIST

NUMBER(2)

Normally we insert history data for the last shift/day when data_date is after the end of the last shift/day. But at sites with low activity which do not log events frequently we might want to insert the history data soon after the end even with no new events. This field is the number of minutes after the end to wait before we go ahead and write the history even if no new event has been logged.

MINS_WAIT_TO_LOAD_HIST

NUMBER(2)

This is the number of minutes into the shift/day to wait before loading data from the previous shift/day into the WIP_END_SHIFT_HIST/WIP_PLAN_DAY_HIST table. This delay is to prevent loading incomplete data for the last shift/day in case WEH events are inserted out of order. For example, if we have at event at 07:01:20 but we configure to 2 minutes then we will not insert into WESH. Instead we will wait until we have an insert after 07:02:00.

MNT_INSTANCES_PER_EVENT

NUMBER(2)

The number of future instances we will show for each maintenance event. This column works together with max_days_for_mnt_instance. For example, if this is 7 and max_days is 31 then we will show daily PMs for the next week (limited by 7 instances) and weekly PMs for the next month (4 or 5 instances limited by 31 days) and only the next instance of an annual PM.

MSO_COPY_SOURCE_DB_LINK

VARCHAR2(128)

Database link to use to copy MSO data from. This is used to keep the MSO rule configurations in sync.

MSO_MES_OPERATOR

VARCHAR2(64)

The operator that the MES uses when MSO sends interdictions to tools. Required for the view SYSMNTR_P_MSO_NOTIFICATION.

NUM_DAYS_FOR_CV_OF_AV

NUMBER(3)

This is the number of days of history to use when calculating the coefficient of variation of availability by tool.

NUM_EVENTS_KEEP_DASH_TOOL_HIST

NUMBER(4)

For speed reasons, we get the recent tools for the Dashboard tool page from the table EQP_LAST_EV_OLDER_1HR which is build specifically for this purpose. This table keeps the last x events for each tool regardless of time and x is controlled by this parameter. The default is 100 but at sites with a small and fast DWH this could be set higher.

ONLY_SKIP_EVENTS_COUNT_AS_SKIP

CHAR(1)

At most sites, we want to count any moves that move a lot forward to a future step as either ISKIP or DSKIP if it is not a COMP. But if this is set to Y then we only count moves with an event_type of SKIP as SKIP. Any other moves will count as ROUTE which we ignore we calculate moves as COMP + ISKIP + DSKIP - REPEAT.

PERF_DAYS_AVG_WIP_BY_ECT_STATE

NUMBER(4)

This column specifies the number of days to load the average WIP by ECT state for the Performance charts. Since the DASH_P_ECT_WIP_SHIFT_HIST uses the huge ECT_HIST table directly, we want to restrict the number of days that we are allowed to query from it independently of the range selected in the application. So even if you query the Performance for the last 60 days you will only see the avg WIP by ECT state data from the last x days per this configuration. The shorter this number is the faster the performance query will be for the Performance application.

PERF_HIST_DAYS_FOR_SHIFT_DAY

NUMBER(4)

This is a special purge_days limit for our Historical Performance application. We require PERF tables and tables used in PERF views to have at least this many days of data in them (at least once the initial data population reaches this many days) so technically we prevent the purge_days column in CFG_TABLES for these tables to be less than this limit. This column applies to tables where the data is summarized by shift or day while the PERF_HIST_DAYS_FOR_WEEK_MONTH column applies to the week or month tables.

PERF_HIST_DAYS_FOR_WEEK_MONTH

NUMBER(4)

See comment in PERF_HIST_DAYS_FOR_SHIFT_DAY column.

PURGE_CHGLOG_DAYS_ADMIN_CFG

NUMBER(5,1)

Since FPSADMIN CFG tables are not in CFG_TABLES, we set purge_chglog_days for all of them using this value.

PURGE_CHGLOG_DAYS_APP_C

NUMBER(5,1)

Since FPSAPP C tables (i.e. PFIX_C_xxx) are not in CFG_TABLES, we set purge_chglog_days for all of them using this value.

PURGE_CHGLOG_DAYS_APP_W

NUMBER(5,1)

Since FPSAPP W tables (i.e. PFIX_W_xxx) are not in CFG_TABLES, we set purge_chglog_days for all of them using this value.

SET_BEG_PROC_INST_IF_NO_TOOL

CHAR(1)

Set to Y to set BEG_PROC_INST for any BEGIN event, even if logged with no entity or with an entity that does not exist in the DWH. Set to N to set BEG_PROC_INST by tool.

SET_REPEAT_BY_EVENT

CHAR(1)

At most sites, we automatically calculate is_repeat_curr_shift and is_repeat_curr_plan_day by checking the history to see if this lot has already moved out of this step in the current shift/day. But if this is set to Y then we set both is_repeat_curr_xxx flags based on the is_repeat_if_set_by_event value for the event in WIP_EVENTS. This is typically used when the MES reports that the move is a repeat and we want to use the MES value. Since we we calculate moves as COMP + ISKIP + DSKIP - REPEAT then repeats are effectively not counted in our moves calculation.

SHIFTS_FOR_TOOL_MAX_COMP

NUMBER(2)

In the DASH_P_TOOL_MAX_SHIFT_COMP view we get the maximum completes for each tool in any recent shift. The default is 14 shifts but we can adjust as needed with this parameter.

SHOW_DAY_BEFORE_MONTH

CHAR(1)

Our default date display format is the US standard of month-day-year like Nov 27 1976 but setting this flag to Y changes to day-month-year like 27 Nov 1976.

SHOW_IDLE_INSTEAD_OF_SBY

CHAR(1)

The words standby and idle are synonyms. FPS uses standby but some sites prefer to use idle so they can set this flag to Y and our ETP state display names will replace Standby with Idle automatically.

SITE_NAME

VARCHAR2(5)

N

Short name of the site. Each DWH instance must be for a single site but we can have one or more sites for a given client and we can have one or more facilities at a given site. To use a famous company who we will never work for as an example, the client_name would be GM, client_name_display General Motors, site_name GMDET, site_name_display GM Detroit Truck Fab, and two facilities on the site F150 and F250.

SITE_NAME_DISPLAY

VARCHAR2(24)

N

Longer display friendly site name.

SKIP_UPDATE_WSF_IF_BEHIND_MINS

NUMBER(3)

The procedure call to update WIP_STEP_FUTURE after each move event is by far the slowest part of our realtime data load but it is not valuable to do the full update when our data falls way behind because it is likely that the lot will have another move event later and overwrite the information. This is normally set to 30 so if we ever fall more than 30 minutes behind we just skip all WSF updates to catch up quicker and then the ADM_FIX procedure refreshes any lots where the newest move event has not been updated.

SKIP_UPDATE_WSF_IF_SAME_LOOP

CHAR(1)

The rn_desc_of_step_moves logic speeds up our RealTime job by only updating WIP_STEP_FUTURE once per lot per job and should be enabled by setting this flag to the default of Y in most cases. The first case where it must be disabled (meaning we will call UPDATE_WIP_STEP_FUTURE after each move event) is when we do not populate step along with next_step in WIP_EVENT_HIST. This first case is checked in SYSMNTR_ERRORS. The second case is if we develop a new ETL approach where we insert events one at a time and commit after each event. This logic is designed for our standard approach of scraping recent events and inserting them in bulk into WIP_EVENT_HIST.

STATIC_CURR_DATE

DATE

For static instances like FPSDEV or FPSDEMO where there is no live data feed this is the datetime when the data was updated. We use this in place of sysdate so that logic will work properly at static instances as well as live ones.

STEP_SEC_RQD_FOR_COMP

NUMBER(2)

A lot is required to be at a step for at least this many seconds in order to be eligible to move_type to COMP. The default value is 60 seconds. There are other factors required to be COMP but any lot that spends less than this many seconds at the step will never have the move_type of COMP. Instead it will be ISKIP unless the route or qty changes.

SYSMNTR_ERROR_INTERVAL_MINS

NUMBER(3)

SYSMNTR_ERRORS sends emails about all recent R errors (errors during run that are not failures). We want to ensure that all R errors get included in one but only one email so we want to look back since the last email check with an overlap of a couple minutes.

THPT_WEEKS_TO_SHOW

NUMBER(2)

The number of previous weeks to show on the Throughput Tracker weekly history charts. Even though we might only use 4 or 8 weeks to calculate the automatic values, we almost certainly want to show more weeks like 13 on the chart.

TIME_ZONE_OF_MES_DATA

VARCHAR2(30)

This column should be null as long as the data from the MES is in the same time zone as the facility in which the people are using the applications. But if the MES data is loaded from a different time zone (ex: UTC for daylight savings time support) then this value should be set to the time zone of the MES data and the TIME_ZONE_OF_WEB_VIEWER should be set to the time zone of the facility where the users are viewing the data. It is important to note that both time zone fields must either be null (which will then apply the dbtimezone of the database server) or all must be not null and specified based on the appropriate time zone for each field. Time zones are listed at https://docs.oracle.com/cd/E84527_01/wcs/tag-ref/MISC/TimeZones.html.

TIME_ZONE_OF_WEB_VIEWER

VARCHAR2(30)

See column comment on TIME_ZONE_FOR_MES_DATA for details.

USE_7D_FOR_DASH_ETP_HIST

CHAR(1)

At most sites it is reasonably fast to query ETP_HIST with a filter on eqp_to_inst or etp_to_inst depending on the use_etp_for_web flag. Using ETP_HIST allows us to go back to any time range in the past, at least any time range that has not been purged from the ETP_HIST table. But at some of our largest sites querying ETP_HIST even for one day is quite slow. This flag gives the option to use DASH_B_H_ETP_HIST_7D which is a smaller copy of ETP_HIST that not only has a shorter history but eliminates rows where from_inst and to_inst are the same second which can be a significant number especially if using EQP rather than ETP.

USE_COMMA_AS_DECIMAL_POINT

CHAR(1)

Our default number display format is the US standard of period for decimal point and comma for thousands separation like 12,345.67 but setting this flag to Y swaps these like 12.345,67 which is common in Europe.

USE_DATA_DATE_AS_CURR_DATE

CHAR(1)

This is for our live demo databases where the data is actively loading but for a time that is way in the past. In this case we just want curr_date to always be one second after data_date.

USE_ETP_FOR_WEB

CHAR(1)

Flag to display FPS ETP states on dashboard instead of client standard EQP states.

USE_MAIN_FOR_EQP_STATE

CHAR(1)

Flag to use only client mainframe state for EQP state on chamber tools instead of MPCT value calculated using the chamber states, when available. Some clients have already developed more detailed tool states that reflect the tool as they would like it to be represented.

USE_MSO_DECISION_OVR

CHAR(1)

Flag is used to control if the final mes decision changes the counter for rules that we are writing to the MES. If we tag a lot, but the lot skips metrology, then we will update the counter to count the lot as a skip. You do not want this flag on if you are doing development and dont want the mes decisions to override and see normal behavior of the rules.

USE_M_EVENTS_TO_CHOOSE_TOOL

CHAR(1)

When multiple tools log events at a step, we need to choose which one to count as the tool. This is a critical decision because we use this tool field in WIP_STEP_HIST when we count tool completes and in our logic to determine the process family. Our default is to choose the tool which automatically logged BEGIN and END events first then to choose the tool which manually logged BEGIN_M and END_M events only if no other tool automatically logged BEGIN and END. However at some sites the manual events come from the MES and the automatic events come from a less reliable tool log so when this flag is Y then we choose the tool with manual events. Finally it is worth noting that COMP events are not included here even though they are really a version of an END_M event but this should never cause any trouble because the BEGIN_M event will correctly choose the tool. So in the remote scenario where the MES does not log a BEGIN_M then automation logs BEGIN and/or END to the wrong tool and then MES moves out the lot with a COMP event to the correct tool, we will choose the wrong tool - and we accept this.

USE_OTHER_FACILITY_LOGIC

CHAR(1)

Our other facility logic is based on the other_facility column in RTG_ROUTE_STEPS. A few features of this logic, particularly regarding WIP_STEP_FUTURE, add some overhead to our triggers that we want to skip at sites where we are not sharing facilities.

USE_UPDATED_FOR_CHK_DATA_DATE

CHAR(1)

For some sites on weekends and at night, it is reasonable to not have any WIP events logged so this allows us to check the last_success_time of WIP_EVENT_HIST rather than data_date which is the last event.

WEH_INSERT_LOAD_JOB

VARCHAR2(10)

Name of load job in CFG_SCHED which includes the object_name that loads the WIP_EVENT_HIST table.

WEH_INSERT_OBJECT_NAME

VARCHAR2(30)

Object_name in CFG_SCHED which loads the WIP_EVENT_HIST table. Usually this will be simply WIP_EVENT_HIST but not always.

WEH_PRELOAD_LOAD_JOB

VARCHAR2(10)

See column comment for WEH_PRELOAD_OBJECT_NAME. This is the name of load job in CFG_SCHED which includes that object.

WEH_PRELOAD_OBJECT_NAME

VARCHAR2(30)

At some sites we have a preliminary job which loads data from MES into an intermediate table which is then loaded into WIP_EVENT_HIST. If applicable, this is the object_name in CFG_SCHED which does this.

WHY_ARCHIVELOGMODE_NECESSARY

VARCHAR2(128)

FPS prefers that ARCHIVELOGMODE is turned off because our data warehouse generates large archive logs which are unnecessary so we warn in SYSMNTR_ERRORS if it is on. However some sites, particularly those where their DBAs administer many Oracle databases, require that ARCHIVELOGMODE is on so we need to hide this warning. Populating this column hides the warning and explains the situation at this site.