M204 Features Reference

Database Programmer's Toolkit

Model 204 Features Master Reference



The terms "Model 204" and "204" are trademarks of Rocket Software Inc., and that fact is acknowledged wherever those terms are used in this document. Likewise the term "Sirius functions" which is a trademark of Sirius Software.

Summary

The main reason for this document is to answer questions such as "does DPT have a XXXXX statement like M204 does?", and the inevitable follow-up, "why not?". The following sections contain lists of Model 204 features, with accompanying comments along the lines of "DPT does this just like M204", or "DPT doesn't do this because ....", or "DPT does something similar to this, but not the same, and this is why". You get the idea.

The lists are based on Model 204 version 4.2.0, since when this project was scoped out those were the manuals available on the CCA web site. However, a few features of Version 5, as per the published release notes, were included in some form or another, and over time a few more features from Version 5 and 6 have crept in as they've been requested.

In many cases there are one or more "ref" numbers. These correspond to the general issues discussed in the emulation strategy document. For example the DEFINE PROCESSGROUP command is not emulated because Horizon is not emulated. Issue ref# 1.2 = connectivity.

M204 Feature Lists:


Emulation of Commands

Commands in the list that say "OK" can be assumed to work more or less the same as on M204. The numeric references correspond to the compatibility issues in the strategy document. In cases where there is a syntax or processing difference, hotlinks are given to the Language Reference document, which also contains details of a few DPT custom commands.

Command (Ref) Comments
ALLOCATE 2.3 Partial (notes...)
ANALYZE - Some different options and output (notes...)
ASSIGN 1.1 Unsupported
AUTHCTL 1.1 Unsupported
BEGIN - OK
BROADCAST 2.4OK (notes...)
BROADCAST FILE2.4OK (notes...)
BUMP - OK
*CANCEL - OK
CHECKPOINT - OK - one extra option (notes...)
CHKABORT - OK
CHKMSG - Unnecessary - use MONITOR CHECKPOINT
CLEARG - OK
CLEARGO - OK
CLOSE 3.1 OK
CLOSE LINK 1.2 Unsupported
COPY 1.8 OK (notes...)
COPY PROC 3.1 Mostly (notes...)
CREATE 2.3 Mostly (notes...)
CREATE GROUP 1.24 Mostly (notes...)
CREATEG 1.24 Unsupported
DEASSIGN 1.1 Unsupported
DEBUG 3.6 Replaced: SPY
DECREASE 2.3, 3.2Unsupported
DEFAULT 3.1 OK
DEFINE FIELD - Partial (notes...)
DEFINE FILE 2.3 Unsupported
DEFINE LINK 1.2 Unsupported
DEFINE PRINTER 2.5 Unsupported
DEFINE PROCESS 1.2 Unsupported
DEFINE PROCESSGROUP 1.2 Unsupported
DEFINE PUNCH 2.5 Unsupported
DEFINE REMOTE 1.2 Unsupported
DEFINE SESSIONGROUP 1.2 Unsupported
DEFINE STREAM 2.5 Unsupported
DELETE (PROC) 3.1 OK
DELETE FIELD - OK
DELETE GROUP 1.24 OK
DESECURE 1.1 Unsupported
DISCONNECT 2.5? OK - treated as a synonym for LOGOFF
DISPLAY (PROC) 3.1 OK (notes...)
DISPLAY EW 2.5 Unsupported
DISPLAY FIELD - OK (notes...)
DISPLAY FILE 3.1 Some different options and output (notes...)
DISPLAY GROUP 1.24 OK (notes...)
DISPLAY GTBL 3.7 Some different options and output (notes...)
DISPLAY RECORD 1.42 Unsupported (but see *RECINFO)
DUMP 1.12? 2.3Unsupported
DUMPG 1.24 Unsupported
EDIT 3.6 Differences (notes...)
ENABLE 1.7 Unsupported
ENQCTL 2.3 Unnecessary (no discontinuities)
EOD - OK
EOJ 2.5 Replaced: =UNHALT
FILELOAD 1.7, 1.28Unsupported
FLOD 1.7, 1.28Unsupported
FREE - OK (notes...)
HALT - OK (notes...)
IF - OK
IFAMXXXX 1.2, 1.3Unsupported
INCLUDE 3.1 OK
INCREASE 2.3, 3.2OK
INITIALIZE 2.3, 3.2, 3.7 OK (notes...)
LOGOFF/OUT - OK
LOGWHO - OK (notes...)
LOGxxx (others) 1.2 Very limited support (notes...)
*LOOK 2.5, 3.2Unsupported (but see LOOK PAGE)
*LOWER - OK
MODIFY 1.2 Unsupported
MONITOR various Various new and different options (notes...)
MORE - OK
MSG 2.5 Unsupported, (but see $EMAIL function)
MSGCTL 3.3 OK - less options (notes...)
NEW PAGE - OK
OFFLOAD 1.8 Unsupported
OPEN/OPENC 3.1, 1.24OK (notes...)
OPEN LINK 1.2 Unsupported
PRIORITY 2.1 OK (notes...)
PROCEDURE 3.1, 3.5OK (notes...)
REACTIVATE 2.5 Unsupported
REDEFINE FIELD - OK (notes...)
REGENERATE 1.8 Unsupported
RENAME FIELD - OK (notes...)
RENAME PROC 3.1 OK - no aliases (notes...)
REORGANIZE OI 3.2, 2.3, 1.28 From V3.0, not strict emulation however
RESET - OK (notes...)
RESET COMMAND 1.1 Partial (notes...)
RESTART 2.5 Unsupported
RESTORE 1.12? 2.3Unsupported
RESTOREG 1.24 Unsupported
SECURE 1.1 Unsupported
SETGRC - OK
*SLEEP - OK
*SNAP 2.5 Unsupported
START FILE 1.12 Unsupported
START SUBSYS 1.24 Unnecessary (subsystems do not require starting)
START (LINK etc) 1.2 Unsupported
STATUS (files) 1.8 OK (notes...)
STATUS (console) 2.5 Unsupported
STOP FILE 1.12 Unsupported
STOP SUBSYS 1.24 Unnecessary (see START)
START (LINK etc) 1.2 Unsupported
STOPUSER 1.12 Unsupported
TABLEB 3.7 Some different options and output (notes...)
TABLEC 1.41 Unsupported
TEST 3.6 Replaced: SPY
TIME - OK
TMASKUPDATE 1.1 Unsupported
TSS 1.1 Unsupported
*UPPER - OK
USE 2.8 OK
USE PROC 3.1 OK
USE $xxx 2.5 $PRINT only
UTABLE 2.2 Allowed as a synonym for RESET
VIEW - OK (notes...)
VIEW COMMAND 1.1 Partial (notes...)
VTAMXX 2.4 Unsupported (but see =SOCKET)
WARN 2.5 Unsupported
XREF 1.4 Unsupported
Z 3.2, 2.3, 1.28 OK
*ZAP 2.5 Unsupported

Top


Emulation of User Language Features

Emulation of statements

A key design principle of DPT was to handle UL as accurately as possible, so rather than list the individual statements with reasons for not emulating them, here are the few statements that are not emulated reasonably accurately. For the most part these statements are not emulated because they relate to inter-process communications.

See the User Language Reference for more details on small differences in the handling of statements, and also for some notes on the handful of DPT custom statements and some pre-installed custom $functions

Statement(Ref) Comments
CLOSE PROCESS 1.2 -
CONFIRM 1.2 -
CONFIRMED 1.2 -
CONTINUE 1.7 -
DECLARE MENU1.25 No menus - see later
END MENU1.25 No menus - see later
END UPDATE 1.7 -
FLUSH PROCESS 1.2 -
INVITE 1.2 -
ON FCC/MISSING...1.14 Compiles with warning - irrelevant at run time
OPEN PROCESS 1.2 -
PRINT ALL FIELD NAMES?Undocumented on M204 but unsupported anyway!
PREPARE MENU 1.25 -
POSITION file 1.2 -
QUERY PROCESS 1.2 -
READ MENU 1.25 -
RECEIVE IMAGE 1.2 -
RELEASE POSITION1.2 -
SEND ERROR 1.2 -
SEND IMAGE 1.2 -
SIGNAL PROCESS 1.2 -
TEST FOR ... 1.2 -
TRANSFER CONTROL1.2 -
UPDATE RECORD 1.7 -
WAIT 1.2 -


Full screen features

Pretty much all screen features are supported apart from MENUs. However, in such a presentation-oriented area various more or less cosmetic issues arise from the fact that DPT is not a 3270 emulator, and has its own front-end quirks.

In the IDE user's guide there is a special section on how User Language screen I/O is handled on the display. This also covers the conventions for the various 3270-style keyboard functions, plus other handy PC-style input controls.

Other non-presentational compatibility issues with screens are covered in the Language Reference.


