Appendix B . Reference Pages

This appendix covers the following reference pages, formerly called man pages:

addumap

Add a local-to-remote mapping for a local/remote domain pair
SYNOPSIS

DMCONFIG=dmconfig
addumap -d local domain ID -R remote domain ID
-p local principal name -u remote username

DESCRIPTION

addumap can only be executed as a subcommand of dmadmin. The purpose of this page is to describe options for the subcommand and to show examples.
The subcommand allows the administrator to add local-to-remote user mappings for a local/remote domain pair.
Mappings are defined to be inbound, outbound or both when the application is using OSI Domain gateways and SECURITY is set to USER_AUTH, ACL, or MANDATORY ACL in the ubbconfig file and SECURITY is set to DM_PW or USER_PW in the DMCONFIG file.
The following options are available:

-d local domain ID
This is the name of the local domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-R remote domain ID
This is the name of the remote domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-p local principal
The user identification number. The local principal must be defined in the ACL user file and must be unique within the list of existing identifiers for the application.
-u remote username
The remote user name as defined in the ACL security application (for example, RACF) of the remote domain.

Before running this subcommand the application must be configured using either the Graphical Administrative Interface or tmloadcf and dmloadcf. dmadmin addumap may be run on any active node.
PORTABILITY

This subcommand is available only on non-/WS sites running TUXEDO System /T Release 6.4.
DIAGNOSTICS

The dmadmin addumap subcommand exits with a return code of 0 upon successful completion.
EXAMPLE

addumap -d ldom -R cics -p tuxusr -u cicsusr
/*maps principal tuxusr with
remote user cicsusr */

SEE ALSO

dmadmin, delumap

addusr

Add a user to the remote domain user and password file
SYNOPSIS

DMCONFIG=dmconfig
addusr -d local domain ID -R remote domain ID -u remote username[-w ]

DESCRIPTION

addusr can only be executed as a subcommand of dmadmin. The purpose of this page is to describe options for the subcommand and to show an example.
The subcommand allows the administrator to add remote usernames and passwords to the remote domain remote user and password table. If -w is not specified, the user must is prompted for a password.
The table entries created are used for passing remote user names and passwords to remote OSI domains when the application is using OSI Domain gateways and SECURITY is set to USER_AUTH, ACL, or MANDATORY ACL in the ubbconfig file and SECURITY is set to DM_PW or USER_PW in the DMCONFIG file.
The following options are available:

-d local domain ID
This is the name of the local domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-R remote domain ID
This is the name of the remote domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-u remote username
The remote user name to be added.
-w
Do not prompt for password.

Before running this subcommand the application must be configured using either the Graphical Administrative Interface or tmloadcf and dmloadcf. dmadmin addusr may be run on any active node.
PORTABILITY

This subcommand is available only on non-/WS sites running TUXEDO System /T Release 6.4.
DIAGNOSTICS

The dmadmin addusr subcommand exits with a return code of 0 upon successful completion.
EXAMPLES

addusr -d tux -R cics -u cicsusr /*adds remote user cicsusr to cics
domain users. The administrator is
prompted for a password*/

SEE ALSO

delusr, modusr

build_dgw

Builds a customized domain gateway process.
SYNOPSIS

build_dgw [ -c dmtype] [ -o name] [ -v ]

DESCRIPTION

Constructs a customized TUXEDO System/T domain gateway module. The files included by the caller should include only the application buffer type switch and any required supporting routines. The command combines the files supplied by the -c option with the standard TUXEDO System/T libraries necessary to form a gateway load module. The load module is built by the cc command described in UNIX System reference manuals which build_dgw invokes. The options to build_dgw have the following meaning:

-c dmtype
specifies a domain type that characterizes communications access module domain gateway. The value of dmtype must appear in the domain type table located in $TUXDIR/udataobj/DMTYPE. Each line in this file has the form:
dmtype:access_module_lib:comm_libs:tm_typesw_lib:gw_typesw_lib
Using the dmtype value, build_dgw retrieves the corresponding entry from $TUXDIR/udataobj/DMTYPE. The access_module_lib specifies the libraries used by this particular type of domain instantiation. The comm_libs parameter contains a list of the networking communications libraries used by the access module. The tm_typesw_lib parameter defines a list of libraries or object modules with the definition of the typed buffers used by the local application. If this parameter is not defined, the gateway will be linked with the default typed buffer definitions. The gw_typesw_lib parameter applies only to a gateway of type OSITP and defines a list of libraries or object modules used by the gateway to transform buffers into the protocol required by the remote domain. There should be a one-to-one mapping between the buffer types defined in the tm_typesw array (see typesw and tuxtypes) and the gw_typesw array (see gwtypesw and gwtypes). If this parameter is not defined, the gateway will be linked with the default typed buffer definitions provided with the OSITP instantiation.
Currently, dmtype may be set to one of the following values:

TDOMAIN
builds a gateway for communications with another System/T domain. The build_dgw command will use the standard TUXEDO System/T libnws.a networking library. This is the default option.
OSITP
builds a gateway for communications with an OSI TP domain. The OSITP access module uses the XAP-TP interface. The pathname for the library containing the XAP-TP primitives is provider dependent and should be set according to the provider's specifications.

-o name
specifies the name of the file the output gateway load module is to have. If not supplied, the load module is named GWTDOMAIN for the TDOMAIN type or GWOSITP for the OSITP type. Note that the name selected for the load module must also be the name used for the definition of the gateway in the SERVERS section of the TUXCONFIG file.
-v
specifies that build_dgw should work in verbose mode. In particular, it writes the cc command to its standard output.

build_dgw normally uses the cc command to produce the a.out. In order to allow for the specification of an alternate compiler, build_dgw checks for the existence of a shell variable named CC. If CC does not exist in build_dgw's environment, or if it is the string "--", build_dgw will use cc as the compiler. If CC does exist in the environment, its value is taken to be the name of the compiler to be executed. Likewise, the shell variable CFLAGS is taken to contain a set of parameters to be passed to the compiler.
PORTABILITY

build_dgw is supported as a TUXEDO System/T-supplied compilation tool on UNIX operating systems only.
EXAMPLES

The following example shows how to build a domain gateway of type TDOMAIN.
CC=ncc CFLAGS="-I $TUXDIR/include"; export CC CFLAGS
build_dgw -o DGW
The following example shows use of build_dgw for an OSI TP instantiation:
build_dgw -c OSITP -o OTPGW
The DMTYPE file will contain the following entries:
TDOMAIN:$TUXDIR/lib/libgwt.a:$TUXDIR/lib/libnwi.a
$TUXDIR/lib/libnws.a::
OSITP:$TUXDIR/lib/libgwo.a:-l xaptp -l ositp::
SNA:libgws.a:$TUXDIR/lib/libcpic.a:$SNADIR/lib/libsna.a
The paths for the libxaptp.a and libositp.a libraries are installation and provider dependent. The application administrator must specify the correct pathnames before building a /OSITP gateway instantiation.
SEE ALSO

cc, ld in UNIX System reference manuals
gwtypes, gwtypesw, tuxtypes, typesw

delumap

Delete a local-to-remote mapping for a local/remote domain pair
SYNOPSIS

DMCONFIG=dmconfig
delumap -d local domain ID -R remote domain ID
-p local principal name -u remote username

DESCRIPTION

delumap can only be executed as a subcommand of dmadmin. The purpose of this page is to describe options for the subcommand and to show examples.
The subcommand allows the administrator to delete local-to-remote user mappings for a local/remote domain pair.
Mappings are defined to be inbound, outbound or both when the application is using OSI Domain gateways and SECURITY is set to USER_AUTH, ACL, or MANDATORY ACL in the ubbconfig file and SECURITY is set to DM_PW or USER_PW in the DMCONFIG file.
The following options are available:

-d local domain ID
This is the name of the local domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-R remote domain ID
This is the name of the remote domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-p local principal
The user identification number. The local principal must be defined in the ACL user file and must be unique within the list of existing identifiers for the application.
-u remote username
The remote user name as defined in the ACL security application (for example, RACF) of the remote domain. Space is a valid remote username.

Before running this subcommand the application must be configured using either the Graphical Administrative Interface or tmloadcf and dmloadcf. dmadmin delumap may be run on any active node.
PORTABILITY

This subcommand is available only on non-/WS sites running TUXEDO System /T Release 6.4.
DIAGNOSTICS

The dmadmin delumap subcommand exits with a return code of 0 upon successful completion.
EXAMPLE

delumap -d ldom -R cics -p tuxusr -u cicsusr
/*deletes the mapping of principal
tuxusr with remote user cicsusr */

SEE ALSO

dmadmin, addumap

delusr

Delete a user from the remote domain user and password file
SYNOPSIS

DMCONFIG=dmconfig
delusr -d local domain -R remote domain -u remote username

DESCRIPTION

delusr can only be executed as a subcommand of dmadmin. The purpose of this page is to describe options for the subcommand and to show an example.
The subcommand allows the administrator to remove remote usernames and passwords from the remote domain remote user and password table.
Once the entries are deleted they can no longer be used for mapping remote user names and passwords to local user names and passwords when the application is using OSI Domain gateways and SECURITY is set to USER_AUTH, ACL, or MANDATORY ACL in the ubbconfig file and SECURITY is set to DM_USER_PW in the DMCONFIG file.
The following options are available:

-d local domain ID
This is the name of the local domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-R remote domain ID
This is the name of the remote domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-u remote username
The remote user name to be deleted.

Before running this subcommand the application must be configured using either the Graphical Administrative Interface or tmloadcf and dmloadcf. dmadmin delusr may be run on any active node.
PORTABILITY

This subcommand is available only on non-/WS sites running TUXEDO System /T Release 6.4.
DIAGNOSTICS

The dmadmin delusr subcommand exits with a return code of 0 upon successful completion.
EXAMPLES

delusr -d tux -R cics -u cicsusr /*deletes remote user cicsusr to
cics domain users. The
administrator is prompted for a
password*/

SEE ALSO

addusr, modusr

DMADM

/Domain administrative server
SYNOPSIS

DMADM SRVGRP = "identifier"
SRVID = "number"
REPLYQ = "N"

DESCRIPTION

The /DOMAIN administrative server DMADM is a TUXEDO-supplied server that provides run-time access to the BDMCONFIG file. When DMADM is booted the BDMCONFIG environment variable should be set to the pathname of the file containing the binary version of the DMCONFIG file.
DMADM is described in the *SERVERS section of the UBBCONFIG file as a server running within a group, e.g., DMADMGRP. There should be only one instance of the DMADM running in this group and it must not have a reply queue ( REPLYQ must be set to "N").
The following server parameters can also be specified for the DMADM server in the *SERVERS section: SEQUENCE, ENVFILE, MAXGEN, GRACE, RESTART, RQPERM and SYSTEM_ACCESS.
PORTABILITY

DMADM is supported as a TUXEDO-supplied server on UNIX System operating systems.
INTEROPERABILITY

The initial release of OSI Domain can only be installed on a node running TUXEDO Release 6.4.
EXAMPLES

