Skip to main content

System Administration & Shared Services

Source libraries: homersys (application shell, navigation, logon, shared search and maintenance windows — 152 objects), system (non-visual shared services and base classes — 42 objects), base (a grab-bag of developer/ad-hoc extract objects — 38 objects, mostly one-off DataWindows).

Security administration (users, classes, group-level data security, menu security) lives in the app_sec library and is documented separately in Security Model. This page covers everything else that makes HOMER a single coherent application: the MDI shell and data-driven navigation, the logon/connection sequence, reference-data (code table) maintenance, and the shared behavioral framework — search/selection windows, standard CRUD patterns, wizards, preferences, logging — that every functional module inherits. These patterns are requirements: they define the consistent behavior users experience across all ~550 screens, and a migration that rebuilds modules one-by-one without them will produce an inconsistent product.

Actors​

  • All HOMER users — everyone enters through the shell, logon, and navigator.
  • System administrators / MIS staff — maintain code tables, batch report definitions, letter headers, release notes, and diagnose problems via error logs, trace, and the test log.

The navigation shell​

MDI frame​

w_sfpi_frame (homersys/w_sfpi_frame) is the MDI frame every functional screen opens inside as a sheet. On post-open it:

  1. Shows the connected user and database/server in the MicroHelp bar and status bar, and halts if the database connection is not live.
  2. Applies Oracle roles for the user (system/f_set_roles) and re-reads the user description once security tables are readable.
  3. Sets the window title to indicate the environment — (Production), (Test), or (Development) derived from the database name — plus the application version (homersys/w_sfpi_frame pfc_postopen).
  4. Verifies the client build against the database: of_check_app_ver counts rows in homer_versions matching the running version string and halts with "not currently running a valid version" if none match (homersys/n_cst_sfpiappmanager).
  5. Initializes the security service, applies menu security via n_system_menu_security.of_applymenusecurity (see Security Model), and builds the subscriber-protection list (below).
  6. Opens the tree navigator automatically when the user's INI setting SETTINGS/sys_menu is True (the default) (homersys/w_sfpi_frame).

The status bar shows user id, a clock (interval and format configurable from the INI: timerinterval, timerformat), free-memory indicator, the active sheet name, and a notes indicator that switches between "no notes", "notes found", and "VIP notes found" bitmaps under module control (w_sfpi_frame.wf_notes_found/wf_no_notes/wf_vip_notes_found).

  • SYS-1 — All functional screens open as sheets of a single main window that permanently displays: logged-on user, connected database and server, an environment indicator (Production / Test / Development), application version, and the active screen's identity. (homersys/w_sfpi_frame)
  • SYS-2 — The client checks its own version against a database version registry (homer_versions) at startup and refuses to run when the version is not registered. (homersys/n_cst_sfpiappmanager.of_check_app_ver, w_sfpi_frame pfc_postopen)

The function tree (w_system_tree_menu)​