Image features

On DPT, images can be read from, and written to, sequential files and the screen, but no other destinations (DB2, etc.). When transferring data between platforms there will often be problems with anything but string or packed data.

All "structural" image functionality, that is the complete range of item types, is supported. See also the notes in the language reference about compatibility etc.


$Functions

General comments

These are divided into 4 categories to describe the degree of emulation, as follows. At the time of writing at least 90% of the standard and math $functions are in category 1 or 2.
  1. Full support (or as close as makes no difference)
  2. Good support, with only DPT-irrelevant options missing (e.g. SORTKEY option of $VNUM)
  3. Unsupported, but may compile successfully and return dummy results depending on the value of the CSTFLAGS parameter 8 bit
  4. Unsupported and compilation fails with the "not linked in" message.
For $functions in category 2 and 3 some detailed discussion is given in non-obvious cases in the DPT language reference. The only $functions in category 4 are those concerning PQO, which the Model 204 manuals say are disallowed except in a PQO installation.

Standard functions

$Function (Ref) Comments
ACCT 1.1 OK (always returns user name)
ACCOUNT 1.1 OK (always returns user name)
ALPHNUM - OK
ARRSIZE - OK
ASCII 1.6 OK
BINARY 2.7 OK
BLDPROC - OK
CENQCT 2.2 Type 3
CHKMOD - OK
CHKPAT - OK
CHKPINF - OK 2
CHKSFLD - OK
CHKTAG - OK
CODE 1.27 Type 3
CURFILE - OK, but see also $CURDIR
CURREC - OK
C2X 1.6 OK (converts ASCII codes not EBCDIC)
DATE - OK
DATEP - OK
DATEJ - OK
DATECHG - OK
DATECHK - OK
DATECNV - OK
DATEDIF - OK
DAY - OK
DAYI - OK
DEBLANK - OK
DECODE 1.27 Type 3
DELG - OK
DSCR variousOK 2 (only AINSTU)
DSN 3.1,3.2 OK
DSNNUM 3.1,3.2 OK
ECBDGET -OK
ECBDSET -OK
ECBTEST -OK
ECFSTAT - Type 3
EDIT 1.27 OK 2
EFORMAT - OK
ENCRYPT 1.27 Type 3
ENTER 1.26 OK
ERRCLR - OK
ERRMSG 3.3 OK
FDEF variousOK
FLDLEN variousOK (always 0 or 8)
FLOAT 2.7 OK
FLOATD - OK
FLSACC 1.1 OK (always SRUA or null)
FLSCHK 1.1 OK (all access is allowed)
FSTERR 3.3 OK
GETG - OK
GETL - OK
GETP - OK
GRMLOC 1.7 Type 4
GRMNAME 1.7 Type 4
GRNLEFT 1.7 Type 4
GRNMISS 1.7 Type 4
GROUPFILES 1.7,3.1OK 2
HSH 1.27 OK (probably a different algorithm though)
HPAGE - OK
INDEX - OK
INCRG 1.26 OK
ITSOPEN 3.1 OK 2
ITSREMOTE 1.7 Type 4
JOBCODE 2.5 OK 2
LANGSPEC 1.5 Type 3
LANGSRT 1.5 Type 3
LANGUST 1.5 Type 3
LEN - OK
LOWCASE - OK
LSTFLD variousOK
LSTPROC 3.1 OK 2
MISGRP 1.7 Type 4
MISLOC 1.7 Type 4
MISNAME 1.7 Type 4
MISGNUM 1.7 Type 4
MISSTMT 1.7 Type 4
MOD - OK
OCCURS 1.42 OK (always 0 or -1)
ONEOF - OK
PACK - OK
PAD - OK
PADR - OK
POST -OK
RDPROC - OK
READ 1.25OK
READINV 1.25OK
READLC -OK
REMOTE 1.2 OK (always null)
REVERSE - OK
RLCFILE - OK
RLCREC - OK
RLCUID - OK
RLCUSR - OK
SCAN - OK
SCLASS 1.1 OK (always null)
SETG - OK
SETL - OK 2
SETP - OK
SLSTATS - OK
SNDX - OK
STAT 1.22 OK
STATUS - OK 2
STATUSD 2.5 OK 2
SUBSYS 1.43 OK 2
STRIP - OK
SUBSTR - OK
TCAMFHP 1.2 OK (always null)
TIME - OK
UNBIN 2.7 OK
UNBLANK - OK
UNFLOAT 2.7 OK
UNPACK - OK
UNPOST -OK
UNQREC 1.12 OK 2 (always -1)
UPCASE - OK
UPDATE - OK
UPDFILE 1.12 Type 3
UPDFLD 1.12 Type 3
UPDLOC 1.7 Type 4
UPDOVAL 1.12 Type 3
UPDREC 1.12 Type 3
UPDSTAT 1.12 Type 3
UPDSTMT 1.12 Type 3
UPDVAL 1.12 Type 3
USER - OK
USERID - OK
USRPRIV 1.1 OK (always allowed)
VERIFY - OK
VIEW - OK
VNUM 1.12 OK 2
WAIT -OK
WORD - OK
WORDS - OK
X2C 1.6 OK (converts according to ASCII not EBCDIC)

Math functions

Numeric precision is emulation issue number 2.7. In addition to any un-planned problems arising from differences between Model 204 and DPT, always bear in mind, as the UL manual says, that some of the routines used on the mainframe are not accurate to the full number of significant figures they return (i.e. some digits are meaningless). The functions used on DPT *are* accurate to the full extent of their return value. In most cases they have been left delivering the maximum possible precision, which is 16 or 17 significant figures, although $PI is an exception, since on M204 it is hard-coded as 15 sig fig, and DPT respects that.

When validating parameters, the limits specified in the UL manual are applied and the corresponding return value (usually zero) is set if they are breached. Notwithstanding this, most of the math functions just pass through to the standard ANSI C versions.

As for the ones not done in the table below, they are .. ahem .. left as an exercise in coding custom $functions for you if you need them. A tutorial document on this subject will hopefully appear at some point.

$Function (Ref) Comments
ABS - OK
ARCCOS 2.7 OK
ARCSIN 2.7 OK
ARCTAN 2.7 OK
ARCTAN2 2.7 OK
COS 2.7 OK
COSH 2.7 OK
COTAN 2.7 OK
ERF 1.26Type 3
ERFC 1.26Type 3
EXP 2.7 OK
GAMMA 1.26Type 3
IXPI 2.7 OK
LGAMMA 1.26Type 3
LOG 2.7 OK
LOG10 2.7 OK
MAX - OK
MIN - OK
PI - OK. (15 sf: ..8979)
RXPI 2.7 OK
RXPR 2.7 OK
SIN 2.7 OK
SINH 2.7 OK
SQRT 2.7 OK
TAN 2.7 OK
TANH 2.7 OK

Sirius functions

The full set of real Sirius functions is quite long - those guys are prolific! Emulation was started in DPT Version 2.0, and will be extended as time goes on. The following list should be up-to-date, but if not you can always issue the =FUNCLIST command at the terminal to see what's actually linked in to the system you're using.

A2E , ARR_FIND , ARR_INIT , ARR_MAX , ARR_MIN , BITAND , BITOR , BITXOR , COMMBG , COMMNDL , D2X , E2A , FAKEENT , HEXA , IHEXA , IMGINF , IMGOVL , LIST_CAPTURE , LIST_COPY_ITEMS , LIST_GLOBAL , LIST_GLOBAL_DEL , LIST_GLOBAL_LIST , LIST_MAXIL , LIST_PRINT , LISTADD , LISTADDI , LISTADJ , LISTCHK ,LISTCNT , LISTCPY , LISTDEL , LISTFIND , LISTFINDI , LISTFINDI_SUB , LISTILN , LISTIMG , LISTIMG_COPY , LISTINF , LISTINFI , LISTINS , LISTINSI , LISTLOC , LISTLUP , LISTMOVE , LISTNEW , LISTOVL , LISTOVLI , LISTREM , LISTREP , LISTREPI , LISTRST , LISTSAV , LISTSAVE , LISTSORT , LISTSRT , PROCCLS , PROCDAT , PROCGET , PROCLOC , PROCOPN , RANDOM , RANDOM_SEED , STRAND , STROR , STRXOR , SUBREP , X2D.

See also the more detailed notes in the language guide, which indicate the few places where the emulation is or may not be 100% accurate.

Top


Emulation of Database Features

Since very few of the M204 file and field attributes are emulated, this section does not list all the M204 features, as most would simply say "Unsupported". We can summarise quite simply that the only file-structural features that are present are: The DBA Guide has some more detailed information on this stuff, as do the Language Reference sections for DEFINE FIELD and CREATE FILE.

Top


Parameters

Notes on specific parameters follows each table, but here are some general points.

Validation