The following example illustrates the definition of the administrative server and a gateway group in the UBBCONFIG file.
#
*GROUPS
DMADMGRP  LMID=mach1 GRPNO=1
gwgrp     LMID=mach1 GRPNO=2
#
*SERVERS
DMADM SRVGRP="DMADMGRP" SRVID=1001 REPLYQ=N RESTART=Y GRACE=0
GWADM SRVGRP="gwgrp" SRVID=1002 REPLYQ=N RESTART=Y GRACE=0
GWTDOMAIN SRVGRP="gwgrp" SRVID=1003 RQADDR="gwgrp" REPLYQ=Y
RESTART=Y MIN=1 MAX=1
SEE ALSO

dmadmin, tmboot, dmconfig, GWADM, servopts, ubbconfig
TUXEDO /Domain Guide
TUXEDO Administrator's Guide

dmadmin

TUXEDO System/T Domain Administration Command Interpreter
SYNOPSIS

dmadmin [-c]

DESCRIPTION

dmadmin is an interactive command interpreter used for the administration of domain gateway groups defined for a particular TUXEDO System/T application. dmadmin can operate in two modes: administration mode and configuration mode.
dmadmin enters administration mode when called with no parameters. This is the default. In this mode, dmadmin can be run on any active node (excluding workstations) within an active application. Application administrators can use this mode to obtain or change parameters on any active domain gateway group. Application administrators may also use this mode to create, destroy, or reinitialize the DMTLOG for a particular local domain. In this case, the domain gateway group associated with that local domain must not be active, and dmadmin must be run on the machine assigned to the corresponding gateway group.
dmadmin enters configuration mode when it is invoked with the -c option or when the config subcommand is invoked. Application administrators can use this mode to update or add new configuration information to the binary version of the domain configuration file BDMCONFIG.
dmadmin requires the use of the DOMAIN administrative server DMADM for the administration of the BDMCONFIG file and the gateway administrative server GWADM for the re-configuration of active DOMAIN gateway groups (there is one GWADM per gateway group).
ADMINISTRATION MODE COMMANDS

Once dmadmin has been invoked, commands may be entered at the prompt (">") according to the following syntax:
command [arguments]
Several commonly occurring arguments can be given default values via the default command. Commands that accept parameters set via the default command check default to see if a value has been set. If no value is set, an error message is returned.
Once set, a default value remains in effect until the session is ended, unless changed by another default command. Defaults may be overridden by entering an explicit value on the command line, or unset by entering the value "*". The effect of an override lasts for a single instance of the command.
Output from dmadmin commands is paginated according to the pagination command in use (see the definition for the paginate subcommand).
Commands may be entered either by their full name or their abbreviation (shown in parentheses) followed by any appropriate arguments. Arguments appearing in square brackets, [], are optional; those in curly braces, {}, indicate a selection from mutually exclusive options. Note that for many commands local_domain_name is a required argument, but note also that it can be set with the default command.
The following commands are available in administration mode:

addumap [ options ]
Add local user mappings to remote user mappings for a local/remote domain pair. Mappings are defined to be inbound, outbound or both. See the addumap manual page for an explanation of the available options and for examples.
addusr (addu) [ options ]
Add remote usernames and passwords to the remote user and password tables of a remote domain. See the addusr manual page for an explanation of the available options and for examples.
advertise (adv) -d local_domain_name [{ -all | service}]
Advertise all remote services provided by the named local domain or the specified remote service.
audit (audit) -d local_domain_name [{off | on}]
Activate (on) or deactivate (off) the audit trace for the named local domain. If no option is given, then the current setting will be toggled between the values on and off, and the new setting will be printed. The initial setting is off.
chbktime (chbt) -d local_domain_name -t bktime
Change the blocking timeout for a particular local domain.
config (config)
Enter configuration mode. Commands issued in this mode follow the conventions defined in the section "CONFIGURATION MODE COMMANDS" on page B-20.
crdmlog (crdlg) -d local_domain_name
Create the domain transaction log for the named local domain on the current machine (that is, the machine where dmadmin is running). The command uses the parameters specified in the DMCONFIG file. This command fails if the named local domain is active on the current machine or if the log already exists.
default (d) [-d local_domain_name]
Set the corresponding argument to be the default local domain. Defaults may be unset by specifying "*" as an argument.
If the default command is entered with no arguments, the current default values are printed.
delumap [ options ]
Delete local to remote user mappings for a local/remote domain pair. See the delumap manual page for an explanation of the available options and for examples.
delusr (delu) [ options ]
Delete remote usernames and passwords from the remote user and password tables of a remote domain. See the delusr reference page for an explanation of the available options and for examples.
dsdmlog (dsdlg) -d local_domain_name [ -y ]
Destroy the domain transaction log for the named local domain on the current machine (that is, the machine where dmadmin is running). An error is returned if a DMTLOG is not defined for this local domain, if the local domain is active, or if outstanding transaction records exist in the log. The term outstanding transactions means that a global transaction has been committed but an end-of-transaction has not yet been written. This command prompts for confirmation before proceeding unless the -y option is specified.
echo (e) [{off | on}]
Echo input command lines when set to on. If no option is given, then the current setting is toggled, and the new setting is printed. The initial setting is off.
forgettrans (ft) -d local_domain_name [ -t tran_id]
Forget one or all heuristic log records for the named local domain. If the transaction identifier tran_id is specified, then only the heuristic log record for that transaction will be forgotten. The transaction identifier tran_id can be obtained from the printtrans command or from the ULOG file.
help (h) [command]
Print help messages. If command is specified, the abbreviation, arguments, and description for that command are printed. Omitting all arguments causes the syntax of all commands to be displayed.
indmlog (indlg) -d local_domain_name [ -y ]
Reinitialize the domain transaction log for the named local domain on the current machine (that is, the machine where dmadmin is running). An error is returned if a DMTLOG is not defined for this local domain, if the local domain is active, or if outstanding transaction records exist in the log. The term outstanding transactions means that a global transaction has been committed but an end-of-transaction has not yet been written. The command prompts for confirmation before proceeding unless the -y option is specified.
modusr (modu) [ options ]
Change remote passwords in the password tables of a remote domain. See the reference page "modusr" on page B-67 for an explanation of the available options and for examples.
paginate (page) [{off | on}]
Paginate output. If no option is given, then the current setting will be toggled, and the new setting is printed. The initial setting is on, unless either standard input or standard output is a non-tty device. Pagination may only be turned on when both standard input and standard output are tty devices. The shell environment variable PAGER may be used to override the default command used for paging output. The default paging command is the indigenous one to the native operating system environment, for example, the command pg is the default on UNIX System operating environments.
passwd (passwd) [ -r ] local_domain_name remote_domain_name
Prompts the administrator for new passwords for the specified local and remote domains. The -r option specifies that existing passwords and new passwords should be encrypted using a new key generated by the system. The password is truncated after at most eight characters.
printdomain (pd) -d local_domain_name
Print information about the named local domain. Information printed includes connected remote domains, global information shared by the gateway processes, and additional information that is dependent on the domain type instantiation.
printstats (stats) -d local_domain_name
Print statistical and performance information gathered by the named local domain. The information printed is dependent on the domain gateway type.
printtrans (pt) -d local_domain_name
Print transaction information for the named local domain.
quit (q)
Terminate the session.
resume (res) -d local_domain_name [{ -all | service}]
Resume processing of the specified service or for all remote services handled by the named local domain.
stats (stats) -d local_domain_name [{ off | on | reset }]
Activate (on), deactivate (off), or reset (reset) statistics gathering for the named local domain. If no option is given, then the current setting will be toggled between the values on and off, and the new setting will be printed. The initial setting is off.
suspend (susp) -d local_domain_name [{ -all | service}]
Suspend one or all remote services for the named local domain.
unadvertise (unadv) -d local_domain_name [{ -all | service}]
Unadvertise one or all remote services for the named local domain.
verbose (v) [{off | on}]
Produce output in verbose mode. If no option is given, then the current setting will be toggled, and the new setting is printed. The initial setting is off.
! shellcommand
Escape to shell and execute shellcommand.
!!
Repeat previous shell command.
# [text]
Lines beginning with "#" are comment lines and are ignored.
<CR>
Repeat the last command.

CONFIGURATION MODE COMMANDS

The dmadmin command enters configuration mode when executed with the -c option or when the config subcommand is used. In this mode, dmadmin allows run-time updates to the BDMCONFIG file. dmadmin manages a buffer that contains input field values to be added or retrieved, and displays output field values and status after each operation completes. The user can update the input buffer using any available text editor.
dmadmin first prompts for the desired section followed by a prompt for the desired operation.
The prompt for the section is as follows:
Sections:
       1) LOCAL_DOMAINS     2) REMOTE_DOMAINS
       3) LOCAL_SERVICES    4) REMOTE_SERVICES
       5) ROUTING           6) ACCESS_CONTROL
       7) PASSWORDS         8) TDOMAIN
       9) OSITP            10) SNA
      11) QUIT
Enter Section [1]:
The number of the default section appears in square brackets at the end of the prompt. You can accept the default by pressing RETURN or ENTER. To select another section enter its number, then press RETURN or ENTER.
dmadmin then prompts for the desired operation.
Operations:
       1) FIRST             2) NEXT
       3) RETRIEVE          4) ADD
       5) UPDATE            6) DELETE
       7) NEW_SECTION       8) QUIT
Enter Operation [1]:
The number of the default operation is printed in square brackets at the end of the prompt. Pressing RETURN or ENTER selects this option. To select another operation enter its number, then press RETURN or ENTER.
The currently supported operations are:

1. FIRST
Retrieve the first record from the specified section. No key fields are needed (they are ignored if in the input buffer).
2. NEXT
Retrieve the next record from the specified section, based on the key fields in the input buffer.
3. RETRIEVE
Retrieve the indicated record from the specified section by key field(s) (see the following fields description).
4. ADD
Add the indicated record in the specified section. Any fields not specified (unless required) take their default values as specified in dmconfig. The current value for all fields is returned in the output buffer. This operation can only be done by the System/T administrator.
5. UPDATE
Update the record specified in the input buffer in the selected section. Any fields not specified in the input buffer remain unchanged. The current value for all fields is returned in the input buffer. This operation can only be done by the System/T administrator.
6. DELETE
Delete the record specified in the input buffer from the selected section. This operation can only be done by the System/T administrator.
7. NEW SECTION
Clear the input buffer (all fields are deleted). After this operation, dmadmin immediately prompts for the section again.
8. QUIT
Exit the program gracefully (dmadmin is terminated). A value of q for any prompt also exits the program.

For configuration operations, the effective user identifier must match the System/T administrator user identifier UID for the machine on which this program is executed. When a record is updated or added, all default values and validations used by dmloadcf are enforced.
dmadmin then prompts whether or not to edit the input buffer.
Enter editor to add/modify fields [n]? 
Entering a value of y will put the input buffer into a temporary file and execute the text editor. The environment variable EDITOR is used to determine which editor to be used; the default is "ed". The input format is in field name/field value pairs and is described in the CONFIGURATION INPUT FORMAT section that follows. The field names associated with each DMCONFIG section are listed in tables in the subsections that follow. The semantics of the fields and associated ranges, default values, restrictions, etc., are described in dmconfig. In most cases, the field name is the same as the KEYWORD in the DMCONFIG file, prefixed with "TA_". When the user completes editing the input buffer, dmadmin reads it. If more than one line occurs for a particular field name, the first occurrence is used and other occurrences are ignored. If any errors occur, a syntax error will be printed and dmadmin prompts whether or not to correct the problem.
Enter editor to correct? 
If the problem is not corrected (response n), then the input buffer will contain no fields. Otherwise, the editor is executed again.
Finally, dmadmin asks if the operation should be done.
Perform operation [y]?
When the operation completes, dmadmin prints the return value as in
Return value TAOK
followed by the output buffer fields. The process then begins again with a prompt for the section. All output buffer fields are available in the input buffer unless the buffer is cleared.
Entering break at any time restarts the interaction at the prompt for the section.
When "QUIT" is selected, dmadmin prompts for authorization to create a backup ASCII version of the configuration:
Unload BDMCONFIG file into ASCII backup [y]? 
If a backup is selected, dmadmin prompts for the file name.
Backup filename [DMCONFIG]? 
On success, dmadmin indicates that a backup was created, otherwise an error is printed.
CONFIGURATION INPUT FORMAT

