TAOK - No service updates were made to the metadata repository

TAUPDATED - All service updates were made to the metadata repository

TAPARTIAL - Partial service updates were made to the metadata repository

FML32 fields related to specific metadata repository attributes use the prefix TA_REPOS followed by the name of the repository keyword in upper case. For more information on Metadata Repository service and parameter key words, see tmloadrepos(1).

METAREPOS Attribute Fields

Service-Level Attribute Fields

METAREPOS service-level attribute fields are used to describe services. The TA_REPOSSERVICE attribute is a key field that is used to name services and uniquely identify them for retrieval or get operations. TA_REPOSSERVICE can accept regular expressions as defined in rex(1). For example, using the regular expression value "*" with TA_REPOSSERVICE retrieves all service information in a metadata repository.

For set operations, TA_REPOSSERVICE must include a Tuxedo service name and cannot be interpreted as a regular expression.

For more information on service-level keywords, see Managing The Tuxedo Service Metadata Repository, Creating The Tuxedo Service Metadata Repository.

Parameter-Level Attribute Fields

METAREPOS parameter-level attribute fields are used to describe service parameters. Common occurrence numbers are used to associate different attribute fields as part of a common parameter.The nth service parameter is described by the occurrence number n-1 of all parameter-level attribute fields.

For example, the first service parameter is described by the first occurrence of the attribute field as "0"; the second service parameter is described by the second occurrence of the attribute field as "1", and so on.

If a specific attribute field occurrence is required by a later numbered parameter, but not by one or more earlier numbered parameters, you must specify a value for the earlier attribute field occurrences so that the later occurrences are properly numbered.

Sub-Parameter Values

TA_REPOSEMBED is used to provide information about service parameters that have sub-parameter values, or in other words, embedded data.

Because the Tuxedo service metadata repository requests input and output in FML32 format, when TA_REPOSEMBED is specified with sub-parameter values (other than the default empty record), it must contain an FML32 record. This FML32 record consists of parameter-level fields corresponding to each sub-parameter (FML field or VIEW element) in the record described by the associated TA_REPOSPARAM field.

The TA_REPOSEMBED parameter value corresponds to the information contained between matching parentheses "(" and ")"in the repository_input file or the unloaded -t repository_file. For more information on the repository_input file and repository_file, see tmloadrepos(1) and tmunloadrepos(1).

Table 37 METAREPOS Attribute Field Table 

Attribute Field	Level	Type	Permissions	Values	Default
TA_REPOSSERVICE (x)(r)(*)	service	string	rwxr--r--	string[115]	N/A
TA_STATE(k)	N/A	string	rwxr-xr--	GET:"VAL" SET:"{NEW | unset | INV}	N/A N/A
TA_REPOSTUXSERVICE	service	string	rwxr--r--	string[115]	N/A
TA_REPOSSEVICETYPE	service	string	rwxr--r--	"{service|oneway|queue}"	service
TA_REPOSEXPORT	service	string	rwxr--r--	"{ Y | N }"	"Y"
TA_REPOSINBUF	service	string	rwxr--r--	string[1...8]	N/A
TA_REPOSOUTBUF	service	string	rwxr--r--	string[0...8]	N/A
TA_REPOSINVIEW	service	string	rwxr--r--	string[0..16]	N/A
TA_REPOSOUTVIEW	service	string	rwxr--r--	string[0..16]	N/A
TA_ REPOSSVCDESCRIPTION	service	string	rwxr--r--	string[0..1024]	N/A
TA_REPOSSENDQSPACE	service	string	rwxr--r--	string[0..15]	N/A
TA_REPOSSENDQUEUE	service	string	rwxr--r--	string[0..15]	N/A
TA_REPOSRPLYQUEUE	service	string	rwxr--r--	string[0..15]	N/A
TA_REPOSERRQUEUE	service	string	rwxr--r--	string[0..15]	N/A
TA_REPOSRCVQSPACE	service	string	rwxr--r--	string[0..15]	N/A
TA_REPOSRCVQUEUE	service	string	rwxr-r--	string[0..15]	N/A
TA_REPOSVERSION	service	string	rwxr--r--	string[0..1024]	N/A
TA_REPOSATTRIBUTES	service	string	rwxr--r--	string[0..1024]	N/A
TA_REPOSFIELDTBLS	service	string	rwxr--r--	string[0..1024]	N/A
TA_REPOSPARAM	parameter	string	rwxr-r--	string[1..32]	N/A
TA_REPOSTYPE	parameter	string	rwxr--r--	"{ byte | short | integer | float | double | string | carray | dec_t | xml | ptr | fml32 | view32 | mbstring }	N/A
TA_REPOSSUBTYPE	parameter	string	rwxr--r--	string[0..32]	N/A
TA_REPOSACCESS	parameter	string	rwxr--r--	"{ in | out | inout | noaccess }	N/A
TA_REPOSCOUNT	parameter	long	rwxr--r--	0<=num<=32767	1
TA_REPOSPARAMDES CRIPTION	parameter	string	rwxr--r--	string[0...1024]	N/A
TA_REPOSSIZE	parameter	long	rwxr--r--	0<=num	N/A
TA_REPOSREQUIRED COUNT	parameter	long	rwxr--r--	0<=num<=32767	N/A
TA_REPOSFLDNUM	parameter	long	rwxr--r--	0<=num	N/A
TA_REPOSFLDID	parameter	long	r--r--r--	0<=num	N/A
TA_REPOSVFBNAME	parameter	string	rwxr--r--	string[0...30]	N/A
TA_REPOSVFLAG	parameter	string	rwxr--r--	string[0...6]	N/A
TA_REPOSVNULL	parameter	String	rwxr--r--	string[0...32]	N/A
TA_REPOSEMBED	parameter	FML32	rwxr--r--		Empty record
(x) - Regular expression GET key field (r) - Required field for object creation( SET TA_STATE NEW ) (*) - GET/SET key, one or more required for SET operations (k) - GET key

 