In the tables below, if a maximum and minimum are given it means the parameter is numeric. If it's a string value, the validation is specified as a pattern, so that for example "@/0-3(+)" means a string is required which starts with a letter and has a possible 3 unspecified characters after it. You may have to refresh your memory on pattern syntax!

Resettability

NR in the tables means the parameter is completely read-only, or in the case of file parameters not resettable after CREATE time. R means resettable using the RESET command. R* means the parameter can be changed, but where it's not just a case of issuing a RESET command. This category includes e.g. where the *LOWER command changes CASE, but also all the file usage "parameters" like BHIGHPG, which are really statistics. R** means the parameter is resettable using RESET, but can't be set to an initial value in the ini file. These parameters have iodev-specific defaults. Conversely there are some parameters, indicated with R***, which are only settable in the ini file, and can't be dynamically reset using the RESET command.

Bearing the above comment in mind, resettable parameters are always resettable by any user if at all. All commands on DPT are currently allowed by any user since the login password security feature is not supported.

Emulated M204 Parameters

ParameterMin-Max / patternDefault Reset?(Ref)Comments
ACCOUNT- - - 1.1 Unsupported
ACCTIM- - - 1.22Unsupported
ADDLVL- - - 2.1 Unsupported
AGExxxxx- - - 1.1 Unsupported
ALLOCPRIV- - - 1.1 Unsupported
ALTIODEV- - - 1.2 Unsupported
AMPSUBS- - - 1.7 Unsupported
ARETRIES- - - 3.2 Unsupported
ASIZE--- 3.2Unsupported (field defs are in table D)
ASTRPPG- - - 3.2 Unsupported
ATRPG- - R*3.2 Read-only: indicates current usage
AUTOSYS@/0-9(+)-R***1.24 OK (interactive thread types only)
BASECENT- - R***-OK
BEXTOVFL- - - 1.14Unsupported
BHIGHPG- - R*- OK
BLOWPG- - -3.2 Unsupported (not interesting)
BPGPOVFL- - - 1.14Unsupported
BQLEN- - R*-OK
BRECPPG1-1024256NR-OK
BRESERVE0-409617NR- OK
BREUSE0-10020NR-OK
BREUSED- - R*-OK
BSIZE1-2G5R*-OK
CACHE- - - 2.5 Unsupported
CASEUPPER,LOWERUPPERR*-OK
CAUDIT0-70R-(see note below) (2)
CECHO0-70R-OK (see note below)
CEECHO- - - 3.1 Unsupported
CENTSPLT0-99- R***- OK
CFRJRNL- - - 1.8 Unsupported
CFRLOOK- - - 1.22Unsupported (always effectively active)
CMSVERSN- - - 2.5 Unsupported
COMEND++ ?/R- OK (can not be reset with hex value)
COMPOPTbits0R- (Sirius parameter). Only X'01' and X'02'
COMSTART++/?R- OK (can not be reset with hex value)
CPMAX11NR1.8 Always 1
CPSORT- - - 1.2 Unsupported
CPTIME0-any1 R- OK, (see note below)
CPTO-1-any5 R- OK (plus custom value of -1)
CPTQ- - - 1.2 Unsupported
CPUSLICE- - - 2.1 Unsupported
CRETRIES- - -1.41 Unsupported
CRFSCHNL- - - 1.2 Unsupported
CRIOCHNL- - - 1.2 Unsupported
CSIZE- - - 1.41 Unsupported
CURCLASS- - - 1.1 Unsupported
CURFILE- - R* 3.1 See also DPT custom CURDIR later
CURLOC- - - 1.7 Unsupported
CURPRIV- - - 1.1 Unsupported
CURRALVL- - - 1.1 Unsupported
CURREC- - R* -OK
CURRLVL- - - 1.1 Unsupported
CURSLVL- - - 1.1 Unsupported
CURULVL- - - 1.1 Unsupported
CUSTOMvarious0 R***1.11Only settings 1-4
DACTIVE- - R*-OK
DB2PLAN- - - 1.2 Unsupported
DB2POINT- - - 1.2 Unsupported
DB2QUITE- - - 1.2 Unsupported
DB2THRD- - - 1.2 Unsupported
DEBUGUL- - - 3.6 Unsupported
DEFCENT- - R- OK
DHIGHPG- - R*- OK
DKUPDTWT- - - 1.8 Unsupported - always zero
DPGSRES0-327670NR1.21OK
DPGSUSED- - R*- OK (and see note below)
DRESERVE0-10015NR- OK
DSIZE2-2G15R*- OK
DUFILES- - - -OK
DUPTERM- - - 1.2? Unsupported
DVADD- - - 1.2 Unsupported
EDIT- - - 3.6 Unsupported
ENQRETRY0-2553R-OK
EOVFLADD- - - 3.2 Unsupported
EOVFLDEL- - - 3.2 Unsupported
ERASE- - - 3.6 Unsupported
ERMXany5 R 3.3 OK (see note below)
ERRLEN- - - 3.3 Unsupported - always whole message
ERRSAVE0-10004R3.3 OK
EXCPVR- - - 2.5 Unsupported
EXTNADD- - R*- OK
EXTNDEL- - R*- OK (only affected when whole records are deleted)
FICREATE@- - 3.2 OK-ish. Letters from A onwards. Used internally.
FIFLAGSvarious0NR-OK (some values)
FIFORMAT- - - 3.2 Unsupported
FILEMODL-0- 1.14Replaced - see similar FMODLDPT later
FILEORG0 or 360NR3.2, 1.14Only entry order and RRN are emulated
FISTATvarious0R*-OK
FITRANS- - - 3.2 Unsupported
FIXSIZE- - - 2.2 Unsupported
FLUSH- - - 3.6 Unsupported
FOPT- - - 3.3 Unsupported (but see RCVOPT)
FRCVOPT- - - 1.21Unsupported (but see RCVOPT)
FREESIZE- - - 3.2Unsupported
FSATTN- - - 3.6 Unsupported (always effectively the 'escape' key)
FSOUTPUT- - - 3.6 Unsupported - always effectively on
FSTRMOPT- - - 3.6 Unsupported
FVFPG- - - 1.41Unsupported
HASHKEY- - - 1.14Unsupported
HDRCTL- - - 3.6 Unsupported
HIGHSORT- - - 1.14Unsupported
HTLEN- - - 3.7 Unsupported (but see DPT custom OUTFLAGS later)
IFAMBS- - - 1.2 Unsupported
IFAMCHNL- - - 1.2 Unsupported
INCCC- - - 3.6 Unsupported
INCSLICE- - - 2.1 Unsupported
INMRL- - - 3.6 Unsupported
INPUT- - NR 1.2 OS file name or IP address
IODEVAny positivevariousR 1.2 OK - (see note below)
IOSLICE- - - 2.1 Unsupported
IVERIFY- - - 2.5/3.7?Unsupported
JESID- - - 2.5 Unsupported
JOBNM- - - 2.5 Unsupported
KOMMOPT- - - 1.7 Unsupported
LANGFILE- - - 1.5 Unsupported
LAUDIT0-70 R - (see note below)
LAUDPROC- - - 1.8Unsupported (whole proc name appears)
LCPDLST- - - 2.2 Unsupported (the system is ALL C!)
LDKBMRAW- - - 2.2 Unsupported (too advanced)
LDKBMW- - - 2.2 Unsupported (too advanced)
LDKBMWND- - - 2.2 Unsupported (too advanced)
LECHO0-70R-OK (see note below)
LEECHO- - - 3.6 Unsupported
LENQTBL- - - 2.2 Unsupported
LFSCB- - - 2.2 Unsupported
LFTBL- - - 2.2 Unsupported
LGTBL0-2G1KR-OK
LHEAP- - - 2.2 Unsupported
LIBUFF- - - 1.2?, 3.6Unsupported
LINEEND- - - 3.1, 3.6Unsupported
LINENO- - - 1.2 Unsupported
LITBL- - - 2.2 Unsupported
LNTBL- - - 2.2 Unsupported
LOBUFF- - - 3.6Unsupported (but see DPT custom OUTFLAGS later)
LOCATION- - - 1.7 Unsupported
LOGADD- - - 1.1 Unsupported
LOGFAIL- - - 1.1 Unsupported
LOGONENQ- - - 1.1 Unsupported
LOGTRY- - - 1.1 Unsupported
LOUTPB- - - 3.6 Unsupported
LPFORCE- - - 1.1 Unsupported
LQTBL- - - 2.2 Unsupported
LRETBL- - - 2.2 Unsupported
LRUPG- - - 2.2 Unsupported
LRUTIM- - - 2.2 Unsupported
LSECHO0-50R-OK (see note below)
LSERVER- - - 2.2 Unsupported
LSERVPD- - - 2.2 Unsupported
LSTBL- - - 2.2 Unsupported
LTTBL- - - 2.2 Unsupported
LVLTRC0-10 R - OK
LVTBL- - - 2.2 Unsupported (but see DPT custom LVARTBL later)
LXTBL- - - 2.2 Unsupported
MAXBUF0-2GvariesR***2.2 Slightly different meaning - see memory management
MAXHDR0-10005R-OK (see note on resetting below)
MAXINCL0-405R-OK
MAXSPINS- - - 1.7 Unsupported
MAXTIME- - - 2.5 Unsupported
MAXTRL0-10005R-OK (see note on resetting below)
MAXUD- - - 2.2 Unsupported
MBSCAN-1-2G0R-OK
MCNCT0-2G0R-OK
MCPU0-2G0R-OK (see note in "statistics" later)
MDKRD0-2G0R-OK
MDKWR0-2G0R-OK
MINBUF- - - 2.2 Unsupported
MODEL1-255992R3.6 See note below
MOUT0-2G0R - OK
MPOPTS- - - 1.7 Unsupported
MSGCTLbits0 R 3.3Some differences (see note below)
MSTRADD- - R-OK
MSTRDEL- - R-OK
MUDD0-2G0R-OK
MVFPG- - - 1.41Unsupported
NBKPG- - - 3.6 Unsupported
NDCBS- - - 2.5 Unsupported - only limited by OS
NECBS0-20000 - -OK
NDIR- - - 2.5 Unsupported - only limited by OS
NFILES- - - 2.5 Unsupported - only limited by OS
NGROUP- - - 1.24Unsupported - only limited by memory
NJBUFF- - - 1.8 Unsupported
NMPSUBS- - - 1.7 Unsupported
NORQS0-100010R-OK - resettable too!
NOTERM- - - 1.2? Unsupported
NOTHREAD- - - 1.2? Unsupported
NOUTBUF- - - 2.5 Unsupported
NRMTFILE- - - 1.7 Unsupported
NRMTLOCS- - - 1.7 Unsupported
NSERVS- - - 2.1, 2.2Unsupported
NSUBTKS- - - 2.1 Unsupported
NUMBUF- - - 2.2 Unsupported
NUSERS 1-9999R***- OK
OIDEPTH- - - 3.2Unsupported - btrees are held at field level
OILEAVES- - R*3.2 As IODEPTH
OILPACT- - - 3.2Unsupported
OINBYTES- - - 3.2Unsupported
OINENTRY- - - 3.2As OIDEPTH
OINODES- - - 3.2 As OIDEPTH
OPENCTL- - - 1.1 Unsupported
OPSYS- - NR2.5 Textual value instead of a number
OUTCCC- - - 3.7 Unsupported (but see DPT custom OUTFLAGS later)
OUTLPP-1-32KvariesR**3.6OK (and can be reset on any IODev)
OUTMRL0-32K0R3.6Stands in for some others too (see also OUTFLAGS)
OUTPNOany- R*- OK
OUTPUT- - NR 1.2 OS file name or IP address
OVFLADD- - - 1.14Unsupported
OVFLDEL- - - 1.14Unsupported
PAGE- - - 3.6 Unsupported
PAGEFIX- - - 2.5 Unsupported
PAGESZ- - NR 2.3OK (System level not file, always 8192)
PDSIZE- - - 3.1 Unsupported
PDSTRPPG- - - 3.1 Unsupported
PGSEP---3.6, 2.4 OK (all thread types)
POLLNO- - - 1.2? Unsupported
PQOOPT- - - 1.7 Unsupported
PQOSYS- - - 1.7 Unsupported
PRCLDEF- - - 1.1 Unsupported
PRIOMAX- - - 2.1 Unsupported
PRIORITY- - NR 2.1OK
PRIVDEF- - - 1.1 Unsupported
PROBECTL- - - 2.5 Unsupported
PROMPTvariousX'09'R**3.6 OK - see note below
RCVOPTBits3R***1.8, 1.21OK-ish, but mostly custom bit settings
READLVL- - - 1.1 Unsupported
RECSCTY- - - 1.1 Unsupported
RECSECID- - - 1.1 Unsupported
RESCURR- - - 2.2 Unsupported
RESHIGH- - - 2.2 Unsupported
RESSIZE- - - 2.2 Unsupported
RESTHRSH- - - 2.2 Unsupported
RETRVKEY- - - 3.6 Unsupported (unnecessary in the custom IDE)
RPTCNT- - - 1.22 Unsupported
SCHDOPT- - - 1.7 Unsupported
SECTRLOG- - - 1.1 Unsupported
SECTY- - - 1.1 Unsupported
SELLVL- - - 1.1 Unsupported
SEQOPT0-2550 R 2.3OK, but is a a file level parameter
SERVACTV- - - 2.2 Unsupported
SERVSIZE- - - 2.2 Unsupported
SIOSLICE- - - 2.1 Unsupported
SLICEMAX- - - 2.1 Unsupported
SMFLORN- - - 2.5 Unsupported
SMFSLRN- - - 2.5 Unsupported
SMFSVC- - - 2.5 Unsupported
SMPLTIM- - - 1.22Unsupported
SNAPCLS- - - 2.5 Unsupported
SNAPCTL- - - 2.5 Unsupported
SNAPDEST- - - 2.5 Unsupported
SNAPID- - - 2.5 Unsupported
SNAPLIM- - - 2.5 Unsupported
SNAPPDLS- - - 2.5 Unsupported
SORTKEY- - - 1.14Unsupported
SPCORE- - - 2.2 Unsupported
SPILLADD- - - 1.14Unsupported
SPILLDEL- - - 1.14Unsupported
SQLBSCAN- - - 1.3 Unsupported
SQLBUFSZ- - - 1.3 Unsupported
SQLCNVER- - - 1.3 Unsupported
SQLFILE- - - 1.3 Unsupported
SQLIQBSZ- - - 1.3 Unsupported
SQLLPLIM- - - 1.3 Unsupported
SRVSLICE- - - 2.1 Unsupported
STEPNM- - - 2.5 Unsupported
STORCUR- - - 2.2 Unsupported
STORINIT- - - 2.2 Unsupported
STORMAX- - - 2.2 Unsupported
SUB0-54R- OK
SVIOMAXT- - - 2.1 Unsupported
SYSDATE- - - 2.5 Unsupported
SYSDINFO- - - 2.5 Unsupported
SYSID- - - 2.5 Unsupported (but see DPT custom SYSNAME later)
SYSOPT- - - 2.5Unsupported
SYSTIME- - - 2.5 Unsupported
TABSP1-32K10R- OK
TCPNAME- - - 2.5 Unsupported (but see DPT custom SYSPORT later)
TEMPCUR- - - 2.2 Unsupported
TEMPHIGH- - - 2.2 Unsupported
TEMPMAX- - - 2.2 Unsupported
TERMBUF- - - 2.2 Unsupported
TERMCPS- - - 3.6 Unsupported
TERMID- - NR1.2 Same as INPUT/OUTPUT on socket threads only
TERMOPT- - - 3.6 Unsupported
TIMELEF- - - 2.5 Unsupported
TIMEOUT---2.5Always effectively 0
TIMESTOP- - - 2.5 Unsupported
TIMESVC- - - 2.5 Unsupported
UDDCCC- - - 3.6 Unsupported (but see DPT custom OUTFLAGS later)
UDDLPP-1-32K56R- OK
UDDRFM- - - 3.6, 2.8Unsupported
UPDTID0... - NR - OK
UPDTLVL- - - 1.1 Unsupported
UPRIV- - - 1.1 Unsupported
USERID@/0-29(+)-NR1.1 OK-ish, but no automatic security checks applied
VDP0-150R- OK
VERIFY- - - 2.5/3.7?Unsupported
VERSION- - - 2.5 Unsupported (but see DPT custom VERSDPT later)
VLEN0-25520R- OK
VMFSCHNL- - - 2.5 Unsupported
VMIFCHNL- - - 2.5 Unsupported
VMIOCHNL- - - 2.5 Unsupported
VTAMNAME- - - 2.4 Unsupported
VTAMNTO- - - 2.4 Unsupported
VTGCSSRV- - - 2.4 Unsupported
VTYPEvariousSTRINGR- OK
WAITSCAN- - - 2.1 Unsupported
WAITTIME- - - 2.5 Unsupported
XMEMOPT- - - 2.5 Unsupported
XMEMSVC- - - 2.5 Unsupported