Input packets consist of lines formatted as follows:
-fldname-<tabs>-fldval
The field name is separated from the field value by one or more tabs (or spaces).
Lengthy field values can be continued on the next line by having the continuation line begin with one or more tabs (which are dropped when read back into dmadmin).
Empty lines consisting of a single newline character are ignored.
To enter an unprintable character in the field value or to start a field value with a tab, use a backslash followed by the two-character hexadecimal representation of the desired character (see ASCII in a UNIX reference manual). A space, for example, can be entered in the input data as \20. A backslash can be entered using two backslash characters. dmadmin recognizes all input in this format, but its greatest usefulness is for non-printing characters.
CONFIGURATION LIMITATIONS

The following are general limitations of the dynamic domain re-configuration capability:

Values for key fields (as indicated in the following sections) may not be modified. Key fields can be modified, when the system is down, by reloading the configuration file.

Dynamic deletions cannot be applied when local domains are active (the corresponding gateway group is running).

RESTRICTIONS FOR CONFIGURATION FIELD IDENTIFIERS/UPDATES

The following sections describe, for each DMCONFIG section, what the field identifiers are for each DMCONFIG field, what the field type of the identifier is, and when the field can be updated. All applicable field values are returned with the retrieval operations. Fields that are allowed and/or required for adding a record are described in dmconfig. The following fields indicated as key are key fields that are used to uniquely identify a record within section. These key fields are required to be in the input buffer when updates are done and are not allowed to be updated dynamically. The Update column indicates when a field can be updated. The possible values are:

Yes
Can be updated at any time.
NoGW
Cannot be updated dynamically while the gateway group representing the local domain is running.
No
Cannot be updated dynamically while at least one gateway group is running.

CONFIGURING THE DM_LOCAL_DOMAINS SECTION

The following table lists the fields in the *DM_LOCAL_DOMAINS section.

Table B-1 *DM_LOCAL_DOMAINS SECTION

Field Identifier Field Type Update Notes

TA_LDOM

string

NoGW

key

TA_AUDITLOG

string

Yes

TA_BLOCKTIME

numeric

Yes

TA_DOMAINID

string

NoGW

TA_DMTLOGDEV

string

NoGW

TA_DMTLOGNAME

string

NoGW

TA_DMTLOGSIZE

numeric

NoGW

TA_GWGRP

string

NoGW

TA_MAXDATALEN

numeric

Yes

TA_MAXRDOM

numeric

Yes

TA_MAXRDTRAN

numeric

NoGW

TA_MAXTRAN

numeric

NoGW

TA_SECURITY

string

Yes

format: {NONE | APP_PW | DM_PW}

TA_TYPE

string

NoGW

format: {TDOMAIN | OSITP | SNA}

CONFIGURING THE DM_REMOTE_DOMAINS SECTION

The following table lists the fields in the *DM_REMOTE_DOMAINS section.

Table B-2 *DM_REMOTE_DOMAINS SECTION

Field Identifier Field Type Update Notes

TA_RDOM

string

No

key

TA_DOMAINID

string

No

TA_TYPE

string

No

format: {TDOMAIN | OSITP | SNA}

CONFIGURING THE DM_TDOMAIN SECTION

The *DM_TDOMAIN section contains the network addressing parameters required by TDOMAIN type domains. The following lists the fields in this section:

Table B-3 *DM_TDOMAIN SECTION

Field Identifier Field Type Update Notes

TA_LDOM or TA_RDOM

string

No/NoGW

key

TA_NWADDR

string

No/NoGW

ASCII format (no embedded NULL characters)

TA_NWDEVICE

string

No/NoGW

If the domain identifier (TA_LDOM) is a local domain identifier, then the TA_NWADDR and TA_NWDEVICE fields can be updated if the gateway group representing that local domain is not running.
CONFIGURING THE DM_OSITP SECTION

The *DM_OSITP section contains the network addressing parameters required by OSITP type domains. The following lists the fields in this section:

Table B-4 *DM_OSITP SECTION

Field Identifier Field Type Update Notes

TA_LDOM or TA_RDOM

string

No/NoGW

key

TA_APT

string

No/NoGW

TA_AEQ

string

No/NoGW

TA_AET

string

No/NoGW

TA_ACN

string

No/NoGW

TA_APID

string

No/NoGW

TA_AEID

string

No/NoGW

TA_PROFILE

string

No/NoGW

If the domain identifier (TA_LDOM) is a local domain identifier, then the other fields in this table can be updated if the gateway group representing that local domain is not running.
CONFIGURING THE DM_LOCAL_SERVICES SECTION

The following table lists the fields in the *DM_LOCAL_SERVICES section.

Table B-5 *DM_LOCAL_SERVICES SECTION

Field Identifier Field Type Update Notes

TA_SERVICENAME

string

No

key

TA_LDOM

string

Yes

TA_RNAME

string

Yes

TA_ACLNAME

string

Yes

CONFIGURING THE DM_REMOTE_SERVICES SECTION

The following table lists the fields in the *DM_REMOTE_SERVICES section.

Table B-6 *DM_REMOTE_SERVICES SECTION

Field Identifier Field Type Update Notes

TA_SERVICENAME

string

No

key

TA_RDOM

string

No

key

TA_LDOM

string

No

key

TA_RNAME

string

Yes

TA_CONV

string

NoGW

format: { Y | N }

TA_ROUTINGNAME

string

Yes

TA_TRANTIME

numeric

Yes

CONFIGURING THE DM_ROUTING SECTION

The following table lists the fields in the *DM_ROUTING section.

Table B-7 *DM_ROUTING SECTION

Field Identifier Field Type Update Notes

TA_ROUTINGNAME

string

No

key

TA_FIELD

string

Yes

TA_RANGE

string

Yes

TA_BUFTYPE

string

Yes

CONFIGURING THE DM_ACCESS_CONTROL SECTION

The following table lists the fields in the *DM_ACCESS_CONTROL section.

Table B-8 *DM_ACCESS_CONTROL SECTION

Field Identifier Field Type Update Notes

TA_ACLNAME

string

No

key

TA_RDOM

string

Yes

CONFIGURING THE DM_PASSWORDS SECTION

The following table lists the fields in the *DM_PASSWORDS section.

Table B-9 *DM_PASSWORDS SECTION

Field Identifier Field Type Update Notes

TA_LDOM

string

No

key

TA_RDOM

string

No

key

TA_LPWD

string

Yes

format: { Y | N | U }

TA_RPWD

string

Yes

format: { Y | N | U }

The TA_LPWD and TA_RPWD show the existence of a defined password for the local and/or the remote domain. Passwords are not displayed. If an UPDATE operation is selected, the value of the corresponding field must be set to U. The program will then prompt with echo turned off for the corresponding passwords.
DIAGNOSTICS IN CONFIGURATION MODE

dmadmin fails if it cannot allocate an FML typed buffer, if it cannot determine the /etc/passwd entry for the user, or if it cannot reset the environment variables FIELDTBLS or FLDTBLDIR.
The return value printed by dmadmin after each operation completes indicates the status of the requested operation. There are three classes of return values.
The following return values indicate a problem with permissions or a TUXEDO System/T communications error. They indicate that the operation did not complete successfully.

[TAEPERM]
The calling process specified an ADD, UPDATE, or DELETE operation but it is not running as the System/T administrator. Update operations must be run by the administrator (that is, the user specified in the UID attribute of the RESOURCES section of the TUXCONFIG file).
[TAESYSTEM]
A TUXEDO System/T error has occurred. The exact nature of the error is written to userlog.
[TAEOS]
An operating system error has occurred.
[TAETIME]
A blocking timeout occurred. The input buffer is not updated so no information is returned for retrieval operations. The status of update operations can be checked by doing a retrieval on the record that was being updated.

The following return values indicate a problem in doing the operation itself and generally are semantic problems with the application data in the input buffer. The string field TA_STATUS will be set in the output buffer and will contain short text describing the problem. The string field TA_BADFLDNAME will be set to the field name for the field containing the value that caused the problem (assuming the error can be attributed to a single field).

[TAECONFIG]
An error occurred while reading the BDMCONFIG file.
[TAEDUPLICATE]
The operation attempted to add a duplicate record.
[TAEINCONSIS]
A field value or set of field values are inconsistently specified.
[TAENOTFOUND]
The record specified for the operation was not found.
[TAENOSPACE]
The operation attempted to do an update but there was not enough space in the BDMCONFIG file.
[TAERANGE]
A field value is out of range or is invalid.
[TAEREQUIRED]
A field value is required but not present.
[TAESIZE]
A field value for a string field is too long.
[TAEUPDATE]
The operation attempted to do an update that is not allowed.

The following return values indicate that the operation was successful.

[TAOK]
The operation succeeded. No updates were done to the BDMCONFIG file.
[TAUPDATED]
The operation succeeded. Updates were made to the BDMCONFIG file.

When using dmunloadcf to print entries in the configuration, optional field values are not printed if they are not set (for strings) or 0 (for integers). These fields will always appear in the output buffer when using dmadmin. In this way, it makes it easier for the administrator to retrieve an entry and update a field that previously was not set. The entry will have the field name followed by a tab but no field value.
CONFIGURATION EXAMPLE

In the following example, dmadmin is used to add a new remote domain. For illustration purposes, ed is used for the editor.
$ EDITOR=ed dmadmin
> config
Sections:
       1) LOCAL_DOMAINS       2) REMOTE_DOMAINS
       3) LOCAL_SERVICES      4) REMOTE_SERVICES
       5) ROUTING             6) ACCESS_CONTROL
       7) PASSWORDS           8) TDOMAIN
       9) OSITP              10) SNA
       11) QUIT
Enter Section [1]: 2
Operations:
       1) FIRST               2) NEXT
       3) RETRIEVE            4) ADD
       5) UPDATE              6) DELETE
       7) NEW_SECTION         8) QUIT
Enter Operation [1]: 4
Enter editor to add/modify fields [n]? y
a
TA_RDOM                       B05
TA_DOMAINID                   BA.BANK05
TA_TYPE                       TDOMAIN
w
53
q
Perform operation [y]? <return>
Return value TAUPDATED
Buffer contents:
TA_OPERATION                  4
TA_SECTION                    2
TA_DOMAINID                   BA.BANK05
TA_RDOM                       B05
TA_TYPE                       TDOMAIN
TA_STATUS                     Update completed successfully
Operations:
       1) FIRST               2) NEXT
       3) RETRIEVE            4) ADD
       5) UPDATE              6) DELETE
       7) NEW_SECTION         8) QUIT
Enter Operation [4]: 7
Sections:
       1) LOCAL_DOMAINS       2) REMOTE_DOMAINS
       3) LOCAL_SERVICES      4) REMOTE_SERVICES
       5) ROUTING             6) ACCESS_CONTROL
       7) PASSWORDS           8) TDOMAIN
       9) OSITP              10) QUIT
Enter Section [1]: 8
Operations:
       1) FIRST               2) NEXT
       3) RETRIEVE            4) ADD
       5) UPDATE              6) DELETE
       7) NEW_SECTION         8) QUIT
Enter Operation [6]: 4
Enter editor to add/modify fields [n]? y
a
TA_RDOM                       B05
TA_NWADDR                     0x00020401c0066d05
TA_NWDEVICE                   /dev/tcp
w
55
q
Perform operation [y]? <return>
Return value TAUPDATED
Buffer contents:
TA_OPERATION                  4
TA_SECTION                    8
TA_RDOM                       B05
TA_NWADDR                     0x00020401c0066d05
TA_NWDEVICE                   /dev/tcp
TA_STATUS                     Update completed successfully
Operations:
       1) FIRST               2) NEXT
       3) RETRIEVE            4) ADD
       5) UPDATE              6) DELETE
       7) NEW_SECTION         8) QUIT
Enter Operation [4]: 8
> quit
The dmadmin program ends.
SECURITY

If dmadmin is run with the application administrator's UID, it assumes a trusted user and Security is bypassed. If dmadmin is run with another user ID, and if the security option is enabled in the TUXCONFIG file, then the corresponding application password is required to start the dmadmin program. If standard input is a terminal, then dmadmin will prompt the user for the password with echo turned off. If standard input is not a terminal, the password is retrieved from the environment variable, APP_PW. If this environment variable is not specified and an application password is required, then dmadmin will fail to start.
When running with another user ID (other than the UID of the administrator) only a limited set of commands is available.
ENVIRONMENT VARIABLES

dmadmin resets the FIELDTBLS and FLDTBLDIR environment variables to pick up the ${TUXDIR}/udataobj/dmadmin field table. Hence, the TUXDIR environment variable should be set correctly.
If the application requires security and the standard input to dmadmin is not from a terminal, then the APP_PW environment variable must be set to the corresponding application password.
The TUXCONFIG environment variable should be set to the pathname of the TUXEDO System/T configuration file.
GENERAL DIAGNOSTICS

If the dmadmin command is entered before the system has been booted, the following message is displayed:
No bulletin board exists. Only logging commands are available.
dmadmin then prompts for the corresponding commands.
If an incorrect application password is entered or is not available to a shell script through the environment, then a log message is generated, the following message is displayed, and the command terminates:
Invalid password entered.
INTEROPERABILITY

dmadmin for OSI must be installed on TUXEDO System/T R6.4. Other nodes in the same domain with an R6.1 gateway may be TUXEDO System/T R4.2.2 or later.
PORTABILITY

dmadmin for OSI is supported as a TUXEDO System/T-supplied administrative tool on UNIX operating systems only.
SEE ALSO

dmloadcf, tmadmin, dmconfig, DMADM, addusr, delusr
TUXEDO /Domain Guide

**Table B-1 *DM_LOCAL_DOMAINS SECTION**
Field Identifier	Field Type	Update	Notes
TA_LDOM	string	NoGW	key
TA_AUDITLOG	string	Yes
TA_BLOCKTIME	numeric	Yes
TA_DOMAINID	string	NoGW
TA_DMTLOGDEV	string	NoGW
TA_DMTLOGNAME	string	NoGW
TA_DMTLOGSIZE	numeric	NoGW
TA_GWGRP	string	NoGW
TA_MAXDATALEN	numeric	Yes
TA_MAXRDOM	numeric	Yes
TA_MAXRDTRAN	numeric	NoGW
TA_MAXTRAN	numeric	NoGW
TA_SECURITY	string	Yes	format: {NONE \| APP_PW \| DM_PW}
TA_TYPE	string	NoGW	format: {TDOMAIN \| OSITP \| SNA}

**Table B-2 *DM_REMOTE_DOMAINS SECTION**
Field Identifier	Field Type	Update	Notes
TA_RDOM	string	No	key
TA_DOMAINID	string	No
TA_TYPE	string	No	format: {TDOMAIN \| OSITP \| SNA}

**Table B-3 *DM_TDOMAIN SECTION**
Field Identifier	Field Type	Update	Notes
TA_LDOM or TA_RDOM	string	No/NoGW	key
TA_NWADDR	string	No/NoGW	ASCII format (no embedded NULL characters)
TA_NWDEVICE	string	No/NoGW

**Table B-4 *DM_OSITP SECTION**
Field Identifier	Field Type	Update	Notes
TA_LDOM or TA_RDOM	string	No/NoGW	key
TA_APT	string	No/NoGW
TA_AEQ	string	No/NoGW
TA_AET	string	No/NoGW
TA_ACN	string	No/NoGW
TA_APID	string	No/NoGW
TA_AEID	string	No/NoGW
TA_PROFILE	string	No/NoGW

**Table B-5 *DM_LOCAL_SERVICES SECTION**
Field Identifier	Field Type	Update	Notes
TA_SERVICENAME	string	No	key
TA_LDOM	string	Yes
TA_RNAME	string	Yes
TA_ACLNAME	string	Yes

**Table B-6 *DM_REMOTE_SERVICES SECTION**
Field Identifier	Field Type	Update	Notes
TA_SERVICENAME	string	No	key
TA_RDOM	string	No	key
TA_LDOM	string	No	key
TA_RNAME	string	Yes
TA_CONV	string	NoGW	format: { Y \| N }
TA_ROUTINGNAME	string	Yes
TA_TRANTIME	numeric	Yes

**Table B-7 *DM_ROUTING SECTION**
Field Identifier	Field Type	Update	Notes
TA_ROUTINGNAME	string	No	key
TA_FIELD	string	Yes
TA_RANGE	string	Yes
TA_BUFTYPE	string	Yes

**Table B-8 *DM_ACCESS_CONTROL SECTION**
Field Identifier	Field Type	Update	Notes
TA_ACLNAME	string	No	key
TA_RDOM	string	Yes

**Table B-9 *DM_PASSWORDS SECTION**
Field Identifier	Field Type	Update	Notes
TA_LDOM	string	No	key
TA_RDOM	string	No	key
TA_LPWD	string	Yes	format: { Y \| N \| U }
TA_RPWD	string	Yes	format: { Y \| N \| U }

dmconfig

TUXEDO System/T ASCII domain configuration file
DESCRIPTION

dmconfig is the ASCII version of a TUXEDO System/Domain domain configuration file; it is also referred to by its environmental variable name: DMCONFIG. The dmconfig file is parsed and loaded into a binary version by the dmloadcf utility. The binary configuration file, called the BDMCONFIG file, contains information used by domain gateways to initialize the context required for communications with other domains. dmadmin uses the binary file (or a copy of it) in its monitoring activity. There will be one BDMCONFIG file for each TUXEDO System/Domain application that uses the /Domain feature.
A DMCONFIG file, and its binary BDMCONFIG counterpart, are analogous to the UBBCONFIG and TUXCONFIG files of a non-/Domain System/T application. The DMCONFIG file extends the definition of a non-/Domain System/T application so that the application becomes a domain.
Definitions

A TUXEDO System/Domain Application is defined as the environment described in a single TUXCONFIG file. A System/T Application can communicate with another System/T Application or with another TP Application via a domain gateway group. In "TUXEDO System/Domain" terms, an Application is the same as a TP Domain.
A Gateway Group is a collection of domain gateway processes that provide communication services with a specific type of TP Domain.
A Domain Gateway is a TUXEDO System/Domain process that relays requests and replies to another TP Domain.
A Local Domain characterizes a part of the application (set or subset of services) that is made available to other domains. A Local Domain is always represented by a Domain Gateway Group, and both terms are used as synonyms.
A Remote Domain is a remote application that is accessed through a Gateway Group. The remote application may be another TUXEDO System/Domain application or an application running under another TP system.
A Remote Service is a service provided by a remote domain that is made available to the local application through a Gateway Group.
A Local Service is a service of a local domain that is made available to remote domains through a Gateway Group.
Configuration File Format

The format of a domain configuration file is as follows:
The file is made up of eight possible specification sections. Lines beginning with an asterisk (*) indicate the beginning of a specification section. Each such line contains the name of the section immediately following the *. Allowable section names are: DM_LOCAL_DOMAINS, DM_REMOTE_DOMAINS, DM_LOCAL_SERVICES, DM_REMOTE_SERVICES, DM_ROUTING, DM_ACCESS_CONTROL and DM_domtype, where domtype is OSITP or TDOMAIN. The DM_LOCAL_DOMAINS section must precede the DM_REMOTE_DOMAINS section.
Parameters are generally specified by: KEYWORD = value. This sets KEYWORD to value. Valid keywords are described in the following sections. KEYWORDs are reserved; they can not be used as values unless they are quoted.

Lines beginning with the reserved word, DEFAULT:, contain parameter specifications that apply to any lines that follow them in the section in which they appear. Default specifications can be used in all sections. They can appear more than once in the same section. The format for these lines is:
DEFAULT: [ KEYWORD1 = value1 [ KEYWORD2 = value2 [...]]]
The values set on this line remain in effect until reset by another DEFAULT: line, or until the end of the section is reached. These values can also be overridden on non-DEFAULT: lines by placing the optional parameter setting on the line. If on a non-DEFAULT: line, the parameter setting is valid for that line only; lines that follow revert to the default setting. If DEFAULT: appears on a line by itself, all previously set defaults are cleared and their values revert to the system defaults.
If a value is numeric, standard C notation is used to denote the base (that is, 0x prefix for base 16 (hexadecimal), 0 prefix for base 8 (octal), and no prefix for base 10 (decimal)). The range of values acceptable for a numeric parameter are given under the description of that parameter.
If a value is an identifier, standard C rules are used. An identifier must start with an alphabetic character or underscore and contain only alphanumeric characters or underscores. The maximum allowable length of an identifier is 30 (not including the terminating null). An identifier cannot be the same as any KEYWORD.
A value that is neither an integer number or an identifier must be enclosed in double quotes. Certain special characters can be escaped inside a string using a backslash. "\\'' translates to a single backslash. ``\"\"'' translates to a double quote. "\n" translates to a newline. "\t" translates to a tab. "\f" translates to a formfeed. "\x" (where 'x' is any character other than one of the previously mentioned special characters) translates to 'x'.
Input fields are separated by at least one space (or tab) character.

"#" introduces a comment. A newline ends a comment.

Blank lines and comments are ignored.

Comments can be freely attached to the end of any line.

Lines are continued by placing at least one tab after the newline. Comments can not be continued.
VERSION=string_value
where string_value can be any value. The field is not checked by the software; it is provided simply as a place where the customer can enter a string that may have some documentation value to the application.

The DM_LOCAL_DOMAINS Section

This section identifies local domains and their associated gateway groups. The section must have an entry for each gateway group (Local Domain). Each entry specifies the parameters required for the domain gateway processes running in that group.
Entries have the form:
LDOM required parameters [optional parameters]
where LDOM is an identifier value used to name each local domain. LDOM must be unique within a particular configuration. As you will see in the description of the *DM_LOCAL_SERVICES section, LDOM is the identifier that connects local services with a particular gateway group.
The following are the required parameters:

GWGRP = identifier
specifies the name of the gateway server group (the name provided in the TUXCONFIG file) representing this local domain. There is a one-to-one relationship between a DOMAINID and the name of the gateway server group, that is, each GWGRP must have its own, unique DOMAINID.
TYPE = identifier
is used for grouping local domain into classes. TYPE can be set to one of the following values: TDOMAIN or OSITP. The TDOMAIN value indicates that this local domain can only communicate with another TUXEDO System/Domain. The OSITP value indicates that this local domain communicates with another TP Domain via the OSI-TP protocol. Domain types must be defined in the $TUXDIR/udataobj/DMTYPE file.
DOMAINID = string
is used to identify the local domain. DOMAINID must be unique across both local and remote domains. The value of string can be a sequence of characters (for example, "BA.CENTRAL01"), or a sequence of hexadecimal digits preceded by "0x" (for example, "0x0002FF98C0000B9D6"). DOMAINID must be 32 octets or fewer in length. If the value is a string, it must be 32 characters or fewer (counting the trailing null).
DMTLOGDEV = string
specifies the TUXEDO filesystem that contains the Domain transaction log (DMTLOG) for this machine. The DMTLOG is stored as a TUXEDO System VTOC table on the device. If this parameter is not specified (and it should not be specified if TYPE=SNADOM), the domain gateway group is not allowed to process requests in transaction mode. Local domains running on the same machine can share the same DMTLOGDEV filesystem, but each local domain must have its own log (a table in the DMTLOGDEV) named as specified by the DMTLOGNAME keyword.

Optional parameters describe resources and limits used in the operation of domain gateways:

AUDITLOG = string
specifies the name of the audit log file for this local domain. The audit log feature is activated from the dmadmin command and records all the operations within this local domain. If the audit log feature is active and this parameter is not specified, the file DMmmddyy.LOG (where mm=month, dd=day, and yy=year) is created in the directory specified by the $APPDIR environment variable or the APPDIR keyword of the *MACHINES section of the TUXCONFIG file.
BLOCKTIME = numeric
specifies the maximum wait time allowed for a blocking call. The value sets a multiplier of the SCANUNIT parameters specified in the TUXCONFIG file. The value SCANUNIT * BLOCKTIME must be greater than or equal to SCANUNIT and less than 32,768 seconds. If this parameter is not specified, the default value is set to the value of the BLOCKTIME parameter specified in the TUXCONFIG file. A timeout always implies a failure of the affected request. Notice that the timeout specified for transactions in the TUXCONFIG will always be used when the request is issued within a transaction.
DMTLOGNAME = identifier
specifies the name of the domain transaction log for this domain. This name must be unique when the same DMTLOGDEV is used for several local domains. If not specified, the default is the string ``DMTLOG''. The name must be 30 characters or less.
DMTLOGSIZE = numeric
specifies the numeric size, in pages, of the Domain transaction log for this machine. It must be greater than 0 and less than the amount of available space on the TUXEDO filesystem. If not specified, the default is 100 pages.
MAXDATALEN = numeric
specifies a maximum amount of data (in bytes) that can be sent to or from any services advertised by this local domain. There is no limit if this parameter is not specified.
MAXRDOM = numeric
specifies the maximum number of connections (or dialogues if the domain is of type OSITP) allowed per gateway. There is no limit if this parameter is not specified.
MAXRDTRAN = numeric
specifies the maximum number of domains that can be involved in a transaction. It must be greater than 0 and less than 32,768. If not specified, the default is 16.
MAXTRAN = numeric
specifies the maximum number of simultaneous global transactions allowed on this local domain. It must be greater than or equal to 0 and less than or equal to the MAXGTT parameter specified in the TUXCONFIG file. If not specified, the default is the value of MAXGTT.
MAXSENDLEN = numeric
specifies the maximum length (in bytes) of messages sent or received by this local domain. If this parameter is set all messages sent or received will be broken up into packets of no more than MAXSENDLEN bytes. There is no limit if this parameter is not specified.
SECURITY = value
specifies the type of application security to be enforced. The following description applies to security in an /SNA Domain.
The combined setting of the SECURITY parameter in the UBBCONFIG and the DMCONFIG file have the following effects:
When the DMCONFIG SECURITY parameter is set to NONE or APP_PW, no action is taken by the /SNA Domain gateway with regard to security.
However, when the UBBCONFIG file is configured with SECURITY set to APP_PW, dmloadcf and dmunloadcf will require entering of an application password. The application password is validated by an AUTHSVC when clients join the application. The AUTHSVC is provided by the user application.
If security is to be enforced for each request inbound from CICS to a local /TDOMAIN or outbound to CICS from a local /TDOMAIN, the UBBCONFIG file SECURITY parameter must be set to one of: USER_AUTH, ACL, or MANDATORY_ACL and the DMCONFIG file SECURITY parameter must be set to DM_USER_PW.
When the DMCONFIG SECURITY parameter is set to USER_PW, and the UBBCONFIG file SECURITY parameter is set to USER_AUTH, ACL, or MANDATORY_ACL the following applies:
When a request is being received from CICS the domain access control list in the DMCONFIG file for the local service (if present) is checked to see if requests from the remote domain are permitted. If the DMCONFIG file does not contain an access control list for the local service, the service is accessible.
If access is permitted, the remote userid is extracted from the conversation startup request from CICS. The remote userid is used to find the local userid and password in the domain security table. This local userid and password will be used for subsequent ACL or MANDATORY_ACL security checking as and if specified in the UBBCONFIG file.
(IMPORTANT: If the application has set UBBCONFIG SECURITY to USER_AUTH, and is using its own AUTHSVC, the least significant 17 bits of the local application password must be able to be stored and subsequently used as a local userid for mapping to remote usernames and passwords in the domain security table.)
When the DMCONFIG SECURITY parameter is set to DM_PW, and the UBBCONFIG file is set to USER_AUTH, ACL, or MANDATORY_ACL, the following applies:
For requests sent from CICS, the remote userid is extracted from the conversation startup request from CICS. If a remote password is also available in the startup request, it is checked. The remote userid is mapped to the remote DomainID and password. The remote DomainID are used for further ACL checking.
The domain administrator can add or delete users from the domain security table. Local userids and passwords corresponding to remote userids and passwords are entered into the domain security table in two ways: first, through data entry panels in the TUXEDO System administration Graphical Administrative Interface, and second, by using the dmadmin command dmusradd.

The DM_REMOTE_DOMAINS Section

This section identifies the known set of remote domains and their characteristics.
Entries have the form:
RDOM   required parameters 
where RDOM is an identifier value used to identify each remote domain known to this configuration. RDOM must be unique within the configuration.
The following parameters are required:

TYPE = identifier
is used for grouping remote domain into classes. TYPE can be set to one of the following values: TDOMAIN, OSITP or SNA. The TDOMAIN value indicates that this remote domain can only communicate with another TUXEDO System/Domain Domain. The OSITP value indicates that this remote domain communicates with another TP domain via the OSI-TP protocol.
DOMAINID = string
is used to identify a remote domain. DOMAINID must be 32 octets or fewer in length. If the value is a string, it must be 32 characters or fewer (counting the trailing null). DOMAINID must be unique across remote domains. The value of string can be a sequence of characters or a sequence of hexadecimal digits preceded by "0x".

There are no optional parameters for this section.
The DM_TDOMAIN Section

This section defines the addressing information required by domains of type TDOMAIN. This section should have an entry per local domain if requests from remote domains to local services are accepted on that local domain (gateway group), and an entry per remote domain accessible by the defined local domains.
Entries have the form:
DOM   required parameters [optional parameters] 
where DOM is an identifier value used to identify either a local domain (LDOM) or a remote domain (RDOM) in the *DM_LOCAL_DOMAINS section or in the *DM_REMOTE_DOMAINS section. The DOM identifier must match a previously defined LDOM in the *DM_LOCAL_DOMAINS sections or RDOM in the *DM_REMOTE_DOMAINS section.
The following parameter is required:

NWADDR = string
This parameter specifies the network address used by a local or a remote domain to accept connections from other TUXEDO System/Domain Domains. If string has the form ``0xhex-digits'', it must contain an even number of valid hexadecimal digits.

The following parameter is optional:

NWDEVICE = string
Specifies the device file name to be used when binding to the listening address of a local or a remote domain. If the networking functionality is TLI-based, the device name must be an absolute pathname. If the networking functionality is Sockets-based, this parameter does not need to be specified.
NWIDLETIME = numeric
Specifies the maximum time allowed for a connection to be idle or unused. When this time is reached, the idle connection is terminated. The numeric value represents a time in minutes. If this keyword is not specified, then idle connections will be maintained until the gateway handling the connection is shutdown.
Notice that multiple entries for a particular domain may be defined in this table. Multiple addresses specified for a remote domain mean that the first address (the first entry in the table for the remote domain) should be used to establish the connection and the other addresses should be used as back-up addresses in case of failure of the connection setup to the first address. Multiple addresses specified for a local domain mean that multiple listening ports are available on the same or different types of networks.

The DM_OSITP Section

This section defines the addressing information required by domains of type OSITP. This section should have one entry per gateway group (local domain), and one entry per remote domain of type OSITP.
Entries have the form:
DOM   required parameters [optional parameters] 
where DOM is an identifier value used to identify a local domain (LDOM) or a remote domain (RDOM) in the *DM_LOCAL_DOMAINS section or in the *DM_REMOTE_DOMAINS section. The DOM identifier must match a previously defined LDOM in the *DM_LOCAL_DOMAINS sections or RDOM in the *DM_REMOTE_DOMAINS section.
The following are required parameters:

APT = string
This parameter specifies an OSI Application Process Title (APT). An APT may be a name (i.e., the Directory Name of an Application Process Title) or an object identifier (i.e., a sequence of integer values separated by periods).
AEQ = string
This parameter specifies an OSI Application Entity Qualifier (AEQ). An AEQ may be a name (i.e., the relative distinguished name of a particular Application Entity) or an integer (i.e., if the APT is an object identifier).
NWDEVICE = string
Specifies the device name to be used when binding to an XAP dialogue instance. It may be an absolute pathname of a device filename or just an identifier of a device. The value of the string is specific to the XAP-TP provider.

The following are optional parameters:

AET = string
This parameter specifies an OSI Application Entity Title (AET). An AET is formed from an Application Process Title (APT) and an Application Entity Qualifier (AEQ), i.e. in ASN.1 AET is defined as a SEQUENCE { APT, AEQ } where APT and AET are of type ANY. Three main formats are accepted for the value of string:

encoded string
This is a single value as a hexadecimal octet string which a represents a valid BER encoding of the AET, e.g. AET = "0x06062B80CE0F0107".
{object identifier}, {integer}
The first element represents the APT defined as an object identifier (i.e., a sequence of integer values separated by periods) and the second element represents an AEQ defined as an integer constant, e.g., AET = "{1.3.15.0.3},{1}".
{string}, {string}
This format allows the APT and the AEQ to be defined as string constants, e.g., AET = "{BA.CENTRAL01},{TUXEDO}".

ACN = {XATMI | UDT}
This parameter specifies the object identifier of the Application Context Name (ACN) used by this domain. Current allowed application contexts are: the XATMI-ASE (XATMI) and the UDT-ASE (UDT). If this parameter is not specified, the ACN is set to the object identifier of the XATMI-ASE Application Context.
APID = integer
This parameter specifies an OSI Application Process Invocation Identifier (APID).
AEID = integer
This parameter specifies an OSI Application Entity Invocation Identifier (AEID).
PROFILE = identifier
This parameter specifies the OSI TP profile used by this domain and is used to determine the required OSI TP functional units. PROFILE can be set to one of the following values: ATP11, ATP21, ATP31, ATP12, ATP22, and ATP32. The UDT ASE application context allows the use of any of these profiles. The XATMI-ASE application context only allows profiles ATP11, ATP21 and ATP31. Profiles ATP11, ATP21 and ATP31 use the Dialogue, Polarized Control and Handshake functional units. Profiles ATP12, ATP22 and ATP32 use the Dialogue, Shared Control, and Handshake functional units. Profiles ATP11 and ATP12 do not use OSI TP transactions (the Commit functional unit is not used). Profiles ATP21 and ATP22 require the Commit, Unchained Transactions, and Recovery functional units. Profiles ATP31 and ATP32 require the Commit, Chained Transactions, and Recovery functional units. By default, the ATP21 profile is always selected.
URCH = string
This parameter specifies the user portion of the OSITP Recovery Context Handle. It may be required by the XAP-TP provider in order to perform recovery of distributed transactions after a communications line or system failure.

The DM_ACCESS_CONTROL Section

This section specifies the access control lists used by local domain. Lines in this section are of the form:
ACL_NAME   required parameters
where ACL_NAME is a (identifier) name used to identify a particular access control list; it must be 15 characters or less in length.
Required parameters are:

ACLIST = identifier [,identifier]
where an ACLIST is composed of one or more remote domain names (RDOM) separated by commas. The wildcard character (*) can be used to specify that all the remote domains defined in the *DM_REMOTE_DOMAINS section can access a local domain.

The DM_LOCAL_SERVICES Section

This section provides information on the services exported by each local domain. This section is optional and if it is not specified then all local domains defined in the *DM_LOCAL_DOMAINS section accept requests to all of the services advertised by the TUXEDO System/Domain application. If this section is defined then it should be used to restrict the set of local services that can be requested from a remote domain.
Lines within this section have the form:
service    [optional parameters] 
where service is the (identifier) local name of the exported service, and it must be 15 characters or fewer in length. This name corresponds to a name advertised by one or more servers running with the local TUXEDO System/Domain application. Notice that exported services inherit the default or special properties specified for the service in an entry in the SERVICES section of the TUXCONFIG file. Some of these parameters are: LOAD, PRIO, AUTOTRAN, ROUTING, BUFTYPE, and TRANTIME.
Optional parameters are:

ACL = identifier
specifies the name of the access control list (ACL) to be used by the local domain to restrict requests made to this service by remote domains. The name of the ACL is defined in the *DM_ACCESS_CONTROL section. If this parameter is not specified then access control will not be performed for requests to this service.
LDOM = identifier
specifies the name identifying the local domain exporting this service. If this keyword is not specified then all the local domains defined in the *DM_LOCAL_DOMAINS section will accept requests to this local service.
RNAME = string
specifies the name exported to remote domains. This name will be used by the remote domains for request to this service. If this parameter is not specified, the local service name is supposed to be the name used by any remote domain.

The DM_REMOTE_SERVICES Section

This section provides information on services "imported" and available on remote domains. Lines within this *DM_REMOTE_SERVICES section have the form:
service    [optional parameters] 
where service is the (identifier) name used by the local TUXEDO System/Domain application for a particular remote service. Remote services are associated with a particular remote domain.
Optional Parameters are:

AUTOTRAN= { Y | N }
specifies whether or not a transaction should automatically be started if a request message is received that is not already in transaction mode. The default is No.
BLOCKTIME = numeric
specifies the maximum wait time allowed for a reply to this remote service. The value sets a multiplier of the SCANUNIT parameters specified in the TUXCONFIG file. The value SCANUNIT * BLOCKTIME must be greater than or equal to SCANUNIT and less than 32,768 seconds. A timeout always implies a failure of the affected transaction or request.
CONV = { Y | N }
specifies whether (Y) or not (N) the remote service is a conversational service. The default value is N.
LDOM = identifier
specifies the name of a local domain in charge of routing requests to this remote service. The gateway group associated with the local domain advertises service in the TUXEDO System/Domain Bulletin Board. If this parameter is not specified then all the local domains will be able to accept requests to this remote service. The service request will be then redirected to a remote domain of the same type (see RDOM keyword).
LOAD = integer
specifies that the remote service imposes a load of integer units. The value of LOAD can be between 1 and 32767 inclusive. If not specified, the default is 50. A higher number indicates a greater load.
PRIO = integer
specifies the dequeing priority of service requests to this remote service. The value of PRIO must be greater than 0 and less than or equal to 100, with 100 being the highest priority. The default is 50.
RDOM = identifier
specifies the name of the remote domain responsible for the actual execution of this service. If this parameter is not specified and a routing criteria (see ROUTING keyword) is not specified, then the local domain assumes that any remote domain of the same type accepts this service and it selects a known domain (a domain to which a connection already exists) or remote domain from the \**DM_REMOTE_DOMAINS section.
RNAME = string
specifies the actual service name expected by the remote domain. If this parameter is not specified, the remote service name is the same as the name specified in service.
ROUTING = identifier
when more than one remote domain offers the same service, a local domain can perform data dependent routing if this optional parameter is specified. The identifier specifies the name of the routing criteria used for this data dependent routing. If not specified, data dependent routing is not done for this service. identifier must be 15 characters or less in length. If multiple entries exist for the same service name but with different RDOM parameters, the ROUTING parameter should be the same for all of these entries.
TRANTIME = integer
specifies the default timeout value in seconds for a transaction automatically started for the associated service. The value must be greater than or equal to 0 and less than 2147483648. The default is 30 seconds. A value of 0 implies the maximum timeout value for the machine.

The DM_ROUTING Section

This section provides information for data dependent routing of service requests using FML, VIEW, X_C_TYPE, and X_COMMON typed buffers. Lines within the DM_ROUTING section have the form:
CRITERION_NAME    required parameters 
where CRITERION_NAME is the (identifier) name of the routing entry that was specified on the services entry. CRITERION_NAME must be 15 characters or less in length.
Required parameters are:

FIELD = identifier
specifies the name of the routing field. It must be 30 characters or less. This field is assumed to be a field name that is identified in an FML field table (for FML buffers) or an FML view table (for VIEW, X_C_TYPE, or X_COMMON buffers). The FLDTBLDIR and FIELDTBLS environment variables are used to locate FML field tables, and the VIEWDIR and VIEWFILES environment variables are used to locate FML view tables.
RANGES = string
specifies the ranges and associated remote domain names (RDOM) for the routing field. string must be enclosed in double quotes. The format of string is a comma-separated ordered list of range/RDOM pairs (see the following EXAMPLES).
A range is either a single value (signed numeric value or character string in single quotes), or a range of the form "lower - upper" (where lower and upper are both signed numeric values or character strings in single quotes). Note that "lower" must be less than or equal to "upper". To embed a single quote in a character string value (as in O'Brien, for example), it must be preceded by two backslashes ('O'Brien'). The value MIN can be used to indicate the minimum value for the data type of the associated FIELD; for strings and arrays, it is the null string; for character fields, it is 0; for numeric values, it is the minimum numeric value that can be stored in the field. The value MAX can be used to indicate the maximum value for the data type of the associated FIELD; for strings and arrays, it is effectively an unlimited string of octal-255 characters; for a character field, it is a single octal-255 character; for numeric values, it is the maximum numeric value that can be stored in the field. Thus, "MIN - -5" is all numbers less than or equal to -5 and "6 - MAX" is all numbers greater than or equal to 6. The meta-character "*'' (wild-card) in the position of a range indicates any values not covered by the other ranges previously seen in the entry; only one wild-card range is allowed per entry and it should be last (ranges following it will be ignored).
The routing field can be of any data type supported in FML. A numeric routing field must have numeric range values and a string routing field must have string range values.
String range values for string, array, and character field types must be placed inside a pair of single quotes and can not be preceded by a sign. Short and long integer values are a string of digits, optionally preceded by a plus or minus sign. Floating point numbers are of the form accepted by the C compiler or atof(): an optional sign, then a string of digits optionally containing a decimal point, then an optional e or E followed by an optional sign or space, followed by an integer.
When a field value matches a range, the associated RDOM value specifies the remote domain to which the request should be routed. A RDOM value of "*" indicates that the request can go to any remote domain known by the gateway group.
Within a range/RDOM pair, the range is separated from the RDOM by a ":".
BUFTYPE = ~type1[:subtype1[,subtype2 . . . ]][;type2[:subtype3[, . . . ]]] . . .~
is a list of types and subtypes of data buffers for which this routing entry is valid. The types are restricted to be either FML, VIEW, X_C_TYPE, or X_COMMON. No subtype can be specified for type FML and subtypes are required for the other types ("*" is not allowed). Duplicate type/subtype pairs can not be specified for the same routing criterion name; more than one routing entry can have the same criterion name as long as the type/subtype pairs are unique. This parameter is required. If multiple buffer types are specified for a single routing entry, the data types of the routing field for each buffer type must be the same.

If the field value is not set (for FML buffers), or does not match any specific range and a wild-card range has not been specified, an error is returned to the application process that requested the execution of the remote service.
FILES

The BDMCONFIG environment variable is used to find the BDMCONFIG configuration file.
EXAMPLE1

The following configuration file defines a 5-site domain configuration. The example shows 4 Bank Branch domains communicating with a Central Bank Branch. Three of the Bank Branches run within other TUXEDO System/Domain domains. The fourth Branch runs under the control of another TP Domain and OSI-TP is used in the communication with that domain.
# TUXEDO DOMAIN CONFIGURATION FILE FOR THE CENTRAL BANK
#
#
*DM_LOCAL_DOMAINS
# <local domain name> <Gateway Group name> <domain type> <domain id> <log device>
#                     [<audit log>] [<blocktime>] 
#                     [<log name>] [<log offset>] [<log size>]
#                     [<maxrdom>] [<maxrdtran>] [<maxtran>]
#                     [<maxdatalen>] [<security>]
#                     [<tuxconfig>] [<tuxoffset>]
#
#
DEFAULT: SECURITY = NONE
c01 GWGRP = bankg1
TYPE = TDOMAIN
DOMAINID = "BA.CENTRAL01"
DMTLOGDEV = "/usr/apps/bank/DMTLOG"
DMTLOGNAME = "DMTLG_C01"

c02 GWGRP = bankg2
TYPE = OSITP
DOMAINID = "BA.CENTRAL01"
DMTLOGDEV = "/usr/apps/bank/DMTLOG"
DMTLOGNAME = "DMTLG_C02"
NWDEVICE = "OSITP"
URCH = "ABCD"
#
*DM_REMOTE_DOMAINS
#<remote domain name> <domain type> <domain id>
#
b01 TYPE = TDOMAIN
DOMAINID = "BA.BANK01"

