Unsupported content


This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Recommendations when writing a grammar

eTo avoid common mistakes when writing a grammar to interpret a configuration file, use the following recommendations:

  • Values and keys must include delimiters. For example, if you are parsing /etc/group with the format A:B:Con each line, any token representing A, B, or C must not include a colon. The following are examples:


    Following delimiters are supported for custom configuration files:

    • Comma (,)

    • Space

    • Equal (=)

    • Colon (:)

  • If rule A references rule B, rule B must be defined before rule A. For example, the following syntax is incorrect:


    In this example, RULE_B is using RULE_A, but RULE_A is not yet defined. If the two lines were inverted, this example would be correct.

    A rule can always reference itself.

  • You cannot save a child record to a parent that does not yet exist. If you are attempting to create a hierarchy from one line in a configuration file, you must save the parent record before you can save any child records.
  • Do not reference an item in a rule that does not exist. Doing so can cause serious problems. For example, the following rule references the fourth argument in the rule by calling $3, but the rule only has three arguments. This is incorrect.

    RULE_A VALA VALB VALC $new_field $3
  • For changes to a grammar file to take effect, you must:
    • Restart the Application Server
    • Recreate any BLPackages that reference this grammar
    • In multi-Application Server environments, load the revised grammar file to the file server
Was this page helpful? Yes No Submitting... Thank you