Synergy Data Language syntax and usage

The following conventions are used to document the Synergy Data Language statement syntax:

• Statement names (such as FILE) and keywords (such as LONG DESCRIPTION) are shown in UPPERCASE.
• Arguments that you should replace with actual data are shown in lowercase italics.
• Optional items are enclosed in [italic square brackets].
• String data is enclosed in “quotation marks”.
• Arguments that may be repeated more than once are followed by an ellipsis (…).

Together, these elements form a definition, as shown in the example below.

1. Synergy Data Language definition.

General usage rules

• Names, keywords, and arguments can be specified in either uppercase or lowercase letters, except for quoted definition names, which must be uppercase. All non-quoted data is converted to uppercase on input.
• If required data is not supplied, or if it is invalid, the entire statement is ignored.
• Definitions can be specified in any order, with some exceptions. See Recommended definition order.
• Keywords can be specified in any order, unless otherwise noted. In the statement syntax, keywords are listed in the order in which they are generated by the Generate Repository Schema utility.
• A keyword that is longer than a single physical word cannot span multiple lines. For example, the following is invalid, because LONG DESCRIPTION is split over two lines:

FIELD ccname TYPE date SIZE 8 STORED YYYYMMDD
DESCRIPTION "Opened account" LONG
DESCRIPTION "Opened account (YYYYMMDD)"

• For some keywords, the keyword and associated data must be kept together on the same line. Where this is the case, it is documented with the keyword.
• Keyword data that contains colons (:) (for example, the arguments for OVERLAY and DIMENSION) cannot contain embedded spaces.
• Negative values for numeric keyword arguments are not permitted, except where noted. When a negative value is used, it must be immediately preceded by a minus sign (for example, -3 or -10).
• String data must be enclosed in a set of matching double or single quotation marks ( “ ” or ‘ ’ ) and cannot span multiple lines.
• String data can contain a quotation character if that character is different from the character that encloses the data. For example, both of the following strings are valid:

"Type 'Return' to continue"
'Type "Return" to continue'

• Data that exceeds the maximum size allowed is truncated.
• Comments are indicated by placing a semicolon as the first character (in the first column) on the line. Comments are not permitted within a Synergy Data Language statement.

Recommended definition order

In general, definitions can be specified in any order. If multiple types of definitions (e.g., template, structure, etc.) are combined within one schema file, global formats must be specified before templates, and templates must be specified before structures. For slightly faster processing times, load definitions in the following order:

1.

Global formats.

2.

Enumerations.

3.

Templates in reference order. That is, define all parent templates before their child templates.

4.

Each structure in reference order, along with all of its formats, fields, keys, relations, and aliases.

A structure referenced within an implicit group specification or as a Struct data type must be defined before the structure that references it.

Each structure must be followed by its formats, fields, keys, aliases, relations, and tag. The formats must occur before any fields. The fields must be grouped together and must occur before any keys or aliases that reference them. Relations can occur anywhere within the structure, except between fields. (Relations are not validated until the end of the schema loading process, so if they are not defined with their structure, they may be placed after all structures in the schema file.) A structure’s tag must be defined before the group of fields or after the entire group.

5.

Files.

General processing rules

A Synergy Data Language file (schema file) can be used to create a new repository or update an existing one.

• When a schema file is used to create a new repository, you simply specify the name of the new repository, and it is created for you by the Load Repository Schema utility. If any errors occur, the new repository is not created; you must correct the schema file and reload it.
• When a schema file is used to update (merge with) an existing repository, the Load Repository Schema utility makes a copy of the target repository, and then updates the copy. If any errors occur, the copied repository is deleted; you must correct the schema file and reload it. If no errors occur, the copied repository either replaces the original or not, depending on the options you specified.

When a repository has been successfully loaded or updated, you should run both the Verify Repository utility and the Validate Repository utility on the new (or copied) repository.

The Load Repository Schema utility is able to process the specification of both new and existing repository definitions. The way each is handled depends on the options you set when running the utility.

• If you are loading a schema into a new repository, all definitions specified in the schema file are added. If a duplicate definition exists in the schema file, an error is logged in the log file.
• Adding new structures also adds any fields, keys, relations, formats, and tags specified for the structure.
• If you are merging a schema into an existing repository, all new definitions are added. You can choose to replace or overlay existing definitions.

Replace deletes the current definition and stores the new one from the schema file. Replacing an existing structure essentially deletes all fields, keys, etc., for the current structure, and adds back only those specified in the schema file.

Overlay updates existing fields, etc., with those in the schema file and adds new fields, etc. It does not delete any fields, etc. Overlay is typically used to add to the attributes of existing definitions.

The Load Repository Schema utility attempts to load all the definitions in the schema file into the repository. If your file contains definitions you do not wish to load, you must remove them from the file. For example, if your schema file contains both new and existing definitions, and you want only to update the existing ones, you must remove the new definitions from the file before loading the schema.

The table below summarizes the rules that your schema must follow to use the Load Repository Schema utility to update (merge) an existing repository. Carefully review this table before merging schemas.

Rules for Schema Files
Option	Definition type	Rules
Add	<All>	All required keywords and data must be specified. Non-specified, non-required attributes are set to default values.
	Global formats	Must be defined before any templates or structures, if multiple definition types are combined in one schema file.
	Enumerations	No additional rules.
	Templates	Must be defined before any structures, if multiple definition types are combined in one schema file.
	Structures	No additional rules.
	Formats	Must be defined before any fields.
	Fields	Must be defined before any keys.
	Keys	Must be defined before any relations.
	Tags	Must be defined before any fields or after all fields for the current structure.
	Files	No additional rules.
Replace	<All>	(See “Add” above.)
	Global formats	No additional rules.
	Enumerations	No additional rules.
	Templates	No additional rules.
	Structures	No additional rules. Notes: New fields, keys, etc., are added. Existing fields, keys, etc., are replaced. Non-specified existing fields, keys, etc., are deleted. New alias structures and alias fields are added. All alias fields in existing alias structures are replaced by specified alias fields. Non-specified alias structures (and their fields) are unaffected.
	Formats	No additional rules.
	Fields	No additional rules.
	Keys	No additional rules.
	Relations	No additional rules.
	Tags	No additional rules.
	Files	To disassociate structures from a file, specify only the ones you want to keep. Specifying no assigned structures clears all current assigned structures.
Overlay	<All>	The definition name must be specified, followed by the attributes to be overlaid or added to the definition. (Exceptions to this rule are listed below.) All other attributes remain unchanged.
	Global formats	All keywords and data except JUSTIFY must be respecified.
	Enumerations	All members must be respecified when you overlay one or more members.
	Templates	No additional rules. Notes: When a parent is added to an existing template, both the existing override flags and the template attributes that are explicitly specified in the schema file are retained as parent overrides.
	Structures	No additional rules. Notes: New fields, keys, etc., are added. Existing fields, keys, etc., are updated. Non-specified existing fields, keys, etc., remain unchanged. New alias structures and alias fields are added. All alias fields in existing alias structures are replaced by specified alias fields.
	Formats	All keywords and data except JUSTIFY must be respecified.
	Fields	No additional rules. Notes: When a template is added to an existing field, only the existing override flags and the field attributes that are explicitly specified in the schema file are retained as template overrides.
	Keys	All key segments must be respecified when you overlay one or more segments. (To clear all segments, use Replace.) All compression options must be respecified when you overlay one or more options.
	Relations	All attributes must be respecified.
	Tags	All attributes must be respecified.
	Files	All assigned structures must be respecified (along with any ODBC table names) when changing one or more.