METAREPOS Attribute Semantics

TA_REPOSSERVICE: string[115]

Service name. This attribute accepts regular expressions as defined in rex(1) for metadata repository service information retrieval. Regular expressions cannot be used to update metadata repository service information.

TA_STATE:

GET: "{ VALid }"

A GET operation retrieves information for the selected service object(s). The following state(s) define TA_STATE returned in response to a GET request.

 

VALid

Service object is defined. Note that this is the only valid state for service metadata repository.

 

SET: "{ NEW | unset | INValid }"

A SET operation updates information for the selected service object(s). The following state(s) define TA_STATE set in a set request. States not listed cannot be set

.

NEW	Create new service object. Successful return leaves the object in the VALid state.
unset	Modify an existing service object. This combination is not allowed in the INValid state. Successful return leaves the object state unchanged.
INValid	Delete service object. State change allowed only when in the VALid state. Successful return leaves the object in the INValid state.

 

TA_REPOSTUXSERVICE: string[115]

Actual tuxedo service name. By default, it has the same value as TA_REPOSSERVICE.

TA_REPOSSERVICETYPE: "{service|oneway|queue}"

Service invocation type. This term comes from the Tuxedo Control.

· "service" supports synchronous request/response.

· "oneway" supports request without response.

· "queue" supports tpenqueue and tpdequeue.

TA_REPOSEXPORT: "{ Y | N }"

Indicates whether a service object is available or not. This attribute is for Jolt Repository compatibility only. The default value is "Y".

TA_REPOSINBUF: string[1... 8]

The service(s) input buffer type. Valid values : FML, FML32, VIEW, STRING, CARRAY, XML, X_OCTET, X_COMMON, X_C_TYPE, MBSTRING or a custom-defined type. Only one type is allowed.

Note: Limitation: A string of custom type may contains up to 8 characters. See "Managing Typed Buffers" in Programming a BEA Tuxedo ATMI Application Using C

A_REPOSOUTBUF: string[08]

The service(s) output buffer type. Valid value is same as TA_REPOSINBUF. Note that this attribute can be null.

TA_REPOSINVIEW: string[016]

View name for input parameters. This information is optional only if one of the following buffer types is used: VIEW, VIEW32, X_COMMON, X_C_TYPE.

TA_REPOSOUTVIEW: string[016]

View name for output parameters. Similar with TA_REPOSOUTVIEW.

TA_ REPOSSVCDESCRIPTION: string[01024]

String value for service description.

TA_REPOSSENDQSPACE: string[015]

String value for send queue space name. Optional only when TA_REPOSSERVICETYPE is "queue".

TA_REPOSSENDQUEUE: string[015]

String value for send queue name. Optional only when TA_REPOSSERVICETYPE is "queue".

TA_REPOSRPLYQUEUE: string[015]

String value for reply queue name. Optional only when TA_REPOSSERVICETYPE is "queue".

TA_REPOSERRQUEUE: string[015]