Notes on emulated M204 parameters

Parameter categories in the VIEW command
Parameters are still viewable by category, but there are no CWAIT and UTABLE categories, for reasons discussed elsewhere. LGTBL is now a USER parameter, as are the other remaining UTABLE parameters, MAXHDR, MAXTRL and NORQS. All the other L?TBL type parameters have been dropped. UNSUPPORTED is a special category simply listing unsupported Model 204 parameters.

Maximums, minimums, defaults etc.
These are not always the same as on Model 204.

Audits & Echoes
The set of parameters CAUDIT, CECHO, LAUDIT, LECHO, LSAUDIT, LSECHO is emulated, but given the nature of procedure and terminal handling, may behave slightly differently in some circumstances. The new parameters LLECHO and LLAUDIT (logical line) add a further distinction, being roughly equivalent to Lxxxxx, but with comments and blank lines taken out. To help clear this up at run time, all the echoes and audits are prefixed with the parameter that has triggered them, e.g. "LECHO: BEGIN".

CPTIME
Unlike on Model 204, resetting this parameter has an effect even if no pseudo-user was initiated at start-up time. If you reset CPTIME from zero to a non-zero value, the checkpointing daemon is simply started. Likewise if you set it to zero, the daemon logs off and automatic checkpointing ceases. When changing from one positive value to another, the new value takes effect next time the daemon wakes up.

