Skip to content
English
  • There are no suggestions because the search field is empty.

Report: *.dbparam.rpt - Database Parameter & Configuration Report

The *.dbparam.rpt files under rpt/ are a complete snapshot of how a database is currently configured.

The OpenEdge release, all runtime parameters and their default/modifiable status, the remote server (broker) configuration, and a .st-style structure description of the on-disk layout. They are produced by util/dbparamrpt.p.

One file is written per database, named <shortname>.dbparam.rpt (or <ldbname(1)>.dbparam.rpt if pt_shortname is unset) and placed in $RPTDIR (or the current directory if RPTDIR is unset).

Invocation

mbpro <dbname> -p util/dbparamrpt.p

It is also wired into ProTop's interactive menus and the dba_report collection flow.

Prerequisite

This program depends on the _dbParams VST, which is only available in OpenEdge 11.5 or later with that VST activated. If the VST is missing or the running OE release is older, the program pops a centered red nastyGram ("This functionality requires OpenEdge 11.5 or better with the _dbParams VST activated."), waits for a key, and exits without writing the report.

Layout

The file is built up in six distinct phases.

Phase 1 — header line

The very first line is the database's physical pathname (pdbname(1)), right-padded out to about 130 columns, followed by now. Then a blank line.

Phase 2 — proutil ... -C describe output

The program shells out to:

proutil <db> -C describe -cpinternal <session:cpinternal> -cpstream <session:cpstream> >> <rptOut>

This appends the standard OpenEdge "Database Description" block to the report, covering:

  • OpenEdge release banner
  • Database name, version, block size, largest cluster
  • Create / Last-Open / Prior-Open / Schema-Change dates
  • BI block size, cluster size, last-open, BI-truncation-on-target
  • AI block size, begin date, last AIMAGE NEW, current busy area, current file number
  • Backup info (last full / last incremental)
  • Code page / collation / word-rule
  • Database Features table (Large Files, AI Mgmt/Archiver, 64-bit DBKEYs, Large Keys, 64-bit Sequences, CDC, etc., with their active flag and any details)

This is verbatim proutil output — it is not assembled by ProTop.

Phase 3 — _dbParams VST listing

Re-opens the file in append mode and walks every row of _dbParams via a dynamic query, producing the bulk of the report:


Parameter Name         Def?  Mod?  Value                                         Description

---------------------- ----- ----- --------------------------------------------- -----------------------------------------------------------------------------

