Support for SMA-standard B-correlatives
Paddy
We are not yet QM users but are interested in finding out more.
My primary concern in a conversion would beour 100 or so B-
correlatives which are written in SMA-standard style (as a B-
correlative, not a SUBR). I have been told that you only support
SUBRs.
1) Is that true?
2) If so, do you have any plans for supporting B-correlatives in the
near future?
3) Does anyone else out there share this problem?
4) Do you realize that B-correlatives can be used as conversions as
well as correlatives, thus are callable on the BREAK line and allow
manipulations for averaging, percentages of one column against
another, and much, much, more, which SUBRs do not?
5) Do you realize they can be called within F- and A-correlatives as
conversions?
6) Do you realize that other database vendors support both types: B-
correlatives and SUBRs?
7) Is there support out there for the idea of supporting both?
8) Maybe those who would need them have already decided against
converting due to being discouraged at the prospects of the financial
and temporal impracticality of such a conversion. Is anyone out there
aware of such companies?
It would take at least a year, maybe more, to convert all of our B-
correlatives and not having them would destroy much of our reporting
capability on my software offering. We have other things that need
doing besides just working on B-correlatives.
From what I have heard about QM, I would dearly like us to climb on
the bandwagon but the conversion would virtually eliminate any chance
of keeping business going. We are a small company and need to grow
and do not have the resources to spend a lot of time in a conversion
like this. Support for SMA-style B-correlatives could make conversion
to QM a possibility for us.
Sincerely,
John P. Racine, BA, PMP, MBA
President and CEO
Racine Enterprises Inc.
Home of Purveyor Software and the BuildingBlocks4GL/RAD Tools
207 E. Water St. #203
Centreville, MD 21617
(301) 661-6011 (M)
(410) 758-6793 (H)
j...@purveyorsoftware.com
http://www.purveyorsoftware.com
http://examples.purveyorsoftware.com
Martin Phillips
Firstly, please do not post multiple copies of the same question. You seem
to have posted this four times.
> My primary concern in a conversion would beour 100 or so B-
> correlatives which are written in SMA-standard style (as a B-
> correlative, not a SUBR). I have been told that you only
> support SUBRs.
>
> 1) Is that true?
>
> 2) If so, do you have any plans for supporting B-correlatives in the
> near future?
QM is based on the "Information style" model but has options for closer
compatibility with Pick style systems. There is basic support for
correlatives but we do not provide everything that is found in Pick systems
as much of this can be better implemented using alternative constructs that
have evolved over the years.
B-correlatives are not supported by QM. As far as I can see, they are also
not supported by the U2 products which are reported to be the current market
leading multivalue database environments.
This is not to say that we would not consider implementing B-correlatives if
there was a good case to do it.
My current thoughts are that our triggers provide everything that can be
done by a B-correlative and much more.
> 3) Does anyone else out there share this problem?
None of our existing users has raised this issue before. Indeed, until your
posting today, we had never heard of B-correlatives. We have tracked down
some documentation and it appears that this construct is only relevant to
the Pick Update Processor.
QM is not a clone of any other system and never will be. We do not have the
Update Processor in its Pick form and hence B-correlatives probably do not
fit into the QM model.
The Pick Systems Reference Manual appears to have a slightly different
description of B-correlatives, suggesting that they can be used to define
the link between two files without the Update Processor involvement. In this
situation, take a look at our L-type records that define the relationship
between files and, in the extreme, can totally remove the need for
T-conversions or TRANS() functions.
> 4) Do you realize that B-correlatives can be used as conversions
> as well as correlatives, thus are callable on the BREAK line and
> allow manipulations for averaging, percentages of one column
> against another, and much, much, more, which SUBRs do not?
I would be interested to see some examples of this so that we can determine
whether there is a need for a new mechanism in QM. I-type expressions almost
certainly provide this.
> 5) Do you realize they can be called within F- and A-correlatives as
> conversions?
Again, use of triggers would seem to remove the problem.
> 6) Do you realize that other database vendors support both types: B-
> correlatives and SUBRs?
Some but not all. The multivalue products fall into two distinct groups;
Information style and Pick style. I will probably stir up a lot of comments
from this but our view is that Pick style systems have largely not moved
forwards but have retained constructs that are akin to assembler programming
whereas Information style products had taken advantage of new technologies
and moved forwards. You reference use of SUBRs but our preference would be
for use of I-type dictionary records.
Since QM was released as a commercial product in 2001, we have received many
comments regarding the model followed by QM. Some of these have been from
Pick users who have reluctantly moved forwards to the world of D/I type
dictionary records, paragraphs instead of Procs, etc and eventually become
strong supporters of the QM model. We support A/S dictionary items and Procs
only to ease migration, strongly recommending that developers then slowly
move to the newer technologies after the initial migration is complete.
> 7) Is there support out there for the idea of supporting both?
Yours is the first request and I suspect that there are better ways to do
it. We wil lwatch for other responses in this thread.
> 8) Maybe those who would need them have already decided against
> converting due to being discouraged at the prospects of the financial
> and temporal impracticality of such a conversion. Is anyone out there
> aware of such companies?
We are not aware of any. In addition, there is no point in migrating if all
you are looking for is a clone of your current system. Migration should be
considered as an opportunity to move forwards. It will always require some
changes but no one has ever suggested to us that the costs are an issue.
> It would take at least a year, maybe more, to convert all of our B-
> correlatives and not having them would destroy much of our reporting
> capability on my software offering. We have other things that need
> doing besides just working on B-correlatives.
Would it really take a year? Based on your "100 or so", that's a couple of
days each. I find that hard to believe. A trigger routine to perform the
equivalent of a B-correlative as described in the documentation we have
found should take no more than a few minutes to write. Furthermore, you
probably have the same B-correlative action defined in several places
whereas a trigger is a one-off description of the action to be performed
that affects every access to the file.
> From what I have heard about QM, I would dearly like us to climb
> on the bandwagon but the conversion would virtually eliminate any
> chance of keeping business going. We are a small company and
> need to grow and do not have the resources to spend a lot of time
> in a conversion like this. Support for SMA-style B-correlatives could
> make conversion to QM a possibility for us.
I think that you need to take a closer look at alternative solutions to your
problem that already exist within QM. No migration is ever totally painless
but the gains once you have completed it can be enormous.
One of the other things that we have done to make it easier to migrate
whilst still developing within your existing environment is that we have
produced a simple pre-processor that adds support in D3 (etc) for the
conditional compilation constructs found in the newer multivalue products.
It is thus possible to maintain a single source stream that contains both
the D3 and QM variants of the application, removing the horrors of divergent
sources.
Please let us take this forward to ensure that QM is the right path for you.
I believe that we probably already have an alternative to the B-correlative.
If you disagree, please provide some more detail of how you use them.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
p...@asent.com
I believe you are correct in your interpretation of the D3 "B
correlative" being used by the Update processor. It actually sounds
like it may be invoked for all file updates, making it similar to QM's
triggers.
I think John is inquiring about the "B correlative" as implemented on
mvBase, which is a BASIC CALL from a dictionary. I actually did the
initial implementation of this for General Automation and can send you
my original documentation. This is similar to QM's SUBR() function. I
don't see that there would be much difficulty converting from the
mvBase B correlative to the SUBR() function in an I-type, except for
two things: First, there are two B forms: B;sub and B:sub. The 2nd
form cannot be embedded in an A or F correlative and is called with
the current attribute containing all its values and sub-values. The
first form (B;) is called a value at a time, like other Pick-style
conversions. This form can be embedded in an A or F correlative and
can perform different processing on break lines than on detail lines
(the NB$ variable indicates the break level).
As far as I know, the only remaing implementation of the BASIC CALL B-
correlative is mvBase. Historically, it was available on ADDS Mentor,
GA, Fujitsu and Altos implementations.
Hope this helps.
Thanks,
Peter Schellenbach
AccuSoft Enterprises
Martin Phillips
> I think John is inquiring about the "B correlative" as implemented on
> mvBase, which is a BASIC CALL from a dictionary. I actually did the
> initial implementation of this for General Automation and can send you
> my original documentation.
This would be much appreciated.
Thanks.
Kevin Powick
> I think John is inquiring about the "B correlative" as implemented on
> mvBase, which is a BASIC CALL from a dictionary.
processing code. Can be found on page 806 of the D3 7.5 ref manual
(PDF).
--
Kevin Powick
CDMI - Steve T
PO Box 13403
Maumelle, AR 72113
(501) 803-0974 09:00am - 6:00pm CST
Martin Phillips
Paddy
well-documented in all three manual sets and well-used.
Paddy
Having worked many years on both Information style and Pick style
systems I can concur with you that my tools are geared more toward the
Pick side than the Information side. Many do, however, work for both
and almost all could work for both with simple modifications. Because
I wrote them all using code snippets that point to particular
libraries of implementation-specific Basic, Access, TCL, etc.
commands, I can simply throw a switch in the Master dictionary and
recompile and most things will work for almost any implementation.
The big exception has always been the B-correlatives, which are almost
entirely an issue with my Purveyor Software ERP/MRP vertical
application and almost irrelevant with my BuildingBlocks4GL/RAD Tools
horizontals.
B-correlatives are called on each value and subvalue, which is
appropriate for Pick-style systems, given them being well integrated
with their types of conversions and correlatives. I have always known
that compiled I-types are more efficient but run time, even on the
very large systems I've worked on, was never a very big issue for
Access reports and cutting a few minutes off them at the expense of
functionality never seemed to make that much sense to me or the people
for whom I have worked. Saving a few minutes on a report that runs
for hours (back then) anyway or a few seconds on a report today that
runs in a few minutes, didn't seem significant, especially if such
reports ran overnight anyway.
B-correlatives serve the same function as SUBRs in dictionary items.
They provide an interface for accessing Basic functionality from data
dictionary items. They are called like:
DICT1
001 S
002 5
003
004
005
006
007 B;SUBCALL
008
009 L
010 10
or
DICT2
001 S
002 5
003
004
005
006
007
008 B;SUBCALL
009 L
010 10
or
DICT3
001 S
002 5
003
004
005
006
007
008 B:SUBCALL
009 L
010 10
In DICT1, it is specified as a conversion and will be called on detail
lines on the BREAK-ON line and total line, too. (The SEMICOLON ;
indicated that it will be called again and again on each value and
subvalue. If this was ever an issue performance-wise, even on the
older, slower systems, I never heard about it and I have seen hundreds
of companies use them).
In DICT2, it is specified as a correlative and will be called only on
the detail lines. (Again, the SEMICOLON ; ...)
In DICT3, it is specified as a correlative and emulates SUBRs in prime
Information and will not be called on the BREAK-ON line or the total.
(The COLON : indicates it should be run as a SUBR- called once per
attribute and returning an array.
For those putting performance over functionality, the PRIME style
would still be there. For those needing the functionality over the
performance, the Pick style would be there. In my experience, given
the choice on these systems where both methods have been available,
the functionality have always been chosen over the performance.
Anyway, both would then be available to your users and to people
wanting to port their system over to yours.
When used as DICT1 and DICT2, such counters as NI, ND, NB are
available, as are standard commons which are available to pass
information from on dictionary to another, useful more before NAMED
COMMONS came along. NAMED COMMONS can also be used in them. The NI,
ND, and NB are useful for computer information for the BREAK-ON and
total lines in a very customizable fashion.
Maybe the L-type link records serve that purpose; I don't know. I
haven't heard of them. B-correlatives have been around for 18 years
and have been supported on Pick, ADDS, mvBase, Sequoia, mvEnterprise,
and Ultimate, that I know of first hand. There is really very little
difference in implementation of these across those platforms and it is
a very important capability as you well understand from your doubtless
use of SUBRs. I am proficient in the use of SUBRs and I-types and
know all too well what goes into moving one to the other. We did this
at MAMSI moving from Sequoia to universe and it was the biggest
conversion issue. It took about 15 programmers over 6 months to do
the conversion, largely because these needed to be converted. Many
were left at the wayside and users and department head were told that
they would just have to do without some of their reports. The chore
was either impossible or too daunting, though, over the following
years a few were worked back in. This, despite the fact that Universe
does support F- and A- correlatives.
As for the documentation for the SFORMS, I do not feel free to e-mail
you the appropriate documentatation but it is open to the public on
the TigerLogic/RainingData website in both the mvBase manuals and the
mvEnterprise manuals. On mvBase, it is called SFORMS/SREPT, while on
mvEnterprise it is called "SORT/LIST @(X,Y):DICT " under Access
Reports.
Here are the manual numbers and page numbers:
mvBase
http://www.rainingdata.com/support/documentation/mvb/20/ReferenceManual/Access.pdf
Chapter 7, the whole chapter.
mvEnterprise
http://www.rainingdata.com/support/documentation/mve/manual/08access.pdf
Chapter 8, Section 4, Access Reports
Likewise,
B-correlatives can be found at:
D3:
(On D3 it is called "call basic.program.name" instead of
"B;basic.program.name" but it is still the same type of correlative/
conversion
http://www.rainingdata.com/support/documentation/d3nt/75/refman/index.htm
under "Processing Codes>call Processing Code"
mvBase
http://www.rainingdata.com/support/documentation/mvb/20/ReferenceManual/Access.pdf
Chapter 9, B code
mvEnterprise
http://www.rainingdata.com/support/documentation/mve/manual/08access.pdf
Chapter 9, B code: Basic Subroutine Call
The forms generation software is something we would have liked to have
at MAMSI, on UniVerse, very much because we achieved only a very
contrived and simplified approach at this with considerable difficulty
using very crude and time-consuming approaches to printing on top of
"background" items such as scanned forms.
Also, for many printed forms such as invoices, purchase orders, and
checks, it can provide a powerful and easily maintained reporting
interface, regardless of the use of "background" items or not.
Again, I appreciate the time you have taken to consider these issues
and ideas and also for taking the time to look at my website. It will
not be forgotten.
On 10 Jun, 12:59, "Martin Phillips" <martinphill...@ladybridge.com>
wrote: