ODBC Driver for RM/Cobol files (Relativity ONLY ?)

[Cosmark]

I have been asked by a company which uses software developed in the early 80's in RM Cobol and still uses the system in its original black-and-white form to "bring their system to the new century".

I am very seriously considering recommending and going ahead with Relativity by Liant (in order to use MS Access and other Microsoft programs) but after reading previous comments in this forum about this product I am wondering whether there are any other products in the market today to consider.

Your opinion on this or any other similar product will be greatly appreciated.

Best regards

Cosmark

 

[rgh]

Cosmark,

Is there any reason why you need to keep the Cobol data files?

When you say "bring their system to the new century", do you mean let them still use the Cobol data capture screens and let them use Access etc. to access the data for reporting etc. or are you planning a complete re-write of their system using the original cobol files to store the data.

Richard.

 

[Cosmark]

Thanks for your response Richard. Well, the company, a small, producing company, computerised their operations (Accounting, Payroll, Stock control etc.) back in the early 80's and apart from intervention for the 2YK problem they have done very little since.

They have looked at various enterprise solutions, such as the SAP, but the cost and the anticipated interruption was prohibitive. What they want, if possible, is to maintain for as long as they can their present arrangement but with enhanced functionality as offered by new programs such as the MS suite (Access, Excel, PowerPoint etc.) away from the blank-and-wide format. To "bring the system to the new century" is their expression.

What I will suggest to them is keeping the Cobol Files to store the data but through ODBC and tools like Relativity they can use BOTH RM Cobol and MS Access to manipulate the data (view/read/write) with more functionality (reports etc.), if this is at all possible. They do not have in-house support for RM Cobol (they rely on outside Software houses for support, which is expensive) but they have in-house knowledge in database design and development in MS Access.

My involvement will be to assist in the development of the Stock Control (my area of expertise) module in MS Access using (linking to) the RM Cobol files in real-time. Fair to say I know little about Relativity apart from what Liant say.

I hope this gives you the scope of work. Your advice on what is available in the area of ODBC, including Relativity will be appreciated.

Thanks again,

Cosmark

 

[rgh]

Cosmark,

Unfortunately if the company's approach is as you have described then Relativiy is your only hope.

Overall Relativity does the job that you want it to do, just do not push it, and do not expect implementing it to be the easiest thing you have ever done.

That should be enough to keep you going. If yo have any further queries let me know.

Richard.

 

[k5tm]

Cosmark, from your description I think Relativity will do the job you want. You will need the file descriptions and COBOL (not SQL!) SELECT statements used in the application; it is unclear from your description whether your client has access to these.

Richard has raised some issues to which I can add some technical information.

1. I assume here that Richard is discussing data items containing, or subordinate to, OCCURS clause. As an example assume a very simple example:

01  record-name.
    02  key-item   pic x(10).
    02  fixed-part-of-record.
        03  first-name   pic x(20).
        03  last-name    pic x(20).
    02  monthly-payment-history occurs 12.
        03  beginning-balance pic s9(12)v9(4).
        03  payments-applied  pic s9(12)v9(4).
        03  ending-balance    pic s9(12)v9(4).

I think Richard is implying that he would define 36 columns to cover the data within monthly-payment-history (informally called spreading a table). However, this does not produce a very good relational data model. It would be better to produce 12 rows, with three columns. In fact, Relativity's preferred mode of operation would be to produce 12 rows (informally called unrolling a table) with a column for beginning-balance, payments-applied, ending-balance, AND another column based upon the occurance number implied by the definition -- four columns in all.

This is not a thorough example. Relativity will allow either model (unrolled or spread), and has tools in the Designer to easily accomplish either.

2. Relativity handles NULL (in the SQL sense) quite well. Perhaps Richard is writing of the inability of MS Access to deal with ASCII NUL characters (binary zero) in fields that it expects to contain character data. I speculate that this is due to the fact that the C programming language treats a binary zero character as the termination of a character string. This flaw of MS Access is not seen in other packages; however, it is probably true that one should not expect ODBC-enabled reporting tools to understand character fields containing LOW-VALUES...

3. Relativity is a forward-only driver. Relativity is not slow in general.

4. ODBC specifies an SQL grammar and divides it into segments: minimum, core and extended. Relativity implements all of minimum (an absolute requirement of any ODBC driver), and most of core and extended. I am not aware of which SQL standard Richard is using as "the" full SQL language; most of the "industrial strength" database products have several extensions that are not specified in the ODBC standard, which is a subset of the ISO SQL-92 standard.

5. Joins are constrained by the keys available in the files. Poorly constructed joins can cause any database to slow to a crawl.

6. This is true. Multiple record types are a fact of life in most COBOL applications. The relational model does not have an analog (multiple row types?!). The most straightforward way of dealing with this reality without imposing some really stupid data model on the SQL user is to define a table for each record type.

7. I consider two different types of redefinition: macro and micro. See 6 above (multiple record types) for large scale, multiple record type redefinition. I consider the micro redefinition to be where one field in a record is used for two purposes depending on a flag somewhere else in the record. For example, suppose a pic 9(5)v9(4) field is used as either a percentage discount or an absolute amount discount, depending on another field's value (the flag field). In my opinion, it is best to set this up as two columns in the table (i.e. PercentDiscount and AmountDiscount), and use the flag field's value to cause an SQL NULL to be returned in one or both of the columns. The SQL data model here is not distorted.

8. Client-Server works quite well. I think that Richard's 9th comment probably ties to this issue, since he clearly had two years of frustration, without any success to show for it. Client-Server is appropriate to reduce network traffic: send a query to the server and receive back a set of rows. Client-Server does imply a bit more administrative work. I would ask Richard to email rm_support@liant.com, with a specific request to forward to me, including such information as server platform, Relativity version number, problem, etc., as well as a brief description of his communications over the two years, so that I can correct this matter if at all possible.

9. Liant support is an email away (see above or our web site). I do not minimize the difficulties that Richard has apparently had getting appropriate support, but I will claim that it is not typical (I get involved with most of the 'tough ones' on the Relativity product, and I am not familiar with his problem). Liant also has a CEO who takes customer feedback quite seriously.

Tom Morrison
Liant Software Corporation

http://www.liant.com

 

[Shiver]

Hi Cosmark,

I am kind of suprised by Richards replies. We have been using Relativity for a number of years, currently on version 3.24 and soon to version 4.X. Although some of the issues Richard mentions date back to the first releases of Relativity I do not think they are true any more.

In regards to the issues of arrays, redefinitions and multiple record definitions it is a matter of finding the best solution to meet your needs as the relational model does not support these structures. We have been working with big arrays and multiple record definitions and we are satisfied with the performance.

In the issues of speed I think it boils down to a good design of the COBOL files (primary and alternate keys) as these will dictate the performance of your ODBC driven queries. Do not expect Relativity to "fix" a bad COBOL file design because it will not. We found that in certain instances by adding an alternate key to the COBOL file we increased the performance of the queries by many orders as Relativity hounours the keys for a well constructed query.

In regards to NULLS Tom Morrison reply gives the stigma.

Regards,

Spyros

 

[Shiver]

Please also let me add to the above the issue of support. I have been doing business with LIANT for over a decade and I am abolutely satisfied with the response times and level of knowledge by the UK and US people.

They have always been supportive and have resolved all of my questions and problems.

Regards,

Spyros