DPGSUSED
"Table D" pages, as we know, get used for all sorts of things. On DPT DPGSUSED is recorded as a whole, but also for each page type in the shape of parameters DPGS_1, DPGS_2, etc. If you do a VIEW TABLES command you can see all these and get a simple description of what each one means.

ERMX
On Model 204, if the error count reaches ERMX, the user is restarted "softly", which means it's often a good idea to cancel a compilation at the new page prompt. DPT softens this action even further (there never seemed anything soft about a M204 soft restart anyway), and it behaves much the same as if attention had been pressed. This means any request being compiled is aborted, and the user is returned to command level. Unless they're in a subsystem, in which case the error procedure is invoked with error global value ATN. The default is 5 and not 30 like M204 because of the fact that error messages don't invoke paging, so the full quota of messages always gets listed. (Compiler messages after the first handful are usually unreliable anyway aren't they...).

IODEV
This parameter is resettable, to cater for the possible desire of User Language applications to invoke different code paths depending on the value of the parameter. For example to display a confirmation screen if a program is being run on a screen-based thread, but assume a default response on a BATCH2 or other robot thread:

IF $VIEW('IODEV') EQ 7 THEN
    READ SCREEN CONFIRM
    %CONFIRMED = (%CONFIRM:PFKEY EQ 3)
ELSEIF $VIEW('IODEV') EQ 15 THEN
    %CONFIRMED = ($READ('Really delete record (enter ''Y'')?') EQ 'Y')
ELSE
    %CONFIRMED = 1
END IF

IF %CONFIRMED THEN
    DELETE RECORD
END IF

Note that there is absolutely no internal effect of resetting IODEV, so for example if a program running on an IODev7 thread resets its IODEV parameter to 3, subsequent READ SCREEN statements will invoke the full screen interface as usual. But a program running on a real IODev 3 (file-based thread) clearly cannot, and will not invoke full-screen processing.

MODEL
On DPT this parameter only affects the size of User Language screens, and is unrelated to both the editor, and OUTMRL as used in printed output (which in any case is handled differently).

Values of 1 to 5 cause the size of a screen "panel" to take the appropriate values listed in the Model 204 manual for those 3270 models. You can then define screens which contain items positioned anywhere within those boundaries, and they will work as normal, taking into account the general screen handling characteristics of the DPT client front end.

If you want to be creative it is also possible to do something similar to the Sirius "Model 6" setting. On DPT you specify a value in the form CCCRR, where CCC is the number of columns and RR is the number of rows. So for example if you had a very large monitor and a very small font installed, the maximum value of 25599 would allow you to generate some very detailed UL fullscreen displays indeed. The value 8023 would just cause the same behaviour as the default of 2.

MSGCTL
The MSGCTL parameter is user-specific on DPT instead of system-wide, meaning that each user can suppress all terminal messaging from their thread if required, without issuing lots of and MSGCTL commands. It is therefore something of a hybrid in functionality between M204's MSGCTL and DEBUGUL (which is not used). If the subsystem message-suppression options are used, they cause a hidden MSGCTL command to be issued when entering and leaving a subsystem.

There is a DPT custom switch bit, X'20' (32), which can be added to any other value. This causes audited messages to be accompanied by the procedure name and line number, as they normally are on the terminal. It can be useful if for some reason terminal messages are suppressed (e.g. in an APSY), or if the failing code is being run by a daemon, in which case looking at the audit trail is more convenient than browsing the daemon's output file.

PROMPT
The 4 bit of this parameter, and to a lesser extent the 1 bit, is puzzling, and it does not seem fully clear how or why it works on Model 204. However, the rule on DPT is that whenever a dummy string, of any type (?&, ??, ?$), results in a terminal read, the display of the dummy string name is controlled by the 1 bit of PROMPT. If the bit is off, the user is expected to just know that they have to enter a dummy string value at that point, so you would think it should always be left on on an interactive IODev. (Although perhaps a more descriptive UL-generated prompt might have been PRINTed beforehand). In any case, whether the dummy string originated at command level or inside a procedure seems irrelevant here, and the 4 bit of PROMPT is simply ignored. The distinction between command-level and in-procedure originated dummy strings is provided however by the SUB parameter, controlling whether to process dummy strings at all, and also the LSECHO/LSAUDIT parameters, which control the echoing of lines which experience dummy string substitutions.


"Special" VIEWable I/O Parameters

These are treated to all intents and purposes exactly the same as normal parameters - who knows why they aren't listed as such in the M204 manuals. DPT treats the file-related ones as fully paid-up file parameters, holds them in the FCT, and shows them when you do a VIEW FILE or VIEW FPARMS. The rest are regarded as system parameters, and are included in the output from VIEW SYSTEM.

ParameterMin-Max / patternDefault Reset?(Ref)Comments
FIWHEN--R*-OK
FIWHO--R*-Contains user id not terminal
DTSLUPDT--R*-OK
DTSLDKWR--R*-OK
DTSLCHKP--R*-OK
DTSLRCVY--NR-OK (start of last attempted recovery!)
DTSLRFWD---1.8Unsupported
DTSLBOPR---1.8Unsupported


Custom DPT Parameters

ParameterMin-Max/patternDefault Reset?Comments
ATRFLD0-64K-R*Number of fields defined to a file
AUDCTLbits10R***See below
AUDKEEP0-any3R***Old generations of the audit file to keep
BTREEPAD0-81000R***See Analyze command
BUFAGE0-any600RSee below
CODESA2E/256(+)see belowR***See below
CODESE2A/256(+)see belowR***See below
CSTFLAGS32 bits0RSee below
DPGS_X0-any0NRSee standard DPGSUSED comment above
EACTIVE0-any-R*See below
FMODLDPT0-11R*See Numeric values in files
FUNNDAEMany1RSee below
ILACTIVE0-any-R*See below
LOADxxxx---See below
LVARTBL0-any100KRRelated to the unused L?TBL
MAXRECNO0-2G16777215RRecs before table B is considered "full"
NCPUS1+-NRSee below
OSNAME*-NRView-only file parameter showing the OS file name (DSN)
OUTFLAGSbits0RSee below
PRSUFFIX"/0-1(!.)/0-10(@,#)"".txt"RSee below
RETCODEany0RSee below
RTTRACEbits0R*See below
SPYFLAGSbits0R*See below
SPYMODE0-30R*See below
SRVSTPWT1-360020R***Windows service stop wait hint seconds
STRINGMAX255-2G255RSee below
STRINGRSV0-10RSee below
SYSNAME "@/1-29(+)""DPToolkit" R***See system config options
SYSPORT -1-6553513204R*See socket threads
VERSDPTV...variesR*Analogous to M204's
WEBCONTO1-605RSee below
WEBDMINI*-R***See below
WEBDMLGN*-RSee below
WEBPCURTany0RSee below
WEBEXTN*.dptwRSee below
WEBFLAGSbitsX'00001000'RSee below
WEBHOME*index.htmlRSee below
WEBNDAEM0-any0RSee below
WEBPORT-1-65535-1R*See below
WEBPMAXany-1RSee below
WEBPMAXTany-1RSee below
WEBPRDSN*WEBPROCRSee below
WEBPROC*WEBPROCRSee below
WEBROOT"@*"-R***See below
WEBSSI0-any0RSee below

Notes on custom DPT parameters

AUDCTL:
The bits in this parameter control various aspects of the columnar layout of the audit trail, with bits enabling columns as follows:

If the X'01' bit is not set, the date is printed once at the top of the file.

BUFAGE:
This parameter controls a pseudo-user (daemon), similar to the familiar checkpointing daemon, which wakes up periodically to perform some task. In this case the daemon ID used is PST_T. As with CPTIME, the main meaning of the parameter is the interval in seconds between wake-ups, with zero indicating the facility is turned off. In this case the task performed is to put in some work tidying up the disk buffer pool.

