|
|
|
|
|
|
Section 1 - Commands
introduction to BEA Tuxedo Commands
Description
The BEA Tuxedo Command Reference describes, in alphabetic order, shell-level commands delivered with the BEA Tuxedo software.
Reference Page Command Syntax
Unless otherwise noted, commands described in the Synopsis section of a reference page accept options and other arguments according to the following syntax and should be interpreted as explained below.
bldc_dce(1)
Name
bldc_dce-builds a BEA Tuxedo system client that can be called via OSF/DCE
Synopsis
bldc_dce [-o output_file] [-i idl_options] [-f firstfiles]
[-l lastfiles] [idl_file . . .]
Description
bldc_dce parses any input IDL and related ACF source files and combines them with C source and object files and the OSF/DCE libraries to generate a BEA Tuxedo system client that can be called via DCE RPC (it is a DCE RPC client).
The command-line arguments include the input IDL source file and options to control the actions of the IDL compiler. The options are as follows:
See Also
tidl(1)
blds_dce(1)
Name
blds_dce-build a BEA Tuxedo system server that calls OSF/DCE
Synopsis
blds_dce [-o output_file] [-i idl_options] [-f firstfiles]
[-l lastfiles] [-s service] [idl_file . . .]
Description
blds_dce parses any input IDL and related ACF source files and combines them with C source and object files and the OSF/DCE libraries to generate a BEA Tuxedo system server that can make DCE RPC calls. The primary use of this command is to make a BEA Tuxedo system-to-OSF/DCE gateway process.
The command-line arguments include the input IDL source file and options to control the actions of the IDL compiler. The options are as follows:
See Also
tidl(1)
build_dgw(1)
Name
build_dgw-build customized domain gateway process
Synopsis
build_dgw [ -c dmtype] [ -o name] [ -v ]
Description
build_dgw is used to construct a customized BEA Tuxedo 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 BEA Tuxedo libraries necessary to form a gateway load module. The load module is built by the cc(1) command described in UNIX system reference manuals which build_dgw invokes. The options to build_dgw have the following meaning:
dmtype:access_module_lib:comm_libs:tm_typesw_lib:gw_typesw_lib
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 the build_dgw command'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 BEA Tuxedo-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
For the /TDOMAIN and /OSITP instantiations, 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::
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 an OSITP gateway instantiation.
See Also
cc(1), ld(1) in UNIX system reference manuals, tuxtypes(5), typesw(5)
buildclient(1)
Name
buildclient-construct a BEA Tuxedo client module
Synopsis
buildclient [ -C ] [ -v ] [ {-r rmname | -w } ] [ -o name]
[ -f firstfiles] [ -l lastfiles] Description
buildclient is used to construct a BEA Tuxedo client module. The command combines the files supplied by the -f and -l options with the standard BEA Tuxedo libraries to form a load module. The load module is built by buildclient using the default C language compilation command defined for the operating system in use. The default C language compilation command for the UNIX system is the cc(1) command described in UNIX system reference manuals.
Environment Variables
Portability
buildclient is supported as a BEA Tuxedo-supplied compilation tool on UNIX and MS-DOS operating systems. However, due to file naming restrictions, only the buildclt alias is supported on MS-DOS. Note that filenames supplied as part of the buildclient command line must conform to the syntax and semantics of the resident operating system.
The MS-DOS version of buildclt has significant differences from the UNIX system version. These differences warrant a separate man page for the MS-DOS version of the command. Therefore, a separate buildclt(1) reference page is also included to describe the command for the MS-DOS environment.
Examples
CC=ncc CFLAGS="-I /APPDIR/include"; export CC CFLAGS
buildclient -o empclient -f emp.c -f "userlib1.a userlib2.a"
COBCPY=$TUXDIR/cobinclude
COBOPT="-C ANS85 -C ALIGN=8 -C NOIBMCOMP -C TRUNC=ANSI -C OSEXT=cbl"
COBDIR=/usr/lib/cobol LD_LIBRARY_PATH=$COBDIR/coblib:$TUXDIR/lib
export COBOPT COBCPY COBDIR LD_LIBRARY_PATH
buildclient -C -o empclient -f name.cbl -f "userlib1.a userlib2.a"
See Also
buildclt(1), buildserver(1), buildtms(1), compilation(5),
cc(1), ld(1) in a UNIX system reference manual
buildclt(1)
Name
buildclt-construct a BEA Tuxedo Workstation client program for MS-DOS, Windows, Windows NT, and OS/2
Synopsis
buildclt [ -C ] [ -v ] [ -m {m | l} ] [ -c {m | b | i} ]
[ -o name ] [ -f firstfiles ] [ -F Firstlibs ] [ -l libfiles ]
[ -W ] [ -O ] [ -P ] [ -d deffile ]Description
buildclt is used to construct a BEA Tuxedo Workstation client program for MS-DOS, Windows, Windows NT, and OS/2. The command combines the files supplied by the -f and -l options with the standard BEA Tuxedo libraries to form an executable program. The load module is built by buildclt using the C and COBOL language compilation commands defined for the operating system in use. The options to buildclt have the following meaning:
The following environment variables must be set for the COBOL environment.
Microsoft C Compilation
The buildclt command assumes that directories for needed libraries are specified in the environment variables INCLUDE and LIB. They might look like the following:
INCLUDE=C:\TUXEDO\INCLUDE;C:\NET\TOOLKIT\INCLUDE;C:MSVC\INCLUDE
LIB=C:\NET\TOOLKIT\LIB;C:\WINDEV\LIB;C:\MSVC\LIB;C:\TUXEDO\LIB;
Note that in the above example, C:MSVC is the directory where Microsoft Visual C++ resides; earlier versions such as C600 or C700 can be used. Note that in the above example, C:NET is the directory where Novell LAN Workplace resides; earlier versions resided in C:XLN and can be used.
Note that COBOL source files that reference ATMI calls must be compiled with the LITLINK option.
The names of all libraries used for linking the client followed by the files specified in the -l option are put into a temporary response file and linking is done using the command line:
LINK firstfiles, outname @tmpfile
are the filenames specified with the -f option, outname is the output filename (default client.exe), and tmpfile is the temporary response filename. The -f option should be used to include any necessary options to be passed to LINK (for example, /ST:10000 to set the default stack size to 10000 bytes). The -l option should be used to include any necessary network provider libraries (for example, mlibsock.lib). To create an executable that can be debugged using Codeview (assuming that the object files have been compiled with the -Zi option), use -f /CO.
Examples
MS-DOS C Compilation:
buildclt -cm -ml -o emp.exe -f "/CO/ST:10000/SE:200" -f emp.obj -l llibsock.lib
WINDOWS C Compilation:
buildclt -W -cm -mm -o emp.exe -f "/CO emp.obj" -d emp.def rc -k emp.res emp.exe
OS2 16-Bit:
buildclt -O -cm -ml -o emp.exe -f "/NOI/ST:15000/CO emp.obj" -d emp.def
OS2 32-Bit IBM:
buildclt -O -ci -f "/NOI/ST:25000 /CO emp.obj" -o emp.exe
Windows NT:
!include <ntwin32.mak>
rc -r emp.rc
buildclt -W -f "emp.obj emp.res" -l "$(winlibs)" -oemp.exe
DOS/WINDOWS/OS2 COBOL Compilation:
COBCPY=C:\TUXEDO\COBINC
COBDIR=C:\COBOL\LBR;C:\COBOL\EXEDLL
PATH=C:\C700BIN\;C:COBOLEXEDLL;...
TUXDIR=C:\TUXEDO
INCLUDE=C:\TUXEDO\INCLUDE;C:\XLN\TOOLKIT\INCLUDE;C:\C700\INCLUDE
LIB=C:\XLN\TOOLKIT\LIB;C:\C700\LIB;C:\TUXEDO\LIB;C:\COBOL\LIB
COBOL EMP.CBL OMF"OBJ" LITLINK
DOS:
BUILDCLT -C -o EMP.EXE -f EMP+MFC7INTF+C7DOSIF+C7DOSLB \
-f "/NOD/NOE/SE:300/CO/ST:10000" -l LLIBSOCK
WINDOWS:
BUILDCLT -C -W -o EMP.EXE -f EMP -d EMP.DEF -f "/NOD/NOE/CO/SE:300"
OS2:
BUILDCLT -C -P -o EMP.EXE -f EMP+MFC6INTF+C6OS2IF+C6OS2LB -d
EMP.DEF \ -f "/NOD/NOE/SE:300/CO"
See Also
Microsoft C/C++ Programming Techniques, Microsoft Corporation. Micro Focus COBOL/2 Operating Guide, Micro Focus Ltd. Micro Focus COBOL/2 Workbench for DOS and OS2, Micro Focus Ltd.
buildserver(1)
Name
buildserver-construct a BEA Tuxedo server load module
Synopsis
buildserver [-C] [-s { @filename | service[,service...][:func] | :func } ] [-n maxdynam] [-v] [-o outfile] [-f firstfiles]
[-l lastfiles] [{-r|-g} rmname] [-k] Description
buildserver is used to construct a BEA Tuxedo server load module. The command combines the files supplied by the -f and -l options with the standard server main routine and the standard BEA Tuxedo libraries to form a load module. The load module is built by the cc(1) command, which buildserver invokes. (See cc(1) in any UNIX system reference manual.) The options to buildserver have the following meaning:
Note: The generated contents of this file may change from release to release; DO NOT count on the data structures and interfaces exposed in this file. This option is provided to aid in debugging of build problems.
Environment Variables
Compatibility
In earlier releases, the -g option was allowed to specify a genoption of sql or database. For upward compatibility, this option is a synonym for the -r option. The genoption database is equivalent to TUXEDO/D, and the genoption sql is equivalent to TUXEDO/SQL.
Portability
The buildserver compilation tool is supported on any platform on which the BEA Tuxedo server environment is supported.
Notices
Some compilation systems may require some code to be executed within the main(). For example, this could be used to initialize constructors in C++ or initialize the library for COBOL. A general mechanism is available for including application code in the server main() immediately after any variable declarations and before any executable statements. This will allow for the application to declare variables and execute statements in one block of code. The application exit is defined as follows. #ifdef TMMAINEXIT #include "mainexit.h" #endif. To use this feature, the application should include "-DTMMAINEXIT" in the ALTCFLAGS (for COBOL) or CFLAGS (for C) environment variables and provide a mainexit.h in the current directory (or use the -I include option to include it from another directory).
For example, Micro Focus Cobol V3.2.x with a PRN number with the last digits greater than 11.03 requires that cobinit() be called in main before any COBOL routines, if using shared libraries. This can be accomplished by creating a mainexit.h file with a call to cobinit() (possibly preceded by a function prototype) and following the procedure above.
Examples
The following example shows how to specify the resource manager (-r TUXEDO/SQL) libraries on the buildserver command line:
buildserver -r TUXEDO/SQL -s OPEN_ACCT -s CLOSE_ACCT -o ACCT
-f ACCT.o -f appinit.o -f util.o
The following example shows how buildserver can be supplied CC and CFLAGS variables and how -f can be used to supply a -lm option to the CC line to link in the math library:
CFLAGS=-g CC=/bin/cc buildserver -r TUXEDO/SQL -s DEPOSIT
-s WITHDRAWAL -s INQUIRY -o TLR -f TLR.o -f util.o -f -lm
The following example shows use of the buildserver command with no resource manager specified:
buildserver -s PRINTER -o PRINTER -f PRINTER.o
The following example shows COBOL compilation:
COBCPY=$TUXDIR/cobinclude COBOPT="-C ANS85 -C ALIGN=8 -C NOIBMCOMP
-C TRUNC=ANSI -C OSEXT=cbl" COBDIR=/usr/lib/cobol
LD_LIBRARY_PATH=$COBDIR/coblib export COBOPT COBCPY COBDIR
LD_LIBRARY_PATH buildserver -C -r TUXEDO/SQL -s OPEN_ACCT
-s CLOSE_ACCT -o ACCT -f ACCT.o -f appinit.o -f util.o
See Also
buildtms(1), ubbconfig(5), servopts(5), cc(1), ld(1) in a UNIX system reference manual
buildtms(1)
Name
buildtms(1)-construct a transaction manager server load module
Synopsis
buildtms [ -v ] -o name -r rm_name
Description
buildtms is used to construct a transaction manager server load module.
While several TM servers are provided with BEA Tuxedo, new resource managers may be provided to work with BEA Tuxedo for distributed transaction processing. The resource manager must conform to the X/OPEN XA interface. The following four items must be published by the resource manager vendor: the name of the structure of type xa_switch_t that contains the name of the resource manager, flags indicating capabilities of the resource manager, and function pointers for the actual XA functions; the name of the resource manager that is contained in the name element of the xa_switch_t structure; the name of the object files that provide the services of the XA interface and supporting software; and the format of the information string supplied to the OPENINFO and CLOSEINFO parameters in the UBBCONFIG configuration file. See ubbconfig(5).
When integrating a new resource manager into the BEA Tuxedo system, the file $TUXDIR/udataobj/RM must be updated to include the information about the resource manager. The format of this file is
rm_name:rm_structure_name:library_names
where rm_name is the resource manager name, rm_structure_name is the name of the xa_switch_t structure, and library_names is the list of object files for the resource manager. White space (tabs and/or spaces) is allowed before and after each of the values and may be embedded within the library_names. The colon (:) character may not be embedded within any of the values. Lines beginning with a pound sign (#) are treated as comments and are ignored.
A transaction manager server for the new resource manager must be built using buildtms and installed in $TUXDIR/bin. buildtms uses the buildserver(1) command to build the resulting a.out. The options to buildtms have the following meaning:
buildtms uses the buildserver command to produce the a.out. buildserver uses the CC and CFLAGS environment variables, if set, for the compiler and compiler flags, respectively. See buildserver(1) for further details.
Portability
buildtms is supported as a BEA Tuxedo system-supplied compilation tool for UNIX and Windows NT systems.
Examples
buildtms -o $TUXDIR/bin/TMS_D -r TUXEDO/D # standard System/D TMS
buildtms -o $TUXDIR/bin/TMS_XYZ -r XYZ/SQL # TMS for XYZ resource manager
See Also
buildserver(1), ubbconfig(5)
buildwsh(1)
Name
buildwsh-build customized Workstation Handler process
Synopsis
buildwsh [ -v ] [ -o name] [ -f files]
Description
buildwsh is used to construct a customized BEA Tuxedo Workstation Handler 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 -f option with the standard BEA Tuxedo libraries necessary to form a Workstation Handler load module. The load module is built by the cc(1) command described in UNIX system reference manuals, which buildwsh invokes. The options to buildwsh have the following meaning:
buildwsh normally uses the cc command to produce the a.out. In order to allow for the specification of an alternate compiler, buildwsh checks for the existence of a shell variable named CC. If CC does not exist in the buildwsh command's environment, or if it is the string "", buildwsh 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.
If your application uses shared libraries, it is not necessary to go through this compile and link process. See the description in the "Buffer Types" chapter of the BEA WebLogic Enterprise Administration Guide.
Portability
buildwsh is supported as a BEA Tuxedo-supplied compilation tool on UNIX operating systems only.
Examples
ncc CFLAGS="-I $TUXDIR/include"; export CC CFLAGS buildwsh
-o APPWSH -f apptypsw.o
See Also
buildclient(1), wsl(5) cc(1), ld(1) in UNIX system reference manuals
cobcc(1)
Name
cobcc-COBOL compilation interface
Synopsis
cobcc [option...] filename...
Description
cobcc is used as an interface shell to the COBOL compiler. It is invoked, by default, when buildclient(1) or buildserver(1) is executed with the -C (COBOL) option. This can be overridden by specifying the ALTCC environment variable.
The following list indicates the options recognized by cobcc. To use these options, set the environment variable ALTCFLAGS to the string of options to be recognized by cobcc when running buildclient or buildserver. Consult your documentation for the COBOL and C compilers to see what effect the various options have.
Note that for cobcc, unlike cc and cob, all options must come before any filenames.
The options and their arguments and the filenames are passed to the COBOL compiler with the correct options so that the right information is processed by the COBOL compiler, the C compiler, or the loader. The COBOL compiler name is assumed to be cob and already in the PATH.
See Also
buildclient(1), buildserver(1), cc reference page, Micro Focus COBOL/2 Operating Guide, Micro Focus Ltd.
dmadmin(1)
Name
dmadmin-BEA Tuxedo 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 BEA Tuxedo 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 reconfiguration 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 defaults via the default command. Commands that accept parameters set via the default command check default to see if a value has been set. If one hasn't, an error message is returned.
Once set, a default 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 paginate subcommand below).
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:
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:
Section:
1) RESOURCES 2) LOCAL_DOMAINS
3) REMOTE_DOMAINS 4) LOCAL_SERVICES
5) REMOTE_SERVICES 6) ROUTING
7) ACCESS_CONTROL 8) PASSWORDS
9) TDOMAINS 10) OSITPS
11) SNADOMS 12) LOCAL_REMOTE_USER
13) REMOTE_USERS 14) SNACRMS
15) SNASTACKS 16) SNALINKS
17) 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:
For configuration operations, the effective user identifier must match the BEA Tuxedo administrator user identifier (UID) for the machine on which this program is executed. When a record is updated or added, all defaults and validations used by dmloadcf(1) 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 is 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 below. The field names associated with each DMCONFIG section are listed in tables in the subsections below. The semantics of the fields and associated ranges, defaults, restrictions, etc., are described in dmconfig(5). 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 filename: 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 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(5) 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 reconfiguration capability:
Restrictions for Configuration Field Identifiers/
Updates
The following sections describe, for each DMCONFIG section, what the field identifiers are associated with 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(5). Fields indicated below 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:
Configuring the dm_local_domains section
The following table lists the fields in the *DM_LOCAL_DOMAINS section.
|
Field Identifier |
Type |
Update |
Notes |
|---|---|---|---|
|
TA_LDOM |
string |
NoGW |
key |
|
TA_AUDITLOG |
string |
NoGW |
|
|
TA_BLOCKTIME |
numeric |
NoGW |
|
|
TA_CONNECTION_POLICY |
string |
NoGW |
|
|
TA_DOMAINID |
string |
NoGW |
|
|
TA_DMTLOGDEV |
string |
NoGW |
|
|
TA_DMTLOGNAME |
string |
NoGW |
|
|
TA_DMTLOGSIZE |
numeric |
NoGW |
|
|
TA_GWGRP |
string |
NoGW |
|
|
TA_MAXRDOM |
numeric |
NoGW |
|
|
TA_MAXRDTRAN |
numeric |
NoGW |
|
|
TA_MAXRETRY |
numeric |
NoGW |
|
|
TA_MAXTRAN |
numeric |
NoGW |
|
|
TA_RETRY_INTERVAL |
numeric |
NoGW |
|
|
TA_SECURITY |
string |
NoGW |
format: {NONE | APP_PW | DM_PW} |
|
TA_TYPE |
string |
NoGW |
format:{TDOMAIN | OSITP} |
Configuring the dm_remote_domains section
The following table lists the fields in the *DM_REMOTE_DOMAINS section.
|
Field Identifier |
Type |
Update |
Notes |
|---|---|---|---|
|
TA_RDOM |
string |
No |
key |
|
TA_DOMAINID |
string |
No |
|
|
TA_TYPE |
string |
No |
format: {TDOMAIN | OSITP} |
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:
|
Field Identifier |
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:
|
Field Identifier |
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.
|
Field Identifier |
Type |
Update |
Notes |
|---|---|---|---|
|
TA_SERVICENAME |
string |
No |
key |
|
TA_LDOM |
string |
Yes |
|
|
TA_RNAME |
string |
Yes |
|
|
TA_ACLNAME |
string |
Yes |
|
|
TA_BUFTYPE |
string |
Yes |
|
|
TA_BUFSTYPE |
string |
Yes |
|
|
TA_OBUFTYPE |
string |
Yes |
|
|
TA_OBUFSTYPE |
string |
Yes |
|
Configuring the dm_remote_services Section
The following table lists the fields in the *DM_REMOTE_SERVICES section.
|
Field Identifier |
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_BUFTYPE |
string |
Yes |
|
|
TA_BUFSTYPE |
string |
Yes |
|
|
TA_OBUFTYPE |
string |
Yes |
|
|
TA_OBUFSTYPE |
string |
Yes |
|
|
TA_ROUTINGNAME |
string |
Yes |
|
|
TA_TRANTIME |
numeric |
Yes |
|
Configuring the dm_routing Section
The following table lists the fields in the *DM_ROUTING section.
|
Field Identifier |
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.
|
Field Identifier |
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.
|
Field Identifier |
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 BEA Tuxedo communications error. They indicate that the operation did not complete successfully.
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).
The following return values indicate that the operation was successful.
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(1) is used for the editor.
$ EDITOR=ed dmadmin
> config
Sections:
1) RESOURCES 2) LOCAL_DOMAINS
3) REMOTE_DOMAINS 4) LOCAL_SERVICES
5) REMOTE_SERVICES 6) ROUTING
7) ACCESS_CONTROL 8) PASSWORDS
9) TDOMAINS 10) OSITPS
11) SNADOMS 12) LOCAL_REMOTE_USER
13) REMOTE_USERS 14) SNACRMS
15) SNASTACKS 16) SNALINKS
17) 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 BEA Tuxedo 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 must be installed on BEA Tuxedo Release 5.0 or later. Other nodes in the same domain with an Release 5.0 gateway may be BEA Tuxedo Release 4.1 or later.
Portability
dmadmin is supported as a BEA Tuxedo-supplied administrative tool on UNIX operating systems only.
See Also
dmloadcf(1), dmconfig(5), DMADM(5), tmadmin(1) BEA Tuxedo Domains Guide
dmloadcf(1)
Name
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 BEA Tuxedo 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 filename 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 BEA 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 BEA 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 found to have been initialized already, 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 limited to 30 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 BEA 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 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(1), dmconfig(5), ubbconfig(5), BEA Tuxedo Domains Guide, BEA WebLogic Enterprise Administration Guide
dmunloadcf(1)
Name
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(5).
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 BEA 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 BEA 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(1), dmconfig(5) BEA Tuxedo Domains Guide
gencat(1)
Name
gencat-generate a formatted message catalog
Synopsis
gencat [-m] catfile msgfile . . .
Description
The gencat utility merges the message text source file(s) msgfile into a formatted message database catfile. The database catfile will be created if it does not already exist. If catfile does exist its messages will be included in the new catfile. If set and message numbers collide, the new message-text defined in msgfile will replace the old message text currently contained in catfile. The message text source file (or set of files) input to gencat can contain either set and message numbers or simply message numbers, in which case the set NL_SETD([see nl_types(5)]) is assumed.
The format of a message text source file is defined in the list below. Note that the fields of a message text source line are separated by a single ASCII space or tab character. Any other ASCII spaces or tabs are considered to be part of the subsequent field.
|
Description |
Symbol |
Escape Sequence |
|---|---|---|
|
newline |
NL(LF) |
\n |
|
horizontal tab |
HT |
\t |
|
vertical tab |
VT |
\v |
|
backspace |
BS |
\b |
|
carriage return |
CR |
\r |
|
form feed |
FF |
\f |
|
backslash |
\ |
\\ |
|
bit pattern |
ddd |
\ddd |
The escape sequence \ddd consists of backslash followed by 1, 2 or 3 octal digits, which are taken to specify the value of the desired character. If the character following a backslash is not one of those specified, the backslash is ignored.
Backslash followed by an ASCII newline character is also used to continue a string on the following line. Thus, the following two lines describe a single message string:
1 This line continues \
to the next line
which is equivalent to:
1 This line continues to the next line
Portability
gencat is supported as a BEA Tuxedo-supplied tool on UNIX and MS-DOS operating systems.
Notices
This version of gencat produces a catalog that at runtime is read into malloc'ed space. Shared catalogs available with some versions of gencat are not available. On some systems, generation of malloc'ed catalogs requires that the -m option be specified. This option can be specified on the command line, but has no effect. malloc'ed catalogs are the default; the -m option is supported for compatibility only.
The catalog file generated by this command is limited in size to 64K. Larger catalog files will result in an error being reported by this command and no catalog file being generated.
See Also
nl_types(5)
loadfiles(1)
Name
loadfiles-load files into shared memory cache
Synopsis
loadfiles -k key [files] [--]
Description
Loads the files specified in the command line or the standard input into a shared memory cache associated with key. If a shared memory cache exists for key then a directory of files in that cache is printed, and no files are added to the cache. When the cache is created its permissions are set to 0666. This permission means that the cache is readable and writable by everyone on the system. Files to be loaded into the cache are taken from the standard input if-is specified on the command line instead of files.
ipcrm(1) destroys the shared memory cache created by loadfiles.
Examples
The command:
loadfiles -k${MSKIPCKEY} file1 file2loads file1 and file2 into a shared memory cache associated with the value of the shell variable MSKIPCKEY.
Notices
Only the last part of a filename is stored in the cache's directory. For example, /etc/motd would be stored as motd. Therefore, one cannot have both /etc/motd and /tmp/motd in the cache at the same time.
See Also
ipcrm(1) in a UNIX system reference manual
mio(1)
Name
mio, wmio-mask input/output program
Synopsis
mio [ -B ] [ -n ] [ -e ] [ -F ] [ -t ] [ -i fname] [ -m fname]
[ -r rname] [ -p rname] [ -s service] [ -b usrname] [ -u file]
wmio [options]
Description
Note: For BEA Tuxedo Sample Application only. mio is the Data Entry System mask input/output handler. It reads mask object files created by the compiler and displays user-defined forms on the standard output. Once the forms are filled out, their contents are shipped to a server in the form of fielded buffers. If the form has been created with the parameter TRANMODE set to TRAN, mio is invoked in transaction mode. See the BEA Tuxedo Programmer's Guide for a detailed explanation.
wmio is a version of mio build using the workstation libraries. On sites supporting just BEA Tuxedo workstation, only the wmio command will be present.
The following command-line options are available:
By default, the following function keys are defined by mio. These can be changed with the -u option.
Notices
The terminfo(4) database must exist for mio to run, and the TERMINFO shell variable must point to the correct directory.
Portability
mio and/or wmio are supported as BEA Tuxedo-supplied clients on UNIX operating systems only.
Environment Variables
TERMINFO, TERM, TUXDIR, LOGNAME, UBBCONFIG, NGXACTS, OKXACTS, FLDTBLDIR, FIELDTBLS, SRVID, SRVGRP, MSKIPCKEY, MASKPATH.
APP_PW must be set to the application password in a security application if standard input is not from a terminal. WSNADDR, WSDEVICE, and optionally, WSTYPE, must be set if access is from a workstation. See compilation(5) for more details on setting environment variables for client processes.
See Also
udfk(5), the BEA WebLogic Enterprise Administration Guide, and terminfo(4) in a UNIX system reference manual
mkfldhdr, mkfldhdr32(1)
Name
mkfldhdr, mkfldhdr-create header files from field-tables
Synopsis
mkfldhdr [-d outdir] [ field_table... ]
mkfldhdr32 [-d outdir] [ field_table... ]
Description
mkfldhdr translates each field table file to a corresponding header file suitable for inclusion in C programs. The resulting header files provide #define macros for converting from field names to field IDs. Header filenames are formed by concatenating a .h to the simple filename for each file to be converted.
The field table names may be specified on the command line; each file is converted to a corresponding header file.
If the field table names are not given on the command line, then the program uses the FIELDTBLS environment variable as the list of field tables to be converted, and FLDTBLDIR environment variable as a list of directories to be searched for the files. FIELDTBLS specifies a comma-separated list of field table filenames. If FIELDTBLS has no value, fld.tbl is used as the name of the (only) field table file (in this case, the resulting header file will be (fld.tbl.h). The FLDTBLDIR environment variable is a colon-separated list of directories in which to look for each field table whose name is not an absolute pathname; the search for field tables is very similar to the search for executable commands using the UNIX system PATH variable. If FLDTBLDIR is not defined, only the current directory is searched. Thus, if no field table names are specified on the command line and FIELDTBLS and FLDTBLDIR are not set, mkfldhdr will convert the field table fld.tbl in the current directory into the header file fld.tbl.h.
The -d option is available to specify that the output header files are to be created in a directory other than the present working directory.
mkfldhdr32 is used for 32-bit FML. It uses the FIELDTBLS32 and FLDTBLDIR32 environment variables.
Errors
Error messages are printed if the field table load fails or if an output file cannot be created.
Examples
FLDTBLDIR=/project/fldtbls
FIELDTBLS=maskftbl,DBftbl,miscftbl,
export FLDTBLDIR FIELDTBLS
mkfldhdr produces the #include files maskftbl.h, DBftbl.h, and miscftbl.h in the current directory by processing the files maskftbl, DBftbl, and miscftbl in directory /project/fldtbls.
With environment variables set as in the example above, the command mkfldhdr -d$FLDTBLDIRprocesses the same input field-table files, and produces the same output files, but places them in the directory given by the value of the environment variable FLDTBLDIR.
The command mkfldhdr myfieldsprocesses the input file myfields and produces myfields.h in the current directory.
See Also
Fintro(3fml), field_tables(5)
mklanginfo(1)
Name
mklanginfo-compile language information constants for a locale
Synopsis
mklanginfo [fname]
Description
This program takes the file specified as an argument, and converts the input into a file suitable for placement in $TUXDIR/locale/xx/LANGINFO where xx is a specific locale. The standard input is used if a file argument is not specified. The language values are used by setlocale(3c), strftime(3c) and nl_langinfo(3c).
mklanginfo reads input lines, ignoring lines that begin with white space or '#'. Value input lines must be of the form
<token> = "value"
(the characters between the token and the double-quoted value can be anything but a double quote as long as white space appears after the token). If value is the null string, the line is ignored. Otherwise, token must either be a integer between 1 and 48, inclusive, or a string as follows:
Integer String Value 1
DAY_1 Day 1 of the week, e.g., Sunday 2
DAY_2 Day 2 of the week, e.g., Monday 3
DAY_3 Day 3 of the week, e.g., Tuesday 4
DAY_4 Day 4 of the week, e.g., Wednesday 5
DAY_5 Day 5 of the week, e.g., Thursday 6
DAY_6 Day 6 of the week, e.g., Friday 7
DAY_7 Day 7 of the week, e.g., Saturday 8
ABDAY_1 Abbreviated day 1 of the week, e.g., Sun 9
ABDAY_2 Abbreviated day 2 of the week, e.g., Mon 10
ABDAY_3 Abbreviated day 3 of the week, e.g., Tue 11
ABDAY_4 Abbreviated day 4 of the week, e.g., Wed 12
ABDAY_5 Abbreviated day 5 of the week, e.g., Thu 13
ABDAY_6 Abbreviated day 6 of the week, e.g., Fri 14
ABDAY_7 Abbreviated day 7 of the week, e.g., Sat 15
MON_1 Month 1 of the year, e.g., January 16
MON_2 Month 2 of the year, e.g., February 17
MON_3 Month 3 of the year, e.g., March 18
MON_4 Month 4 of the year, e.g., April 19
MON_5 Month 5 of the year, e.g., May 20
MON_6 Month 6 of the year, e.g., June 21
MON_7 Month 7 of the year, e.g., July 22
MON_8 Month 8 of the year, e.g., August 23
MON_9 Month 9 of the year, e.g., September 24
MON_10 Month 10 of the year, e.g., October 25
MON_11 Month 11 of the year, e.g., November 26
MON_12 Month 12 of the year, e.g., December 27
ABMON_1 Abbreviated month 1 of the year, e.g., Jan 28
ABMON_2 Abbreviated month 2 of the year, e.g., Feb 29
ABMON_3 Abbreviated month 3 of the year, e.g., Mar 30
ABMON_4 Abbreviated month 4 of the year, e.g., Apr 31
ABMON_5 Abbreviated month 5 of the year, e.g., May 32
ABMON_6 Abbreviated month 6 of the year, e.g., Jun 33
ABMON_7 Abbreviated month 7 of the year, e.g., Jul 34
ABMON_8 Abbreviated month 8 of the year, e.g., Aug 35
ABMON_9 Abbreviated month 9 of the year, e.g., Sep 36
ABMON_10 Abbreviated month 10 of the year, e.g., Oct 37
ABMON_11 Abbreviated month 11 of the year, e.g., Nov 38
ABMON_12 Abbreviated month 12 of the year, e.g., Dec 39
RADIXCHAR Radix character, e.g., '.' 40
THOUSEP Separator for thousands 41
YESSTR Affirmative response string, e.g., yes 42
NOSTR Negative response string, e.g., no 43
CRNCYSTR Currency symbol 44
D_T_FMT string for formatting date and time, e.g., "%a%b%d%H:%M:0Y" 45
D_FMT string for formatting date, e.g., "%m/%d/%y" 46
T_FMT string for formatting time, e.g., "H:%M:%S" 47
AM_FMT Ante Meridian affix, e.g., AM 48
PM_FMT Post Meridian affix, e.g., PM
The input lines may appear in any order (if an input line appears more than once for the same value, the last line for that value is used).
After processing the file, mklanginfo prints the string name and string value for each language information constant listed above to the standard error in the order specified above. The null string is used as a value for any language information constant not specified; nl_langinfo will use the default value for the C locale (U.S. English values) for these unset constants.
If a filename is specified on the command name, mklanginfo writes the compiled output to fname.out; otherwise, the output is written to the standard output. The format is a list of all of the null-terminated string values (without newlines).
Diagnostic
If an error occurs in reading the file or in the syntax, an error message is printed to the standard error and the program exits with exit code 1. On success, the program exits with exit code 0.
Examples
The defaults for the BEA Tuxedo system (locale C) are located in $TUXDIR/locale/C/lang.text. To provide French values, an administrator might do the following: mkdir $TUXDIR/locale/french cd $TUXDIR/locale/french cp $TUXDIR/locale/C/lang.text. ed lang.text... convert to French values w q mklanginfo lang.text > LANGINFO
Files
$TUXDIR/locale/C/lang.text - the default values for the C locale $TUXDIR/locale/C/LANGINFO - the "compiled" file for the C locale $TUXDIR/locale/xx/LANGINFO - the "compiled" file for the "xx" locale
Notices
The mklanginfo command and the resulting LANGINFO file are needed only if the BEA Tuxedo system compatibility functions for setlocale(), strftime(), or nl_langinfo() are used. The functions provided with the UNIX system use a different set and format of files.
See Also
setlocale(3c), strftime(3c), nl_langinfo(3c), langinfo(5)
pic_uform(1)
Name
pic_uform-picture to UFORM conversion program
Synopsis
pic_uform [-l lastchar] [-f firstchar] [-s fillchar] [-r rows] infile outfile
Description
pic_uform is a tool used to create a skeleton UFORM source definition (outfile) from an edit file image of a form (infile). The placement of fields and literals on the form is identical to their placement in the edit file.
No differentiation is made between protected and unprotected fields. Fields are designated as follows:
The last line of all fields begins with lastchar. By default this is + but it can be reset with the -l option. All other lines of fields begin with firstchar. By default this is = but it can be reset with the -f option. All other positions in fields contain fillchar. fillchar defaults to a _, but may be reset with the -s option. The tab character, (\t), or the space character, (" "), can not be used as substitutes for the defaults.
A new page is indicated by a form feed (CTRL-L). New pages are automatically generated when the number of rows on a page exceeds the rows argument on the command line. By default the maximum number of rows on a page is 24. The last row on a page is always reserved for the status line so only rows-1 rows are available on each page.
All text (other than fields) is assumed to be literals.
Examples
The input:
THIS IS A TEST MASK
+___________ +___________ +___________
+___________ +___________ +___________
^L
PAGE TWO
=____________
=____________
+____________
The output:
#SERVICE NAME=NULL
#FORM STATUSLINE=24 FLAGS="-"
#PAGE FLAGS="-" STATUSLINE=24
*ROW COL MIN LINES WIDTH FLAGS VALUE
1 25 0 1 19 L "THIS IS A TEST MASK"
+2 1 0 1 12 U
- 33 0 1 12 U
- 65 0 1 12 U
+1 1 0 1 12 U
- 33 0 1 12 U
- 65 0 1 12 U
#PAGE FLAGS="-" STATUSLINE=24
*ROW COL MIN LINES WIDTH FLAGS VALUE
+1 25 0 1 8 L "PAGE TWO"
+2 1 0 3 13 U
Notices
Whenever the form edit image changes and a new UFORM skeleton is produced, all modifications made to the old skeleton, such as validations, help messages, etc., must be made to the new skeleton.
See Also
BEA Tuxedo Data Entry System Guide
qmadmin(1)
Name
qmadmin-Queue manager administration program
Synopsis
[QMCONFIG=<device>] qmadmin [<device>]
Description
With the commands listed below, qmadmin provides for creation, inspection and modification of message queues. The name of the device (file) on which the universal device list resides (or will reside) for the queue space may either be specified as a command line argument or via the environment variable QMCONFIG. If both are specified, the command option is used.
As a system-provided server, qmadmin does not go through normal initialization, so it does not pick up the value of ULOGPFX. As a result, any log entries generated by qmadmin commands are written to the current working directory. This is corrected by setting and exporting the ULOGPFX environment variable to the pathname of the directory where the userlog is located.
qmadmin uses the greater than sign, >, as a prompt. Arguments are entered separated by white space (tabs and/or spaces). Arguments that contain white space may be enclosed within double quotes; if an argument enclosed within double quotes contains a double quote, the internal double quote must be escaped with a backslash. Commands will prompt for the information if it is not given on the command line. A warning message is displayed and the prompt shown again, if a required argument is not entered.
The user can exit the program by entering q or CTRL-d> when prompted for a command. Output from a command may be terminated by hitting BREAK; the program then prompts for the next command. Hitting return when prompted for a command repeats the previously executed command, except after a break.
Note that there is no way to effectively cancel a command once you press RETURN; hitting BREAK only terminates output from the command, if any. Therefore, be sure that you type a command exactly as you intended before pressing RETURN.
Output from qmadmin commands is paginated according to the pagination command in use (see the paginate subcommand below).
When first entering qmadmin, no queue space is opened. A queue space is created using qspacecreate and is opened using qopen. The qaborttrans, qclose, qchangeprio, qchangequeue, qchangetime, qcommittrans, qchange, qcreate, qdeletemsg, qinfo, qlist, qprinttrans and qset commands can only be executed when a queue space is open.
qmadmin Commands
Commands may be entered either by their full name or their abbreviation (if available, the abbreviation is listed below in parentheses following the full name), followed by any appropriate arguments. Arguments appearing in square brackets, [], are optional; those in curly braces, {}, indicate a selection from mutually exclusive options.
chdl [dlindex [newdevice]]
Change the name for a universal device list entry. The first argument is the index of the device on the universal device list that is to be changed (device indexes are returned by lidl). The program will prompt for it if not provided on the command line. The second argument is the new device name. If not provided on the command line, the program prints the current device name and then prompts for a new one. The name is limited to 64 characters in length. Files or data will no longer be accessible via the old name after the device name is changed so this command must be used cautiously. A more detailed description of the Universal Device List and Volume Table of Contents are provided in the BEA WebLogic Enterprise Administration Guide.
[high [low [cmd]]]]]]]]
[-i corrid] | none }]
[messages [errorq [inityn [blocking]]]]]]
[procs [messages [errorq [inityn [blocking]]]]]]]]
Example
The following sequence shows how to set up a queue.
$ QMCONFIG=/dev/rawfs qmadmin
qmadmin - Copyright (c) 1987 ATT; 1991 USL. All rights reserved.
QMCONFIG=/dev/rawfs
# create the list of devices on which the queue space
# can exist; specify two devices, 80000 and 600
# blocks, respectively
# NOTE: the first one will actually contain the device list
#
# create first device on a raw slice
#
> crdl /dev/rawfs 0 80000
Created device /dev/rawfs, offset 0, size 80000 on /dev/rawfs
#
# create another device on a UNIX file
#
> crdl /home/queues/FS 0 600
Created device /home/queues/FS, offset 0, size 600 on /dev/rawfs
#
# if you want a list of the device list
#
> v Verbose mode is now on
> lidl
universal device index. 0:
name: /dev/rawfs
start: 0
size: 20000
free space map(1 entry used 47 available):
size[1]: 79974 addr[1]: 26
universal device index. 1:
name: /home/queues/FS
start: 0
size: 600
free space map(1 entry used 47 available):
size[1]: 600 addr[1]: 0
#
# create a queue space
#
> qspacecreate
Queue space name: myqueuespace
IPC Key for queue space: 42000
Size of queue space in disk pages: 50000
Number of queues in queue space: 30
Number of concurrent transactions in queue space: 20
Number of concurrent processes in queue space: 30
Number of messages in queue space: 20000
Error queue name: ERRORQ
Initialize extents (y, n [default=n]): y
Blocking factor [default=16]: 16
....................
#
# open queue space
#
> qopen myqueuespace
#
# use queue space defaults for queue
> qcreate
Queue name: service1
queue order (priority, time, fifo, lifo): fifo
out-of-ordering enqueuing (top, msgid, [default=none]): top,msgid
retries [default=0]: 1
retry delay in seconds [default=0]: 30
High limit for queue capacity warning (b for bytes used, B for blocks used,
% for percent used, m for messages [default=100%]): 100m
Reset (low) limit for queue capacity warning [default=0m]: 50
queue capacity command: /usr/app/bin/mailadmin myqueuespace service1
#
# get out of the program
#
> q
Security
The system administrator for the queue must be the same as the BEA Tuxedo administrator. The device on which the queue resides must be owned by the administrator and qmadmin can only be run as the administrator for the queue. All IPC resources allocated for the queue will be owned by the queue administrator and will be created with mode 0600.
Portability
qmadmin is supported as a BEA Tuxedo-supplied administrative tool on UNIX operating systems only. It cannot be run from a workstation.
See Also
BEA WebLogic Enterprise Administration Guide.
rex(1)
Name
rex-off-line regular expression compiler and tester
Synopsis
Compiling:
rex pattern-file C-file
Testing:
rex pattern [file...]
Description
When invoked without arguments, rex reads regular expressions from the standard input and writes initialized character arrays to the standard output. Normally, the output would be included in a C program to preclude the need for calling recomp(3c). This saves on both execution time and program size. The command rex compiles the regular expressions on the standard input (normally redirected from an input file) and writes the output to the standard output (normally redirected to an output file).
The input file may contain several patterns, each of the form: name string [string...]
where name is the C name to be used for the output array and string is the regular expression enclosed with double quotes. Where more than one string follows a name they are concatenated into one string. (Multiple strings are strictly a formatting convenience.) If double quotes occur in the pattern they need to be preceded by a backslash. The output may be included in a C program or compiled and later loaded. In the C program that uses the rex output, rematch(abc,line,0) will apply the regular expression named abc to line.
Sample input file:
<cname "[a-zA-Z_][a-(3c)-Z0-9_]*"
tn "\\\\(([0-9]{3})$0\\\\)"
"([0-9]{3})$1"
"-"
"([0-9]{4})$2"
Corresponding output:
/* pattern: "[a-aA-Z_][a-zA-Z0-9_]*" */
char cname[] = {
040,0,0206,012,0,0210,0141,0172,0210,0101,0132,0137,
... };
/* pattern: "\\\\(([0-9]{3})$0\\\\)([0-9]{3})$1-([0-9]{4})$2" */
char tn[] = {
063,0,050,0202,0225,013,0,03,0206,06,0,0210,060,071,
... };
rex can be used to try patterns against test data by invoking it with one or more arguments. The first argument is taken as a pattern (regular expression) to be applied to each line of the files whose names are mentioned in the remaining arguments. If no filename arguments are given the standard input is used. The special filename, -, may be used as an argument to refer to the standard input.
When matching text is found, the line containing the match is printed and the matching portion of the line is underlined. In addition, any text extracted for specified subpatterns is printed on separate line(s).
For example, the command
rex '(^| )([0-9]+)$0(|$)'
with input
... or 200 programmers in one week.
This sentence has 3 erors.
I need 12 bad men.
produces
... or 200 programmers in one week.
-----
$0 = \Q200'
This sentence has 3 errors.
---
$0 = \Q3'
I need 12 bad men.
----
$0 = \Q12'
Diagnostics
rex prints the associated error messages for errors returned from recomp() or rematch() (see recomp(3c)). Other errors include file open errors, argument errors, etc. and are self-explanatory.
See Also
recomp(3c)
tidl(1)
Name
tidl-Interface Definition Language compiler
Synopsis
tidl [option] ... filename [option]...
Description
tidl parses the input IDL and related ACF source file, and optionally generates a header file, and client and server stubs and auxiliary files. The generated source code can be compiled using compilers for Classic C, ANSI C, or C++.
The command-line arguments include the input IDL source file and options to control the actions of the IDL compiler. The options are as follows:
For the IDL source file and any imported IDL files, the compiler searches for a related ACF with a .acf suffix added to the base name of the IDL source file. The directories that are searched are the same directories specified for the C preprocessor (see -I and -no_def_idir above), plus ACF files are searched for in the directory specified in the IDL source filename.
Notices
The IDL filename tbase.idl is reserved for use by the IDL compiler.
Examples
Here is an example IDL source file, math1.idl.
[uuid(2048A080-0B0F-14F8-26E0-930269220000)]
interface math1
{
import "math2.idl";
long add_op([in] long first1, [in] long second);
long sub_op([in] long first1, [in] long second);
}
Here is a sample ACF source file, math1.acf.
[auto_handle]
interface math1
{
include "stdio";
[code] add_op([fault_status,comm_status] result);
}
The following command line will compile math1.idl generating client side only files out/math1_cs.c and out/math1_cs.o (no auxiliary files are needed), along with out/math1.h. The IDL compiler will look for math2.idl (which might have the division and multiplication operations) in the current directory, in the app subdirectory, and in $TUXDIR/include.
tidl math1.idl -Iapp -client all -server none -keep all
-cstub math1_cs -out app
See Also
uuidgen(1)
tlisten(1)
Name
tlisten-generic listener process
Synopsis
tlisten [-d device ] -l nlsaddr [-u {uid-# | uid-name}] [-z bits ] \
[ -Z bits ]Description
tlisten is a network independent listener process that runs as a daemon process on BEA Tuxedo application processors and provides remote service connections for other BEA Tuxedo processes, for example, tmboot(1). The following command-line options are used by tlisten:
The tlisten process authenticates most service requests. tlisten reads a file with a list of passwords, and any process requesting a service must present at least one of the passwords found in the file. If the APPDIR environment variable is set, passwords will be obtained from a file named APPDIR/.adm/tlisten.pw. If this file is not found, the system will look for TUXDIR/udataobj/tlisten.pw, which is created when the BEA Tuxedo system is installed. A zero-length or missing password file disables password checking. When running in this insecure mode, the tlisten and any process connecting to tlisten will generate a userlog warning message.
Processes which request services from tlisten such as tmboot find the passwords to be used during authentication in files on their own machines. They use the same methods as the tlisten to find their password files.
Environment Variables
Note: During the installation process, an administrative password file is created. When necessary BEA Tuxedo searches for this file in the following directories (in the order shown):
If the link-level encryption feature is in operation between tlisten and a requesting process such as tmboot, then link-level encryption will be negotiated and activated before authentication occurs.
Termination
The only way to stop a tlisten process with normal termination is by sending it a SIGTERM signal.
Recommended Use
We recommend that you start one tlisten process for each application upon system startup. Remember to set the TUXDIR and APPDIR environment variables before invoking tlisten.
One alternative method for starting the tlisten process is to start it manually. The -u option can be omitted if the tlisten process is started by the application administrator. Duplicate tlisten command invocations using the same network address will terminate automatically and gracefully log an appropriate message.
Network Addresses
Suppose the local machine on which the tlisten is being run is using TCP/IP addressing and is named backus.company.com, with address 155.2.193.18. Further suppose that the port number at which the tlisten should accept requests is 2334. Assume that port number 2334 has been added to the network services database under the name bankapp-nlsaddr. The address specified by the -l option could be represented in the following ways:
//155.2.193.18:bankapp-nlsaddr
//155.2.193.18:2334
//backus.company.com:bankapp-nlsaddr
//backus.company.com:2334
0x0002091E9B02C112
The last of these representations is hexadecimal format. The 0002 is the first part of a TCP/IP address. The 091E is the port number 2334 translated into a hexadecimal number. After that each element of the IP address 155.2.193.12 is translated into a hexadecimal number. Thus the 155 becomes 9B, 2 becomes 02 and so on.
For a STARLAN network, a recommended address of uname.tlisten will usually yield a unique name.
Windows NT Control Panel Applet
Administrative privileges on a remote Microsoft Windows NT machine are required in order to start a tlisten process on that machine through the Control Panel Applet.
See Also
ubbconfig(5)
tmadmin(1)
Name
tmadmin-BEA Tuxedo Bulletin Board command interpreter
Synopsis
tmadmin [ -r ] [ -c ] [ -v ]
Description
With the commands listed below, tmadmin provides for inspection and modification of Bulletin Boards and associated entities in either a uniprocessor, multiprocessor, or networked environment. The TUXCONFIG and TUXOFFSET environment variables are used to determine the location and offset where the BEA Tuxedo configuration file has been loaded.
If tmadmin is invoked with the -c option, it enters configuration mode. The only valid commands are default, echo, help, quit, verbose, livtoc, crdl, lidl, dsdl, indl, and dumptlog. tmadmin may be invoked in this mode on any node, including inactive nodes. A node is considered active if tmadmin can join the application as an administrative process or client (via a running BBL).
The -r option instructs tmadmin to enter the Bulletin Board as a client instead of the administrator and provides read-only access. This is useful if it is desired to leave the administrator slot unoccupied. Only one tmadmin process can be the administrator at a time. When the -r option is specified by a user other than the BEA Tuxedo administrator and security is turned on, the user will be prompted for a password.
The -v option causes tmadmin to display the BEA Tuxedo version number and license number. After printing out the information, tmadmin exits. If the -v option is entered with either of the other two options, the others are ignored; only the information requested by the -v option is displayed.
Normally, tmadmin may be run on any active node within an active application. If it is run on an active node that is partitioned, then commands are limited to read only access to the local Bulletin Board. These command include bbls, bbparms, bbstat, default, dump, dumptlog, echo, help, interfaceparms, printactiveobject, printclient, printinterface, printfactory, printjdbcconnpool, printnet, printqueue, printroute, printserver, printservice, printtrans, printgroup, reconnect, quit, serverparms, serviceparms, and verbose, in addition to the configuration commands. If the partitioned node is the backup node for the MASTER (specified as the second entry on the MASTER parameter in the RESOURCES section of the configuration file), the master command is also available to make this node the MASTER for this part of the partitioned application.
If the application is inactive, tmadmin can only be run on the MASTER processor. In this mode, all of the configuration mode commands are available plus the TLOG commands (crlog, dslog, and inlog) and boot.
Once tmadmin has been invoked, commands may be entered at the prompt (">") according to the following syntax: command [arguments].
Several commonly occurring arguments can be given defaults via the default command. Commands that accept parameters set via the default command check default to see if a value has been set. If one has not, an error message is returned.
In a networked or multiprocessor environment, a single Bulletin Board can be accessed by setting a default machine (the logical machine id (LMID) as listed in the MACHINES section of the UBBCONFIG file). If the default machine is set to all, all Bulletin Boards are accessed. If machine is set to DBBL, the distinguished Bulletin Board is addressed. The default machine is shown as part of the prompt, as in: MASTER>.
If machine is not set via the default command, the DBBL is addressed (the local BBL is used in a SHM configuration).
The machine value for a command can generally be obtained from the default setting (printserver is an example). A caution is required here, however, because some commands (the TLOG commands, for example) act on devices found through TUXCONFIG; a default setting of DBBL or all results in an error. There are some commands where the machine value must be provided on the command line (logstart is an example); the value does not appear as an argument to the -m option.
After being set, a default 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 tmadmin commands is paginated according to the pagination command in use (see the paginate subcommand below).
There are some commands that have either verbose or terse output. The verbose command can be used to set the default output level. However, each command (except boot, shutdown and config) takes a -v or -t option to turn verbose or terse output on for that command only. When output is printed in terse mode, some of the information (for example, LMID or GROUP name, service or server name) may be truncated. Truncation may be at either the left or right end of the value. The more important end of the value is not truncated. Truncation is indicated by a plus sign (+). The entire value may be seen by re-entering the command in verbose mode.
tmadmin Commands
Commands may be entered either by their full name or their abbreviation (as given 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 command-line options that do not appear in square brackets need not appear on the command line (that is, they are optional) if the corresponding default has been set via the default command. Ellipses following a group of options in curly brackets, {}..., indicate that more than one of the options may appear on the command line (at least one must appear).
-n module_name -j main_jar
[-C local_classpath] [-A initialization_args]
Note: If the JavaServer specified in this command does not have hot deployment enabled, the request fails and no change is made. For information on enabling hot deployment, see the description of the Dwle.dynamic option in the "Using Server Command-Line Options" section in "Chapter 3" of the in the BEA WebLogic Enterprise Administration Guide..
advertise (adv) {-q qaddress [ -g groupname ]
[-i srvid] | -g groupname -i srvid} service[:func]
[-i srvid] -s service | -g groupname -i srvid -s service | -I interface [-g groupname]} newload
-n module_name -j main_jar
[-C local_classpath] [-A initialization_args]
Note: Using the changemodule command to redeploy a module is a shortcut for requesting undeployment, immediately followed by deployment-a process that requires that all the parameters necessary for deployment be specified again. The main_jar file that is specified must be different from the JAR file that was specified when the module was originally deployed; this is because the Java run-time environment will usually still be using the previous JAR and will have it locked. The -C and the -A options, if specified, do not necessarily have to match the values that were specified when the module was originally deployed.
Note: If the JavaServer specified in this command does not have hot deployment enabled, the request fails and no change is made. For information on enabling hot deployment, see the description of the Dwle.dynamic option in the "Using Server Command-Line Options" section in "Chapter 3" of the BEA WebLogic Enterprise Administration Guide..
[-i srvid] -s service | -g groupname -i srvid -s service | -I interface [-g groupname]} newpri
[-i srvid] -s service | -g groupname -i srvid -s service | -I interface [-g groupname]} newtlim
[-q qaddress] [-s service] [-b blocks] [-o offset] [-z config] [-a { 0|1|2}] [-I interface] [-B objectid] [-r routingname] [-p jdbcconnpool]
[-p jconnpoolname]
[-q qaddress] [-s service]
Note: If the JavaServer specified in this command does not have hot deployment enabled, the request fails and no change is made. For information on enabling hot deployment, see the description of the Dwle.dynamic option in the "Using Server Command-Line Options" section in "Chapter 3" of the BEA WebLogic Enterprise Administration Guide..
Security
When tmadmin runs as the administrator, it does not pass through security since it is already checked to be the application administrator's login ID.
The only time that tmadmin may run as someone other than the application administrator is if the -r option is used to access the application as a client. If such a user invokes tmadmin with the -r option, and if security is turned on for the application, then the application password is required to access application data. If standard input is a terminal, then tmadmin will prompt the user for the password with echo turned off on the reply. 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 tmadmin will fail.
Environment Variables
tmadmin acts as an application client if the -r option is used or if it cannot register as the application administrator. If this is the case, then the APP_PW environment variable must be set to the application password in a security application if standard input is not from a terminal.
Diagnostics
If the tmadmin command is entered before the system has been booted, the following message is displayed:
No bulletin board exists. Entering boot mode
>
tmadmin then waits for a boot command to be entered.
If the tmadmin command is entered, without the -c option, on an inactive node that is not the MASTER, the following message is displayed and the command terminates:
Cannot enter boot mode on non-master node.
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
tmadmin may be run on any node within an active interoperating application. However, the commands and command-line arguments available are restricted to those available via tmadmin in the release corresponding to the node where tmadmin is running. For example, the commands broadcast, passwd and printclient are not available on Release 4.1 nodes.
Portability
tmadmin is supported as a BEA Tuxedo-supplied administrative tool on UNIX operating systems only.
Notices
The machine option has no effect in a non-networked uniprocessor environment.
See Also
tmloadcf(1), tmboot(1), tmshutdown(1), compilation(5), ubbconfig(5), BEA WebLogic Enterprise Administration Guide.
tmboot(1)
Name
tmboot-bring up a BEA Tuxedo configuration
Synopsis
tmboot [-l lmid] [-g grpname] [-i srvid] [-s aout] [-o sequence]
[-S] [-A] [-b] [-B lmid] [-T grpname] [-e command] [-w] [-y] [-q]
[-n] [-c] [-M] [-d1]
Description
tmboot brings up a BEA Tuxedo application in whole or in part depending on the options specified. tmboot can be invoked only by the administrator of the Bulletin Board (as indicated by the UID parameter in the configuration file) or by root. tmboot can be invoked only on the machine identified as MASTER in the RESOURCES section of the configuration file, or the backup acting as the MASTER, that is, with the DBBL already running (via the master command in tmadmin(1)). Except, if the -b option is used; in that case, the system can be booted from the backup machine without it having been designated as the MASTER.
With no options, tmboot executes all administrative processes and all servers listed in the SERVERS section of the configuration file named by the environment variables, TUXCONFIG and TUXOFFSET. If the MODEL is MP, a DBBL administrative server is started on the machine indicated by the MASTER parameter in the RESOURCES section. An administrative server (BBL) is started on every machine listed in the MACHINES section. For each group in the GROUPS section, TMS servers are started based on the TMSNAME and TMSCOUNT parameters for each entry. All administrative servers are started followed by servers in the SERVERS sections. Any TMS or gateway servers for a group are booted before the first application server in the group is booted. The TUXCONFIG file is propagated to remote machines as necessary. tmboot normally waits for a booted process to complete its initialization (that is, tpsvrinit()) before booting the next process.
Booting a gateway server implies that the gateway advertises its administrative service, and also advertises the application services representing the foreign services based on the CLOPT parameter for the gateway (-A will cause all services defined when the gateway is built with buildgateway(1) to be advertised; -s can be used to give a list of services). If the instantiation has the concept of foreign servers, these servers are booted by the gateway at this time.
Booting an LMID is equivalent to booting all groups on that LMID.
Application servers are booted in the order specified by the SEQUENCE parameter, or in the order of server entries in the configuration file (see description in ubbconfig(5)). If two or more servers in the SERVERS section of the configuration file have the same SEQUENCE parameter, then tmboot may boot these servers in parallel and will not continue until they all complete initialization. Each entry in the SERVERS section can have a MIN and MAX parameter. tmboot boots MIN application servers (the default is 1 if MIN is not specified for the server entry) unless the -i option is specified; using the -i option causes individual servers to be booted up to MAX occurrences.
If a server can not be started, a diagnostic is written on the central event log (and to the standard output, unless -q is specified), and tmboot continues-except that if the failing process is a BBL, servers that depend on that BBL are silently ignored; if the failing process is a DBBL, tmboot ignores the rest of the configuration file. If a server is configured with an alternate LMID and fails to start on its primary machine, tmboot automatically attempts to start the server on the alternate machine and, if successful, sends a message to the DBBL to update the server group section of TUXCONFIG.
For servers in the SERVERS section, only CLOPT, SEQUENCE, SRVGRP and SRVID are used by tmboot. Collectively, these are known as the server's boot parameters. Once the server has been booted, it reads the configuration file to find its runtime parameters. (See ubbconfig(5) for a description of all parameters.)
All administrative and application servers are booted with APPDIR as their current working directory. The value of APPDIR is specified in the configuration file in the MACHINES section for the machine on which the server is being booted.
The search path for the server executables is APPDIR, followed by TUXDIR/bin, followed by /bin and /usr/bin, followed by any PATH specified in the ENVFILE for the MACHINE. The search path is only used if an absolute path name is not specified for the server. Values placed in the server's ENVFILE are not used for the search path.
When a server is booted, the variables TUXDIR, TUXCONFIG, TUXOFFSET, and APPDIR, with values specified in the configuration file for that machine, are placed in the environment. The environment variable LD_LIBRARY_PATH is also placed in the environment of all servers. Its value defaults to $APPDIR:$TUXDIR/lib:/lib:/usr/lib:lib> where lib> is the value of the first LD_LIBRARY_PATH= line appearing in the machine ENVFILE. See ubbconfig(5) for a description of the syntax and use of the ENVFILE.
The ULOGPFX for the server is also set up at boot time based on the parameter for the machine in the configuration file. If not specified, it defaults to $APPDIR/ULOG.
All of these operations are performed before the application initialization function, tpsvrinit(), is called.
Many of the command-line options of tmboot serve to limit the way in which the system is booted and can be used to boot a partial system. The following options are supported:
When the -l, -g, -i, -o, and -s options are used in combination, only servers that satisfy all qualifications specified will be booted. The -l, -g, -s, and -T options cause TMS servers to be booted; the -l, -g, and -s options cause gateway servers to be booted; the -l, -g, -i, -o, -s, and -S options apply to application servers. Options that boot application servers will fail if a BBL is not available on the machine.The -A, -M, and -B options apply only to administrative processes.
The standard input, standard output, and standard error file descriptors will be closed for all booted servers.
Interoperability
tmboot must run on the master node, which in an interoperating application must be the highest release available. tmboot detects and reports configuration file conditions that would lead to the booting of administrative servers such as workstation listeners on sites that cannot support them.
Portability
tmboot is supported as a BEA Tuxedo-supplied administrative tool on UNIX operating systems only.
Environment Variables
During the installation process, an administrative password file is created. When necessary, BEA Tuxedo searches for this file in the following directories (in the order shown): APPDIR/.adm/tlisten.pw TUXDIR/udataobj/tlisten.pw. To ensure that your password file will be found, make sure you have set the APPDIR and/or TUXDIR environment variables.
Link-Level Encryption
If the link-level encryption feature is in operation between tmboot and tlisten, link-level encryption will be negotiated and activated first to protect the process by which messages are authenticated.
Diagnostics
If TUXCONFIG is set to a non-existent file, two fatal error messages are displayed: error processing configuration file configuration file not found.
If tmboot fails to boot a server, it will exit with exit code 1 and the user log should be examined for further details; otherwise it will exit with exit code 0.
If tmboot is run on an inactive non-master node, a fatal error message is displayed: tmboot cannot run on a non-master node.
If tmboot is run on an active node that is not the acting master node, a fatal error message is displayed: tmboot cannot run on a non acting-master node in an active application.
If the same IPCKEY is used in more than one TUXCONFIG file, tmboot fails with the following message: Configuration file parameter has been changed since last tmboot.
If there are multiple node names in the MACHINES section in a non-LAN configuration, a fatal error message is displayed: Multiple nodes not allowed in MACHINES for non-LAN application.
If tlisten is not running on the MASTER machine in a LAN application, a warning message will be printed. In this case, tmadmin(1) will not be able to run in administrator mode on remote machines; it will be limited to read-only operations. This also means that the backup site will be unable to reboot the master site after failure.
Examples
To start only those servers located on the machines logically named CS0 and CS1: tmboot -l CS0 -l CS1. To start only those servers named CREDEB and belonging to group DBG1: tmboot -g DBG1 -s CREDEB1. To boot a BBL on the machine logically named PE8, as well as all those servers whose location is specified as PE8: tmboot -B PE8 -l PE8.
To view minimum IPC resources needed for the configuration: tmboot -c.
The following is an example of the output produced by the -c option:
Ipc sizing (minimum /T values only) ...
Fixed Minimums Per Processor
SHMMIN: 1
SHMALL: 1
SEMMAP: SEMMNI
Variable Minimums Per Processor
SEMUME, A SHMMAX
SEMMNU, * *
Node SEMMNS SEMMSL SEMMSL SEMMNI MSGMNI MSGMAP SHMSEG
------ ------ ------ ------ ------ ------ ------ ------
sfpup 60 1 60 A + 1 10 20 76K
sfsup 63 5 63 A + 1 11 22 76K
where 1 = A = 8.
The number of expected application clients per processor should be added to each MSGMNI value. MSGMAP should be twice MSGMNI. SHMMIN should always be set to 1.
The minimum IPC requirements can be compared to the parameters set for your machine. See the System Administrator's Guide for your machine for information about how to change these parameters. If the -y option is used, the display will differ slightly from the above example.
Notices
The tmboot command ignores the hangup signal (SIGHUP). If a signal is detected during boot, the process continues.
Minimum IPC resources displayed with the -c option apply only to the configuration described in the configuration file specified; IPC resources required for a resource manager, for a mask cache, or for other BEA Tuxedo configurations are not considered in the calculation.
See Also
tmadmin(1), tmshutdown(1), tmloadcf(1), ubbconfig(5), BEA WebLogic Enterprise Administration Guide.
tmconfig(1)
Name
tmconfig-dynamically update and retrieve information about the BEA Tuxedo configuration for a running system
Synopsis
tmconfig
Description
tmconfig is an interactive program that can be used to update some of the configuration file parameters, or MIB attributes, and add records to some of the TUXCONFIG sections while the BEA Tuxedo application is running. tmconfig manages a buffer that contains input field values to be added, updated, 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.
tmconfig is a BEA Tuxedo system client. (It will show up as tmconfig with the username being the login name in the tmadmin printclient command.) If the application is using the SECURITY feature, it will prompt for the application password.
tmconfig first prompts for the desired section followed by a prompt for the desired operation.
The prompt for the section is as follows.
Section:1) RESOURCES, 2) MACHINES, 3) GROUPS 4) SERVERS 5)SERVICES
6) NETWORK 7) ROUTING q) QUIT 9) WSL 10) NETGROUPS 11) NETMAP [1]:
The default section appears in square brackets at the end of the prompt.
tmconfig then prompts for the desired operation.
Operation: 1) FIRST 2) NEXT 3) RETRIEVE 4) ADD 5) UPDATE
6) CLEAR BUFFER 7) QUIT [1]:
The default operation is printed in square brackets at the end of the prompt. Entering return will select this option. The other options are selected by entering the number and RETURN.
The currently supported operations are:
For administrator operations, the effective user identifier must match the BEA Tuxedo 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 tmloadcf(1) are enforced.
tmconfig 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 and the default is ed. The input format is in fieldname/field value pairs and is described in the INPUT FORMAT section below. The field names associated with each UBBCONFIG section are listed in tables in the subsections below. The semantics of the fields and associated ranges, default values, restrictions, etc. are described in ubbconfig(5). Note that permissions values are specified in decimal, not octal. In most cases, the field name is the same as the KEYWORD in the UBBCONFIG file, prefixed with "TA_". When the user completes editing the input buffer, tmconfig 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 tmconfig 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, tmconfig asks if the operation should be done. Perform operation [y]?
When the operation completes, tmconfig 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, tmconfig prompts for creating a backup ASCII version of the configuration: Unload TUXCONFIG file into ASCII backup [y]? If a backup is selected, tmconfig prompts for the filename. Backup filename [UBBCONFIG]? On success, tmconfig indicates that a backup was created; otherwise an error is printed.
Input Format
Input packets consist of lines formatted as follows:
fldname fldval
The field name is separated from the field value by one or more tabs.
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 tmconfig).
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(5) 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. tmconfig recognizes all input in this format, but the greatest usefulness of the hexadecimal format is for non-printing characters.
Limitations
The following are general limitations of the dynamic reconfiguration capability:
Relationship between tmconfig, ubbconfig and MIBs
In what are now ancient releases of BEA Tuxedo all application configuration was accomplished by editing an ASCII file, the UBBCONFIG file, that contained all the configuration parameters for an application. A later version compiled that file into a binary format known as TUXCONFIG, by using tmloadcf(1).Yet another release introduced tmconfig, which enabled dynamic updates (that is, updates while the system was active) of a number of TUXCONFIG parameters. A more recent development was the introduction of BEA Tuxedo Management Information Bases (MIBs) which redefined BEA Tuxedo resources into classes and attributes. With the advent of MIBs, the BEA Tuxedo system also provided an admin API that enables an administrator (or a user) to access and change the attributes of an application programmatically. To keep documentation from getting out of synch, BEA Tuxedo documentation will no longer maintain section tables in this reference page for tmconfig, except for the table for the Network Section. Instead, you will be referred to the appropriate MIB class where the attributes can be found.
When Attributes (Fields) Can Be Updated and Who Can Do It
One feature of the former tmconfig tables was a column that told when a field can be updated.That information is carried in the MIB reference pages, but in a form that requires a little more digging on your part. See the description of Permissions in MIB(5). The Permissions columns in MIB tables look like typical read, write and execute permissions that you may familiar with for files, but they carry more weight than that. For example, by using additional letters they can indicate whether or not the field can be changed when the system is active.
Study the description in MIB(5) before you attempt to use tmconfig.
RESOURCES Section
For attributes in this section, please see the T_DOMAIN class in the TM_MIB(5) reference page.
Notes
The ADD operation is not valid for this section. Since there is only one record in this section, the RETRIEVE operation is the same as the FIRST operation (no key field is required). The NEXT operation will always return record not found.
Changes to TA_LDBAL, TA_CMTRET, and TA_SYSTEM_ACCESS only affect new clients and servers that are subsequently booted. TA_SYSTEM_ACCESS cannot be changed if NO_OVERRIDE is specified and any server entries exist that don't match the specified access type (PROTECTED or FASTPATH). Changes to TA_NOTIFY and TA_AUTHSVC only affect new clients that are subsequently started.
Updates to parameters other than those listed above will not appear in your unloaded ASCII backup file.
MACHINES Section
For attributes in this section, please see the T_MACHINE class in the TM_MIB(5) reference page.
Notes
A machine cannot be added unless LAN appears in the OPTIONS in the RESOURCES section.
Updates to parameters other than those listed above will not appear in your unloaded ASCII backup file.
GROUPS Section
For attributes in this section, please see the T_GROUP class in the TM_MIB(5) reference page.
SERVERS Section
For attributes in this section, please see the T_SERVER class in the TM_MIB(5) reference page.
Notes
Parameter changes in the SERVERS section take effect the next time that an associated server is booted (and not restarted) If multiple servers are defined in an MSSQ set (using TA_RQADDR), they must have the same services booted (that is, changes to TA_CLOPT or ENVFILE must not affect the services that are booted such that they don't match currently booted servers). If TA_MAX is changed, automatic spawning of conversational servers for the new server identifiers will not happen until one or more servers in the server set are booted.
Services Section
For attributes in this section, please see the T_SERVICE class and the T_SVCGRP class in the TM_MIB(5) reference page.
Notes
Parameter changes in the SERVICES section take effect the next time a server offering the service is booted (and not restarted). Updates to TA_ROUTINGNAME are allowed only with a missing or NULL valued TA_SRVGRP field. In this case, all matching *SERVICES entries will have their TA_ROUTINGNAME updated simultaneously. The TA_ROUTINGNAME corresponds to the ROUTING field in the *SERVICES section.
Updates to parameters other than those listed above will not appear in your unloaded ASCII backup file.
NETWORK Section
The following table lists the fields in the NETWORK section.
|
NETWORK Section |
|||
|---|---|---|---|
|
Field Identifier |
Field Type |
Update |
Notes |
|
TA_LMID |
string |
No |
key |
|
TA_NADDR |
string |
Sys |
ASCII format (no embedded NULL characters) |
|
TA_BRIDGE |
string |
Sys |
|
|
TA_NLSADDR |
string |
Sys |
ASCII format (no embedded NULL characters) |
A record cannot be added while the associated LMID is booted.
No operations can be done on the NETWORKS section unless LAN appears in the OPTIONS in the RESOURCES section.
Updates to parameters other than those listed above will not appear in your unloaded ASCII backup file.
ROUTING Section
For attributes in this section, please see the T_ROUTING class in the TM_MIB(5) reference page.
Notes
The ROUTING section cannot be updated while the system is running. New ROUTING section entries may be added provided the Bulletin Board sizing parameters MAXDRT, MAXRFT and MAXRTDATA in the RESOURCES section were set to allow for growth.
WSL Section
For attributes in this section, please see the T_WSL class in the TM_MIB(5) reference page.
Notes
The T_WSL class should be used to update the CLOPT for WSL servers, even though this is available via the SERVER section.
NETGROUPS Section
For attributes in this section, please see the T_WSL Class in the TM_MIB(5) reference page.
NETMAP Section
For attributes in this section, please see the T_NETMAP Class in the TM_MIB(5) reference page.
Security
If tmconfig is run in a secure application, it requires an application password to access the application. If the standard input is a terminal, tmconfig prompts the user for the password with echo turned off on the reply. If the 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 tmconfig will fail.
Workstation Client
As a Workstation client, the command is named wtmconf on DOS and wtmconfig otherwise. The UPDATE and ADD commands are not supported (TAEPERM is returned).
Environment Variables
tmconfig resets the FIELDTBLS and FLDTBLDIR environment variables to pick up the ${TUXDIR}/udataobj/tpadmin field table. TUXDIR must be set correctly.
APP_PW must be set to the application password in a secure application if standard input is not from a terminal.
TUXCONFIG (for non-workstation clients) and WSADDR and possibly WSDEVICE and WSTYPE (for Workstation clients) must be set correctly such that the program can register as a client.
Diagnostics
tmconfig fails if it cannot allocate a typed buffer, if it cannot determine the /etc/passwd entry for the user, if it cannot become a client process, if it cannot create a temporary file in /tmp for the input buffer editing, or if it cannot reset the environment variables FIELDTBLS or FLDTBLDIR.
The return value printed by tmconfig 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 BEA Tuxedo communications error. They indicate that the operation did not complete successfully.
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 indicating 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).
The following return values indicate that the operation was successful, at least at the MASTER site.
Interoperability
The UPDATE and ADD operations are not allowed if a BEA Tuxedo 4.0 or 4.1 node is booted. These nodes must be shutdown before doing these operations. When re-booted, they will pick up the changes.
tmunloadcf Compatibility
When using tmunloadcf(1) to print entries in the configuration, certain field values are not printed if they are not set (for strings) or 0 (for integers), or if they match the default value for the field. These fields will always appear in the output buffer when using tmconfig. 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.
Example
In the following example, tmconfig is used to correct the network address specified on a Workstation Listener server. It happens to be the first entry in the servers section. For illustration purposes, ed(1) is used for the editor.
$ EDITOR=ed tmconfig
Section:1) RESOURCES, 2) MACHINES, 3) GROUPS 4) SERVERS 5)SERVICES
6) NETWORK 7) ROUTING q) QUIT 9) WSL 10) NETGROUPS 11) NETMAP [1]: 4
Operation: 1) FIRST 2) NEXT 3) RETRIEVE 4) ADD 5) UPDATE
6) CLEAR BUFFER 7) QUIT [1]: 1
Enter editor to add/modify fields [n]? <return>
Perform operation [y]? <return>
Return value TAOK
Buffer contents:
TA_OPERATION 4
TA_SECTION 3
TA_SRVID 2
TA_MIN 1
TA_MAX 1
TA_RQPERM 432
TA_RPPERM 432
TA_MAXGEN 1
TA_GRACE 86400
TA_STATUS Operation completed successfully
TA_SRVGRP WDBG
TA_SERVERNAME WSL
TA_CLOPT -A -- -d/dev/tcp -M4 -m2 -x5 -n0x0002fe19c00b6d6b
TA_CONV N
TA_REPLYQ N
TA_RESTART N
Section:1) RESOURCES, 2) MACHINES, 3) GROUPS 4) SERVERS 5)SERVICES
6) NETWORK 7) ROUTING q) QUIT 9) WSL [4]10) NETGROUPS 11) NETMAP [4]: <return>
Operation: 1) FIRST 2) NEXT 3) RETRIEVE 4) ADD 5) UPDATE
6) CLEAR BUFFER 7) QUIT [1]: 5
Enter editor to add/modify fields [n]? y
240
/CLOPT/s/6d6b/690E/p
TA_CLOPT -A -- -d/dev/tcp -M4 -m2 -x5 -n0x0002fe19c00b690E
w
240
q
Perform operation [y]? <return>
Return value TAUPDATED
Buffer contents:
TA_OPERATION 1
TA_SECTION 3
TA_SRVID 2
TA_MIN 1
TA_MAX 1
TA_RQPERM 432
TA_RPPERM 432
TA_MAXGEN 1
TA_GRACE 86400
TA_STATUS Update completed successfully
TA_SRVGRP WDBG
TA_SERVERNAME WSL
TA_CLOPT -A -- -d/dev/tcp -M4 -m2 -x5 -n0x0002fe19c00b690E
TA_CONV N
TA_REPLYQ N
TA_RESTART N
Section:1) RESOURCES, 2) MACHINES, 3) GROUPS 4) SERVERS 5)SERVICES
6) NETWORK 7) ROUTING q) QUIT 9) WSL [1] 10) NETGROUPS 11) NETMAP {1}: q
Unload TUXCONFIG file into ASCII backup [y]? <return>
Backup filename [UBBCONFIG]? <return>
Configuration backed up in UBBCONFIG
$ # boot the changed server
$ tmboot -s WSL -i 2
See Also
tmloadcf(1), tmboot(1), userlog(3c), ubbconfig(5), TM_MIB(5).
tmloadcf(1)
Name
tmloadcf-parse a UBBCONFIG file and load binary TUXCONFIG configuration file
Synopsis
tmloadcf [-n] [-y] [-c] [-b blocks] {ubbconfig_file | -}Description
tmloadcf reads a file or the standard input that is in UBBCONFIG syntax, checks the syntax, and optionally loads a binary TUXCONFIG configuration file. The TUXCONFIG and (optionally) TUXOFFSET environment variables point to the TUXCONFIG file and (optional) offset where the information should be stored. tmloadcf can only be run on the MASTER machine, as defined in the RESOURCES section of the UBBCONFIG file, unless the -c or -n option is specified.
tmloadcf prints a warning message if it finds any section of the UBBCONFIG file missing, other than a missing NETWORK section in a configuration where the LAN OPTION is not specified (see ubbconfig(5)) or a missing ROUTING section. If a syntax error is found while parsing the input file, tmloadcf exits without performing any updates to the TUXCONFIG file.
The effective user identifier of the person running tmloadcf must match the UID, if specified, in the RESOURCES section of the UBBCONFIG file.
The -c option to tmloadcf causes the program to print minimum IPC resources needed for this configuration. Resource requirements that vary on a per-processor basis are printed for each processor in the configuration. The TUXCONFIG file is not updated.
The -n option to tmloadcf causes the program to do only syntax checking of the ASCII UBBCONFIG file without actually updating the TUXCONFIG file.
After syntax checking, tmloadcf checks to see if the file pointed to by TUXCONFIG exists, is a valid WebLogic Enterprise or BEA Tuxedo system file system, and contains TUXCONFIG tables. If these conditions are not true, the user is prompted to decide if they want tmloadcf to create and initialize the file with Initialize TUXCONFIG file: path [y, q]?. 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 tmloadcf to exit without creating the configuration file.
If the TUXCONFIG file is not properly initialized, and the user has given the go-ahead, tmloadcf creates the BEA Tuxedo system file system and then creates the TUXCONFIG 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 BEA Tuxedo system file system. If the value of the -b option is large enough to hold the new TUXCONFIG tables, tmloadcf will use the specified value to create the new file system; otherwise, tmloadcf will print an error message and exit. If the -b option is not specified, tmloadcf will create a new file system large enough to hold the TUXCONFIG tables. The -b option is ignored if the file system already exists.
The -b option is highly recommended if TUXCONFIG 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 TUXCONFIG is a regular UNIX file.
If the TUXCONFIG file is determined to already have been initialized, tmloadcf ensures that the system described by that TUXCONFIG file is not running. If the system is running, tmloadcf prints an error message and exits.
If the system is not running and TUXCONFIG file already exists, tmloadcf will prompt the user to confirm that the file should be overwritten with
Really overwrite TUXCONFIG 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 tmloadcf to exit without overwriting the file.
If the SECURITY parameter is specified in the RESOURCES section of the configuration, then tmloadcf will flush the standard input, turn off terminal echo and prompt the user for an application password as follows:
Enter Application Password?
Reenter Application Password?
The password is limited to 30 characters. The option to load the ASCII UBBCONFIG file via the standard input (rather than a file) cannot be used when the 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 tmloadcf will print an error message, generate a log message and fail to load the TUXCONFIG file.
Assuming no errors, and if all checks have passed, tmloadcf loads the UBBCONFIG file into the TUXCONFIG file. It will overwrite all existing information found in the TUXCONFIG tables.
Note that some values are rounded during the load and may not match when they are unloaded. These include but are not limited to MAXRFT and MAXRTDATA.
When tmloadcf encounters a continuous string of five or more asterisks (*) in a UBBCONFIG file, it treats this as a placeholder for a password and prompts the user to create the password. The password is then stored in TUXCONFIG in encrypted form. This feature applies to the OPENINFO statement in the GROUPS section or a DBPASSWORD or PROPS statement in the JDBCCONNPOOLS section of the UBBCONFIG file. The tmunloadcf utility can be used to store the encrypted password in the UBBCONFIG file, using the double at sign (@@) as delimiters. See the BEA WebLogic Enterprise Administration Guide. for more information about encrypting passwords.
Interoperability
tmloadcf must run on the master node, which must be the latest release available in an interoperating application.
Environment Variables
The environment variable APP_PW must be set for applications that have the SECURITY parameter specified and must run tmloadcf with something other than a terminal as the standard input.
Examples
To load a configuration file from UBBCONFIG file BB.shm, initialized the device with 2000 blocks: tmloadcf -b2000 -y BB.shm.
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 UBBCONFIG file or the system is currently running, no information is updated in the TUXCONFIG file and tmloadcf exits with exit code 1.
If tmloadcf is run by a person whose effective user identifier does not match the UID specified in the UBBCONFIG file, the following error message is displayed:
*** UID is not effective user ID ***
If tmloadcf is run on a non-master node, the following error message is displayed:
tmloadcf cannot run on a non-master node.
If tmloadcf is run on an active node, the following error message is displayed:
tmloadcf cannot run on an active node.
Upon successful completion, tmloadcf exits with exit code 0. If the TUXCONFIG file is updated, a userlog message is generated to record this event.
See Also
tmunloadcf(1), ubbconfig(5), BEA WebLogic Enterprise Administration Guide.
tmshutdown(1)
Name
tmshutdown-shutdown a set of BEA Tuxedo servers
Synopsis
tmshutdown [options]
Description
tmshutdown stops the execution of a set of servers or removes the advertisements of a set of services listed in a configuration file. Only the administrator of the Bulletin Board (as indicated by the UID parameter in the configuration file) or root can invoke the tmshutdown command. tmshutdown can be invoked only on the machine identified as MASTER in the RESOURCES section of the configuration file, or the backup acting as the MASTER, that is, with the DBBL already running (via the master command in tmadmin(1)). An exception to this is the -P option which is used on partitioned processors (see below).
With no options, tmshutdown stops all administrative, TMS, and gateway servers, and servers listed in the SERVERS section of the configuration file named by the TUXCONFIG environment variable and removes their associated IPC resources. For each group, all servers in the SERVERS section, if any, are shut down followed by any associated gateway servers (for foreign groups) and TMS servers. Administrative servers are shut down last.
Application servers without SEQUENCE parameters are shut down first in reverse order of the server entries in the configuration file, followed by servers with SEQUENCE parameters that are shut down from high to low sequence number. If two or more servers in the SERVERS Section of the configuration file have the same SEQUENCE parameter, then tmshutdown may shut down these servers in parallel. Each entry in the SERVERS Section may have an optional MIN and MAX parameter. tmshutdown shuts down all occurrences of a server (up to MAX occurrences) for each server entry, unless the -i option is specified; using the -i option causes individual occurrences to be shut down.
If it is not possible to shut down a server, or remove a service advertisement, a diagnostic is written on the central event log (see userlog(3c)). The following is a description of all options:
-l lmid
For each group whose associated LMID parameter is lmid, all servers in the SERVERS section associated with the group are shut down, followed by any TMS and gateway servers associated with the group.
-g grpname
All servers in the SERVERS section associated with the specified group (that is, whose SRVGRP parameter is grpname) are shut down, followed by all TMS and gateway servers for the group. TMS servers are shut down based on the TMSNAME and TMSCOUNT parameters for the group entry. For a foreign group, the gateway servers for the associated entry in the HOST section are shut down based on GATENAME and GATECOUNT. Shutting down a gateway implies its administrative service and all advertised foreign services are unadvertised, in addition to stopping the process.
The -l, -g, -s, and -T options cause TMS servers to be shut down; the -l, -g, and -s options cause gateway servers to be shut down; the -l, -g, -i, -s, -o, and -S options apply to application servers; the -A, -M, and -B options apply only to administrative processes. When the -l, -g, -i, -o, and -s options are used in combination, only servers that satisfy all qualifications specified will be shut down.
If the distributed transaction processing feature is being used such that global transactions are in progress when servers are shut down, transactions that have not yet reached the point where commit is logged after precommit will be aborted; transactions that have reached the commit point will be completed when the servers (for example, TMS) are booted again.
Interoperability
tmshutdown must run on the master node, which in an interoperating application must be the highest release available.
Diagnostics
If tmshutdown fails to shut down a server or a fatal error occurs, it will exit with exit code 1 and the user log should be examined for further details; otherwise it will exit with exit code 0.
If tmshutdown is run on an active node that is not the acting master node, a fatal error message is displayed: tmshutdown cannot run on a non acting-master node in an active application.
If shutting down a process would partition active processes from the DBBL, a fatal error message is displayed: cannot shutdown, causes partitioning.
If a server has died, the following somewhat ambiguous message is produced: CMDTUX_CAT:947 Cannot shutdown server GRPID
Examples
To shut down the entire system and remove all BEA Tuxedo IPC resources (force it if confirmation not received in 30 seconds): tmshutdown -w 30. To shut down only those servers located on the machine with lmid of CS1. Since the -l option restricts the action to servers listed in the SERVERS section, the BBL on CS1 is not shut down: tmshutdown -l CS1
Notices
The tmshutdown command ignores the hangup signal (SIGHUP). If a signal is detected during shutdown, the process continues.
See Also
tmadmin(1), tmboot(1), ubbconfig(5), BEA WebLogic Enterprise Administration Guide.
tmunloadcf(1)
Name
tmunloadcf-unload binary TUXCONFIG configuration file
Synopsis
tmunloadcf
Description
tmunloadcf translates the TUXCONFIG 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 ubbconfig(5).
tmunloadcf reads values from the TUXCONFIG file pointed to by the TUXCONFIG and TUXOFFSET environment variables and writes them to its standard output.
Note that some values are rounded during configuration and may not match values set during tmloadcf or via the TMIB interface. These include but are not limited to MAXRFT and MAXRTDATA.
When a TUXCONFIG contains a password that was encrypted using tmloadcf, tmunloadcf stores that password in encrypted form in the UBBCONFIG file using the double at sign (@@) as delimiters. For example:
OPENINFO="Oracle_XA: Oracle_XA+Acc=P/Scott/@@A0986F7733D4@@+SesTm=30+LogDit=/tmp"
Portability
For BEA Tuxedo applications, tmunloadcf is supported only on non-workstation sites running BEA Tuxedo system Release 6.0 or later.
Examples
To unload the configuration in /usr/TUXEDO/tuxconfig into the file tconfig.backup run:
tmunloadcf > tconfig.backup
Diagnostics
tmunloadcf checks that the file pointed to by the TUXCONFIG environment variable exists, is a valid BEA Tuxedo system file system, and contains TUXCONFIG tables. If any of these conditions is not met, tmunloadcf prints an error message and exits with error code 1. Upon successful completion, tmunloadcf exits with exit code 0.
See Also
tmloadcf(1), ubbconfig(5), BEA WebLogic Enterprise Administration Guide.
tpacladd(1)
Name
tpacladd-add a new Access Control List on the system
TUXCONFIG=tuxconfig tpacladd [-g gid[,gid...]] [-t type] name
Description
Invoking tpacladd adds a new Access Control List entry to the BEA Tuxedo security data files. This information is used for BEA Tuxedo access control to services, events, and application queues. A BEA Tuxedo configuration with SECURITY set to USER_AUTH, ACL, or MANDATORY_ACL must be created before running this command successfully.
The following options are available:
Before running this command, the application must be configured using either the graphical user interface or tmloadcf(1). tpacladd must be run on the configuration MASTER if the application is not active; if active, this command can run on any active node.
Portability
This command is available only on non-workstation sites running BEA Tuxedo Release 6.0 or later.
Diagnostics
The tpacladd command exits with a return code of 0 upon successful completion.
See Also
tpacldel(1), tpaclmod(1), tpgrpadd(1), tpgrpdel(1), tpgrpmod(1), AUTHSVR(5), BEA WebLogic Enterprise Administration Guide.
tpaclcvt(1)
Name
tpaclcvt-convert BEA Tuxedo security data files
Synopsis
TUXCONFIG=tuxconfig tpaclcvt [-u userfile] [-g groupfile]
Description
tpaclcvt checks and converts the existing user file used by the BEA Tuxedo system 5 AUTHSVR into the format used for BEA Tuxedo system 6. It will also generate a group file based on /etc/group or a similar file. The following options are available:
Before running this command, the application must be configured using either the graphical user interface or tmloadcf(1). tpaclcvt must be run on the configuration MASTER when the application is not active.
Portability
This command is available only on non-workstation sites running BEA Tuxedo Release 6.0 or later.
See Also
tpgrpadd(1), tpusradd(1), AUTHSVR(5), BEA WebLogic Enterprise Administration Guide.
tpacldel(1)
Name
tpacldel-delete an Access Control List
Synopsis
TUXCONFIG=tuxconfig tpacldel [-t type] name
Description
Invoking tpacldel deletes an existing Access Control List entry from the BEA Tuxedo security data files. A BEA Tuxedo configuration with SECURITY set to USER_AUTH, ACL, or MANDATORY_ACL must be created before running this command successfully.
The following options are available:
Before running this command, the application must be configured using either the graphical user interface or tmloadcf(1). tpacldel must be run on the configuration MASTER if the application is not active; if active, this command can run on any active node.
Portability
This command is available only on non-workstation sites running BEA Tuxedo Release 6.0 or later.
Diagnostics
The tpacldel command exits with a return code of 0 upon successful completion.
See Also
tpacladd(1), tpaclmod(1), AUTHSVR(5), BEA WebLogic Enterprise Administration Guide.
tpaclmod(1)
Name
tpaclmod-modify an Access Control List on the system
Synopsis
TUXCONFIG=tuxconfig tpaclmod [-g gid[,gid...]] [-t type] name
Description
Invoking tpaclmod modifies an Access Control List entry in the BEA Tuxedo security data files, replacing the group identifier list. This information is used for BEA Tuxedo access control to services, events, and application queues. A BEA Tuxedo configuration with SECURITY set to USER_AUTH, ACL, or MANDATORY_ACL must be created before running this command successfully.
The following options are available:
Before running this command, the application must be configured using either the graphical user interface or tmloadcf(1). tpaclmod must be run on the configuration MASTER if the application is not active; if active, this command can run on any active node.
Portability
This command is available only on non-workstation sites running BEA Tuxedo Release 6.0 or later.
Diagnostics
The tpaclmod command exits with a return code of 0 upon successful completion.
See Also
tpacladd(1), tpacldel(1), AUTHSVR(5), BEA WebLogic Enterprise Administration Guide.
tpadduser
Name
tpaddusr-create a BEA Tuxedo password file
Synopsis
tpaddusr usrname file [cltname [uid]]
Description
This command allows an application administrator to create a UNIX system style password file suitable for use with the BEA Tuxedo AUTHSVR(5) server. tpaddusr adds the user usrname to the password file file (the file cannot be /etc/passwd). The administrator is prompted for an initial password to be associated with the user. file will be created if necessary with permissions 0600. cltname, if specified, indicates a further qualifier on the password entry. usrname and/or cltname may be specified as the character '*' which is considered a wildcard by AUTHSVR(5). uid, if specified, indicates the numeric user identifier to be returned with a successful authentication of the user. cltname and uid default to '*' and -1 respectively if not specified.
Notices
The cltname values tpsysadm and tpsysop are treated specially by AUTHSVR(5) when processing authentication requests. These cltname values will not be matched against wildcard cltname specifications in the password file.
Additionally, regardless of the order of addition to the password file, wildcard entries are considered after explicitly specified values. An authentication request is authenticated against only the first matching password file entry.
Portability
This command is available only on UNIX system sites running BEA Tuxedo Release 5.0 or later.
Compatibility
This command is used to configure users for SECURITY USER_AUTH. For compatibility with SECURITY ACL or MANDATORY_ACL (including the ability to migrate to these security levels), the following restrictions should be applied.
These restrictions are enforced by the tpusradd(1) command.
Examples
The following sequence of command invocations shows the construction of a simple password file.
$ # 1. Add usrname foo with wildcard cltname and no uid
$ tpaddusr foo /home/tuxapp/pwfile
$ # 2. Add usrname foo with cltname bar and uid 100
$ tpaddusr foo /home/tuxapp/pwfile bar 100
$ # 3. Add usrname foo with tpsysadm cltname and no uid
$ tpaddusr foo /home/tuxapp/pwfile tpsysadm
$ # 4. Add wildcard usrname with tpsysop cltname and no uid
$ tpaddusr '*' /home/tuxapp/pwfile tpsysop
$ # 5. Add wildcard usrname with wildcard cltname and no uid
$ tpaddusr '*' /home/tuxapp/pwfile '*'
The following table shows the password file entry (indicated by numbers shown above) used to authenticate various requests for access to the application. N/A indicates that the request is disallowed because no password file entry exists to be matched against.
Usrname Cltname Password Entry
------ ------- --------------
"foo" "bar" 2
"foo" "" 1
"foo" "tpsysadm" 3
"foo" "tpsysop" 4
"guest" "tpsysop" 4
"guest" "bar" 5
"guest" "tpsysadm" N/A
Lastly, following is an example SERVERS section entry for an instance of AUTHSVR that works with the password file generated above.
AUTHSVR SRVGRP=G SRVID=1 RESTART=Y GRACE=0 MAXGEN=2 CLOPT="-A -- -f /home/tuxapp/pwfile"
See Also
tpdelusr(1), tpmodusr(1), tpusradd(1), tpusrdel(1), tpusrmod(1), AUTHSVR(5)
tpdelusr(1)
Name
tpdelusr-Delete a user from a BEA Tuxedo password file
Synopsis
tpdelusr usrname file [cltname]
Description
This command allows an application administrator to maintain a UNIX system style password file suitable for use with the BEA Tuxedo AUTHSVR(5) server. depletes is used to delete the password file entry for the indicated surname/cattlemen combination (the file cannot be /etc./passed). cattlemen defaults to '*' if not specified. Wildcards specified for usrname and/or cltname match only the corresponding wildcard entry in the password file, they are not expanded to all matching entries.
Notices
The cltname values tpsysadm and tpsysop are treated specially by AUTHSVR(5) when processing authentication requests. These cltname values will not be matched against wildcard cltname specifications in the password file.
Additionally, regardless of the order of addition to the password file, wildcard entries are considered after explicitly specified values. An authentication request is authenticated against only the first matching password file entry.
Portability
This command is available only on UNIX system sites running BEA Tuxedo Release 5.0 or later.
Compatibility
This command is used to configure users for SECURITY USER_AUTH. For compatibility with SECURITY ACL or MANDATORY_ACL (including the ability to migrate to these security levels), the following restrictions should be applied.
These restrictions are enforced by the tpusrdel(1) command.
See Also
tpaddusr(1), tpmodusr(1), tpusradd(1), tpusrdel(1), tpusrmod(1), AUTHSVR(5), BEA WebLogic Enterprise Administration Guide.
tpgrpadd(1)
name
tpgrpadd-add a new group on the system
Synopsis
TUXCONFIG=tuxconfig tpgrpadd [-g gid] grpname
Description
The tpgrpadd command creates a new group definition on the system by adding the appropriate entry to the BEA Tuxedo security data files. This information is used for BEA Tuxedo system authentication with the AUTHSVR(5) server and for access control. A BEA Tuxedo configuration with SECURITY set to USER_AUTH, ACL, or MANDATORY_ACL must be created before running this command successfully.
The following options are available:
Before running this command, the application must be configured using either the graphical user interface or tmloadcf(1). tpgrpadd must be run on the configuration MASTER if the application is not active; if active, this command can run on any active node.
Portability
This command is available only on non-workstation sites running BEA Tuxedo system Release 6.0 or later.
Diagnostics
The tpgrpadd command exits with a return code of 0 upon successful completion.
See Also
tpgrpdel(1), tpgrpmod(1), tpusradd(1), tpusrdel(1), tpusrmod(1), AUTHSVR(5), BEA WebLogic Enterprise Administration Guide.
tpgrpdel(1)
Name
tpgrpdel-delete a group from the system
Synopsis
TUXCONFIG=tuxconfig tpgrpdel grpname
Description
The tpgrpdel command removes a group definition from the system by deleting the entry for the relevant group from the BEA Tuxedo security data files. It does not, however, remove the group ID from the user file. A BEA Tuxedo configuration with SECURITY set to USER_AUTH, ACL, or MANDATORY_ACL must be created before running this command successfully.
The following options are available:
Before running this command, the application must be configured using either the graphical user interface or tmloadcf(1). tpgrpdel must be run on the configuration MASTER if the application is not active; if active, this command can run on any active node.
Portability
This command is available only on non-workstation sites running BEA Tuxedo system Release 6.0 or later.
Diagnostics
The tpgrpdel command exits with a return code of 0 upon successful completion.
See Also
tpgrpadd(1), tpgrpmod(1), tpusradd(1), tpusrdel(1), tpusrmod(1), AUTHSVR(5), BEA WebLogic Enterprise Administration Guide.
tpgrpmod(1)
Name
tpgrpmod-modify a group on the system
Synopsis
TUXCONFIG=tuxconfig tpgrpmod [-g gid] [-n name] grpname
Description
The tpgrpmod modifies the definition of the specified group by modifying the appropriate entry to the BEA Tuxedo security data files. A BEA Tuxedo configuration with SECURITY set to USER_AUTH, ACL, or MANDATORY_ACL must be created before running this command successfully.
The following options are available:
Before running this command, the application must be configured using either the graphical user interface or tmloadcf(1). tpgrpmod must be run on the configuration MASTER if the application is not active; if active, this command can run on any active node.
Portability
This command is available only on non-workstation sites running BEA Tuxedo system Release 6.0 or later.
Diagnostics
The tpgrpmod command exits with a return code of 0 upon successful completion.
See Also
tpgrpadd(1), tpgrpdel(1), tpusradd(1), tpusrdel(1), tpusrmod(1), AUTHSVR(5), BEA WebLogic Enterprise Administration Guide.
tpmodusr(1)
Name
tpmodusr-maintain a BEA Tuxedo system password file
Synopsis
tpmodusr usrname file [cltname]
Description
This command allows an application administrator to maintain a UNIX system style password file suitable for use with the BEA Tuxedo system AUTHSVR(5) server. A BEA Tuxedo configuration with SECURITY set to USER_AUTH, ACL, or MANDATORY_ACL must be created before running this command successfully.
tpmodusr is used to modify the password for the indicated user in the password file file (the file cannot be /etc/passwd). The administrator is prompted for a new password to be associated with the user. cltname defaults to '*' if not specified. Wildcards specified for usrname and/or cltname match only the corresponding wildcard entry in the password file, they are not expanded to all matching entries.
Notices
The cltname values tpsysadm and tpsysop are treated specially by AUTHSVR(5) when processing authentication requests. These cltname values will not be matched against wildcard cltname specifications in the password file.
Additionally, regardless of the order of addition to the password file, wildcard entries are considered after explicitly specified values. An authentication request is authenticated against only the first matching password file entry.
Portability
This command is available only on UNIX system sites running BEA Tuxedo system Release 5.0 or later.
Compatibility
This command is used to configure users for SECURITY USER_AUTH. For compatibility with SECURITY ACL or MANDATORY_ACL (including the ability to migrate to these security levels), the following restrictions should be applied.
These restrictions are enforced by the tpusrmod(1) command.
See Also
tpaddusr(1), tpdelusr(1), tpusradd(1), tpusrdel(1), tpusrmod(1), AUTHSVR(5), BEA WebLogic Enterprise Administration Guide.
tpusradd(1)
Name
tpusradd-add a new principal on the system
Synopsis
TUXCONFIG=tuxconfig tpusradd [-u uid ] [-g gid] [-c client_name] usrname
Description
Invoking tpusradd adds a new principal (user or domain) entry to the BEA Tuxedo security data files. This information is used for per-user authentication with the AUTHSVR(5) server. A BEA Tuxedo system configuration with SECURITY set to USER_AUTH, ACL, or MANDATORY_ACL must be created before running this command successfully.
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:
The administrator is prompted for an initial password to be associated with the user.
Before running this command, the application must be configured using either the graphical user interface or tmloadcf(1). tpusradd must be run on the configuration MASTER if the application is not active; if active, this command can run on any active node.
See AUTHSVR(5) for further information about per-user authentication and configuring administrator permissions.
Portability
This command is available only on non-workstation sites running BEA Tuxedo system Release 6.0 or later.
Diagnostics
The tpusradd command exits with a return code of 0 upon successful completion.
Examples
The following sequence of command invocations shows the construction of a simple user file.
$ # 1. Add usrname foo with wildcard cltname and no uid
$ tpusradd -c '*' foo
$ # 2. Add usrname foo with cltname bar and uid 100
$ tpusradd -u 100 -c bar foo
$ # 3. Add usrname foo with tpsysadm cltname and no uid
$ tpusradd -c tpsysadm foo
The following table shows the user entry (indicated by numbers shown above) used to authenticate various requests for access to the application and the associated Uid/Gid. N/A indicates that the request is disallowed because no user file entry exists to be matched against.
Usrname Cltname Password Entry Uid Gid
------- ------- -------------- --- ---
"foo" "bar" 2 100 0
"foo" "" 1 1 0
"foo" "tpsysadm" 3 0 8192
"guest" "tpsysadm" N/A N/A N/A
Lastly, following is an example SERVERS section entry for an instance of AUTHSVR that works with the user file generated above.
AUTHSVR SRVGRP=G SRVID=1 RESTART=Y GRACE=0 MAXGEN=2 CLOPT="-A"
See Also
tpgrpadd(1), tpgrpdel(1), tpgrpmod(1), tpusrdel(1), tpusrmod(1), AUTHSVR(5), BEA WebLogic Enterprise Administration Guide.
tpusrdel(1)
Name
tpusrdel-delete a user from the system
Synopsis
TUXCONFIG=tuxconfig tpusrdel usrname
Description
The tpusrdel command deletes a principal (user or domain name) definition from the system. It removes the definition of the specified user. A BEA Tuxedo configuration with SECURITY set to USER_AUTH, ACL, or MANDATORY_ACL must be created before running this command successfully.
usrname specifies an existing username to be deleted.
Before running this command, the application must be configured using either the graphical user interface or tmloadcf(1). tpusradd must be run on the configuration MASTER if the application is not active; if active, this command can run on any active node.
Portability
This command is available only on non-workstation sites running BEA Tuxedo system Release 6.0 or later.
Diagnostics
The tpusrdel command exits with a return code of 0 upon successful completion.
See Also
tpgrpadd(1), tpgrpdel(1), tpgrpmod(1), tpusradd(1), tpusrmod(1).
tpusrmod(1)
Name
tpusrmod-modify user information on the system
Synopsis
TUXCONFIG=tuxconfig tpusrmod [-u uid ] [-g gid] [-c client_name]
[-l new_login] [-p] usrname
Description
Invoking tpusrmod modifies a principal (user or domain) entry to the BEA Tuxedo security data files. This information is used for BEA Tuxedo system authentication with the AUTHSVR(5) server. A BEA Tuxedo system configuration with SECURITY set to USER_AUTH, ACL, or MANDATORY_ACL must be created before running this command successfully.
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:
Before running this command, the application must be configured using either the graphical user interface or tmloadcf(1). tpusradd must be run on the configuration MASTER if the application is not active; if active, this command can run on any active node.
See AUTHSVR(5) for further information about per-user authentication and configuring administrator permissions.
Portability
This command is available only on non-workstation sites running BEA Tuxedo system Release 6.0 or later.
Diagnostics
The tpusrmod command exits with a return code of 0 upon successful completion.
See Also
tpgrpadd(1), tpgrpdel(1), tpgrpmod(1), tpusradd(1), tpusrdel(1), AUTHSVR(5), BEA WebLogic Enterprise Administration Guide.
tuxadm(1)
Name
tuxadm-BEA Tuxedo Web GUI CGI gateway
Synopsis
http://cgi-bin/tuxadm[TUXDIR=TUXEDO_directory | INIFILE=initialization_file][other_parameters]
Description
tuxadm is a common gateway interface (CGI) process used to initialize the Web GUI from a browser. As shown in the synopsis above, this program is usable only as a location, or URL from a Web browser; it would not normally be executed from a standard command-line prompt. It uses the QUERY_STRING environment variable to parse its argument list, as is normal for CGI programs.
tuxadm parses its arguments and finds a Web GUI initialization file. If the TUXDIR parameter is present, the initialization file is taken to be $TUXDIR/udataobj/webgui/webgui.ini by default. If the INIFILE option is present, then the value of that parameter is taken to be the full path to the initialization file. Other parameters may also be present. Any additional parameters can be used to override values in the initialization file. See the wlisten reference page for a complete list of initialization file parameters. (Note that the ENCRYPTBITS parameter may not be overridden by the tuxadm process unless the override is consistent with the values allowed in the actual initialization file.)
The normal action of tuxadm is to generate, to its standard output, HTML commands that build a Web page that launches the Web GUI applet. The general format of the Web page is controlled by the TEMPLATE parameter of the initialization file, which contains arbitrary HTML commands, with the special string %APPLET% on a line by itself in the place where the Web GUI applet should appear. By using other parameters from the initialization file (such as CODEBASE, WIDTH, HEIGHT, and so on) a correct APPLET tag is generated that contains all the parameters necessary to create an instance of the Web GUI.
Errors
tuxadm generates HTML code that contains an error message if a failure occurs. Because of the way CGI programs operate, there is no reason to return an error code of any kind from tuxadm.
See Also
wlisten(1), tuxwsvr(1)
TuxShell(1)
Name
TuxShell-shell interface to BEA Tuxedo system utilities for Macintosh
Synopsis
TuxShell
Description
This Macintosh executable runs BEA Tuxedo system utilities. The user, using a word processor, creates a script of the utilities to be run, making sure to save the script in text-only format. The user then runs this script using the RUN command under the FILE menu. The user can also specify certain environment variables with the ENVIRONMENT command, located under the FILE menu. Under the UTILITIES menu can be found wud(1) and wud32(1). The only other option under the FILE menu is QUIT, which quits the TuxShell.
TuxShell runs a user defined script. The script accepts the BEA Tuxedo system commands gencat(1), mklanginfo(1), mkfldhdr(1), mkfldhdr32(1), bkenq(1), viewc(1), viewc32(1), viewdis(1) and viewdis32(1). Environment variables can be set and unset with the Set and Unset commands. Set and Unset have the following format:
Set Name Value
Unset Name
Command-line options for any of the utilities may be specified in the script. However, no utility can read from stdin, so any attempt to do so will log an error.
If either the viewc(1) or viewc32(1) utility is to be run with the MPW compiler or the Metrowerks compiler, then the ToolServer program (available from Apple) must be running, with the TUXDIR and Commands environment variables set properly. If the THINK C compiler is to be used then the VIEWC_DNR.prj project must be located in the {TUXDIR}:lib directory. If the Metrowerks compiler is being used, then:
Portability
TuxShell was designed to run on Macintosh systems.
Environment Variables
If the viewc(1) or viewc32(1) is to be run, then the CC variable must be set to THINK_C if the THINK C compiler is to be used. If these utilities are to be used with the MPW compiler, then the CC variable must be set to applec. If viewc(1) or viewc32(1) is to be run with the Metrowerks compiler, then the CC variable must be set to mwerks and the MWERKS_MPW variable must be set to the directory containing the MPW tools that come with the Metrowerks compiler.
Diagnostics
The {TUXDIR}:bin directory will contain stdout and stderr files resulting from the run of the script. Other messages may be logged in the ULOG file.
Note that view files compiled for THINK C are not compatible with view files compiled for the Metrowerks compiler.
See Also
gencat(1), mkfldhdr(1), mkfldhdr32(1), mklanginfo(1), viewc(1), viewc32(1), viewdis(1), viewdis32(1), bkenq(1), wud(1), wud32(1)
tuxwsvr(1)
Name
tuxwsvr-Mini Web server for use with BEA Tuxedo Web GUI
Synopsis
tuxwsvr -l nlsaddr [ -d device ] [-L logfile] [-F]
-i initialization_file
Description
tuxwsvr is a World Wide Web server process that can be used to support the BEA Tuxedo Web GUI by customers who do not have a commercial Web server or a public-domain Web server on the machine where the BEA Tuxedo Web GUI processes are running. tuxwsvr places itself in the background when invoked unless otherwise specified, and continues running until the machine shuts down or the tuxwsvr process is killed using an operating system command.
tuxwsvr contains all functionality necessary to support the BEA Tuxedo Web GUI, but does not include many features present in commercial Web servers, such as preforked processes, server-side HTML includes (.shtml files), default directory indexes, and https connections. (Note, however, that the BEA Tuxedo Web GUI can be run in secure mode without an https connection since it implements its own encryption protocol.) For performance reasons, the generic Web server does not perform reverse DNS lookups for received requests.
The following command-line options are used by tuxwsvr:
"//#.#.#.#:port_number"
Initialization File Format
An initialization file contains mappings to directories needed by the Web server and, possibly, some comment lines. (The latter are marked by # signs at the beginning of the line.) Each non-comment line consists of three fields separated by white space.
|
Field |
Contents |
|---|---|
|
1 |
Either "HTML" or "CGI," indicating the type of files (HTML files or executable CGI programs) residing in the directory described in this line. |
|
2 |
A path prefix. (If a particular request matches more than one prefix, the first matching prefix mapping in the file is chosen.) |
|
3 |
The directory or file to which the path prefix (in Field 2) is mapped. |
The last non-comment line in the initialization file must have a prefix of '/'. If any line prior to the last non-comment line in the initialization file has a prefix of '/', a warning message is generated.
A Note about Changing the Initialization File
The initialization file is read once at startup time. Thus, if you make any changes to this file, you must stop and restart tuxwsvr before your changes will take effect.
Example of a UNIX system Initialization File
The following is an example of an initialization file for a UNIX system.
CGI /cgi-bin /home/TUXEDO/udataobj/webgui/cgi-bin
CGI /webgui /home/TUXEDO/udataobj/webgui/cgi-bin
HTML /java /home/TUXEDO/udataobj/webgui/java
HTML /doc /home/TUXEDO/doc
HTML / /home/TUXEDO/udataobj/webgui
Suppose the Web server is running on port 8080 on the following machine:
tuxmach.acme.com
Enter a request to either of the following URLs:
http://tuxmach.acme.com:8080/cgi-bin/tuxadm?TUXDIR=/home/TUXEDOhttp://tuxmach.acme.com:8080/webgui/tuxadm?TUXDIR=/home/TUXEDO
Your request will have two effects:
(a) It will invoke the program
/home/TUXEDO/udataobj/webgui/tuxadm
(b) It will set the environment variable QUERY_STRING
to TUXDIR=/home/TUXEDO in the program,
as stated in the World Wide Web CGI specification.
Note that it is not a good idea to specify $TUXDIR/bin as a value for an initialization file CGI directory since doing so makes it possible for Web users to invoke any BEA Tuxedo executable. (Such users would not, however, be able to see the output from executables other than tuxadm since these other executables are not written as CGI programs.)
Also, note that in the example above the first HTML line is redundant since the second HTML line would map subdirectories of /java to the same filepath. Nevertheless, we have included this line since some users might wish to place their Java class files in a location other than the one in which they have stored their HTML documents.
Example of a Windows NT Initialization File
The following is an example of an initialization file for a Windows NT system.
HTML /TUXEDO/webgui D:\TUXEDO\htmldocs
CGI /cgi-bin C:\cgi-bin
HTML /java D:\TUXEDO\udataobj\webgui\java
HTML / D:\TUXEDO\udataobj\webgui
Suppose the Web server is running on port 80 on machine ntsvr1. Enter the following URL:
http://ntsvr1/TUXEDO/webgui/page1.html
The following file will be retrieved:
D:\TUXEDO\htmldocs\page1.html
Presumably this file is a customer-created page that will invoke the Web GUI.
Termination
There is only one way to achieve a normal termination of a tuxwsvr process: by sending it a SIGTERM signal.
Recommended Use
In the current release of BEA Tuxedo System/T, the tuxwsvr process is provided as a Web server for the BEA Tuxedo administrative GUI for those customers who do not have a commercial Web server. On UNIX systems, we recommend adding a command line of the following format to UNIX initialization scripts so that the Web server will be started automatically:
TUXDIR=tuxdir_pathname $TUXDIR/bin/tuxwsvr \ -l nlsaddr -i initialization_file
tuxdir_pathname represents the full pathname of the location of the System/T software for that application. nlsaddr is the network-dependent address to be used by this tuxwsvr process.
One alternative method for starting the tuxwsvr process is to start it manually using the command line recommended above. A second alternative is to use cron jobs to start the tuxwsvr process periodically (daily, or perhaps even more often). Duplicate tuxwsvr command invocations using the same network address will terminate automatically and gracefully log an appropriate message.
Network Addresses
The only restriction on the network address specified for the tuxwsvr process by the application administrator is that it be a unique address on the specified network. For a STARLAN network, a recommended address of uname.tuxwsvr will usually yield a unique name. For TCP/IP, the address is formed from a unique port selected by the application administrator paired with the node identifier for the local machine, that is, 0x0002ppppnnnnnnnn. Unique port values for a particular machine (pppp) need to be negotiated among users of that network/machine combination; higher port numbers tend to be better since lower numbers are frequently used for system related services. The appropriate value for the node field (nnnnnnnn) can be found in the /etc/hosts file by using the following steps:
Step 1: Enter uname -n
Returns node_name
Step 2: Enter grep node_name /etc/hosts
Returns 182.11.108.107 node_name
You must convert the dot notation into eight hexadecimal digits.
Examples of Network Addresses
Suppose the local machine on which the tuxwsvr is being run is using TCP/IP addressing. The machine is named backus.company.com and its address is 155.2.193.18. Further suppose that the port number at which the tuxwsvr should accept requests is 2334. Assume that port number 2334 has been added to the network services database under the name bankapp-tuxwsvr. The address specified by the -l option could be represented in any of several ways:
//155.2.193.18:bankapp-tuxwsvr//155.2.193.18:2334//backus.company.com:bankapp-tuxwsvr//backus.company.com:23340x0002091E9B02C112
The last line shows how to represent the address in hexadecimal format: 0002 is the first part of a TCP/IP address, 091E is a hexadecimal translation of the port number 2334, and 9B02C112 is the hexadecimal translation of the IP address, 155.2.193.18. (In the latter translation, 155 becomes 9B, 2 becomes 02, and so on.)
For a STARLAN network, a recommended address of uname.tuxwsvr will usually yield a unique name.
See Also
tuxadm(1), wlisten(1)
txrpt(1)
Name
txrpt-BEA Tuxedo system server/service report program
Synopsis
txrpt [-t] [-n names] [-d mm/dd] [-s time] [-e time]
Description
txrpt analyzes the standard error output of a BEA Tuxedo system server to provide a summary of service processing time within the server. The report shows the number of times dispatched and average elapsed time in seconds of each service in the period covered. txrpt takes its input from the standard input or from a standard error file redirected as input. Standard error files are created by servers invoked with the -r option from the servopts(5) selection; the file can be named by specifying it with the -e servopts option. Multiple files can be concatenated into a single input stream for txrpt. Options to txrpt have the following meaning:
The report produced by txrpt covers only a single day. If the input file contains records from more than one day, the -d option controls the day reported on.
Notices
Make sure that the ULOGDEBUG variable is not set to y when a server is collecting statistics for analysis via txrpt. Debugging messages in the file will be misinterpreted by txrpt.
Examples
For the following command line:
txrpt -nSVC1 -d10/15 -s11:01 -e14:18 newr
The report produced looks like this:
START AFTER: Thu Oct 15 11:01:00 1992
END BEFORE: Thu Oct 15 14:18:00 1992
SERVICE SUMMARY REPORT
SVCNAME 11a-12n 13p-14p 14p-15p TOTALS
Num/Avg Num/Avg Num/Avg Num/Avg
------ -------- -------- -------- -------
SVC1 2/0.25 3/0.25 1/0.96 6/0.37
------- ------- ------- ------- -------
TOTALS 2/0.25 3/0.25 1/0.96 6/0.37
The above example shows that SVC1 was requested a total of six times within the specified period and that it took an average of 0.37 seconds to process the request.
See Also
servopts(5)
ud(1)
Name
ud, wu-BEA Tuxedo driver program
Synopsis
ud [-p] [-ddelay] [-eerror_limit] [-r] [-ssleeptime] [-ttimeout]
[-n] [-u {n | u | j}] [-Uusrname] [-Ccltname] [-Sbuffersize]
ud32 [options]
wud [options]
wud32 [options]
Description
ud reads an input packet from its standard input using Fextread(3fml). The packet must contain a field identified as the name of a service. The input packet is transferred to an FML fielded buffer (FBFR) and sent to the service. If the service that receives the FBFR is one that adds records to a database, ud provides a method for entering bulk fielded data into a database known to the BEA Tuxedo system.
By using flags (see INPUT FORMAT) to begin the lines of the input packet, you can use ud to test BEA Tuxedo services.
By default, after sending the FBFR to the service, ud expects a return FBFR. The sent and reply FBFRs are printed to ud's standard output; error messages are printed to standard error.
ud32 uses FML32 buffers of type FBFR32.
wud and wud32 are versions of ud and ud32 built using the workstation libraries. On sites supporting just workstation, only the wud and wud32 commands will be present.
Options
ud supports the following options:
The -d delay and -r options are mutually exclusive.
Input Format
Input packets consist of lines formatted as follows:
[flag]fldname fldval
flag is optional. If flag is not specified, a new occurrence of the field named by fldname with value fldval is added to the fielded buffer. If flag is specified, it should be one of:
If fldname is the literal value SRVCNM, fldval is the name of the service to which FBFR is to be passed.
Lengthy field values can be continued on the next line by having the continuation line begin with a tab.
A line consisting only of the newline character ends the input and sends the packet to ud.
If an input packet begins with a line consisting of the character n followed by the newline character, the FBFR is reinitialized. FBFR reinitialization can be specified for all packets with the -un option on the command line.
To enter an unprintable character in the input packet, use the escaping convention followed by the hexadecimal representation of the desired character (see ASCII(5) in a UNIX reference manual). An additional backslash is needed to protect the escape from the shell. A space, for example, can be entered in the input data as 20. ud recognizes all input in this format, but its greatest usefulness is for non-printing characters.
Processing Model
Initially, ud reads a fielded buffer from its standard input and sends it to the service whose name is given by the fldval of the line where fldname equals SRVCNM. Unless the -r option is selected, ud waits for a reply fielded buffer. After obtaining the reply, ud reads another fielded buffer from the standard input. In so doing, ud retains the returned buffer as the current buffer. This means that the lines on the standard input that form the second fielded buffer are taken to be additions to the buffer just returned. That is, the default action is for ud to maintain a current buffer whose contents are added to by a set of input lines. The set is delimited by a blank line. ud may be instructed to discard the current buffer (that is, to reinitialize its FBFR structure) either by specifying the -un option on the command line, or by including a line whose only character is the letter n as the first line of an input set. ud may be instructed to merge the contents of the reply buffer into the request buffer by specifying either the -uu option (Fupdate is used) or the -uj option (Fojoin is used).
Security
If ud is run in a security application, it requires an application password to access the application. If standard input is a terminal, ud prompts the user for the password with echo turned off on the reply. However, since ud accepts bulk input on standard input, standard input will typically be a file and not a terminal. In this case, the password is retrieved from the environment variable, APP_PW. If this environment variable is not specified and an application password is required, then ud will fail.
Portability
These commands are supported as BEA Tuxedo-supplied clients on UNIX and MS-DOS operating systems.
Environment Variables
FLDTBLDIR and FIELDTBLS must be set and exported. FLDTBLDIR must include $TUXDIR/udataobj in the list of directories. FIELDTBLS must include Usysflds as one of the field tables.
APP_PW must be set to the application password in a security application if standard input is not from a terminal. TPIDATA must be set to the application specific data necessary to join the application in a security application with an authentication server if standard input is not from a terminal.
WSNADDR, WSDEVICE and optionally WSTYPE must be set if access is from a workstation. See compilation(5) for more details on setting environment variables for client processes.
Diagnostics
ud fails if it cannot become a client process, if it cannot create the needed FBFRs, or if it encounters a UNIX system error. It also fails if it encounters more than 25 errors in processing a stream of input packets. These can be syntax errors, missing service names, errors in starting or committing a transaction, timeouts and errors in sending the input FBFR or in receiving the reply FBFR.
Notices
The final fielded buffer in the input stream should be terminated by a blank line.
Examples
$ud <EOF>
SRVCNM BUY
CLIENT J. Jones
ADDR 21 Valley Road
STOCK AAA
SHARES 100
<CR>
+SRVCNM SELL
+STOCK XXX
+SHARES 300
STOCK YYY
SHARES 150
<CR>
n
SRVCNM BUY
CLIENT T. Smith
ADDR 1 Main Street
STOCK BBB
SHARES 175
<CR>
+SRVCNM SELL
+STOCK ZZZ
+SHARES 100
<CR>
EOF
$
In this example, ud first sends a fielded buffer to the service BUY with CLIENT field set to J. Jones, ADDR field set to 21 Valley Road, STOCK field to AAA, and SHARES field set to 100.
When the fielded buffer is returned from the BUY service, ud uses the next set of lines to change SRVCNM to SELL, STOCK to XXX, and SHARES to 300. Also, it creates an additional occurrence of the STOCK field with value YYY and an additional occurrence of the SHARES field with value 150. This fielded buffer is then sent to the SELL service (the new value of the SRVCNM field).
When SELL sends back a reply fielded buffer, ud discards it by beginning the next set of lines with a line containing only the character n. ud then begins building an entirely new input packet with a SRVCNM of BUY, CLIENT of value T. Smith, and so on.
See Also
Fextread(3fml), compilation(5), ascii(5) in a UNIX system reference manual, BEA Tuxedo Programmer's Guide, BEA Tuxedo FML Programmer's Guide, BEA WebLogic Enterprise Administration Guide.
udfk_test(1)
Name
udfk_test-verify user-defined function key file
Synopsis
udfk_test [-v] file
Description
Reports on errors in the file containing user-defined function keys. The file is normally passed to mio(1) with the -u option. mio can also detect an incorrectly formatted file, but its diagnostics are limited, compared to those of udfk_test. When run with the -v option, udfk_test prints the character sequence associated with each mio command, based on the contents of file.
See Also
mio(1), udfk(5)
uuidgen(1)
Name
uuidgen-generate a Universal Unique Identifier (UUID)
Synopsis
uuidgen [-o filename] [{-i | -n number}] [-v] [-h] [-?]Description
uuidgen, by default, generates a Universal Unique Identifier (UUID) on the standard output.The UUID is used to uniquely identifier an IDL interface definition. The format for a UUID string consists of eight hexadecimal digits followed by a dash, followed by three groups of four hexadecimal digits separated by dashes, followed by a dash and twelve hexadecimal digits (see the Examples below).
The following uuidgen(1) options are supported:
Network Address
The generation of the UUID requires the availability of a 48-bit IEEE 802 address. Since this is not available in all environments and the method of determination is not portable, several methods are available for use with the BEA Tuxedo system version of uuidgen.
num.num.num.num
then it is taken to be a Internet-style address and converted.
0xnnnnnnnnnnnnnnnn
then it is taken to be a hexadecimal network address, as used in workstation.
Note that in each of these cases, a 32-bit address is formed and the remainder of the address (for 48-bits) is treated as 00.00.
Diagnostics
uuidgen will exit with a non-zero exit code if an invalid command-line option is specified, or if it cannot open the output file. A warning is printed if an invalid network address value is given and the value 00.00.00.00 is used.
Examples
Generate a UUID string:
uuidgen
23C67E00-71B6-11C9-9DFC-08002B0ECEF1
Generate an IDL template for developing an interface definition:
uuidgen -i
[uuid(B5F8DB80-3CCA-14F8-1E78-930269370000)]
interface INTERFACE
{
}
Generate two UUID strings:
uuidgen -n 2
C0B37080-3CCA-14F8-265F-930269370000
C0B37081-3CCA-14F8-2CDB-930269370000
See Also
tidl(1)
viewc(1)
Name
viewc, viewc32-view compiler for BEA Tuxedo views
Synopsis
viewc [-n] [-d viewdir] [-C] viewfile [viewfile ...]
viewc32 [-n] [-d viewdir] [-C] viewfile [viewfile ...]
Description
viewc is a view compiler program. It takes a source viewfile and produces:
viewc32 is used for 32-bit FML. It uses the FIELDTBLS32 and FLDTBLDIR32 environment variables.
The viewfile is a file containing source view descriptions. More than one viewfile can be specified on the viewc command line as long as the same VIEW name is not used in more than one viewfile.
By default, all views in the viewfile are compiled and two or more files are created: a view object file (suffixed with .V) and a C header file (suffixed with .h). The name of the object file is viewfile.V in the current directory unless an alternate directory is specified through the -d option. C header files are created in the current directory.
If the -C option is specified, then one COBOL copy file is created for each VIEW defined in the viewfile. These copy files are created in the current directory.
At viewc compile time, the compiler matches each fieldid and field name specified in the viewfile with information obtained from the field table file, and stores mapping information in an object file for later use. Therefore, it is essential to set and export the environment variables FIELDTBLS and FLDTBLDIR to point to the related field table file. For more information on FIELDTBLS and FLDTBLDIR please refer to the BEA Tuxedo FML Programmer's Guide and the BEA Tuxedo Programmer's Guide.
If the viewc compiler can not match a field name with its fieldid because either the environment variables are not set properly or the field table file does not contain the field name, a warning message Field not found is displayed.
With the -n option, it is possible to create a view description file for a C structure that is not mapped to an FML buffer. The BEA Tuxedo Programmer's Guide tells how to create and use such an independent view description file.
The following options are interpreted by viewc:
Portability
The output view file is a binary file that is machine and compiler dependent. That is, it will not work to generate a view on one machine with a specific compiler and use it on another machine type or with a compiler that generates structure offsets differently (that is, different padding or packing).
When a view file description file is compiled on DOS or OS/2, the name of the object file has a .VV suffix instead of a .V suffix because the filenames are not case dependent. The following additional options are recognized.
See Also
Fintro(3), BEA Tuxedo Programmer's Guide
viewdis(1)
Name
viewdis, viewdis32-view disassembler for binary viewfiles
Synopsis
viewdis viewobjfile ... viewdis32 viewobjfile ...
Description
viewdis disassembles a view object file produced by the view compiler and displays view information in viewfile format. In addition, it displays the offsets of structure members in the associated structure.
One or more viewobjfiles (suffixed with .V) can be specified on the command line. By default, the viewobjfile in the current directory is disassembled. If this is not found, an error message is displayed.
Since the information in the viewobjfile was obtained from a match of each fieldid and field name in the viewfile with information in the field table file, it is important to set and export the environment variables FIELDTBLS and FLDTBLDIR.
The output of viewdis looks the same as the original view description(s), and is mainly used to verify the correctness of the compiled object view descriptions.
viewdis32 is used for 32-bit FML. It uses the FIELDTBLS32 and FLDTBLDIR32 environment variables.
See Also
viewc(1), BEA Tuxedo FML Programmer's Guide
wlisten(1)
Name
wlisten-BEA Tuxedo Web GUI listener process
Synopsis
wlisten [-i initialization_file]
Description
wlisten is a listener process that receives incoming connections from Web GUI applets and starts a Web GUI gateway process (wgated). All wlisten options are taken from an initialization file that is specified by the -i option. If the -i option is not given, then $TUXDIR/udataobj/webgui/webgui.ini is used as the default initialization file. The format and parameters allowed in the initialization file are described below. A default initialization file is generated during system installation.
wlisten places itself in the background when invoked (unless the initialization file contains the FOREGROUND=Y parameter), and continues running until the machine shuts down or the wlisten process is killed through an operating system command.
The following command-line option is used by wlisten:
Initialization File
The initialization file specified by the -i option contains parameters that allow the applet, wlisten process, and gateway process to coordinate certain pieces of configuration information necessary for the connection and subsequent operation of the Web GUI.
Most of the parameters contained in the initialization file are configured when BEA Tuxedo is installed. Other parameters may be added automatically when the Web GUI is being run, in response to user input. For example, if you connect to a domain, the GUI adds a listing for that domain to the initialization file. The next time you use the pull-down Domain menu (above the Power Bar in the main GUI window), you will see the new domain listed. Do not be alarmed if you notice that lines have been added or changed in your initialization file without your having explicitly edited the file.
The initialization file consists of commentary lines (blank lines or lines beginning with the # character) and keyword lines. Keyword lines are of the form keyword=value. The allowed keywords and values are outlined below:
Termination
The only way to stop a wlisten process with a normal termination is by sending it a SIGTERM signal.
Recommended Use
To Ensure Automatic Starting of the Listener
To make sure the Web GUI listener is started automatically, we recommend adding a command line in the following format to your UNIX system initialization scripts:
$TUXDIR/bin/wlisten -i initialization_file
To start the wlisten process manually, enter the command line shown above after a system prompt.
To Ensure Administrative Password Will Be Found
During the installation process, an administrative password file is created. When necessary, BEA Tuxedo searches for this file in the following directories (in the order shown):
APPDIR/.adm/tlisten.pw; TUXDIR/udataobj/tlisten.pw
To ensure that your administrative password file will be found, make sure you have set the APPDIR and/or TUXDIR environment variables.
Network Addresses
Suppose the local machine on which wlisten is being run is using TCP/IP addressing. The machine is named backus.company.com and its address is 155.2.193.18.
Further suppose that the port number at which wlisten should accept requests is 2334. Assume that port number 2334 has been added to the network services database under the name bankapp-nlsaddr. The address specified by the -l option may be represented in any of several ways:
//155.2.193.18:bankapp-nlsaddr
//155.2.193.18:2334//backus.company.com:bankapp-nlsaddr//backus.company.com:2334
0x0002091E9B02C112
The last line shows how to represent the address in hexadecimal format: 0002 is the first part of a TCP/IP address, 091E is the hexadecimal translation of the port number 2334, and 9B02CU2 is an element-by-element hexadecimal translation of the IP address, 155.2.193.18. (In the latter translation, 155 becomes 9B, 2 becomes 02, and so on.)
For a STARLAN network, a recommended address of uname.wlisten will usually yield a unique name.
See Also
tuxadm(1), tuxwsvr(1)
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|