Skip to content

Troubleshooting

In This Appendix

This appendix explains general troubleshooting procedures and tells you how to contact Micro Focus Technical Support.

General Troubleshooting Procedures

If you have problems running Databridge, complete the following steps:

  1. Check to see that your system meets the minimum hardware and software requirements necessary to use the product. Refer to the Databridge Host Administrator's Guide for information.
  2. Check your configuration options. Most problems are caused by an incorrect configuration.
  3. Check the usercodes for your DMSII databases and the usercode for the Databridge files. Make sure the Databridge software can access the DMSII DESCRIPTION, CONTROL, DMSUPPORT, and audit files.
  4. Check parameter file options for the Databridge Accessory you are using. Make sure all tailored support library transforms, filters, and formats are also entered into the DBGenFormat parameter file and are spelled correctly.
  5. Check your system. You may be using peripheral equipment or other software that may not be compatible with this product.
  6. Resolve errors. Refer to the Databridge Errors and Messages Guide for information on resolving error messages.
  7. If you cannot identify and solve the problem without assistance, contact your product distributor. Call from a location where you have access to the problem.

  8. Troubleshoot the problem using information available from Micro Focus Technical Support.

    This service directly links you to our internal help desk system, 24hours a day, 7 days a week. 9. Contact Micro Focus Technical Support.

Troubleshooting for All Accessories

Following are two common things to check for in all Accessories:

  • If an Accessory cannot find DBEngine, most likely the Accessory is running under a different usercode than where DBEngine is located. If this is unavoidable, use the ODTSL command to define the DBENGINE function name, as follows (assuming DBEngine is located under the DBA usercode on a pack called DBAPACK):

    SL DBENGINE = (DBA)OBJECT/DATABRIDGE/ENGINE ON DBAPACK

  • If an Accessory displays a message indicating a version mismatch and then terminates, most likely the Databridge software you are running was compiled using different versions of the Databridge API (SYMBOL/DATABRIDGE/INTERFACE). Make sure that all of the Databridge software is from the same release.

Outdated Filters and Formats

When a filter or format is out-of-date, Databridge Accessories attempt to recompile the DBSupport library. If that is unsuccessful, the Accessory displays an error message informing you that the support library must be recompiled. Use WFL/DATABRIDGE/COMP to recompile a tailored support library.

Troubleshooting External Filters and Formatting Procedures

If an external filtering or formatting procedure is unable to retrieve the correct structure indexes or data set information, and so on, be sure that it is not linking to a different copy of DBEngine than the Accessory. The external library must link to the same copy of DBEngine as the Accessory. The most common cause of linking to the wrong copy of DBEngine is invoking DBLINKENGINE or calling an entry point before the external library performs a FREEZE.

DBEngine is shared-by-run-unit, which means that the Accessory and any libraries it calls share a copy of DBEngine. Until the external library performs a FREEZE, it is considered a separate running program rather than a library, and it gets its own copy of DBEngine if it links to it either implicitly or explicitly.

The most common solution is to declare a flag that indicates whether the external library needs to perform its initialization. The first statement of the filtering or formatting procedure tests the flag and performs the initialization routine if it has not been executed yet.

Troubleshooting Virtual Data Set Transform Procedures

A common problem when creating virtual data sets is that data set record updates or STATE_INFO updates are missing because the virtual data set transform procedure ignores records that do not pertain to the virtual data set. The virtual data set transform procedure must call the formatting procedure passed to it as a parameter (usually BINARYFORMAT) for all records it receives, not just those related to the virtual data set.

Another potential problem is that data set record updates are corrupted. This could happen for either of the following reasons:

  • The virtual data set transform procedure neglected to update the UPDATE_INFO with new values for the structure number, record type, record size, and structure index when it builds a record for the virtual data set. The UPDATE_INFO must contain the attributes of the virtual data set record.

  • After sending a virtual data set record, the virtual data set transform procedure tried to send the original (real) data set record without first restoring the original UPDATE_INFO.

DMSII Reorganizations

The following table indicates changes you might need to make if any of the source data sets for your virtual data set were affected by a DMSII reorganization:

If Then
Your virtual data set transform routine calls a COBOL library to create the data for your virtual data set Recompile the COBOL library.
Any of your source data sets for the virtual data set increased in size If you are calling a COBOL library, make sure that your COBOL program's Working-Storage variable is still large enough to accept the record images passed to it by the TRANSFORM routine.

If the COBOL library uses DMSII user work areas (data set 01s), recompile the COBOL library to get the new layouts.

For ALGOL routines, increase the size of the array holding the record images or dynamically resize the array based on the UI_RECSZ_WORDS value in the UPDATE_INFO.
The Accessory faults (F-DS) with a SEG ARRAY ERROR Take the actions previously described for source data sets that increase in size.

Troubleshooting Reformatting Procedures

One kind of error associated with reformatting procedures is SEG ARRAY ERROR, which can be caused by using the offset values (SourceOfs and DestOfs) as byte offsets. These values are always digit (half-byte) offsets. Likewise, the size values (SourceSz and DestSz) are always in units of digits, not bytes.

For clarity, use the following defines from the sample in your reformatting procedure to distinguish 4-bit values from 8-bit:

SourceSz4
SourceSz8
DestSz4
DestSz8
SourceOfs4
SourceOfs8
DestOfs4
DestOfs8

Use the items ending in 4 with the arrays Source4 and Dest4. Use those ending in 8 with the arrays Source8 and Dest8.

Do not assume the destination area is initialized to any particular value. The reformatting procedure is responsible for the entire contents of the destination, starting at DestOfs for a length of DestSz digits.

When reformatting an OCCURing item, the reformatting procedure receives a SourceSz reflecting the total length of all occurrences. It must reformat all of the occurrences at once.