At 01:35 AM 10/10/95 GMT, Doug Myers wrote:
<PLUG>
STOP! call M.B. Foster Associates at 1-800-ANSWERS and ask about DataExpress
with ODBCLink
 
You really also wanted MPE file support as well! Well didn't you?
 
ok, read on if you must
</PLUG>
 
>James Herod ([log in to unmask]) wrote:
>: In article <[log in to unmask]>,
>: Leslie-Anne Bain <[log in to unmask]> wrote:
>:
>: >PHASE I  - "Connectivity"
>: >
>: >           o Establish SQL connectivity links
>: >
>: >           o Provide Read Access
>: >
>: >           o Treat KSAM files like non-indexed MPE files.  In other words,
>: >          use sequential scans to access information (however, for KSAM
>: >          files our goal is to scan in primary key sequence as the
>: >          default).
>: >
>: >           o Only support access to NM KSAM files (not CM).
>
>: FREAD *automatically* reads a KSAM file by its primary key.  You have
>: to use FREADC to force a chronological scan of a KSAM file.  Please don't
>: foist FREADC off on us as the default!  About read access only:  What's
>: so difficult about coding calls to FWRITE, FUPDATE & FDELETE?
 
M.B. Foster Associates agrees with you!
While there are a number of implementation problems with supporting
modifications to KSAM files, we agree with James(?) that this should be part
of the basic functionality of the product.  When we delivered KSAM support
(prior to Interex95) in ODBCLink, we included the obviously necessary key
support and modification abilities.  We did force our users to add the key
descriptions into the dictionaries (either PDL or our own simple DXFDGEN
dictionary) while they were describing the layout of the files.
 
>
>: FCOPY already understands how NM & CM KSAM files work.  I suggest that
>: the designers take a look at this legendary legacy HP3000 tool.
 
In HP's defence, I am sure that they know how to code to the two targets.
It is often very impractical to incorporate functionality from one product
into another.  They are often developed at radically different points in
time using incompatible tools and techniques.  Cut and Past works best for
children under 4yrs who don't notice or care about the stuff that oozes out
around the edges.  Well, it also works in Windows (deep thought eh!).  ;=)
 
>
>: >PHASE II - "Performance"
>: >
>: >           o Register KSAM keys into the SQL system catalog.
>
>: This needs to be in "Phase I", since it produces a crippled product
>: right from the start.  Why would you NOT want to give customers a
>: product with a reasonable feature set?  FCOPY also knows how to get
>: KSAM key info.  Code reuse will make your project much simpler
>: to accomplish.
>
>: >FUTURE   - "Provide Write Access"
>
>: See above.
>
>[snip]
>
>: Don't sacrifice your customers that are using CM KSAM because of CM appl-
>: ications that are impossible or inconvenient to migrate to NM (missing or
>: lost source code), or are third-party apps for which the customer doesn't
>: have access to the code.
>
>: --Jim
>
>In other words, Jim, you want it all.  And I understand that it is all
>important.  And I appreciate your comments.  But lets keep in mind that
>additional functionality requires additional development time.  Would you
>rather have it in phases, so you can have read access ASAP, or would you
>rather wait for the complete solution?  It makes me wonder how long it would
>have taken to get IMAGE/SQL out the door if we held up the first release
>until we had registered TURBO and third-party keys.
 
It makes me wonder how many more people would have had a positive experience
with the HP ODBC implementation initially if the performance hadn't been so
SLOW to begin with.
 
>
>I would like to hear your input on how you would prioritize the following
>features in their order of importance:
>
>1.  CM KSAM
>2.  Registered KSAM keys
>3.  Write access
 
I vote for (with integer precision):
  1.001 Register KSAM keys
  1.002 Write Access
  1.003 CM KSAM (only because you should really be using NM, lost the source
code? shame on you! ))
>
>Doug Myers
>Hewlett Packard
>
>
 
Brian Duncombe ([log in to unmask]) - M.B. Foster Software Labs
"Inside every large program is a small one struggling to get out."
          C. A. R. Hoare