What happens when the buffer-tidying daemon wakes up is that it looks for all buffer pages older than BUFAGE seconds, that aren't currently in active use by any threads, and aren't dirty. All such pages are deleted from the buffer pool, freeing up the physical memory they occupy. On a quiet system therefore, buffer memory use should become very small after a maximum of (BUFAGE x 2) seconds. This is behaviour you probably don't usually want in a development environment, which is why the default value for the parameter is quite large. The tidy-up mechanism can in any case be invoked manually, using the =BUFFTIDY command.

As with CPTIME, resetting this parameter on DPT is effective even if the value was zero in the start-up parameters. In other words, a daemon is initiated if one isn't active already. Otherwise the change takes effect next time the daemon wakes up.

CODESA2E, CODESE2A
These two parameters hold the code pages which are used to perform the conversions in DPT's character-set related $functions such as
$EBCDIC, and file loading tools. The supplied default tables are based on the "EBCDIC 500" (international EBCDIC) and "Windows-1252" ASCII code pages, translated via Unicode. This scheme gives a successful conversion in 224 out of 256 characters, including all likely textual characters in typical applications. The default convention is that in the remaining 32 cases, a period character in the target character set is the result.

You can set your own code pages if you like, for example to use other EBCDIC and/or ASCII table versions, or to make the conversions performed by $ASCII and $EBCDIC reversible for all 256 values, or perhaps to perform entirely custom character coding/decoding. These parameters can only be reset by user 0 at startup time (parms.ini file), and must both be strings of length 256. Generally you would supply values in hex format, because of the awkwardness of various control characters like newlines and tabs. For example:

CODESA2E = X'000102030405060708090a0b0c0d0e0f10111213141516 ... etc.

Note: Viewing these parameters in their stretched-out form is not very easy on the eye, so the supplied DEMOPROC contains a short UL request which $VIEWs the values and tabulates them nicely.

CSTFLAGS
This system-level parameter is a collection of bit-settings controlling general system behaviour, but mainly concerned with custom features like $functions, plus the set of DPT commands and UL statements that are not Model 204 standard. Each bit disables some kind of custom processing, so that a value of X'FFFF' is the "strictest" setting as regards Model 204 compatibility. CSTFLAGS can be reset dynamically or in the ini file.

EACTIVE
This parameter is a sort of cross between Model 204's DACTIVE and EHIGHPG, reflecting the different implementation of "Table E" on DPT as a non-contiguous area.

FUNNDAEM
The number of
$function-support daemons to keep running at any time. If this parameter is non-zero the daemons start automatically when the system starts. If you reset it during a run the daemons adjust their numbers automatically to match. If daemons crash, (or log off - you could tell one of them to issue a LOGOFF command an it would comply), they will respawn as required.

The number of these daemons you need will be dependent on what you intend to to with them, but one or two ought to be enough. As a rule it is a better idea to spawn your own dedicated daemon thread using $SPAWN or =SPAWN for anything that's going to take a significant amount of time. That leaves the $function daemons to take care of small quick requests, which is the whole reason they exist.

ILACTIVE
This parameter is much like Model 204's DACTIVE. It indicates the page number in "table D" currently being used to build inverted list master records.