b02 TYPE = TDOMAIN
DOMAINID = "BA.BANK02"

b03 TYPE = TDOMAIN
DOMAINID = "BA.BANK03"

b04 TYPE = OSITP
DOMAINID = "BA.BANK04"
NWDEVICE = "/dev/osi"
URCH = "ABCD"

*DM_TDOMAIN
#
# <local or remote domain name> <network address> [<nwdevice>]
#
# Local network addresses
c01 NWADDR = "0x0002ff98c00b9d6d" NWDEVICE ="/dev/tcp"
c01 NWADDR = "newyork01.65432" NWDEVICE ="/dev/starlan"
# Remote network addresses
b01 NWADDR = "0x00020401c00b6d05" NWDEVICE = "/dev/tcp"
b02 NWADDR = "dallas.65432" NWDEVICE = "/dev/starlan"
b03 NWADDR = "0x00021094c00b6d9c" NWDEVICE = "/dev/tcp"

*DM_OSITP
#
#<local or remote domain name> <apt> <aeq>
# [<aet>] [<acn>] [<apid>] [<aeid>]
# [<profile>]
#
c02 APT = "BA.CENTRAL01"
AEQ = "TUXEDO.R.4.2.1"
AET = "{1.3.15.0.3},{1}"
ACN = "XATMI"

b04 APT = "BA.BANK04"
AEQ = "TUXEDO.R.4.2.1"
AET = "{1.3.15.0.4},{1}"
ACN = "XATMI"

*DM_LOCAL_SERVICES
#<service_name> [<Local Domain name>] [<access control>] [<exported svcname>]
#
#
open_act ACL = branch
close_act ACL = branch
credit
debit
balance
loan LDOM = c02 ACL = loans

*DM_REMOTE_SERVICES
#<service_name> [<Remote domain name>] [<local domain name>]
# [<remote svcname>] [<routing>] [<conv>] [<trantime>]
#
#
tlr_add LDOM = c01 ROUTING = ACCOUNT
tlr_bal LDOM = c01 ROUTING = ACCOUNT
tlr_add RDOM = b04 LDOM = c02 RNAME ="TPSU002"
tlr_bal RDOM = b04 LDOM = c02 RNAME ="TPSU003"

*DM_ROUTING
# <routing criteria> <field> <typed buffer> <ranges>
#
ACCOUNT FIELD = branchid BUFTYPE ="VIEW:account"
RANGES ="MIN - 1000:b01, 1001-3000:b02, *:b03"

*DM_ACCESS_CONTROL
#<acl name> <Remote domain list>
#
branch ACLIST = b01, b02, b03
loans ACLIST = b04

EXAMPLE 2

This example shows the TUXEDO System/Domain Domain Configuration file required at one of the Bank Branches (BANK01).
#
#TUXEDO DOMAIN CONFIGURATION FILE FOR A BANK BRANCH
#
#
*DM_LOCAL_DOMAINS
#
b01	GWGRP = auth
	TYPE = TDOMAIN
	DOMAINID = "BA.BANK01"
	DMTLOGDEV = "/usr/apps/bank/DMTLOG"
*DM_REMOTE_DOMAINS
#
c01 TYPE = TDOMAIN
DOMAINID = "BA.CENTRAL01"

*DM_TDOMAIN
#
b01 NWADDR = "0x00021094c00b689c" NWDEVICE = "/dev/tcp"
c01 NWADDR = "0x0002ff98c00b9d6d" NWDEVICE = "/dev/tcp"
*DM_LOCAL_SERVICES
#
tlr_add ACL = central
tlr_bal ACL = central

*DM_REMOTE_SERVICES
#
OPA001 RNAME = "open_act"
CLA001 RNAME = "close_act"
CRD001 RNAME = "credit"
DBT001 RNAME = "debit"
BAL001 RNAME = "balance"

*DM_ACCESS_CONTROL
#
central ACLIST = c01

EXAMPLE 3

This example shows the configuration file entries for a BEA Connect SNA application:
# TUXEDO  DOMAIN CONFIGURATION FILE SAMPLE with BEA Connect SNA 
#
*DM_LOCAL_DOMAINS
#<local domain name> <Gateway Group Name> <domain type> <domain id> <log device>
#             [<audit log>] [<blocktime>]
#             [<log name>] [<logoffset>] [<logsize>]
#             [<maxrdomain>] [<maxrdtran>] [<maxtran>]
#             [<maxsendlen>] [<security>]
#             [<tuxconfig>] [<tuxoffset>]
#             [<luname>] {<modename>] [<netid>]
#
#
DEFAULT: SECURITY = NONE

ldom1 GWGRP=bankgrp1
     TYPE=SNADOM
     DOMAINID="TELLER"
     SECURITY=NONE
     
 
ldom2 GWGRP=bankgrp2
     TYPE=SNADOM
     DOMAINID="LOANS"
     
#
*DM_REMOTE_DOMAINS
#
#<remote domain name> <domain type> <domain id>
sna1     TYPE=SNADOM
     DOMAINID=MC
 
sna2     TYPE=SNADOM
     DOMAINID=VISA
#
*DM_SNADOM
#
# <remote domain name> <luname><netid><modename> <localLUname><credfile>
#
ldom1   LUNAME="L0F0024A"
     NETID="SNANET1"
     MODENAME="SNA62"
     SECURITY_TYPE="LOCAL"
     SYMDESTNAME="CICSSYSN"
     MAXSNASESS=10
ldom2 LUNAME="L0F0024B" NETID="SNANET1" MODENAME="SNA62" SECURITY_TYPE="LOCAL" SYMDESTNAME="CICSSYSN" MAXSNASESS=10

sna1 LUNAME="CICSSYSN"
NETID="SNANET1"
MODENAME="SNA62"
SECURITY_TYPE="LOCAL"
SYMDESTNAME="L0F0024A"

sna2 LUNAME="CICSSYSM"
NETID="SNANET1"
MODENAME="SNA62"
SYMDESTNAME="L0F0024B"

*DM_LOCAL_SERVICES
# <service_name> [<Local Domain name> [<access control>] [<exported svcname>]
# [<inbuftype>] [<outbuftype>]
#
debit LDOM=ldom1
INBUFTYPE=VIEW:cust
OUTBUFTYPE=VIEW:bill
RNAME="DEBIT"
credit LDOM=ldom1
INBUFTYPE=VIEW:cust
OUTBUFTYPE=VIEW:refund
RNAME="CREDIT"
active LDOM=ldom2
INBUFTYPE=STRING
OUTBUFTYPE=VIEW:cust
RNAME="ACTIVE"
inactive LDOM=ldom2
INBUFTYPE=STRING
OUTBUFTYPE=VIEW:cust
RNAME="INACTIVE"

*DM_REMOTE_SERVICES
# <service_name> [<Remote domain name>] [<local domain name>]
# [<remote svcname>] [<routingname>] [<conv>] [<blocktime>]
# [<prio>] [<load>] [<autran>] [<trantime>]
# [<inbuftype>] [<outbuftype>]
#
open RDOM=sna1 ROUTING=ACCOUNT RNAME="ACCTOPEN"
close RDOM=sna1 ROUTING=ACCOUNT RNAME="ACCTCLSE"
open RDOM=sna2 LDOM=ldom2 RNAME="ACCTOPEN"
close RDOM=sna2 LDOM=ldom2 RNAME="ACCTCLSE"

*DM_ROUTING
# <routing criteria> <field> <typed buffer> <ranges>
#
ACCOUNT FIELD=branchid BUFTYPE="VIEW:account"
RANGES="MIN - 1000:sna1, *:sna2"
#

SEE ALSO

build_dgw, dmadmin, tmboot, tmshutdown, dmloadcf, dmunloadcf
dmgwopts, GWADM, DMADM
TUXEDO /Domain Guide
TUXEDO Administrator's Guide
TUXEDO Programmer's Guide

dmloadcf

Parse a DMCONFIG file and load binary BDMCONFIG configuration file
SYNOPSIS

dmloadcf [-c] [-n] [-y] [-b blocks] {dmconfig_file | - }

DESCRIPTION

dmloadcf reads a file or the standard input that is in DMCONFIG syntax, checks the syntax, and optionally loads a binary BDMCONFIG configuration file. The BDMCONFIG environment variable points to the path name of the BDMCONFIG file where the information should be stored.
dmloadcf prints an error message if it finds any required section of the DMCONFIG file missing. If a syntax error is found while parsing the input file, dmloadcf exits without performing any updates to the BDMCONFIG file.
dmloadcf requires the existence of the $TUXDIR/udataobj/DMTYPE file. This file defines the valid domain types. If this file does not exist, dmloadcf exits without performing any updates to the BDMCONFIG file.
The effective user identifier of the person running dmloadcf must match the UID in the RESOURCES section of the TUXCONFIG file.
The -c option to dmloadcf causes the program to print minimum IPC resources needed for each local domain (gateway group) in this configuration. The BDMCONFIG file is not updated.
The -n option to dmloadcf causes the program to do only syntax checking of the ASCII DMCONFIG file without actually updating the BDMCONFIG file.
After syntax checking, dmloadcf checks to see if the file pointed to by BDMCONFIG exists, is a valid TUXEDO System file system, and contains BDMCONFIG tables. If these conditions are not true, the user is prompted to create and initialize the file with
Initialize BDMCONFIG file: path [y, q]?
where path is the complete file name of the BDMCONFIG file. Prompting is suppressed if the standard input or output are not terminals, or if the -y option is specified on the command line. Any response other than "y" or "Y" will cause dmloadcf to exit without creating the configuration file.
If the BDMCONFIG file is not properly initialized, and the user has given the go-ahead, dmloadcf creates the TUXEDO file system and then creates the BDMCONFIG tables. If the -b option is specified on the command line, its argument is used as the number of blocks for the device when creating the TUXEDO file system. If the value of the -b option is large enough to hold the new BDMCONFIG tables, dmloadcf will use the specified value to create the new file system; otherwise, dmloadcf will print an error message and exit. If the -b option is not specified, dmloadcf will create a new file system large enough to hold the BDMCONFIG tables. The -b option is ignored if the file system already exists. The -b option is highly recommended if BDMCONFIG is a raw device (that has not been initialized) and should be set to the number of blocks on the raw device. The -b option is not recommended if BDMCONFIG is a regular UNIX file.
If the BDMCONFIG file is determined to already have been initialized, dmloadcf ensures that the local domain described by that BDMCONFIG file is not running. If a local domain is running, dmloadcf prints an error message and exits. Otherwise, dmloadcf, to confirm that the file should be overwritten, prompts the user with:
"Really overwrite BDMCONFIG file [y, q]?"
Prompting is suppressed if the standard input or output are not a terminal or if the -y option is specified on the command line. Any response other than "y" or "Y" will cause dmloadcf to exit without overwriting the file.
If the SECURITY parameter is specified in the RESOURCES section of the TUXCONFIG file, then dmloadcf will flush the standard input, turn off terminal echo and prompt the user for an application password as follows:
Enter Application Password? 
The password is truncated to 8 characters. The option to load the ASCII DMCONFIG file via the standard input (rather than a file) cannot be used when this SECURITY parameter is turned on. If the standard input is not a terminal, that is, if the user cannot be prompted for a password (as with a here file, for example), then the environment variable APP_PW is accessed to set the application password. If the environment variable APP_PW is not set with the standard input not a terminal, then dmloadcf will print an error message, generate a log message and fail to load the BDMCONFIG file.
Assuming no errors, and if all checks have passed, dmloadcf loads the DMCONFIG file into the BDMCONFIG file. It will overwrite all existing information found in the BDMCONFIG tables.
PORTABILITY