String value for error queue name. Optional only when TA_REPOSSERVICETYPE is "queue".

TA_REPOSRCVQSPACE: string[015]

String value for receive queue space name. Optional only when TA_REPOSSERVICETYPE is "queue".

TA_REPOSRCVQUEUE: string[015]

String value for receive queue name. Optional only when TA_REPOSSERVICETYPE is "queue".

TA_REPOSVERSION: string[0...1024]

Any string defined by the user. Tuxedo does not interpret this attribute.

TA_REPOSATTRIBUTES: string[0...1024]

Any string defined by the user. Tuxedo does not interpret this attribute.

TA_REPOSFIELDTBLS: string[0...1024]

Optionally specifies a comma-separated list of field tables where the FML or FML32 fields used by this service can be found. Use the absolute path to describe each field table file.

TA_REPOSPARAM: string[0...32]

Parameter name.

TA_REPOSTYPE: "{ byte | short | integer | float | double | string | carray | dec_t | xml | ptr | fml32 | view32 | mbstring }"

Parameter type.

TA_REPOSSUBTYPE : string[032]

A view name for view32 typed parameter.

TA_REPOSACCESS: '{ in | out | inout | noaccess }'

Parameter access method.

TA_REPOSCOUNT: 0<=num<=32767

Maximum number of parameter occurrences. Default value is 1.

TA_REPOSPARAMDESC: string[0...1024]

Parameter description string.

TA_REPOSSIZE: 0<=num

Optional only if the following parameter types are used: carray, string, xml, mbstring.

TA_REPOSREQUIREDCOUNT: 0<=num<=32767

Minimum number of parameter occurrences.

TA_REPOSFLDNUM: 0<=num

Optional only for FML/FML32 field parameter, field number definition.

TA_REPOSFLDID: 0<=num

Optional only for FML/FML32 field parameter, field id. Note that this field cannot be written or updated.

TA_REPOSVFBNAME: string[0...30]

Optional only when parameter type is view/view32. It is used to specify the corresponding field name for views mapped to FML buffers.

TA_REPOSVFLAG: string[0...6]

Optional only when parameter type is view/view32. Using this field by following the rules of the "Flag" option defined in viewfile(5).

TA_REPOSVNULL: string[0...32]

Optional only when parameter type is view/view32. It is used to define user-specified NULL as the default NULL value for that parameter.

TA_REPOSEMBED

Optional only if the parameter is one of following types: fml32, view32. It is an embedded FML32 field to describe sub-parameters of the parameter.

Note: TA_REPOSEMBED field also is used to encapsulate attributes of each service once there might be multiple services in one FML32 buffer. Please see figure 6-1 and 6-2 for more information.

METAREPOS Buffer Format Diagram

Currently, METAREPOS input and output is in FML32 buffer format and is used to describe one or more instances of service metadata information. This FML32 typed buffer format is define in two modes: Standard Mode and Single Mode.

Figure 1 Standard Mode

In standard mode, each service is encapsulated into one embedded TA_REPOSEMBED FML32 field. Users fill in METAREPOS attributes by following the restrictions defined in the METAREPOS service-level and parameter-level attribute tables.

• Output Buffers: All output buffers returned by the Tuxedo service metadata repository must use standard mode, no matter if one or more service objects are returned.

Note: For SET operations, TA_ERROR and TA_STATUS are included in each TA_REPOSEMBED buffer to indicate the set result of each service.

• Input Buffers: When using input buffer to specify services, standard mode is applied under the following conditions:

1. SET operations (adding or updating) to outstanding multiple services

2. When a user wants to use standard mode instead of single mode

Figure 2 Single Mode




 

Single mode can only be used in METAREPOS input buffers that specify one service only. Single mode can be applied under the following conditions:

1. SET operations to only one outstanding particular service

2. GET operations

METAREPOS Request Examples

Adding a service deposit to repository

Figure 3 Single Mode Request




 

Figure 4 Standard Mode Request

Delete service deposit and transfer

Listing 3

TA_OPERATION SET
A_CLASS T_REPOSITORY
TA_STATE DEL

TA_REPOSSERVICE deposit,transfer

See Also

tmloadrepos(1), tpgetrepos(3c), tpsetrepos(3c), MIB(5), TMMETADATA(5).

MIB(5)

Name

MIB—Management Information Base

#include <fml32.h> 
#include <fml1632.h> /* Optional */ 
#include <tpadm.h> 
#include <cmib.h>  /* Component MIB Header */

