| Application Development | |
This chapter describes transaction manager processing at runtime. It includes:
Running Transaction Manager |  |
Once the application screen is created and its widgets, table views and links are properly defined, the screen is ready to use.
Refer to Chapter 31, "Building a Transaction Manager Screen," for instructions on building a transaction manager screen.
Processing for the transaction manager begins when you open an application screen. On screen entry, the transaction manager automatically executes the following steps:
If a named function cannot be found or if the root table view cannot be determined, an error message is issued and the transaction manager stops its processing.
When you close a screen, the transaction manager performs the necessary exit processing. This includes:
Closing the Screen
If a named function cannot be found, an error message is issued.
The following options are available for viewing the generated SQL:
Viewing the Generated SQL
If you want to disable the transaction manager, change the screen's Root property to Disabling the Transaction Manager
"-none-".
Displaying Data | |
The transaction manager uses two commands to display data from a database, VIEW and SELECT. These commands can be invoked whenever a database connection is active.
VIEW displays information; SELECT allows the user to modify the selected data.
In general, when a VIEW or SELECT command is executed, data is fetched from the database and displayed in appropriate widgets using dbms commands (as part of the TM_SEL_BUILD_PERFORM event):
SQL SELECT statement.
WITH CURSOR clause.For example:
DBMS DECLARE jdb1 CURSOR FOR SELECT ...
DBMS WITH CURSOR jdb1 ALIAS ...
DBMS WITH CURSOR jdb1 EXECUTE USING ...
This series of dbms statements is performed for each server view, which includes the table view (defined as a server view) and all table views joined to it via server links.
If the Panther targets for the select set are arrays, the first retrieved row populates the first occurrence, the second row populates the second occurrence, and so on.
Figure 36-1 illustrates a screen that lets users enter a video title by name or identification number, and view the names of the actors and their roles for the specified video. In addition, new videos can be added with the corresponding actors and roles.
The screen in Figure 36-1 contains two server views; therefore, the statements are executed twice. The first series fetches a video title and its associated price category from the titles and pricecats tables. The second series fetches the actors appearing in the video and the name of their roles.
Figure 36-2 illustrates the DB Interactions window for this screen. The titles table view has a sequential link with the roles table view; therefore, values in the titles table view (which is the parent) are used to fetch data for the child table view. The Relations property of the sequential link tells the transaction manager which widget to use to supply the value. In this example, the value in
The CONTINUE command (only available on two-tier processing) in the transaction manager fetches the next set of data for the screen. For the root table view, the next row, or set of rows, is fetched. For any child table views connected by sequential links, additional There are two ways to allow users to scroll forward and backward through a select set. You can create scrolling widgets or a grid for displaying the data. In environments where memory is limited, you can fetch only a small number of rows to the application and buffer the rest in a disk file. This is known as using a continuation file or a store file.
To use a continuation file with transaction manager, you need to edit the Fetch Directions property for either the screen or the table view. If Fetch Directions is set to Up/Down-all modes or Up/Down-view mode, the transaction manager fetches the data to a continuation file. Then, issuing a CONTINUE_UP command displays the previous set of data, and issuing a CONTINUE_TOP command displays the first set of data.
Panther does not set backward scrolling via continuation files as the default since Panther does not update the continuation file when the onscreen data is changed. Scrolling backward shows the original, fetched data. If you set Fetch Directions to be Up/Down in all modes, be aware that once a SAVE command is issued, you need to re-execute SELECT in order to see any updated data.
The number of occurrences fetched for transaction manger is set in the Maximum Occurrences ( The Count Select property of each server view allows you to request that the transaction manager count the number of rows in a result set and compare it to a specified threshold value before actually fetching data.
In the server view's properties, set the Count Select property and its subproperty, Count Warning, to Yes. In the Count Threshold property, specify the maximum number of rows to fetch in a result set. If the size of a result set (stored in the server view's runtime For any command which can modify the database, such as In order to customize the processing done for any table view, you can:
Figure 36-1 Data are displayed by executing a series of DBMS statements.
title_id is used to build a WHERE clause which fetches only the actors in that video.
Figure 36-2 The DB Interactions window displays the table views and their associated links.
Scrolling Through the Select Set
SQL SELECT statements are issued, using the values from the parent table view in the WHERE clause. For each subsequent CONTINUE command, another set of data is fetched. If there are no additional rows, nothing is done.
Controlling the Number of Rows
max_occurrences) property.
count_result property) exceeds this value, the user is prompted before the data is actually fetched.
SELECT, the transaction manager must synchronize the widgets in a server view. For more information, refer to "Updating Data in Arrays."
Customizing Select Processing
Updating the Database | |
If you execute a command that modifies data, such as NEW, SELECT, COPY or COPY_FOR_UPDATE, the transaction manager initiates before-image processing for all updatable table views. Panther's before image remembers the original values of the fetched data. Then, when you execute SAVE, the transaction model generates the necessary statements so that the database matches the current data on the screen.
The NEW command prepares the screen for data entry; it does not insert information into the database. Similarly, the SELECT command retrieves data from the database and prepares the screen to be edited by changing the screen to update mode. The changes made on the screen are not saved to the database until a SAVE command is executed.
Specialized traversal patterns are used for the TM_INSERT, TM_UPDATE, and TM_DELETE requests. For these requests, the traversal pattern is determined by the link properties for the transaction tree and the operation being performed.
You can change the traversal order for the TM_INSERT, TM_UPDATE, and TM_DELETE requests by modifying the link widget's Insert Order (insert_order), Update Order (update_order), and Delete Order (delete_order) properties, indicating whether the parent (PV_PARENT_FIRST) or child (PV_CHILD_FIRST) table view should be processed first.
The transaction manager SELECT command queries the database for information so that it can be updated. When you execute the SELECT command, the transaction manager fetches the first screenful of data for each of the linked table views. (If you then execute the CONTINUE command, the transaction manager fetches the next screenful of data.)
Panther keeps track of the changes the user makes while the screen is in update mode. When the application executes SAVE, the transaction manager generates the statements to update the database. If the application attempts any other transaction manager operation, the transaction manager prompts the user if it should discard the changes. If the user chooses to discard, the transaction manager proceeds to the next command without changing the database. If the user chooses not to discard, transaction manager returns control to the screen. You can modify this behavior if you wish.
When before image processing is activated, each time a field is modified in some way (data is edited, data is cleared, new data is entered), the data previously in the widget is copied into memory and the transaction manager is notified that data on the screen has changed. Then, when the SAVE command is selected, the transaction manager looks at the changes and determines which statements are necessary to update the database so that it matches what is currently on the screen.
For any command which can modify the database, such as SELECT, NEW, COPY and COPY_FOR_UPDATE, the transaction manager must synchronize the widgets in a server view. This ensures that any updates occur on the same occurrence of each widget in the server view. Each time the SELECT, NEW, COPY and COPY_FOR_UPDATE commands are chosen, the transaction manager attempts to synchronize the widgets in a server view if:
If you get a synchronization error, check to see if the widgets can be set to the same number of occurrences. If this is not possible, review the Use In Select, Use In Insert, and Use In Update properties for each widget to see if they can be changed. Another property change you can make is setting the Synchronization property to No.
However, changing the Synchronization property to No does not change the way Panther fetches data to arrays. The number of rows fetched from the database equals the least number of occurrences set for any widget in the server view whose Use In Select property is set to Yes.
For multi-text widgets with the Word Wrap property set to Yes (the default setting), you need to set the Maximum Occurrences ( If you change value of a primary key, the transaction manger first deletes the row associated with the old value and then inserts a row with the new value.
You can change this behavior by setting the application property In both cases, if you change the value of a primary key to a null value, the transaction manager deletes the row.
To delete data in the transaction manager, execute the CLEAR command, followed by SAVE. This removes all the data displayed on the screen from the database. The The user can also use the logical key For the CLEAR command, the transaction manager clears the fields in each table view (by calling sm_1clear_array). To have the transaction manager clear the fields in each server view (the equivalent of calling sm_clear_array), you need to either:
Using Multi-text Widgets
max_occurrences) property.
Changing the Primary Key
primary_key_update to Yes which performs a SQL UPDATE for the primary key change. Deleting the row can lead to data loss when there are database columns that are not in the table view.
Deleting Data
TM_DELETE request usually processes child table views first. The resulting SQL DELETE statement contains a WHERE clause built from the before image values of the primary key widgets.
DELL to delete a line. Since the transaction manager synchronizes the arrays in a server view, using this key deletes the same occurrence in every array in the server view. You can program a delete line event by calling the function sm_doccur or sm_1clear_array.
Clearing Data in Arrays
tm_clear_fast to PV_YES.
However, setting If widgets have been excluded from synchronization (via the synchronization property) or if widgets are members of a non-updatable table view, they will not be cleared.
If Do not change this property while the transaction manger is traversing table views for a To insert data in the transaction manager, execute the NEW command, let the user complete the data entry, and then execute SAVE. This inserts a row in each table view that was modified on the screen.
If the data is in arrays or grids, the user can use the logical key For inserts, the transaction models call the SQL generator to build a values list for the widgets in the table view whose Use In Insert property is set to Yes.
Since the SAVE command generates different types of statements, depending on whether it needs to insert, update or delete data, the transaction manager checks the value of the variable To check the status of changes generated by the
Note:
The value returned is not equivalent to the number of SQL statements issued, since multiple SQL statements can be issued for each row.
If at any time in this process, you wish to abort the edits to the screen, you can execute the CLOSE command which discards the user's changes and puts the screen in initial mode.
In order to customize the processing done for any table view, you can:
tm_clear_fast to Yes can be over-inclusive, clearing too much data, or under-inclusive, clearing too little data. In particular, widgets in the synchronization group that do not belong to the table view will get cleared.
tm_clear_fast is set to Yes, it is not recommended that you call CLEAR before the synchronization of tables views occurs.
CLEAR command. The current setting applies to the entire application; you cannot apply the setting per table view.
Inserting Data
INSL, which inserts a line. Since the transaction manager synchronizes the arrays in a server view, using this key inserts a line in each array in the server view. You can program an insert line event by calling the function sm_ioccur.
Saving Data
TM_OCC_TYPE to determine what kind of change was made to the row or occurrence. (Refer to "Determining How Screen Data Has Changed" for a description of TM_OCC_TYPE values; the values are defined in tmusubs.h.)
SAVE command, you can call sm_tm_inquire(TM_SAVE_COUNT) which returns the number of rows that were saved to the database.
Customizing Database Updates
For update and insert processing, the Regenerate SQL sub-property specifies whether the transaction manger should include every database column in the SQL statements or only the columns that have changed.
This property, named regenerate_ins_sql and regenerate_upd_sql at runtime, can be set at the table view level or at the application level. Table views, by default, use the application level property value.
Transaction Modes | |
The transaction manager uses a set of transaction modes to help monitor and control your application's appearance and behavior. Transaction modes are initiated by associated transaction manager commands.
At a given point in time, the transaction mode determines:
For example, in a typical client screen the Save button is disabled when you first enter the screen. In this case, the initial transaction mode causes the Save button to be disabled (grayed) and precludes use of the SAVE command.
Table 36-1 lists the transaction modes set by the transaction manager and the commands that initiate those modes.
The following commands do not change the transaction mode, but are available in certain modes:
When you execute a command, the transaction manager checks the current transaction mode and either changes the mode or reports an error if the current mode is invalid for the command. Each screen can have its own mode at any given time.
In addition, when the mode changes, the appearance and protection of widgets can also change depending on the style and class settings for the widget.
As some of the transaction commands are executed, widget behavior is automatically affected. For instance, data entry type widgets can prevent input, menu choices might be deactivated, and push buttons can go from gray (inactive) to becoming accessible. These changes occur because predefined style and class settings exist for each transaction mode.
The style and class settings give a consistent user interface to an application. Data entry widgets can have the same focus and protection settings; the same color changes. This takes place without having to write any source code or set any properties in the screen editor.
The definitions for the styles and classes are defined in the In general, when a SELECT command is executed, rows from the database are retrieved for possible edit, and the transaction mode is set to update. On the screen illustrated in Figure 36-1, the For a given transaction mode, certain types of widget behavior are determined by:
Transaction Styles and Classes
styles.sty file in the distributed client.lib and, for JetNet /Oracle Tuxedo applications, in the distributed server.lib. You can use the predefined styles and classes, or edit style and classes settings or define your own styles and classes using the styles editor (for details on using the styles editor, refer to page 23-1 in the Using the Editors).
Applying Styles
title_id and actor_id widgets are automatically protected from input, preventing any edits to primary key fields. The pricecat_dscr, first_name, and last_name widgets are also protected since they members of non-updatable table views. The remaining data entry widgets can be updated.
In addition, there are other predefined styles to use with menu selections and push buttons. For more information on these styles, refer to page 23-6 in the Using the Editors.
Table 36-3 lists a description for the default transaction classes and the style assignments in each mode. To see how these transaction classes are applied to the data widgets in the sample screen, refer to Figure 36-3.
Figure 36-3 A sample screen with the default transaction classes.
In the sample screen, the default class assignments are as follows:
title_id and actor_id
You can change the class of any widget by editing the Class property.
Accessing Transaction Information | |
When you customize transaction manager behavior, you might need to access various property settings or obtain information about the current transaction. Information is available via:
Several library functions are used by the transaction manager, but two of the functions are provided specifically to obtain information about the current transaction—sm_tm_pinquire and sm_tm_inquire. For example, the name of the current transaction and the root table view of the current transaction are two of the transaction attributes. Some of these attributes can be set by calling the functions sm_tm_pset and sm_tm_iset. For a complete list of the attributes, refer to the functions sm_tm_pinquire and sm_tm_inquire.
Table 36-4 lists the transaction manager variables available for transaction event functions written in JPL.
The following event function performs a "logical" delete on a database row. Instead of physically removing the row from the database, the two slices from the In this example, the customers table view includes a column named In addition to the properties available through the screen editor's Properties window for each object, there are properties associated with the transaction manager which contain information about the current traversal tree. These properties, known as traversal properties, are accessible programmatically using JPL. All transaction manager related properties are readable at runtime, and some of them are settable as long as they are not currently participating in transaction.
The traversal properties provide information about the application (or current transaction), server views, table views, links, and widgets. Some of the properties can apply to more than one object type and return different information depending on what is specified. For example, the property sv, when specified for the application with To use traversal properties effectively, you need to know when a table view is also a server view. A table view is defined as a server view if:
Using Functions to Set Transaction Manager Behavior
Using Transaction Manager Variables
Example of using transaction manager variables
TM_DELETE event, TM_DELETE_DECLARE and TM_DELETE_EXEC, mark the row as deleted so that it can be excluded from selection.
proc logicalDeleteEvent (event)
{
if (event == TM_DELETE_DECLARE)
{
if (@tm_occ < 0)
{
DBMS DECLARE :@tm_save_cursor CURSOR FOR \
UPDATE customers \
SET deleted = 1 \
WHERE cust_id = ::p1
return TM_CHECK
}
}
else if (event == TM_DELETE_EXEC)
{
if (@tm_occ < 0)
{
DBMS WITH CURSOR :@tm_save_cursor \
EXECUTE USING @bi(cust_id)[:@tm_occ]
return TM_CHECK_ONE_ROW
}
}
return TM_PROCEED
}deleted. The column is used to flag the record so that it is excluded from selection. Also, the use of @tm_save_cursor supplies the cursor name, @bi obtains the before image value for cust_id, and @tm_occ supplies the occurrence number.
Using Traversal Properties
@app()->sv, returns the name of the server view participating in the current transaction. When specified for a widget, for example title_id->sv, it returns the name of the server view associated with the widget title_id.
TM_ROOT_NAME). The root property is a screen property and does not necessarily describe an active transaction.
Many of these properties allow you to programmatically iterate through all occurrences of widgets or table views that are participating in the current transaction or all occurrences of widgets belonging to a particular table view. In addition, many properties identify an object (widget, table view, or link) by returning its ID. Panther converts the ID to a string if one is provided; for example, a widget's field number is returned if its Name property has no value.
If a table view or link is not in the current traversal tree, no information is available. If this is specified in a JPL procedure, you receive the message:
Table 36-5 lists application-level traversal properties that are available for identifying, at runtime, the participants associated with the root table view of the current transaction.
The DB Interactions window, accessible via the screen editor, can illustrate how the you can monitor and control the processing of table views and server views via runtime access to properties through JPL.
Figure 36-4 shows the current screen having three server views:
Bad field name, #, or subscript.
Reading the Current Transaction
Figure 36-4 DB Interactions window illustrates the tree of table views, server views, and their links.
rentals, because it is the root table view, and
users and titles, because they each have sequential links to their respective parent table views.
The property In general, to identify the objects in transaction, that is, the objects participating in the traversal tree of the transaction that contain a specified table or server view, you might determine the number of objects in the traversal tree prior to seeking the identity of a particular object.
The following JPL procedure illustrates how, on field entry, to determine to which server view the current field is a member. Given that, the procedure executes the transaction manager If you use server view-specific properties to refer to a table view that is not a server view, no error is reported. Instead, it returns the information for that table view; for example if you use
A widget must be a member of a table view in order to participate in a database transaction in order to get values for its traversal properties. The properties listed in Table 36-7 return the name of the table view to which the widget is a member.
The term server view is defined as the table view containing the specified widget and is considered to be a server view if it is joined to its parent table view by a sequential link. If the table view not a server view, the value returned is the closest table view, in the chain of successive parent table views of the transaction above the specified widget, that is not joined to its parent table view by a server link. (The root table view of the transaction, since it has no parent, is never joined to a parent by a server link. Every widget having membership in a table view in a transaction is a member of some server view.)
Name of server view containing specified widget.
Name of table view containing specified widget.
To identify the link between two table views, use the
There are additional application properties for other aspects of transaction manager operations.
Generate a
In JetNet/Oracle Tuxedo applications, additional application properties are available:
Use the function sm_tm_inquire to determine the current value of
num_svs_below provides the number of server views at and below the specified server view. Therefore, if rentals is specified, the num_svs_below value is 3 and the sv_below property can provide the names of the server views: rentals, users, and titles. If customers is specified, the num_svs_below property value returned is 1 even though customers is part of a server view which has server views below it, customers itself is not a server view and has no children with sequential links. The 1 is returned for the customers table view itself.
Getting and Setting Property Values via JPL
VIEW command for that specific server view.
proc get_sv_query
if K_ENTRY
{
vars value1
value1 = name->sv
call sm_tm_command("VIEW :value1")
}
returnnum_svs_below on a table view that is not a server view, instead of returning the number of server views that participate in the current server view, the value returned is 1 which is derived from the table view itself.
Identifying a Widget's Table View
Table 36-7 Widget traversal properties
Property
Definition
sv
tv
Identifying Links
parent_link property, which identifies the link that connects a specified table view with its parent table view. Once you identify of the link, you can obtain its property definitions.
JPL Properties for Transaction Manager Operations
Table 36-9 Transaction manager application properties
Property
Definition
primary_key_update
SQL UPDATE statement for primary key
changes (instead of a SQL DELETE and INSERT).
Determining How Screen Data Has Changed
TM_OCC_TYPE. The transaction models use the sm_bi_compare function to query for the type of change made to a row or occurrence. The values of TM_OCC_TYPE are:
Processing Errors in the Transaction Manager | |
A transaction manager command is composed of a series of transaction events. If an error occurs while processing an event, the TM_STATUS variable is set to a value other than zero. When the transaction manager completes all the event processing for a command, it then displays an error message.
This section includes information about:
TM_STATUS.
For a listing of common transaction manager errors, refer to page 10-1. For information about how event functions deal with errors, refer to page 32-4.
You can test for the current value of The default processing by the transaction manager sets Generally, the transaction manager sets A transaction model or event function can set the return value unconditionally by calling:
However, the database-specific models set the This sets the Most transaction manager commands are subdivided into three transaction requests:
For example, the VIEW command is divided into three requests: Generally, an error does not prevent the processing of the Consider the processing of the three requests associated with the VIEW command. Normally, each table view processes When an error occurs (setting If there are no events on the stack, then processing continues as if the original event had failed. You can clear the event stack by calling sm_tm_clear_model_events.
If the This is the standard behavior for errors in the transaction manager. You can change this behavior by setting the following variables:
Identifying the Value of the TM_STATUS Variable
TM_STATUS by using the function sm_tm_inquire(TM_STATUS).
TM_STATUS to -1 if there is an error, but you can define other non-zero values for errors if needed.
TM_STATUS to a non-zero value only if its current value is zero. In this way, the value set by the first error is not overwritten by errors in later events.
Setting the Value of TM_STATUS
TM_STATUS can be set to return a certain value in all conditions or only to return that value if its previous value is zero.
sm_tm_iset(TM_STATUS, return_value)
TM_PROPOSE_STATUS parameter:
sm_tm_iset(
TM_PROPOSE_STATUS, return_value)TM_STATUS variable only if the previous value was zero. This prevents a non-zero return value resulting from a previous error from being overridden. The transaction models also use this after calling the function dm_dbms to execute SQL statements. This preserves non-zero values that might have been set by a error handler (if some other non-zero value had not already been set in TM_STATUS).
Event Processing after Errors
TM_PRE_commandName
TM_commandName
TM_POST_commandName
TM_PRE_VIEW, TM_VIEW, and TM_POST_VIEW.
TM_PRE_ and TM_POST_ requests, but does prevent processing of the "main" request. Even if an error occurs in TM_PRE_ or TM_POST_ request processing, it does not interfere with table view traversal. However, traversal for the main request ceases when an error is encountered, and never even begins if an error is encountered in TM_PRE_ processing. Traversal for TM_POST_ processing begins immediately after main processing ceases.
TM_PRE_VIEW. Next, each table view processes TM_VIEW. Then, each table view processes TM_POST_VIEW. If an error is encountered during TM_PRE_VIEW, then processing continues to the TM_POST_VIEW request, but no TM_VIEW processing is done. In particular, this allows TM_POST_VIEW to clean up actions taken by TM_PRE_VIEW. However, if an error is encountered during TM_VIEW processing, the processing immediately switches to TM_POST_VIEW.
Processing the Event Stack
TM_STATUS to a non-zero value), transaction events on the event stack continue to be processed. Since all slices for a request can be pushed onto the stack at the same time, processing for each slice would occur even if there is an error.
Controlling Error Messages
TM_STATUS variable is not zero when sm_tm_command completes its processing of a command, the transaction manager displays an error message. The content of the message indicates the first error that the transaction manager encountered.
TM_EMSG_USED—Controls whether the error message is displayed.
TM_MSG_TEXT—Unconditionally sets error message text.
TM_PROPOSE_MSG_TEXT—Sets error message text only if a message text has not already been set.
TM_MSG—Unconditionally sets the error message number.
TM_PROPOSE_MSG—Sets the error number only if a previous error number was not set.
To set whether the transaction manager error message be displayed, use:
If flag is zero, then sm_tm_command displays an error message. If flag is non-zero, then The most common use of this facility is to disable the transaction manager error message in cases where the error message has already been reported to the user and the transaction manager error message is merely a duplicate.
An example of this could be part of a database error handler as illustrated in the following JPL procedures. The entry procedure is called on screen entry and activates the error handler. The You can specify the text of an error message using the following:
Setting When an error occurs in a transaction event, the transaction manager always sets The transaction models also use this call after calling dm_dbms to execute SQL statements. They thus preserve non-empty values that might have been set by an error handler (if some other non-empty value had not already been set in To change the message displayed for a transaction manager error, you must set these error message variables. The error message variables take precedence over the error number variables.
If no message text has been set by a call to sm_tm_pset or by an error in the transaction manager itself, error message display can be specified by calling:
The Error Message Display
sm_tm_iset(TM_EMSG_USED, flag)
sm_tm_command does not display an error message, even if an error is encountered.
dberror procedure specifies the content of the error handler and tests for a connection error. If a database connection does not exist, the error handler displays the database driver error, but disables the duplicate transaction manager error.
proc entry
DBMS ONERROR JPL dberror
return 0
proc dberror
if @dmretcode == DM_NO_CONNECT
{
call sm_tm_iset(TM_EMSG_USED, 1)
msg emsg "Panther DB: " @dmretcode " " @dmretmsg "%N"\
"Engine Error: " @dmengretcode " " @dmengretmsg}
else
msg emsg "Panther DB Error: " @dmretcode " " \
@dmretmsg "%N"\
"Engine Error: " @dmengretcode " " @dmengretmsg Error Message Content
sm_tm_pset(TM_MSG_TEXT, text)
sm_tm_pset(TM_PROPOSE_MSG_TEXT, text)
TM_MSG_TEXT specifies the content of the message in all conditions. Setting TM_PROPOSE_MSG_TEXT specifies the content of the message only if a message has not already been specified.
TM_PROPOSE_MSG_TEXT which in turn sets TM_MSG_TEXT only if it is empty. It is the value of TM_MSG_TEXT that is displayed when sm_tm_command finishes.
TM_MSG_TEXT).
Error Message Numbers
sm_tm_iset(TM_MSG, msg_nbr)
sm_tm_iset(TM_PROPOSE_MSG, msg_nbr)
msg_nbr parameter would correspond to a message number defined in a message file.
TM_MSG sets the message number in all conditions.
The text of associated with error messages can be defined in a message file.
Refer to page 45-2 for details on how to create a message file for your application.
To suppress transaction manager messages, set:
in a customized transaction model, in the database error handler, or in an event function. If flag is set to a non-zero value, the transaction manager does not display an error message.
Suppress Error Messages
sm_tm_iset
(TM_EMSG_USED, flag)