Copyright © Cloud Software Group, Inc. All Rights Reserved

Conversions

Conversion of Record and Element Names

The conversions that take place when loading CA‑IDMS subschema definitions into TIBCO Object Service Broker are as follows:

•	Element names are truncated to 16 characters.

•	Hyphens in element names are changed to underscores.

•	A sequence number is appended to element names of FILLER to make the element names within a record unique. For example, in the case of FILLER_33, FILLER is the 33rd element in the record.

•	Group names are not stored in the TIBCO Object Service Broker control tables.

•

OCCURS and OCCURS DEPENDING ON are supported up to a maximum of 8999 occurrences. Since occurring fields are not part of a relational database structure, a prefix is added to each field occurrence. For example, if the element AMOUNT occurs three times, the TIBCO Object Service Broker definition is I001_AMOUNT, I002_AMOUNT, and I003_AMOUNT.

•	Redefined elements are stored in the TIBCO Object Service Broker control tables.

Conversion of Data Types

The following table shows the default mapping of CA‑IDMS data types to TIBCO Object Service Broker data types. This mapping is imposed by the Table Definer. When CA‑IDMS data is modified by a TIBCO Object Service Broker transaction, it is converted back to its original data type before being sent to CA‑IDMS.

CA‑IDMS Data Type	External Syntax	TIBCO Object Service Broker Syntax	TIBCO Object Service Broker Length
CHARACTER	C	C	Same
ALPHABETIC	A	C	Same
ZONED NUMERIC UNSIGNED (length=4)	M	B	2
ZONED NUMERIC UNSIGNED (length=8)	M	B	4
ZONED NUMERIC UNSIGNED (length=9)	M	B	4
ZONED NUMERIC UNSIGNED (length not=4, 8, or 9)	M	P	Absolute value of (length/2 + 1)
ZONED NUMERIC SIGNED	N	P	length/2+1
PACKED NUMERIC UNSIGNED	U	P	Same
PACKED NUMERIC SIGNED	P	P	Same
BINARY (2, 4, 8) UNSIGNED	K	P	3, 5, 8 1
BINARY (2, 4, 8) SIGNED	B	P	3, 5, 8 a
BIT	X	Not supported
FLOATING POINT	F	F	Same

---

1

If there are more than 31 significant digits in the field, you must assign the field syntax C and equivalent length.

Providing Default Database Names for Users

If a user always accesses data from a specific physical database, you can assign a default database name to the user for each subschema they require.

To assign a default database name to the user for each subschema, edit the @IDMSDBNAME(subschema) table, adding the user ID in the USERID field and the database name in the DBNAME field.

@IDMSDBNAME Table for the EMPSS01 Subschema

---

 

EDITING TABLE : @IDMSDBNAME(EMPSS01)

COMMAND ==>

SCROLL: P

USERID DBNAME

_ -------- --------

_ DGF40 WEST

_ SHR10 EAST

_ USR40 SOUTH

_ USR90 NORTH

PFKEYS: 4=INSERT 16=DELETE 5=FIND NEXT 6=CHG NEXT 18=EXCLUDE 3=SAVE 12=CANCEL

---

 

If a database name is specified in the Table Definer DBNAME field and the DBNAME field of the @IDMSDBNAME(subschema) table, the entry in @IDMSDBNAME is used when any of the user IDs specified in this table access CA‑IDMS data using the IDM table definition. The @IDMSDBNAME table enables specific users to access different physical databases using the same IDM table definition. You use the default security to access and update this table. If necessary, ensure that users who should not modify this table have the proper security restrictions.

Binding IDM Table Definitions

You can bind an IDM table definition, but not its data. IDM tables for which you request binding are bound to both the Execution Environment and the Gateway when they are accessed from a rule. If you change a definition, it is automatically rebound in the Service Gateway for IDMS/DB.

You can specify the maximum amount of space available to hold all IDM table definitions using the POOLSIZE startup parameter. Refer to Supplying Service Gateway for IDMS/DB Startup Parameters for more information.

See Also

TIBCO Object Service Broker Managing Security for more information on security access levels. See TIBCO Object Service Broker Application Administion for information on binding tables.

Copyright © Cloud Software Group, Inc. All Rights Reserved