Description

A BEA Tuxedo system application consists of distinct components (for example, BEA Tuxedo, Workstation), each administered using a Management Information Base (MIB) defined specifically for that component. These component MIBs are defined in individual reference pages each addressing the MIB for a particular part of the system. For example, the reference page TM_MIB(5) defines the MIB used to administer the fundamental aspects of a BEA Tuxedo application.

However, component MIBs do not provide sufficient definition of the interfaces involved to provide the necessary access. This reference page, MIB(5), describes the generic interfaces through which an administrator, operator or user interacts with any of the defined component MIBs. The generic interface to each BEA Tuxedo system MIB consists of two main parts.

The first part of the generic interface is a description of how existing BEA Tuxedo system interfaces are used to provide access to administrative services responsible for supporting the component MIBs. FML32, a BEA Tuxedo system buffer type, is used as the vehicle for passing input to and receiving output from component MIBs. ATMI request/response verbs are used as the interface to component MIBs, which are implemented as system-supplied services. Details on interaction between an administrative user and component MIBs using FML32 buffers ATMI verbs are provided in the FML32and ATMI sections later in this reference page.

The second part of the generic interface is the definition of additional input and output FML32 fields that are used in interactions with all component MIBs. The additional FML32 fields extend the power of requests (for example, by allowing operation codes to be specified) and add generic response attributes (for example, error codes and explanatory text). Details on additional FML32 fields are provided in the Input and Output sections found later in this reference page.

The Usage section gives examples of the use of existing ATMI verbs and the additional FML32 fields as they might be used for administrative interaction with component MIBs.

In addition to defining how users interface with component MIBs to administer an application, this reference page establishes the format used in the component MIB reference pages to define classes (see Class Descriptions).

Two generic classes are defined in this reference page: T_CLASS and T_CLASSATT. These two classes are used to identify administrative classes and to tune class/attribute permissions. For additional information pertaining to all MIB(5) class definitions, see MIB(5) Additional Information. The Diagnostics section lists error codes that may be returned by component MIB system services.

Authentication

Users are authenticated as they attempt to join the application (see tpinit(3c)). At tpinit() time, administrators and operators can ask to join the application with a client name of either tpsysadm or tpsysop. These two cltname values are reserved and can only be associated with administrators and operators of the application.

The administrator who initially configures an application determines the level of security to be included by choosing a particular security type. Available security types are:

• No security
• Application password authentication
• Application password plus an application specific authentication service

The choice of security type determines the flexibility and security in allowing administrator and operator access to the component MIBs via the AdminAPI.

The most secure and flexible security type is an application password plus an application-specific authentication server (see AUTHSVR(5)). This method allows the administrator to permit access to any user or to only specified users provided they supply the appropriate password to the authentication server.

In the absence of an application specific authentication server, a client must satisfy the authentication requirements of the application (either none or application password), specify one of the special client names in the cltname field of the TPINIT structure and be running as the BEA Tuxedo administrator for the local UNIX system to qualify for special administrator or operator permissions. In any case, a successfully joined client is assigned a key by the system; the key is delivered with all requests it makes. Clients properly authenticated as either tpsysadm or tpsysop are assigned an authentication key that lets the system know they have special privileges.

Administrative authentication, as specified, is applicable only to clients that join the system prior to accessing the API. Servers making use of the API are treated the same as the client on whose behalf they are processing. Service requests made from within tpsvrinit() or tpsvrdone() are treated as coming from the administrator.

FML32

Application administration using BEA Tuxedo system defined component MIBs is supported exclusively through the FML32 buffer type. Application programs accessing MIB information must be written to allocate, manipulate and update FML32 typed buffers. There are two main approaches to using FML32 as detailed in Fintro() and summarized here.

The most direct way to interface to FML32 is to include the <fml32.h> header file instead of the standard <fml.h> header file and then to use the FML32 version of each relevant FML interface specified in the BEA Tuxedo ATMI FML Function Reference. For example, one would use Fchg32() instead of using Fchg().

Another method for interfacing with FML32 is to include both the <fml32.h> header file and the <fml1632.h> header file. These two header files work together to allow the user to program to the base FML interfaces (for example, Fchg()) and yet actually invoke the FML32 version of each interface.

ATMI

