Frequently Asked Questions

How are Generation Data Groups handled?

Arbutus Analyzer defines Generation Data Groups exactly the same as any other data source. The specific generation that is exposed to the end-users can be specified using either the absolute or relative generation number, and symbolic substitution (called macro substitution in the Arbutus products) is available to override the generation number as needed.

All data sets in a Generation Data Group can be exposed by omitting the generation number.

Arbutus Analyzer and LegacyLink™ treat data sets stored on tape as just another data set. As long as the tape data set is catalogued, and mounted, the end-user will not notice that the data came from a tape versus DASD.

How are uncatalogued data sets handled?

Uncatalogued data sets are generally not “visible” to Arbutus Analyzer or LegacyLink™ ad hoc processes. Uncatalogued data sets can be made available by allocating them in the session JCL and accessing them based on a DDNAME.

How are multiple volume data sets handled?

Data sets that span multiple DASD or tape volumes are treated as any other data set. The end-user may experience a delay if multiple tape volumes must be mounted to satisfy a data request.

How are COBOL Level 88 definitions handled?

The Arbutus Analyzer Data Definition Wizard will convert COBOL Level 88 type fields accurately as Arbutus COMPUTED fields. The following are examples of the conversions that will be performed for various Level 88 definitions:

How are COBOL Redefinitions handled?

The Arbutus Analyzer Data Definition Wizard is able to interpret COBOL redefinitions in several ways: If there are redefinitions within a copybook that contains only one level 01, the Wizard will interpret them correctly. If there are multiple 01 levels within the copybook, you are given the choice of how to handle the redefinitions: you can append them together, in the case of a very long record, you can use them to redefine multiple record type fields, or you can ignore them.

How are COBOL Occurs clauses handled?

Arbutus will resolve the first occurrence of the structure and then flag the offset amount so subsequent occurrences may be easily viewed using an array expression.

How are COBOL Occurs Depending On clauses handled?

Arbutus will resolve the first occurrence of the structure and then flag the offset amount so subsequent occurrences may be easily viewed using an array expression but the DEPENDING ON clauses must be interpreted using Arbutus Analyzer logic. This logic can be put in stored procedures so it can be rerun as needed.

Is there any restriction on the size of data set that can be processed?

Arbutus will read any file size that is acceptable to the operating system being accessed.

Does your product work on both OS/390 and Z/OS?

Yes. In fact, the Arbutus Mainframe data engine is operating system independent.

What if the LegacyLink™ driver doesn't appear on my list of drivers?

This would indicate that LegacyLink™ wasn't installed properly. Check the directory where LegacyLink™ was installed and ensure that Legacy.dll, LegacySetup.dll and ASIRes.dll are all present.

How do I configure LegacyLink™ to point at my metadata?

Use the Administrative Tools area within the Control Panel. Double-click Data Sources (ODBC), then select the System DSN tab. You should see the Arbutus LegacyLink™ driver; highlight it and click the Configure button. In the Arbutus Analyser Project area, specify the directory of the ASI file that points to your metadata.

Can LegacyLink™ read data from multiple tables?

Absolutely. You can either join two files together using Analyzer to create one table layout or you can define a relation between multiple tables and create a computed field that references fields of interest from the related file(s).

What is a computed field?

A computed field is a virtual field used for definition purposes. Computed fields don't contain any physical data but can be used to reference physical data or mask that data.

What are Data Relations and how do you create them?

Data Relations are a mechanism used by Arbutus to link tables together logically, rather than physically, based upon a common field(s). Data Relations are an efficient alternative to joining physical files together. By relating tables together and creating computed fields to reference fields from the "child" files, data from multiple tables can be easily exposed to end-users without proliferating your data.