ci-server-engineer/knowledge/manuals/IM36K10P30-01EN.md

manual	title	edition	version	status
IM 36K10P30-01EN	Data Set Service Language	3rd Edition, Sep. 2023	R1.03	compiler run as a syntax check on a copy of the installed DSS files and on a deliberately broken test file (2026-10-01); defining new datasets and updating the dictionary from docs only

Data Set Service Language (R1.03)

The DSS language describes datasets; the DSS compiler (dss.exe) checks the descriptions and builds the data dictionary (%TLS_DAT_PATH%\tlsdic_dss.dic) and C include files. It is a system integrator's tool: changing the dictionary changes CI Server itself and is only needed for custom datasets, custom report destinations (IM36K10R40-01EN.md §3.3) or custom data access servers. Section numbers refer to the manual.

1. DSS files (§2)

• Plain text, one dataset per file recommended, extension .dss. The installed descriptions are in %TLS_ROOT_PATH%\tls\src\ (253 .dss files on the test system, plus .c sources of the data access servers and .umh message files). Reading them is the best way to learn a dataset's fields, ranges, lists and defaults (dssqld -f shows the same information).
• Syntax: <KEYWORD value> or <KEYWORD <SUB …> …>; keywords case-insensitive; strings in double quotes with "" for a quote; /* */ and // comments.
• Order in a file: includes (<INCLUDE "dss_global.dss">), constants (<DEFINE_CONSTANT <LABEL …> <VALUE …>>), macros, field templates, storage nodes, then <DATASET <NAME …> <DESCRIPTION …> <FIELD …>… <PHYSICAL_FIELD …>… <INDEX …>… <DATA_FILE …> <DATA_ACCESS <SERVERNAME "dsilib:…">> <OPERATIONS> <STORAGE <NODES …>> …>.
• A dataset needs a name (not an SQL keyword, unique), at least one field and one unique index.
• Texts (descriptions, headings, list entries) can carry translations (English, Dutch, German, French).
• Field properties: data type or field template, description, heading, format, transformation, basic operations, range/step, list (<ENTRY <NUMERIC n> <STRING "text">>), required, hidden, concealed, default, character restrictions/operations, password-encrypted, "maps upon" (relational field to another dataset), enabled, validate, group. Relational and compound (composed) fields and physical fields have their own sentences; indexes may be unique.

2. Compiler (§3)

Run dss in the folder that holds the .dss files; it compiles all of them.

Flag	Effect
none	Syntax check only (errors on screen)
-d[<dict>]	Create/update a dictionary (default tlsdic_dss.dic in %TLS_DAT_PATH%) — host node only; other nodes get the change through DSSWTH
-i	Write C include files (.dsh)
-l[<list>]	List file (default tlsdic_dss.lst next to the files)
-q / -w / -b	Quiet / no warnings / no boundary check

Installed (verified): a copy of the 253 installed files compiled in 2 s with no errors (dss -l -w, 251 files plus the two include files) and tlsdic_dss.dic was not touched. A test file with a missing > gave cieng_test_df.dss (15,2): EOF is not expected, expected 1 end-of-sentence characters ('>') and 1 errors found. The start script uses an undocumented -u (compile without the DSS shared memory) on the first start. dssxdb has a "beautify DSS dictionary source" function to find unbalanced < > (IM36K10L50-01EN.md §1.2).

To add a value to an existing list (e.g. a report destination, R40 §3.3): edit the .dss in tls\src, run dss -d in that folder, restart CI Server. Not practiced (would change the test system's dictionary).

3. Include files (§4)

The .dsh output holds constants, dataset information, a C record structure and index information for programs that use the DSS API. Not needed for engineering work.