Application programs access and update component MIB specific attribute information by allocating FML32 typed buffers, populating them with request data, sending the requests for servicing, receiving the replies to the service requests and extracting information regarding the results from the reply. The population and extraction of information to and from the FML32 typed buffers involves the FML32 interfaces as described above. Buffer allocation, sending requests and receiving replies is done using the general purpose ATMI routines listed below within the guidelines and restrictions listed. MIB requests for all components should be sent to the core BEA Tuxedo component MIB service, ".TMIB". This service not only acts as an agent for servicing TM_MIB(5) requests, it also directs requests targeted for other component MIBs so that the user need not be concerned with matching service names to MIBs and classes.

tpalloc()

Allocate FML32 typed buffers to be used in sending requests and/or receiving replies to/from BEA Tuxedo system MIB services. The FML32 buffer type has no subtypes and a minimum default size of 1024 bytes.

tprealloc()

Reallocate FML32 typed buffers.

tpcall()

Call BEA Tuxedo system MIB service, ".TMIB", with a populated FML32 typed buffer as input and with an allocated FML32 typed buffer in which to store the output returned from the service. The buffer length for the input buffer may be specified as 0 since FML32 is a self-describing buffer type. The TPNOTRAN flag should be used if the call is being made within a transaction; otherwise, there are no specific requirements or restrictions on the use of the flags defined for this verb.

tpacall()

Asynchronously call BEA Tuxedo system MIB service, ".TMIB", with a populated FML32 typed buffer as input. The buffer length for the input buffer may be specified as 0 since FML32 is a self-describing buffer type. The TPNOTRAN flag should be used if the call is being made within a transaction; otherwise, there are no specific requirements or restrictions on the use of the flags defined for this verb.

tpgetrply()

Get reply for a previously generated asynchronous call to the BEA Tuxedo system MIB service, ".TMIB". The reply is received into a previously allocated FML32 typed buffer. There are no specific requirements or restrictions on the use of the flags defined for this verb.

tpenqueue()

Enqueue a request to the BEA Tuxedo system MIB service, ".TMIB", for later processing. The buffer length for the input buffer may be specified as 0 since FML32 is a self-describing buffer type. There are no specific requirements or restrictions on the use of the flags defined for this verb; however, the TMQFORWARD(5) server configured by the application to handle forwarding of these requests should be started with the -n (tpcall() with TPNOTRAN flag set) and -d (delete) options.

tpdequeue()

Dequeue the reply for a previously enqueued request to the BEA Tuxedo system MIB service, ".TMIB". The reply is received into a previously allocated FML32 typed buffer. There are no specific requirements or restrictions on the use of the flags defined for this verb.

Input

There are certain FML32 fields used to characterize and control administrative requests to any BEA Tuxedo system MIB. These fields are defined in this reference page as well as in the header file <tpadm.h>. The corresponding field table file can be found in ${TUXDIR}/udataobj/tpadm. These fields are added to an FML32 request buffer in addition to any component MIB specific fields necessary before making the administrative service request. The fields are described below and followed by a table summarizing the operations for which each field is required, optional or unused.

TA_OPERATION

String valued field identifying the operation to be performed. Valid operations are GET, GETNEXT and SET.

TA_CLASS

String valued field identifying the class being accessed. Class names are defined within component MIB specific reference pages.

TA_CURSOR

String valued FML32 field returned by the system on a previous GET or GETNEXT operation. The value returned must be transferred by the application to the subsequent request buffer so that the system can determine current retrieval position.

TA_OCCURS

Long valued FML32 field identifying how many objects are to be retrieved on a GET or GETNEXT operation. If this field is not specified, all matching objects are returned, space permitting.

TA_FLAGS

Long valued FML32 field identifying generic and component MIB specific flag values. Component MIB specific values that may be set in this attribute are defined within each component MIB reference page. Generic flag values and uses are listed below.

MIB_LOCAL

This flag is used to modify retrievals from certain classes defined in this MIB. For a number of classes in this MIB, there exists both global information (available at any site in an active application) and local information (available on the particular site where the object is active). Requests to retrieve information from these classes will by default retrieve only the global information and not the local for efficiency. If the application user is willing to wait for local information to be collected, possibly from multiple sites, this flag should be set on the retrieval request. Classes with local information have local attributes listed last in the attribute table with a subheading indicating that they are local attributes. Classes which have only local information will automatically default to retrieving local information even if this flag value is not set.

MIB_PREIMAGE

indicates that a pre-image check must be passed before a SET operation will be performed. A pre-image check insures that occurrence 0 of any MIB specific class attributes match the existing object. If so, the object is updated using occurrence 1 of any MIB specific class attributes. Attributes occurring less than two times are not considered for pre-image checking. Multiply occurring fields are checked if their associated count attribute is specified twice.