Columns:

  • Parameter Name — _dbParams-Name (the startup-parameter switch, e.g. -B, -spin, -aiarcdir).
  • Def? — _dbParams-Is-Default, Yes if the running value matches the Progress default, No if the parameter has been overridden.
  • Mod? — _dbParams-Is-Modifiable, Yes if the parameter can be changed online (e.g. via _proutil ... -C increaseto), No if a database restart is required.
  • Value — _dbParams-Value. Truncated to 42 chars; values longer than that get an ellipsis appended (...).
  • Description — _dbParams-Desc, trimmed at the first  ( so the parenthetical hint that some descriptions carry is dropped.

While iterating, two values are stashed for later: dashN (-n, max users) and dashMn (-Mn, max servers).

Phase 4 — Remote Server Configuration

A header banner:

Remote Server Configuration
===========================

Then, for each row of _servers whose _server-type = "login" (i.e. each login broker), a per-broker block:

================================================================================
Remote <ServerType> login broker on port <port>           ← or "Default ... (unusable)" if portnum = 0

Inside each broker block, parameters are pulled from the broker's _srvParam-name / _srvParam-value / _srvParam-is-default arrays (extent fields, indexed up to 64). The -ServerType, -Mpb, and -Ma slot numbers are looked up first; then parameters are listed two columns wide:

  • Left column — ABL/broker startup parameters, walked from the -ServerType slot down to slot 1 (-S, -PendConnTime, -N, -Mpb, -Mp, -Mm, -Mi, -Ma, -threadedServerStack, -threadedServer, -ssj, -minport, -maxport, -ipver, etc., plus their default flags).
  • Right column — SQL parameters, walked from the -ServerType slot upward so it ends up showing slots that hold the SQL settings (-SQLCursors, -SQLLockWaitTimeout, -SQLQuotedRowid, -SQLStack, -SQLStmtCache, -SQLTempBuff, -SQLTempDisk, -SQLTempPgSize, -SQLTruncateTooLarge, -SQLWidthUpdate, etc.). The right column is suppressed when _srvParam-value(svt) = "ABL" — pure-ABL brokers don't carry SQL parameters, so that side of the table is left blank.

After each broker, the report accumulates totals across all brokers:

  • sum_mpb — running total of (Mpb + 1) (the brokers themselves count as servers).
  • sum_cnx — running total of (Mpb + 1) * Ma, i.e. the maximum concurrent client connections that all brokers combined can support.

Phase 5 — -n / -Mn recommendation

Once every broker has been printed, a recommendation block follows:


To fully support these remote servers:
   -n should be at least: <sum_cnx + 5> (actual = <dashN>)
    -Mn should be at least: <sum_mpb + 1> (actual = <dashMn>)

The +5 slack on -n covers self-service / utility connections, and the +1 on -Mn covers the broker itself. If your actual values are below the suggested ones, the broker config is over-committed: a busy moment will run out of user slots or server slots before all brokers can hand out connections.

Phase 6 — .st-style structure description

Last, the program walks _areaStatus / _area / _areaExtent to emit a description of the on-disk layout in the same syntax that prostrct consumes. Areas with _AreaStatus-areaNum < 6 and <> 3 (the system control / recovery / etc. low-numbered areas other than schema) are skipped.

The format mirrors a .st file:

  • b <path> — Before-Image extent
  • a <path> — After-Image extent
  • d "<name>":<num>,<rpb>;<cluster> <path> — Data/Schema extent

A trailing  f <size> is added for fixed-length extents (_extent-type 36–39); a trailing # <blksVar> comment is added to variable-length data/BI extents to record their current effective size. Areas are separated by # lines so the output is itself a valid .st file plus comments.


The _extent-type decoder used:


code

meaning

1

Control area extent (.db)

4

Variable-length AI extents (.aN)

5

Variable-length data/schema (.dN)

6

Variable-length BI extents (.bN)

36

Fixed-length AI (32 + 4)

37

Fixed-length data/schema (32 + 5)

38

Fixed-length BI (32 + 6)

39

Fixed-length TL file (32 + 7)


areaType is bucketed as 1=BI, 2=AI, 3=data/schema/other and the b/a/d letter at the start of each line is keyed off that.

Side effects

  • Shells out to proutil ... -C describe (Phase 2). On systems where proutil is not on PATH for the mbpro session, that section will be empty.
  • Calls lib/uploader.p ( rptOut, pt_shortname, output xStatus ) to ship the file off as part of the ProTop run.
  • Calls lib/fileviewer.p ( rptOut ) to open the report for the user immediately after it is written. (Unlike tblReport and friends, this one always pops the viewer.)

Reading the report

  • The Phase 3 listing is the headline — scan the Def? column for No rows to see, at a glance, every parameter the DBA has deliberately changed from the Progress default. That's usually the most actionable view of how the DB is tuned.
  • Mod? = No rows are parameters that need a restart to change; plan accordingly.
  • The -n / -Mn recommendation is a hard sanity check: if actual < suggested, the broker stack is mis-sized for the brokers that are configured. Either increase -n / -Mn or trim the brokers.
  • The structure block at the bottom is a self-contained prostrct-friendly description of the database — useful both for documentation and as the starting point for a prostrct create on a new copy.
  • Cross-reference the Database Features table (Phase 2) when planning upgrades — features like Large Keys, 64-bit DBKEYs, and CDC change what options downstream tools can use.