Command String Format

The ZY command string looks like this:

where:

$$\begin{eqnarray*} TID & = & {\rm Transaction\;ID,\;sent\;from\;ZIY\;(optional)... ...\rm n} & = & {\rm The\;newline\;command\;string\;delimiter.}\\ \end{eqnarray*}$$

The TID and TS elements are optional. One or both can be omitted, but if only one of these is omitted, it must be the TS element. If CMD is followed by parameters, the first one must be separated from CMD by a space, and from each other by commas. A command may take more than one number of parameters. For example, COO can take none, 5, or 6, depending on what exactly is desired. The ZY uses the same format to return the results of a command, with the following exceptions:

• An execution success flag immediately follows the command name
• A TID and TS are always returned.
• The string of parameters $P_{1}\ldots P_{n}$ will not necessarily match the string of parameters sent with the original command by the ZY's client. The documentation for each command should be consulted to determine return values.
• The ZY will generate 1 or more return command strings for every command string received! Therefore, the ZY's client should be prepared to handle several return command strings whenever it issues a command. Examples of commands that can do this include SCN, RDF, COO etc. Again, the documentation for each command should be consulted to determine whether the ZY will return more than one command string for the command.

Thus, the returning command string looks like this:

where:

$$\begin{eqnarray*} TID & = & {\rm Transaction\;ID,\;sent\;from\;ZIY\;(always\;s... ...\rm n} & = & {\rm The\;newline\;command\;string\;delimiter.}\\ \end{eqnarray*}$$

The command will always return with $f$ set to 1 if the command succeeded, or 0 if the command failed. In case of failure, an error message would be passed back in one of the parameters. The ZY can also generate return command string on its own, without intervention from its client. For example, whenever the ZY's state changes, it will generate an STW return command string to inform its client of the change. This eliminates any need for the client to poll the ZY for status checks. In addition, the ZY can generate other return command strings to keep the ZY's client updated (see ACU).