MIB_SELF

This flag is used as a shorthand to indicate that identification attributes for the client or server originating the request should be added to the request buffer prior to processing. For clients, TA_CLIENTID is added and for servers, TA_GRPNO and TA_SRVID are added.

TA_FILTER

Long valued FML32 field that may be specified with up to 32 occurrences to indicate the specific class attributes that should be returned. An occurrence with the value 0 may be specified to end the list but is not required. A list with an initial attribute value of 0 will return no class specific attributes but will return a count of class objects matched.

TA_MIBTIMEOUT

Long valued FML32 field identifying the time, in seconds, that should be allowed within the component MIB service to satisfy the request. A value less than or equal to 0 indicates that the component MIB service should not undertake any blocking operation. If unspecified, this value defaults to 20.

TA_CURSORHOLD

Long valued FML32 field identifying the time, in seconds, that a system snapshot generated from an initial GET operation should be held after the current GET or GETNEXT operation is satisfied before disposing of it. A value less than or equal to 0 indicates that the snapshot should be disposed of after satisfying the current request. If unspecified, this value defaults to 120.

In the following table, R indicates a required INPUT attribute, O an optional INPUT attribute, and — an unused INPUT attribute.

Output

Output from successful administrative requests consists of one or more MIB specific objects and one occurrence of the generic output fields. In general, multiple MIB specific objects are reflected in the output buffer by multiple occurrences of each class attribute returned. Occurrence 0 of each attribute relates to the first object, occurrence 1 to the second object, and so on. Exceptions to this guideline are noted in the component MIB reference pages. Intermediate occurrences without values for certain attributes may have FML32-defined NULL field values inserted as place holders. A successful SET operation returns a single object reflecting the object after the operation was performed. A successful GET or GETNEXT operation may return 0 or more occurrences depending on how many occurrences were requested (see TA_OCCURS below), how many occurrences were matched by the specified key fields and space limitations within the MIB specific system service.

It is important to note that not all attributes defined for any class may necessarily be returned for any request depending on object state, interoperating release environments and/or input request filters. Administrative programmers should avoid implicit dependencies on the presence of certain attributes in output buffers and should instead explicitly check for the presence of attribute values.

To repeat, the reply to a successfully processed administrative request includes certain generic fields that apply to all MIBs. The fields are defined in the header file <tpadm.h>. The corresponding field table file can be found in ${TUXDIR}/udataobj/tpadm. The generic reply fields are added to a the reply buffer and returned with the component MIB specific fields. The generic reply fields are described below.

TA_CLASS

String valued field identifying the class represented in the reply buffer. Class names are defined within component MIB specific reference pages.

TA_OCCURS

Long valued FML32 field identifying how many objects are in the reply buffer.

TA_MORE

Long valued FML32 field identifying how many additional objects matching the request key fields are being held in a system snapshot for later retrieval. This field is not returned for SET operations.

TA_CURSOR

String valued FML32 field identifying the position within a system held snapshot. This field must be added to the request buffer for a subsequent GETNEXT operation. The value of this field should not be interpreted or modified by the application user. This field is not returned for SET operations.

TA_ERROR

Long valued FML32 field identifying a non-negative return code characterizing the successful return. Generic return codes and their meaning are defined below.

TAOK

The operation was successfully performed. No updates were made to the application.

TAUPDATED

An update was successfully made to the application.

TAPARTIAL

A partial update was successfully made to the application.

Administrative requests that fail within MIB specific system service processing return an application service failure to the application including the original request and generic fields used to characterize the error. Application service failures are indicated by a TPESVCFAIL error return from tpcall() or tpgetrply(). Application service failures returned via the TMQFORWARD(5) server will appear on the error queue specified on the original request (assuming the -d option was specified on the server command line). Generic fields used to characterize failed administrative requests are listed below.

TA_ERROR

Long valued FML32 field identifying the particular error that occurred. Error codes may be generic in which case they are listed in the "DIAGNOSTICS" section of this reference page, or they may be specific to a component MIB, in which case they are described on the individual component MIB reference page.

TA_STATUS

String valued FML32 field providing a textual description of the error.

TA_BADFLD

Long valued FML32 field providing the field identifier of the offending field in cases where an error can be attributed to the value in a particular field. In cases where errors are caused by the combination of values in multiple fields, there may be multiple occurrences of this field.