dmloadcf is supported as a TUXEDO-supplied administrative tool on UNIX operating systems only.
ENVIRONMENT VARIABLES

The environment variable APP_PW must be set for applications that require security (the SECURITY parameter in the TUXCONFIG file is set to APP_PW) and dmloadcf is run with something other than a terminal as the standard input.
The BDMCONFIG environment variable should point to the BDMCONFIG file.
EXAMPLES

The following example shows how a binary configuration file is loaded from the bank.dmconfig ASCII file. The BDMCONFIG device is created (or reinitialized) with 2000 blocks:
dmloadcf -b 2000 -y bank.dmconfig
DIAGNOSTICS

If an error is detected in the input, the offending line is printed to standard error along with a message indicating the problem. If a syntax error is found in the DMCONFIG file or the system is currently running, no information is updated in the BDMCONFIG file and dmloadcf exits with exit code 1.
If dmloadcf is run on an active node, the following error message is displayed:
*** dmloadcf cannot run on an active node ***
If dmloadcf is run by a person whose effective user identifier doesn't match the UID specified in the TUXCONFIG file, the following error message is displayed:
*** UID is not effective user ID ***
Upon successful completion, dmloadcf exits with exit code 0. If the BDMCONFIG file is updated, a userlog message is generated to record this event.
SEE ALSO

dmunloadcf, dmconfig, ubbconfig
TUXEDO /Domain Guide
TUXEDO Administrator's Guide

dmunloadcf

Unload binary BDMCONFIG domain configuration file
SYNOPSIS

dmunloadcf
DESCRIPTION

dmunloadcf translates the BDMCONFIG configuration file from the binary representation into ASCII. This translation is useful for transporting the file in a compact way between machines with different byte orderings and backing up a copy of the file in a compact form for reliability. The ASCII format is the same as is described in dmconfig.
dmunloadcf reads values from the BDMCONFIG file pointed to by the BDMCONFIG environment variable and writes them to its standard output.
PORTABILITY

dmunloadcf is supported as a TUXEDO-supplied administrative tool on UNIX operating systems only.
EXAMPLES

To unload the configuration in /usr/tuxedo/BDMCONFIG into the file bdmconfig.backup:
BDMCONFIG=/usr/tuxedo/BDMCONFIG dmunloadcf > bdmconfig.backup
DIAGNOSTICS

dmunloadcf checks that the file pointed to by the BDMCONFIG environment variable exists, is a valid TUXEDO file system, and contains BDMCONFIG tables. If any of these conditions is not met, dmunloadcf prints an error message and exits with error code 1. Upon successful completion, dmunloadcf exits with exit code 0.
SEE ALSO

dmloadcf, dmconfig
TUXEDO /Domain Guide

dmusradd

Add a user to the domain password file
SYNOPSIS

DMCONFIG=dmconfig
dmusradd [ -ld local domain ID ][ -rd remote domain ID]
[ -lu local uid] [ -lp local password]
[- ru remote username] [-rp remote password]

DESCRIPTION

This command allows the administrator to add local userids and passwords and corresponding remote userids and passwords to the domain password table.
The entries created are used for mapping remote user names and passwords to local user names and passwords when the application is using OSI gateways and SECURITY is set to USER_AUTH, ACL, or MANDATORY ACL in the ubbconfig file and SECURITY is set to DM_PW or USER_PW in the DMCONFIG file.
The system file entries created with this command have a limit of 512 characters per line. Specifying long arguments to several options may exceed this limit.
The following options are available:

-ld local domain ID
This is the domainID of the local domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-rd remote domain ID
This is the domainID of the remote domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-lu local uid
The user identification number. The local uid must be a positive decimal number smaller than 128K. uid must be unique within the list of existing identifiers for the application. uid defaults to the next available (unique) identifier greater than 0. The wildcard character ('*') is a valid uid.
-lp local password
The local password that is associated with the local uid to be added.
-ru remote username
The name of the remote user as defined in the remote domain's security application, for example, RACF. The wildcard character ('*') and space are valid remote usernames.
-rp remote password
The remote password that is associated with the local uid to be added.

The administrator is prompted for the local password and for the remote password if not specified on the command line.
Before running this command, the application must be configured using either the Graphical Administrative Interface or tmloadcf and dmloadcf. dmusradd may be run on any active node. If the application is not active, dmusradd must be run on the MASTER node.
PORTABILITY

This command is available only on non-/WS sites running TUXEDO System /T Release 6.4.
DIAGNOSTICS

The dmusradd command exits with a return code of 0 upon successful completion.
EXAMPLES

Associate uid 408 with theirname in CICS security dmusradd -ld ldom -rd cics -lu 408 -ru theirname

Associate uid 409 with any remote user dmusradd -ld ldom -rd cics -lu 409 -ru '*'

Associate any local user with remote theirname dmusradd -ld ldom -rd cics -lu '*' -ru theirname

SEE ALSO

dmusrdel, dmusrmod

dmusrmod

Change a user password in the remote domain password file
SYNOPSIS

DMCONFIG=dmconfig
dmusrmod [ -ld local domain ID ][ -rd remote domain ID ]
[ -lu local uid ] [ -ru remote username ] [ -rp remote password ]

DESCRIPTION

This command allows the administrator to modify the username and password of remote domain users in the corresponding remote domain password file.
Once the entry is modified, the old information can no longer be used for mapping remote user names and passwords to local user names and passwords when the application is using OSI gateways and SECURITY is set to USER_AUTH, ACL, or MANDATORY ACL in the ubbconfig file and SECURITY is set to DM_PW or USER_PW in the DMCONFIG file.
The following options are available:

-ld local domain ID
This is the domainID of the local domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-rd remote domain ID
This is the domainID of the remote domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-lu local uid
The user identification number. The local uid must be a positive decimal number smaller than 128K. uid must be unique within the list of existing identifiers for the application. uid defaults to the next available (unique) identifier greater than 0. The wildcard character ('*') is a valid uid.
-ru remote username
The name of the remote user that is associated with the local uid to be modified.
-rp remote password
The remote password that is associated with the local uid to be modified.

Before running this command, the application must be configured using either the Graphical Administrative Interface or tmloadcf and dmloadcf. dmusrmod may be run on any active node. If the application is not active, dmusrmod must be run on the MASTER node.
PORTABILITY

This command is available only on non-/WS sites running TUXEDO System /T Release 6.4.
DIAGNOSTICS

The dmusrmod command exits with a return code of 0 upon successful completion.
EXAMPLES

Change uid 408
dmusrmod -ld ldom -rd cics -lu 408 -ru newname -rp*****

SEE ALSO

dmusrdel, dmusradd

GWADM

/Domain gateway administrative server
SYNOPSIS

GWADM SRVGRP = "identifier" SRVID = "number" REPLYQ = "N"
CLOPT = "-A -- [-a { on | off } ] [-s services ]
[-t { on | off } ]"

DESCRIPTION

The gateway administrative server GWADM is a TUXEDO-supplied server that provides administrative functions for a /Domain gateway group.
GWADM should be defined in the *SERVERS section of the UBBCONFIG file as a server running within a particular gateway group, that is, SRVGRP must be set to the corresponding GRPNAME tag specified in the *GROUPS section. The SVRID parameter is also required and its value must consider the maximum number of gateways allowed within the gateway group.
There should be only one instance of a GWADM per /Domain gateway group, and it should NOT be part of the MSSQ defined for the gateways associated with the group. Also, GWADM should have the REPLYQ attribute set to N.
The CLOPT option is a string of command line options that is passed to the GWADM when it is booted. This string has the following format:
CLOPT="-A -- <gateway group runtime parameters>" 
The following runtime parameters are recognized for a gateway group:

-a { on | off }
This option turns off or on the audit log feature for this local domain. The default is off. The dmadmin program can be used to change this setting while the gateway group is running (see dmadmin).
-s services
Specifies the remote services that should be initially offered by the domain gateway. The specifications for these services are found in the DMCONFIG file. For example, the specification
-s x,y,z
implies that the gateway should initially advertise remote services x, y, and z. Spaces are not allowed between commas and the -s option may appear several times.
-t { on | off }
This option turns off or on the statistics gathering feature for the local domain. The default is off. The dmadmin program can be used to change this setting while the gateway group is running (see dmadmin).

The GWADM server must be booted before the corresponding gateways.
PORTABILITY

GWADM is supported on TUXEDO-supplied servers, using UNIX System operating systems.
INTEROPERABILITY

The initial release of OSI Domain can only be installed on a node running TUXEDO Release 6.4.
EXAMPLES

The following example illustrates the definition of the administrative server in the UBBCONFIG file.
#
*GROUPS
DMADMGRP  GRPNO=1
gwgrp    GRPNO=2
#
*SERVERS
DMADM SRVGRP="DMADMGRP" SRVID=1001 REPLYQ=N RESTART=Y GRACE=0
GWADM SRVGRP="gwgrp" SRVID=1002 REPLYQ=N RESTART=Y GRACE=0
      CLOPT="-A -- -a on -t on"
GWTDOMAIN SRVGRP="gwgrp" SRVID=1003 RQADDR="gwgrp" REPLYQ=Y
RESTART=Y MIN=1 MAX=1
SEE ALSO

dmadmin, tmboot
dmconfig, DMADM, servopts, ubbconfig
TUXEDO /Domain Guide
TUXEDO Administrator's Guide

modusr

Modify a remote user password
SYNOPSIS

DMCONFIG=dmconfig
modusr -d local domain ID -R remote domain ID -u remote username

DESCRIPTION

modusr can only be executed as a subcommand of dmadmin. The purpose of this page is to describe options for the subcommand and to show an example.
The subcommand allows the administrator to modify passwords in the remote password table. The administrator is prompted for the remote password.
The table entries modified are used for passing remote user names and passwords to remote OSI domains when the application is using OSI gateways and SECURITY is set to USER_AUTH, ACL, or MANDATORY ACL in the ubbconfig file and SECURITY is set to DM_USER_PW in the DMCONFIG file.
The following options are available:

-d local domain ID
This is the name of the local domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-R remote domain ID
This is the name of the remote domain gateway with which the ids and passwords are associated. This is the same ID as the one used when creating the domain definitions either in the DMCONFIG file or through the Graphical Administrative Interface.
-u remote username
The remote user whose password is being modified.

Before running this subcommand the application must be configured using either the Graphical Administrative Interface or tmloadcf and dmloadcf. dmadmin modusr may be run on any active node.
PORTABILITY

This subcommand is available only on non-/WS sites running TUXEDO System /T Release 6.4.
DIAGNOSTICS

The dmadmin modusr subcommand exits with a return code of 0 upon successful completion.
EXAMPLES

modusr -d tux -R cics -u cicsusr /*modifies remote user's password
sent to CICS. The administrator
is prompted for the password*/

SEE ALSO

delusr, addusr

[Top] [Previous]