LOADxxxx
This group of parameters controls various aspects of the processing related to data loads and unloads. This means plain deferred-update loads (STORE RECORDS statement), but also commands such as REORGANIZE, =LOAD and some variations of REDEFINE FIELD, which invoke the same DBMS routines under the covers.

  • LOADCTL: Miscellaneous control flags [default=0]
    Bit settings as follows:

  • LOADDIAG: Run-time diagnostics level [default=0]
    Specifies the amount of diagnostic detail sent to the audit trail. Valid settings are: If this parameter is left at zero, the default level of diagnostics varies depending on the operation currently being performed. For example single-step deferred update processing defaults to level 4 (detailed), whereas most others including REDEFINE and fast loads/unloads default to level 1 (minimal).

  • LOADFVPC: Field-value pairs per chunk [default=0]
    Used for diagnostics and testing. Setting this to a small positive value forces DPT to build indexes in lots of tiny chunks instead of its usual more-or-less intelligent approach based on memory availability (see LOADMEMP). This is a quick way to find out the point where OS file handles will be exhausted during the merge phase (see LOADMMFH).

  • LOADMEMP: Target real memory usage percent [default=75]
    Affects processes which attempt to achieve optimum performance by building data structures in physical RAM. More is almost certainly better. The valid range of settings is 5 to 95.

  • LOADMMFH: Merge - max OS file handles [default=256]
    Specifies the number of chunk files to open concurrently during the merge phase of an index build. If there are more chunks, DPT performs an extra merge pass over some or all of the sorted files, in groups of this size, until few enough remain for the final table-D-updating pass. This extra processing is efficient and not a huge overhead, but it's still an overhead so if you have a load which uses say 1000 chunks, and a machine/OS you know will have 1000 OS file handles free, increasing LOADMMFH is worthwhile. On extremely restricted platforms reducing this parameter would be how to stop "insufficient file handles" error messages.

  • LOADTHRD: Parallel-processing threads [default=1]
    Affects fast loads and unloads, reorgs, and single-step deferred update processing. During an unload (=UNLOAD command or phase 1 of a REORG command) all file areas can all be extracted in parallel. During a load (=LOAD command or phase 2 of a REORG command) the field definitions and data are loaded on their own but indexes can be loaded in parallel. During single-step deferred update processing the final index load phase can be done in parallel for all fields, except ones defined with the NO MERGE attribute.

    The default for LOADTHRD is 1, i.e. no parallelism. This is because the fast unload and load processing is highly CPU-efficient and therefore usually IO-bound, meaning that on storage hardware with no parallel processing support (typical at the time of writing) trying to parallel process is counter-productive. It results in the disk head having to keep moving between 2 (or 4 etc.) work locations rather than making a single relatively smooth pass across the file sectors. LOADTHRD can be set up to the number of CPUs on the host machine, but is intended for users with fancy storage hardware like RAID or solid state.

    Note that DPT does not currently support files made up from several datasets (which could be on separate disks) like Model 204 does. However, using multiple user threads to load data into a group where each member resides on a different disk has been shown to be beneficial on a multi-CPU machine.

    NCPUS: Number of CPUs on host machine [read-only]
    This system parameter might be useful to application programs under certain circumstances. DPT makes occasional internal use of parallel processing, for example during file unloads and loads, and there is no need for user code to worry about this issue then. However you might have an application doing some heavy number crunching that was CPU-bound for long periods, in which case you could consider
    $SPAWNing or $COMMBGing one or more new threads to help out if $VIEW('NCPUS') > 1.

    OUTFLAGS
    This parameter initially sprung from a (probably misguided) attempt to consolidate several very similar M204 parameters into one, namely OUTMRL. It may be removed in a later release if people want to go back to OUTCCC, HTLEN, etc.

    Needless to say losing 4 whole parameters, however much they duplicate each other's functionality, is bound to lose at least one piece of non-trivial control. And indeed, one example is the ability to turn off line spills with OUTCCC=0. However, it didn't seem right to re-introduce OUTCCC just to use its kluge setting, so OUTFLAGS was born. As it's turned out, having somewhere to hold a variety of output-control switches is quite handy, and in that respect OUTFLAGS performs a similar kind of function as PROMPT does for line input.

    The 1 bit
    activates the Model 204 OUTCCC=0 behaviour, namely that once OUTMRL has been reached, a line can not be extended any more with further terms on a PRINT statement, or a continuation of a previous statement that ended with "...". This setting also kicks in when for example an AT specification is less than the current print position on the line.

    The 2 bit
    tells the system not to insert a hyphen and line-end sequence (i.e. CRLF on Windows) when writing past the end of the line. This behaviour is intended to provide the ability to write continuous "non-record-style" data to a file by extending a single line indefinitely with "PRINT ...". Because in this mode there is no "left margin" of a notional output page, TAB has no effect, and works the same as WITH.

    The 4 bit
    is custom DPT functionality, and controls whether partially-filled pages are padded out with blank lines before actually throwing the new page. On interactive devices like line-mode telnet and the IODev7 client, doing so would usually be unhelpful. On IODev3 or user 0, it might be more handy. Note that if there are UL trailers defined, pages are always padded anyway. Conversely if OUTLPP/UDDLPP is set to 0 or -1 no padding is ever done, since the page length is undefined. At other times on all device types the default is off - no padding - which is the most logical behaviour, and the main reason this control bit was introduced.

    PRSUFFIX
    Assumed file extension of procedures, unless overridden on the ALLOCATE command. The slightly complicated validation pattern given in the above table is intended to ensure valid Windows file extensions are used. It is restricted for simplicity to a single optional full stop, followed by up to 10 alpha or numeric characters, but no special characters. This pattern allows for a null string and (surely!) all realistic file extensions.

    Note that to reset PRSUFFIX to a null string you can either use the C'' syntax, or give it as a stand-alone dot, which is taken to be the same thing since Windows file names can't end with a dot. Null PRSUFFIX would be useful to access OS files which have no extension, or simply if you prefer to always see and type the file extensions. It might be more usual to do that with a per-file override rather than the main parameter though..

    RETCODE
    This "parameter" is provided as a potentially more convenient access path to the system-wide value traditionally maintained by the $JOBCODE function.

    RTTRACE, SPYMODE, SPYFLAGS
    These parameters are really just control switches used by the UL evaluator, and can only be set by the SPY command. They are made viewable for interest.

    STRINGMAX
    This parameter controls the longest string that the system will accept. The default is 255, in other words the same as Model 204. STRINGMAX is consulted internally in a number of situations, as follows:

    Increasing the value of STRINGMAX is how applications on DPT can get access to internal objects of arbitrary length, such as data POSTed from HTML forms, or from the LOOK PAGE statement. It also removes the need for a Sirius-style "longstring" object type.

    Note that the idea of variable-length strings has not been extended, despite the temptation, to STRING and ORDERED CHARACTER fields in files, which are still stored with a length byte, and therefore limited to 255-character string values. Extra-long string values used in UL database access statements will either cause run-time errors, or truncate depending on the situation.

    STRINGRSV
    This parameter controls whether User Language STRING variables allocate memory for their entire potential length at compile time, or initially take a minimal allocation and expand at run time when they are populated. The default of zero means expand at run time.

    Setting STRINGRSV to 1 would give Model 204-like behaviour in the sense that if a request compiles there may be less chance of memory problems at run time. However, the underlying string-manipulation facilities are designed to work best with the default setting, and STRINGRSV=1 is unlikely to be helpful in many situations, if any.

    WEBxxxx
    The following bunch of parameters was added in version 2.0 for controlling the web server functionality, and all have the prefix 'WEB'.

    WEBCONTO
    Quiet web connections are timed out (closed) after this number of seconds. Browsers will sometimes make a connection and speculatively leave it open after displaying a complete page, to cater for the user requesting more content from the same server. DPT colludes with this for WEBCONTO seconds but no more.

    In other situations a browser may send part of a request message before giving up or being prematurely closed by the user. DPT will wait at the break in the incoming message stream for WEBCONTO seconds before deciding that no more is going to arrive. Just in case the browser is still there it is sent a HTTP 408 response before the socket is closed.

    WEBDMINI
    The name of the procedure run in WEBPROC when the first server daemon starts (a similar idea to M204 subsystem processing where the initialization procedure is run once when the subsystem starts). Only the first daemon runs this procedure, and if WEBNDAEM (the number of daemons) is more than 1, the others wait till the init proc has been run before logging on (at which point they'll run WEBDMLGN - see below).

    The init proc would be a good place to put ALLOCATE commands for web-related files which will be required by OPEN commands in the login proc. It would also be perfectly reasonable to leave WEBDMINI null and just have everything initialized by user 0.

    Note that a common convention is for user 0 to perform system initialization work, and often the web parts of an application will require this initialization to be complete before they log on. For example user 0 allocates some general-purpose files which are also incidentally accessed by web code and therefore should be opened in the daemon login proc. In such cases the daemons can be held back by leaving WEBNDAEM set to zero and then having user 0 reset it when it has completed initialization. (This is how the demo system is configured).

    WEBDMLGN
    The name of the procedure run in WEBPROC when server daemon users start up their sessions. This is the place to put file OPEN commands etc. to save them having to be repeatedly issued before each user script is run.

    WEBEXTN
    This parameter is the URI extension which is considered to be a request for DPT to run a script and generate some dynamic content. The dot is optional. By default it is set to ".dptw" which suggests that a DPT Web script will be run, but feel free to use any other descriptive abbreviation or acronym, or even a null string which would mean you would just request scripts by their "procedure name", with no extension at all.

    WEBFLAGS
    This parameter contains bit settings enabling or disabling the following things.

    WEBHOME
    This parameter is the file name assumed if a request for a resource with a null name arrives. On most web servers the default for this is "index.html" and DPT is the same. The name specified can be either an absolute host-local file name or otherwise it is taken to be relative to WEBROOT - see below.

    WEBNDAEM
    If this parameter is non-zero in the ini file the daemons start automatically when the system starts. If you reset it during a run the daemons adjust their numbers automatically to match. If daemons crash, (or log off - you might code LOGOFF in certain serious caught-error situations), they will respawn as required.

    Running with more than one daemon means that users with slow connections, or who run complex database searches, do not hold up the processing of small requests for other users. It also offers the chance for browsers to multi-stream requests for several resources on the same page, which often makes things appear smoother to the end-user.

    If user 0 will be performing system initialization (e.g. allocating files) that the daemons will need in place when they log in, it can be best to leave WEBNDAEM at zero till all this initialization has taken place. (See also WEBDMINI comments above).

    WEBPORT
    This parameter can be consdered together with SYSPORT, as they are both TCP/IP port numbers on which incoming connections can be received. In both cases a "listener" process runs within the DPT host, accepting connections and starting user threads as appropriate. In both cases the listener process can be dynamically stopped and started using the
    =SOCKET command, and that is what you have to do if you want to reset this parameter on the fly. WEBPORT defaults to -1, which means don't listen for web connections - i.e. the web server is inactive.

    WEBPMAX / WEBPMAXT / WEBPCURT
    These parameters cater for the accidental or deliberate posting of enormous HTTP messages which could block the system whilst it deals with them. PMAX and PMAXT specify a maximum size in bytes for the message data block, over which the request gets turned away. PMAX applies to a single message, and PMAXT applies to the aggregate total for the current DPT run. The special, and default, settings of -1 mean no check is applied.

    PCURT is the current aggregate against which the incoming message size and PMAXT are compared, and is updated after each message is processed. If PMAXT is exceeded but you're happy that no funny business is going on, you can reset PCURT to zero again.

    WEBPROC, WEBPRDSN
    When the first web server daemon starts it automatically allocates the proc directory which will be allocated and used as the default source of user "script" procedures. The value of WEBPROC will be the directory name as you would use from the command line (e.g. IN WEBPROC INCLUDE MYSCRIPT), and WEBPRDSN is obviously the OS file name. They are processed just as they would be in an ALLOCATE command. You don't have to code this ALLOCATE yourself anywhere - this scheme is used so that the web daemons can get up and running even if user 0 encounters problems before it might have reached an ALLOCATE command coded in its input file (see also WEBDMINI comments). If the directory specified by WEBPRDSN doesn't exist, it is created.

    WEBPROC can be null, in which case the daemons start with no WEBPROC open, meaning they can serve static content, but run no dynamic scripts. WEBPROC can also be specified as a group, but this requires clever sequencing of actions in the init and login procs - see if you can work out how to do it! (Hint: if these daemons log off, new ones will start automatically).

    WEBROOT
    This is the directory which will be regarded as the logical "root" from the perspective of web browsers. If you change the default you can give it as an absolute directory location ("C:\etc.) or as dpthost-relative, which might be more usual. The default null value means that a request for an otherwise unqualified page name will be serviced by locating the file in dpthost.exe's working directory. See also notes above about the WEBFLAGS bits which control public access below the "root".

    WEBSSI
    Controls whether the system processes
    SSI directives when serving HTML files. The value of the parameter is the number of SSI directives allowed in a single page. When setting it try to use a value a little over the maximum number that you expect any of your SSI pages will need - that way the parameter serves to guard against the possibility of accidental circular recursion. The default is 0 (no SSI), but the demo installation has some SSI pages for illustration, so it will be around 10 or so. It is more efficient to have this parameter turned off unless it's needed, since scanning for the SSI directives is a CPU overhead.

    Top


    Emulation of Statistics

    See also the system config guide for some more background on the subject of statistics.

    M204 stats: Not-emulated at all

    BLKI, BLKO, BLKRLK, CDLWAIT, DEVxx (see note), DKAR, DKRR, DUMP, DUPDTS, ECxxxx, ERRPDL, FSCB, FTBL, HEAP, INxxx (see note), ITBL, IXDEL, LKPOST, LKWAIT, LONGUPxx, MOVE, MPHASHD, MQXXX, NTBL, OUTxxx (see note), PBRSFLT, PCPU, PDL, PFLxxx, PNGDTIME, PR, QTBL, REDY, REST, RETRY, RSXCOMP, RUNG, SCHDCPU, SGMTI/SGMTO (see note), SLIC, SQRD, SQWR, SRBT, SRVC, STBL, STCPU, STDEQ, STIMERS, STPOST, STWAIT, SVxx, SWPG, SWT, TCON, TFMX, TQWT, TTBL, USRS, VTBL, WAIT, WTSERV, XTBL.

    Note re. DEVxxx, INxxx, OUTxxx, SGMTx
    All these have been consolidated under the more descriptive:

    M204 stats: Collected at user logout, user since-last and system level only

    AUDIT, BLKCFRE, CNCT, CPU, IN, OUT, REQ, RQTM, SCREENS, SORTS, UDD, WTCFR, WTRLK.

    Notes re. time accounting
    Precision: Various levels of timing precision are available on Windows, ranging from simple nearest-second times (used on DPT for checkpoints and file-open time stamps), to hardware-implemented high-resolution counters not available on all machines and typically used for low level code tuning. Generally speaking, the better the precision, the higher the run-time cost of obtaining it, so DPT does not overdo things unless necessary. DKUPTIME and UPDTTIME for example are only accurate to the nearest 10ms or so.

    Thread CPU: In the important case of CPU, the fact that DPT relies on Windows for thread-scheduling services (see notes elsewhere) means that we are also at its mercy when it comes to accounting. There are lots of interesting implications here, and you should consult Windows documentation for more details. For example an IO-hungry thread which is always paged out for IO before it uses its whole time slice will register zero CPU. CNCT is often a more useful stat, especially in a single-user situation on a personal computer.

    M204 stats: Collected at file level as well as the other 3 levels

    BACKOUTS, BADD, BCHG, BDEL, BXDEL, BXFIND, BXFREE, BXINSE, BXNEXT, BXRFND, BXSPLI, COMMITS, DIRRCD, DKPR, DKRD, DKSxxx (see note), DKWR, FBWT (see note), FINDS, RECADD, RECDEL, RECDS, STRECDS, UPDTTIME.

    Note re. Disk buffer stats (DKSxxx and FBWT)
    The disk buffer manager on DPT maintains various of these statistics. However, the algorithms used by Model 204 in this key module are largely a black box, and the appropriate stat to increment on DPT at various points was just guesswork. Anybody planning serious analysis of the values reported should contact DPT HQ for an explanation of exactly what they mean.

    M204 stats: Other notes

  • BXCHG is not recorded because on DPT btree value entries are only ever added or deleted. What is the meaning of BXCHG on Model 204? Possibly it reflects a change to one of the inverted lists actually held within the btree leaves (IMMED parameter). On DPT this would register under ILCHG - see below. If anyone wants to isolate such cases, BXCHG could easily be reinstated, if this is what it really means.
  • SORTS is not held at file level, since in many cases the sorted records might come from the members of a group. On DPT SORTS is incremented for value sorts as well as records sorts (see also the custom STVALS stat below).
  • RQTM simply reports the internal CNCT statistic, but always at since-last level, regardless of the level requested.


    Custom DPT Stats

    Line IO stats
    PROCI and PROCO replace all M204 stats representing procedure IO, for example SGMTI and SGMTO. Note that PROCO includes procedure writes during normal save processing. COPY proc is not included however, since that is a blocked copy.
    SEQI and SEQO replace all M204 stats representing physical IO to sequential files. For the same reason as above, COPY DATASET UNFORMATTED does not register either SEQI or SEQO.

    ILxxxxx
    Information about inverted list (bitmaps etc.) maintenance and retrieval. Stat names like ILADD, ILCHG etc., with the obvious meanings. On DPT ILCHG covers the case where a very small inverted list is actually held within the b-tree rather than needing any other supplementary structures (see earlier note about BXCHG).

    MERGES, MRGVALS, STVALS
    Extra information about value processing. As mentioned above, SORTS includes value sorts on DPT, including cases where this is implied by FRV {fieldname} IN {kooky} ORDER. The STVALS statistic is analogous to STRECS, although it is not maintained at file level since in group context we could not know which file should be considered the "true" supplier of a value that occurred in more than one member. MERGES and MRGVALS are only relevant to group value processing, where in many cases a full sort is not necessary because all members' value subsets start in the same, correct order. MRGVALS is the sum of all member value set sizes, including the pre-merge dupes.

    VARTBL
    High-water mark, analogous to GTBL, (and the unused other ?TBL). Appears in SL stats for both CMPL and EVAL.

    Top


    Miscellaneous System Features

    Security

    Model 204 itself has security scattered through a wide range of its features, allowing selective access to entities like fields, procedures, subsystems etc. At present none of this is supported on DPT - all users have all access.

    From version 2.16 DPT does have a built-in password file and a small set of facilities developers can use for maintaining and querying the file. Support for various of M204's integrated security checks may be added over time if requested by users.

    Dynamic output

    USE $PRINT is supported and is handled internally as a Windows print job to the system default printer, but only a small range of control and text formatting options are available.

    USE $JOB could easily have been implemented by shelling off an OS process, but did not make it into the current release. You can however easily simulate this and other similar "pseudo-destinations" with the =SHELL command.

    Wait states (WT) and flags (FLGS)

    These codes are shown on M204's basic MONITOR display, and DPT provides some "nearest equivalents" on that display, purely for familiarity purposes. These codes are not used for anything internally.

    On DPT each WT value is always shown with the same FLGS, since they both come from a look-up table for the display. This may or may not be the case on Model 204.

    FLGS

    The X'40' and X'08' bits would always be set, so the meaningful bits in FLGS values would in theory always be the result of taking off X'48'. For clarity however, these bits are left off, so that for example a value of X'04' can be more clearly seen to simply mean that the user is bumpable.

    Bit(Ref)Comments
    402.1Since Windows does the scheduling, all users are permanently "swappable", but the bit is never shown set (see note above)
    202.1The term "ECB" is slightly alien to the architecture, although it has a similar meaning when we talk about the thread synchronization functions $POST and $WAIT etc. This "internal ECB" bit should be thought of as meaning that the wait will end at some point "within DPT's control".
    08?I can't think of any situations where only one user can wait for a resource, but the bit is never shown set (see note at the top)
    04-Bumpable: This may not be in exactly the same situations as on M204, but the meaning is the same. Bumping a thread with this value *should* make it log off fairly soon.
    022.5There are no inter-user messaging facilities on DPT. This bit is never set.
    01-Timed waits - probably mostly the same situations (*SLEEP etc.)

    M204 WT values

    The values shown in this table are only those that are shown in the M204 system manager's guide (p 4-13) as having some meaning (i.e. where it says "unspecified" or "reserved", the value is not included below).

    ValueFLGS(Ref)Comments
    1002.2Disk IO (only database files). If the buffers spill to the OS swap file the user would show as WT=8, not 0.
    204-User o/p of any kind
    304-User i/p of any kind
    4002.5User 0 when HALTed only
    5-2.3Unsupported
    6-2.3Unsupported
    7242.3Record locks only
    8202.3, 2.2See also WT=1 and WT=98.
    9-2.1Unsupported
    10-2.1Unsupported
    11-1.2Unsupported
    1225-*SLEEP, UL PAUSE n, =PSTxxxx, MONITOR EVERY
    13-2.2Unsupported
    15-1.8Unsupported
    1600-All reads and writes to the checkpoint file
    17-2.5Unsupported
    18-2.5?Unsupported (what is it?)
    1920-Waiting for all updaters to finish before taking checkpoint - possibly not what it means on M204! Use CHKABORT to effectively bump.
    2020-Waiting for a checkpoint to finish on another thread before starting an update. Similar comments as 19.
    21-2.1Unsupported
    22002.8Read/write to sequential file (image and USE)
    23-1.1Unsupported
    2420-Use MONITOR RESOURCE to see which CFR - then bump the holder not the waiter!
    2520-as above
    26-2.4Unsupported
    27-1.2Unsupported
    28-1.2Unsupported
    29-1.1Unsupported
    3024-OK
    32-1.2Unsupported
    37-1.8Unsupported (only user 0 is allowed on during recovery)
    38-39-3.6Unsupported - no spy daemons
    40-46-1.2Unsupported
    47-48-1.8Unsupported - no extended quiesce

    DPT special WT values

    These are provided as extra detail in some situations.

    ValueFLGS(Ref)Comments
    9024-API thread in default null wait state
    9124-Waiting for unspecified resource using the =RESGET command
    9324-Calling $SOCK_ACCEPT or $SOCK_RECEIVE
    9424-Web server or $COMMxx daemon waiting for work
    9524-Web server daemon in the act of sending HTTP response data.
    9624-User has initiated a synchronous daemon thread ($SPAWN) or $COMMxx request and is waiting for it to finish.
    9724-User is performing buffer housekeeping (see =BUFFTIDY). Others may well be, also unbumpably, in WT=8 while this happens, but buffer housekeeping should not take very long.
    9820-Waiting for another user to free up buffers. Evolves from WT=8 when the complete buffer pool is *actively* in use (i.e. not on LRUQ - in theory very rare). This is the only time the FBWT stat is incremented. WT=98 lasts for a maximum of 5 seconds before "out of memory" is assumed.
    99202.3Waiting for a page-level database lock

    Top