Freshmark replication server

freshmark-canonical

Markdown document

Freshmark Metadata Map

metadata-map.md

Freshmark Metadata Map

Confirmed split between schemas

Current evidence points to a two-part model:

  • fmsz acts as the metadata and runtime-definition schema
  • fmsx stores live menu structures and security group mappings

This split is important because the frontend does not appear to be driven by one giant codebase alone. Some of its behavior is stored as rows and field logic in the database.

Tables with strong evidence

fmsz.ZE_ENQ

  • Purpose: report writer definitions
  • Observed row count: about 142
  • Key fields:
  • ZE_KEY
  • ZE_TABLE
  • ZE_DESC
  • ZE_FIELDS
  • ZE_SELECTION
  • ZE_JOIN
  • ZE_ORDER

This is the clearest report-definition table so far.

fmsz.ZP_PGMS

  • Purpose: program or screen definitions
  • Observed row count: 1763
  • Key fields:
  • ZP_PROGRAM
  • ZP_DESC40
  • ZP_TYPE
  • ZP_ZT

Observed types include DSP, MAN, MDL, PRT, ZZD, SEL, and ENQ.

Working interpretation only:

  • DSP looks like display or general runtime screens
  • MAN and MDL look like maintenance-style screens
  • PRT appears report-oriented
  • ZZD looks like internal rule/action helper definitions

Those meanings still need confirmation from client behavior.

fmsz.ZX_PGMS_FIELDS

  • Purpose: per-screen field layout and embedded runtime logic
  • Observed row count: about 73,930
  • Evidence:
  • stores screen coordinates (ZX_X, ZX_Y)
  • stores field or label metadata (ZX_FIELD, ZX_DESC, ZX_TYPE)
  • stores embedded logic snippets in ZX_CODE

Examples from live rows:

  • DEBTOR_MAN contains inline validation logic
  • ABSA_BUYER_MAN contains $SELECT, $CALCULATE, and table lookup logic
  • ZZMENU_MAN contains menu selector and language-loading behavior

fmsz.ZS_SEL

  • Purpose: reusable selector and lookup metadata
  • Observed row count: about 837
  • Key fields:
  • ZS_KEY
  • ZS_TABLE
  • ZS_DESC
  • ZS_SELECTION
  • ZS_CALLPGM
  • ZS_JOIN

ZX_CODE snippets frequently refer to selectors with tokens like S:DEBTOR_CR2, which makes ZS_SEL important for reconstructing lookup dialogs and pick lists.

fmsz.ZT_TABLE

  • Purpose: table registry
  • Important clue:
  • ZE_ENQ maps to FMSZ
  • ZM_MENU maps to FMSX
  • ZP_PGMS and ZX_PGMS_FIELDS map to FMSZ

This table is currently the best evidence for cross-schema ownership.

fmsz.ZB_DB

  • Purpose: database registry and connection metadata
  • Example values:
  • FMSZ
  • FMS
  • FMSX
  • ARCHIVE

fmsx.ZM_MENU

  • Purpose: live menu structure
  • Observed row count: 1869
  • Key fields:
  • ZM_KEY
  • ZM_SEQ
  • ZM_TYPE
  • ZM_LVL
  • ZM_PGM
  • ZM_DESC
  • ZM_PGMBEFORE
  • ZM_PGMAFTER
  • ZM_ZC

Observed large menu groups:

  • ADMINI_REPS
  • DEBTORS
  • ADMIN_REPORTS
  • MAINMENU
  • SALES
  • COLDSTORAGE

Observed menu item types include P, G, R, M, A, E, and X. Their exact semantics still need confirmation, but the data clearly distinguishes different menu behaviors.

fmsx.ZC_SEC_GROUP

  • Purpose: security or menu-group registry
  • Important clue:
  • ZC_ZM points at root menu MAINMENU
  • group codes such as DEV, AGN, SAD, CAS, and CLD appear inside ZM_MENU.ZM_ZC

This suggests menu visibility is controlled by group membership plus menu-row metadata.

Strong menu clue from ZZMENU_MAN

Program ZZMENU_MAN in ZP_PGMS points to base table ZM_MENU.

Its field logic shows:

  • selector calls to S:ZM_MENU
  • security-group selection with S:ZC_SEC_GROUP
  • language handling through ZZ_LANGUAGE

That is strong evidence that the client can maintain menus through metadata-driven screens rather than a hardcoded admin interface.

Report-backed menu execution chain

The current simulator work shows that report launches are already traceable from menu rows to executable report metadata.

flowchart LR A[fmsx.ZM_MENU] --> B[Parse ZM_PGM] B --> C[fmsz.ZE_ENQ] C --> D[ZE_TABLE] C --> E[ZE_JOIN] C --> F[ZE_SELECTION] D --> G[Preview SQL] E --> G F --> G G --> H[fms data schema]

This gets us to live sample rows already, but not yet to a full report runner with prompts, selectors, ordering, and layout fidelity.

The next implementation phase is documented in report-runner-phase.

Practical takeaway

We should treat the system as:

  1. A conventional application with business tables like STK_TRANS and DEBTOR_MAST
  2. A metadata engine that stores reports, selectors, screen layouts, runtime rules, and menu structure in database rows

That means our rebuild work needs both:

  • business-domain understanding
  • metadata-engine decoding