The primary navigator is homersys/w_system_tree_menu, opened as a sheet titled "Menu". Mechanics:

  • The tree is built by walking the frame menu (m_sys_frame's m_functions branch): each visible menu item becomes a tree node, parents are folders, leaf items are launchable "programs" (w_system_tree_menu.wf_loadmenu). m_sys_frame (homersys/m_sys_frame, ~19,000 lines) is thus the master catalog of every function in the application, organized under top-level areas (Enrollment, Plan, COBRA, Funding, Accounting, Providers, Claims, UR/CM, Administrative, System, Security — per the picture-assignment code in wf_loadmenu).

  • Items the user's security disables are shown non-bold and refuse to launch with "You do not have the proper security authorization to run this program." (wf_launchprogram). The enable/disable state itself comes from menu security applied to m_sys_frame before the tree is built (w_sfpi_frame pfc_postopen → gnv_menu_security.of_applymenusecurity; see Security Model).

  • Favorites: leaf items can be dragged onto a Favorites list; folders are rejected. Favorites launch on double-click/Enter and are removed with Delete. They persist per user as user_ini rows (section_name='MENU', key_name='FAVORITEnn') and are renumbered/compacted on load. (wf_setfavorite, wf_loadfavorites, lv_favorites events)

  • Home item: Ctrl+Enter or right-double-click marks a node as "home"; the tree opens pre-selected there on next start (user_ini MENU/HOME). (wf_sethome, tv_system_menu.ue_load)

  • Expansion state: which folders are expanded is saved per user (section_name='MENU_OPEN') on close and restored on load. (wf_expand_contract)

  • Personal notepad: a free-text notepad on the navigator persists per user, chunked into 2,000-character user_ini rows (MENU/NOTEPADnn), saved on lose-focus/close. (wf_setnotes, wf_loadnotes)

  • System notes banner: a banner DataWindow (d_user_ini_sysnotes) shows broadcast rows (user_ini username SYSTEM or the current user, key SYSNOTE%), supporting [COLOR BOLD ITALIC] markup prefixes and substitution tokens &VERSION, &BUILD, &DATE, &USER, &NAME, &DB, &SERVER; when no rows exist it defaults to "Welcome (user). Running (version)". (w_system_tree_menu.dw_sysnotes pfc_retrieve)

  • SYS-3 — Navigation is presented as a security-filtered hierarchical tree of all application functions, mirroring a single master function catalog; unauthorized functions are visible but disabled and cannot be launched. (homersys/w_system_tree_menu, homersys/m_sys_frame)

  • SYS-4 — Per-user navigator personalization — ordered favorites, a home position, folder expansion state, and a free-text notepad — persists in the database (user_ini keyed by username/section/key), not on the workstation. (homersys/w_system_tree_menu, homersys/d_user_ini)

  • SYS-5 — Administrators can broadcast styled system notes (with runtime substitution of version, date, user, database) that display on every user's navigator. (homersys/d_user_ini_sysnotes, w_system_tree_menu.dw_sysnotes)

The table-driven button menu (w_system_menu)​

An older navigator, homersys/w_system_menu ("HOMER - System Menu"), renders menu options as picture buttons from the system_menu table via d_system_menu_datawindow: SELECT picture_path||picture_name, sys_menu_option, window_to_open, display_order, menu, parameter FROM system_menu WHERE menu = :menu_name ORDER BY display_order. Clicking a row either descends a level (rows whose window_to_open is not a window name), returns a level (names starting x, or Shift-click), or opens the target: names starting w open as sheets (with parameter passed when present), names starting r are opened as response windows after replacing the prefix with w. Every launch is guarded by homersys/f_useraccess, which checks the user's security groups against security_info/security_template for a 'Top Level Menu Object' entry, and denies with "You do not currently have access to the requested Application Function." A breadcrumb of the descent path is maintained in the title text. The frame exposes ue_system_menu to open this navigator at a given level (homersys/w_sfpi_frame).

  • SYS-6 — The function catalog is data-driven: a database table (system_menu) defines menu captions, hierarchy, display order, target window and an optional launch parameter, so navigation can be re-arranged without code changes. (homersys/d_system_menu_datawindow, homersys/w_system_menu; the same table also drives menu security — see Security Model)
  • SYS-7 — Function launch is authorization-checked at the moment of launch (not only at display), with a uniform denial message. (homersys/f_useraccess, w_system_menu doubleclicked, w_system_tree_menu.wf_launchprogram)

Functions not yet built open homersys/w_construct ("Under Construction"); f_useraccess exempts it from security.

Logon and connection flow​

The application manager homersys/n_cst_sfpiappmanager (a PFC application manager subclass, global gnv_app) drives startup:

  1. INI resolution (constructor): the application INI is homer.ini in the current directory if present, otherwise the path registered in win.ini under [SFPI]. The user INI is set to the same file. INI keys read at startup include SETTINGS: microhelp, logo, help, debug, spy_file, activate_testlog, CREATEMEMBERID, pict_path, database, timerinterval, timerformat, sys_menu, test; ErrorLog: logfile, severity; Oracle Production: DbParm. It also writes SETTINGS/archive_dir = U:\mis\archive back to the INI.
  2. Services (pfc_open): error service with configurable log file and severity; transaction registration; the security service; the application preference service (system/u_app_preference); the file service.
  3. Connection: SQLCA.of_Init(inifile, ProfileString(SETTINGS/database, default "Oracle")), then a modal logon loop — of_LogonDlg opens homersys/w_homer_logon repeatedly until logon succeeds or the user cancels (cancel halts the application).
  4. Logon (pfc_logon): sets user/password on the transaction, connects, captures the Oracle session id (system/u_app_sql.uf_getoracleid), and writes an audit trail to the error log: database/server/logid, success or failure with SQL error text, and client environment (OS, CPU).
  5. Password change: the logon window carries optional "New Password" / "Verify New Password" fields; on match and confirmation it issues ALTER USER ... IDENTIFIED BY ... (users are Oracle accounts), with failure guidance and a log entry. (homersys/w_homer_logon pfc_default)
  6. Roles: system/f_set_roles issues SET ROLE readsec, retrieves the user's role list (d_user_role_privs), and issues one SET ROLE r1, r2,… for the session; distinct failure codes for "readsec not granted", "no roles", "set role failed".
  7. Security service: of_start_security opens a second database connection (itr_security) with the same credentials for security lookups, runs of_InitSecurity, and maps failure codes −1…−5 to specific fatal messages (cannot connect / no app parameters / no user parameters / user has no granted functions / no default group), halting the application.
  8. Subscriber protection: of_subscriber_security retrieves d_subscriber_protect (distinct member_sys_key from members_included where name <> :userid) into an in-memory list of member keys the current user must not access — a member-level privacy screen used by search services. (homersys/n_cst_sfpiappmanager)
  9. Frame: only after successful logon is the frame opened (ue_afteropen → Open(w_sfpi_frame)).

Diagnostics wired into the manager: a debug/SQL-spy mode (INI-driven) logging all SQL to a file; a test log mode (activate_testlog=TRUE) that adds a Tools menu item and routes unhandled system errors into a structured bug report window (homersys/w_test_log) writing to the test_log table (version, build, database, window, module, system message, user message, user details); otherwise pfc_systemerror formats error number/text/object/script/line into the standard error service and exits. A single-instance mutex check (of_is_this_app_running via CreateMutexA) exists but its startup call is commented out.

  • SYS-8 — Startup is fail-closed: missing/invalid configuration, failed connection, failed security initialization, an unregistered client version, or a cancelled logon all terminate the application with a specific message. (homersys/n_cst_sfpiappmanager pfc_open, of_start_security; w_sfpi_frame pfc_postopen)
  • SYS-9 — Users authenticate with individual credentials; the session identity drives role activation, security lookups, personalization, and audit attribution. Logon attempts (success and failure), environment details, and password-change attempts are logged. (n_cst_sfpiappmanager pfc_logon, w_homer_logon, system/f_set_roles; see Security Model)
  • SYS-10 — Users can change their own password at logon time with verification and confirmation. (homersys/w_homer_logon)
  • SYS-11 — A per-user member-exclusion list (members_included) is loaded at startup and exposed application-wide so member-selection screens can hide protected members (e.g. fellow employees / VIPs) from users not authorized to see them. (n_cst_sfpiappmanager.of_subscriber_security, homersys/d_subscriber_protect; consumed e.g. by enroll/w_group_member_select)
  • SYS-12 — Behavior toggles are externalized configuration, not code: environment/database selection, debug and SQL tracing, test-log capture, microhelp, help file, image paths, member-ID generation mode (CREATEMEMBERID). (n_cst_sfpiappmanager constructor)

User-visible session info​

homersys/w_homer_about (About box: application, version, copyright, logo) and homersys/w_user_detail (popup showing the resolved system INI file, user INI file, database username, and error-log path) expose session context for support. (w_user_detail pfc_postopen)

Reference-data maintenance​

Generic code tables (codes / code_keys)​

homersys/w_code_maint is the system-wide code table editor. code_keys defines the code sets (key + description, maintained in homersys/w_code_key_maint); codes holds the values per set. The editor lists all code sets, shows the values grid (d_codes_grid) for the selected set, supports add/insert (pre-filling the selected code_key), prompts to save when switching sets, and on delete warns: the system cannot verify whether a code is in use — terminate the code by entering an expiration date rather than deleting it. Code values carry effective/expiration dates: the shared dropdown homersys/dddw_codes selects values for a key where EFF_DT <= :date AND (EXP_DT IS NULL OR …), and helper functions homersys/f_check_code_exp_date / f_check_category_exp_date validate dates.

The codes table is the lookup source for dozens of dropdowns across all modules (relationship codes, action codes, reason codes, etc. — every dddw_codes usage); which specific code sets exist is data, not code, so the authoritative list must come from a code_keys export (see Open questions).

  • SYS-13 — A single generic code-set facility (code_keys → codes) provides administrator-maintainable lookup values with display sequence, short/long descriptions, and effective/expiration dating; expired values drop out of selection lists but remain valid on historical data. (homersys/w_code_maint, w_code_key_maint, dddw_codes)
  • SYS-14 — Deleting a code value requires a double confirmation and the system steers the user toward expiring instead of deleting, because referential use cannot be checked. (w_code_maint.dw_codes pfc_deleterow)

Other reference screens in this domain​

ScreenTable(s)What is maintained
homersys/w_accident_typeaccident_typesAccident type reference values (d_accident_types).
homersys/w_general_member_cat_maintenancegeneral_catThe catalog of member category options ("possible list of group options").
homersys/w_group_options_maintenancegroup_optionsOptions assigned per employer group.
homersys/w_header (+ w_group_validate)letter_headers, groupsPer-group, per-letter-type letterheads: logo text and font, phone numbers, address lines. New entries validate the group id and uniqueness per (group, letter type); deletion is confirmed per group. system/n_letter_headers reads this table wherever letters are generated.
homersys/w_batch_reportsbatch_reportsThe catalog of batch-runnable reports: auto-assigned report_cd, report name (required), report DataWindow (required), parameter window, type, allowed run events/times. Sortable grid with add/delete/print.
homersys/w_examiner_selectuser_infoExaminer list selection window (d_examiner_selection updates USER_INFO); user directory data (name, location, phones) lives in user_info (d_user_info).
  • SYS-15 — Letter headers (logo, fonts, phone/address lines) are maintainable per employer group and letter type, and are resolved at letter generation time by a shared service. (homersys/w_header, homersys/d_letter_headers_maint, system/n_letter_headers)
  • SYS-16 — Batch reports are catalog-driven: a report becomes schedulable by adding a row naming its DataWindow and parameter window; report codes are system-assigned and names/DataWindows are mandatory. (homersys/w_batch_reports, homersys/d_batch_reports)

Shared services that carry business behavior​

These live in system/homersys and are inherited or invoked by every module. Each defines system-wide behavior a migration must reproduce (or consciously replace) once, centrally — not per screen.

Selection → edit patterns​

Two standard "find it, then work on it" window frameworks:

  1. homersys/w_maint_selection — criteria fields at top, result grid below. Each criteria field's tag holds a SQL condition template with a && placeholder; on Find, the window parses the result DataWindow's SQL, appends the filled-in templates to the WHERE clause (user * wildcards become %; entry is upper-cased), re-executes, and enables Open only when rows exist. Retrieval refuses to run with no criteria (no accidental full-table scans). New routes to add-row, Open/Enter routes to the edit window. (w_maint_selection.wf_get_selection_query, wf_criteria_found, dw_selection events)
  2. homersys/w_edit_selection — criteria DataWindow + result DataWindow with registered retrieval/key columns (up to 10). Search disables the criteria until Clear; any edit re-enables Search; leaving with unsaved changes prompts Save/Discard/Cancel; New pre-populates the result row's key columns from the criteria; commit/rollback is centralized in the window's end-transaction event. (w_edit_selection.of_register, of_saveprompt, of_setkeyvalues, pfc_endtran)

The edit service system/n_cst_edit_service links a selection window to its edit window generically: it registers requestor DataWindow + key columns, opens the named edit window in edit/new mode, passes parameters both ways, supports next/previous record navigation from within the edit window, and refresh-on-save of the parent. (n_cst_edit_service prototypes, u_homer_dw.of_seteditservice)

  • SYS-17 — Every maintenance area follows a uniform search-first pattern: criteria-driven retrieval (wildcards supported, case-insensitive), no retrieval without criteria, edit opens from a result row, unsaved-change prompts on navigation, and add pre-keys new rows from the search context. (homersys/w_maint_selection, homersys/w_edit_selection, system/n_cst_edit_service)

Standard data grid (system/u_homer_dw)​

The application-wide DataWindow class layers behavior on the PFC base: switches for row add/delete permission; key-column edit protection; auto-add-row on reaching the last row; "clear new rows" with minimum/maximum row counts; Enter-as-Tab (a per-user preference — u_app_preference.of_set_useenterastab); tab-page advance on tab-out; save-menu enablement when changes exist (of_setsavemenu); update against an alternate table (of_update_table); change tracking (of_ischangemade); size-to-columns. Windows enable the frame Save item only when a grid reports modifications (w_edit_selection ue_setsavemenu, homersys/w_batch_reports). system/n_homer_ds is the matching datastore; system/u_dw_on_tabpage integrates grids with tab folders.

  • SYS-18 — Grid behavior is uniform application-wide: controlled add/delete rights per grid, protected key columns, optional auto-append row, Enter-key navigation per user preference, and Save enabled only when unsaved changes exist. (system/u_homer_dw, system/u_app_preference)

Standard search components​

Reusable, embeddable search objects with consistent behavior (criteria entry → explicit Search button, auto-search when a unique identifier like SSN or member id is completed, Clear resets):

  • Member search: homersys/u_member_search (visual) over homersys/n_member_search, criteria d_member_search_criteria (SSN, name, member id, group). (The member-exclusion list of SYS-11 is exposed as gnv_app.il_subscriber_protect and applied by member-selection screens, e.g. enroll/w_group_member_select.)

  • Group search: homersys/n_group_search, u_group_select (drag-drop multi-select of groups).

  • Provider search: homersys/n_provider_search, n_provider_search_quickfind, u_provider_search, window w_provider_search.

  • Claims examiner search: homersys/n_claims_examiner_search, w_examiner_select.

  • User pickers: homersys/u_choose_user, u_choose_user_class.

  • Multi-group member disambiguation: homersys/w_homer_social_search lets the user pick which enrollment of a member active in multiple groups is meant.

  • SYS-19 — Member, group, provider, examiner, and user lookups are single shared components reused by all modules, so search semantics (fields, wildcards, auto-search on unique ids, exclusion of protected members) are identical everywhere. (homersys/u_member_search, n_member_search, n_group_search, n_provider_search, n_claims_examiner_search)

Wizard framework​

homersys/w_homer_wizard + u_homer_wizardobject: a base response window with Cancel / Previous / Next / Finish buttons over an ordered set of registered step objects; each step validates on leave (ue_leave) and can refuse entry (ue_enter); Finish only enables on the last step. Module wizards (e.g. user assignment in app_sec) inherit this. (w_homer_wizard.wf_nextprev, of_register)

  • SYS-20 — Multi-step guided flows share one wizard framework with per-step validation and controlled navigation. (homersys/w_homer_wizard, homersys/u_homer_wizardobject)

User preferences & settings cloning​

system/u_app_preference centralizes per-user behavior preferences persisted in the user INI (APP PREFERENCES): display all groups, display expired groups, default-to-last group, direct-to-member navigation, default member-ID letter, Enter-as-Tab, client segment (default SFPI). Database-backed personalization goes to user_ini (SYS-4).

homersys/u_clonemanager clones one user's setup to a new user in a single transaction: security group memberships (d_pfcsecurity_grouplookup), database roles (d_user_roles), and user classes (d_user_classes), refusing if the target already has settings and rolling back on any failure.

  • SYS-21 — A new user can be provisioned by cloning an existing user's function groups, roles, and classes atomically. (homersys/u_clonemanager; see Security Model)

Report archive (report_data / report_objects)​

system/n_report_data persists generated report output into the database: report content is stored as blobs in report_data with a description and report_type_cd, related objects in report_objects; it handles 32K-chunk blob/file conversion both directions, and multiple overloads accept DataWindows/datastores. system/n_cst_reprint_print_reports and dropdown homersys/d_dddw_report_type consume this archive; system/w_letter_on_cd retrieves claim letters archived to CD. (No report_hist table appears in these libraries — the archive mechanism here is report_data/report_objects.)

  • SYS-22 — Generated reports/letters can be archived centrally (typed, with description) and re-retrieved or reprinted later without regenerating them. (system/n_report_data, system/n_cst_reprint_print_reports)

Batch scheduler (system/n_batch_scheduler)​

Drives unattended batch windows (claims processing etc.): a process registers by name; the scheduler reads its run window (start/end time), mode (continuous vs. once-daily), frequencies, and optional rollback segment; it verifies the DB connection each cycle, never runs on Sundays, and in daily mode computes the next wake-up and records LAST_RUN_DT in batch_schedules. Setting batch_schedules.running = 'N' externally makes the process halt after its current cycle — the operator kill switch. It also manages claim-lock acquisition for competing batch workers (of_get_claim_lock overloads) and an on-screen console log. (n_batch_scheduler.of_check_processing, of_end_processing)

  • SYS-23 — Batch processes are schedule-driven from a database table (per-process run window, continuous/daily mode, last-run tracking, Sunday blackout) and can be stopped externally via a database flag; concurrent workers coordinate through lock acquisition. (system/n_batch_scheduler, batch_schedules)

Diagnostics & messaging​

  • system/n_homer_message extends the message object so structured parameters (istr_passparms — see system/str_passparms) travel between windows.

  • homersys/n_homer_trace writes timestamped, elapsed-time, free-memory-annotated trace entries for performance debugging, printable or saved to CSV (d_homer_trace).

  • The error service logs to a configurable file with severity filtering (SYS-8/9); system/w_dwdebugger is the PFC DataWindow debugging utility.

  • Address handling: homersys/u_homer_address (standard address entry object) and homersys/u_mailers (address standardization via the "Mailers" interface) with w_addr_search/w_addr_link to apply a corrected address to the linked persons/groups; commented-out startup hooks for the Mailers+4 verification software remain in the app manager (n_cst_sfpiappmanager pfc_open).

  • Utility functions used as business rules: system/n_functions.of_dwrangesvalid (validates from/thru date ranges do not overlap per key — used by dated reference data), system/f_init_cap, f_fixedlength, f_fund_money_to_word/f_fund_digit_to_word (check-amount wording), f_next_letter, f_lookupdisplay, and resize helpers (f_set_resize, f_set_tab_resize, f_set_uo_resize).

  • SYS-24 — Date-ranged records (rates, codes, eligibility-like rows) share one overlap-validation routine ensuring from/thru ranges for the same key do not overlap. (system/n_functions.of_dwrangesvalid)

Member deletion​

homersys/w_member_delete + n_delete_member remove a member and dependent data from the application — an administrative repair function (duplicated in base/w_member_delete). The exact cascade is in n_delete_member and should be reviewed with an SME before migration (see Open questions).

Release notes & help​

  • homersys/w_release_notes displays a printable release-notes grid. The content is hard-coded in the window's open event (38 entries covering versions 1.1.5–1.2.0); d_release_notes is an external (non-database) DataWindow. Later practice moved user-facing announcements to the navigator system notes (SYS-5).

  • Context help: F1 help is wired to a homer.hlp WinHelp file whose path comes from the INI (n_cst_sfpiappmanager constructor, w_sfpi_frame pfc_postopen).

  • MicroHelp: menu/tag-based hints in the frame's status line, toggled by INI (SETTINGS/microhelp; tag convention mh separator — n_cst_sfpiappmanager instance variables).

  • SYS-25 — The system provides in-app release/announcement visibility (currently: static release-notes screen + database-driven system notes) and screen-level help; a migration should consolidate on a data-driven mechanism. (homersys/w_release_notes, d_user_ini_sysnotes)

Data touched​

TableUsed by
system_menuNavigation catalog (d_system_menu_datawindow); menu security (see Security Model)
user_iniFavorites, home, expansion, notepad, system notes (d_user_ini, d_user_ini_sysnotes)
homer_versionsClient-version gate (n_cst_sfpiappmanager.of_check_app_ver)
codes, code_keysGeneric code sets (w_code_maint, dddw_codes)
accident_types, general_cat, group_options, stateReference screens (w_accident_type, w_general_member_cat_maintenance, w_group_options_maintenance, d_states)
letter_headersLetterheads (w_header, n_letter_headers)
batch_reports, batch_schedulesBatch report catalog and scheduler (w_batch_reports, n_batch_scheduler)
report_data, report_objectsReport archive (n_report_data)
test_logIn-app bug reports (w_test_log)
members_includedPer-user member exclusion (d_subscriber_protect)
user_info, user_dept_group, security_groupingsUser directory, department groupings (d_user_info, n_user_dept_groups)
security_*Logon/roles/access checks (see Security Model)

Migration notes​

  • The shell patterns are the product's UX. SYS-17/18/19 (search-first screens, uniform grid behavior, shared lookup components) should be rebuilt as shared components/framework in the target platform before module migration begins, or every migrated screen will re-implement them inconsistently.
  • Navigation should stay data-driven (SYS-3/6): the system_menu table + per-user/role filtering maps naturally to a dynamic menu service; favorites, home, and broadcast notes (SYS-4/5) map to per-user settings and an announcements feature.
  • Oracle-coupled mechanics need redesign: logon as Oracle accounts, SET ROLE, ALTER USER password change, dual security connection, and the DisableBind INI workarounds (f_set_roles) are implementation details — the requirement is individual identity + role activation + self-service password change (SYS-9/10).
  • Workstation INI files split personalization between file (preferences, u_app_preference) and database (user_ini); consolidate on server-side per-user settings.
  • The client-version gate (SYS-2) becomes trivially unnecessary in a server-delivered UI but the compatibility check concept may survive for any installed components.
  • base library: aside from w_member_delete, w_open_windowname (developer window launcher), w_provider_consolidate_vendors (vendor merge utility) and n_check_copy (check-copy/EOB print), it is dominated by one-off extract DataWindows (Burns enrollment dumps, MagellanRx files, test objects) that look like developer ad-hoc work products — candidates to not migrate; the extracts that are real recurring feeds belong to the EDI domain.
  • Test-log / trace facilities (SYS diag) can be replaced by standard logging/APM; the requirement worth keeping is that unhandled errors are captured with context and, in test mode, routed into a triage queue (test_log).

Open questions​

  1. Which code sets live in code_keys? The editor is generic; the authoritative inventory of code sets (and which modules read each) requires a data export of code_keys/codes. (homersys/w_code_maint)
  2. Is w_system_menu (button navigator) still in use, or fully superseded by w_system_tree_menu? Both are wired to the frame (w_sfpi_frame.ue_system_menu vs. the INI-driven tree auto-open).
  3. Member deletion cascade — exactly which child records n_delete_member removes, and under what preconditions, needs SME confirmation before reproducing (or replacing with soft-delete). (homersys/n_delete_member, w_member_delete)
  4. members_included semantics — the protection list retrieves members where name <> :userid, implying the table lists member↔user pairs that are allowed; confirm intended population and coverage (VIPs? employees?). (homersys/d_subscriber_protect)
  5. Mailers address standardization — the Mailers+4 integration hooks are commented out in n_cst_sfpiappmanager; is address standardization (u_mailers, w_addr_search, w_addr_link) still operational?
  6. Pridecare screens (w_pridecare, w_pridecare_bill_data, n_ds_pridecare_coverages) — a client-specific monthly billing extract living in the shared library; is this client still active, and should it migrate as a billing-domain feed?
  7. report_data growth/retention — no purge mechanics were found in these libraries; confirm retention policy for the report archive.
  8. SETTINGS/archive_dir is force-written to U:\mis\archive at every startup (n_cst_sfpiappmanager constructor) — confirm what consumes it (report/letter archival paths) for infrastructure planning.