Ross...

Sound almost like one of my posts!!! Roll on MV2006.

Simon
"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote

Ross Ferris wrote:
Yes. It seems no matter what tool you select, there are routines that
developers will do repeatedly. Java has both a good means and a
culture of sharing libraries (along with the usual not-invented-here
thinking too). There doesn't seem to be as much library sharing in the
MV world. People use tools to generate code, but I don't see a lot of
using other people's libraries as building blocks. Is that because the
language is procedural or the culture is too competitive or what? I do
see code examples here and on u2-users and there are a few tools like
DOWNLOAD (for U2 only), but not freely shared libraries with solid
API's that I have seen.

poor baby

Someone on cdt suggested it sounded like late-binding. I think it is
more like no-binding.

Microsoft has a power where few others could get away with such a
approach. I'd like to see build up around the product, perhaps with
some good libraries, without harming the installed base. Make new
friends, but keep the old.

Yup. I used to think it should be relegated to the trash heap. Then I
saw how much money my budget saved by using it.

You need time and money to market a product (although some creative
approaches might be in order) but it sure seems like it would be a good
investment. I was very disappointed that IBM did not start overt
marketing campaigns. It will be interesting to see if InterSystems
treats their MV product like they treat their MUMPS product or whether
it will seem more like MV compared to DB2.

It is starting to seem to me that Java is so last year (still good to
teach to college students, however). The scripting languages are
starting to rule the day: JavaScript, PHP, Python, Ruby, and maybe even
Perl. This seeming backwards move from OO to procedural/functional
code will correspond to another seeminglybackwards move--from the RM to
more agile database environments, I predict.

cheers! --dawn

"dawn" wrote:
While 99% of apps probably do associated MV set maintenance repeatedly
with different code segments that require independent maintenance, we
have to acknowledge that this is by habit, not a system limitation.
Developers familiar with OO will refactor out code like this into a
file-specific module, perhaps even a general purpose module that
handles associated MV's or file updates for a number of files. We can
do this with MV too. For example:

UTIL.ITEM = MY.ORDER
UTIL.VAL = CURRENT.LINE.ITEM.VAL
CALL UTIL.ORDERS.REMOVE.LINE.ITEM
IF UTIL.ERR THEN
GOSUB HANDLE.ERROR.REMOVE.LINE.ITEM
RETURN
END
MY.ORDER = UTIL.ITEM
....

That one utility knows to remove the specified value from whatever
attributes are required, including perhaps deleting corresponding
detail records from related files. Use of common or params on the
call is app-specific, as well as the choice of using a Call vs
Include. It's critical that the app code be able to handle errors
that could be returned from such calls - Most MV code I see these days
assumes everything is OK if we don't fall into debug.

The same pattern can be applied to all file updates:

GOSUB FILE.ORDER
IF FILE.ERR THEN
GOSUB HANDLE.ERROR.FILE.ORDER
END
RETURN
FILE.ORDER: *
UTIL.ITEM = MY.ORDER
CALL UTIL.ORDERS.FILE
* On success, order is filed with no error
* On failure some UTIL var provides info for the error handler
RETURN

In addition to much better maintainability and significant decrease in
the number of places where errors can occur, using patterns like this
removes a lot of RI issues.
- It allows the MV developer to assert that all such updates are
performed by a single Stored Procedure rather than leaving RI to the
DBMS.
- We get the benefit of doing it ourselves as well as refuting a
relational theorist's claim that doing it ourselves is problematic.
- They can still complain the task is left to the app developer rather
than the DBA, but we can respond that we don't need a DBA to
administer the platform because the app developer has full control
over the exact same single RI routine that a DBA would.

I think we don't see patterns like this in MV because the average MV
developer is a business person who happens to know how to code, not a
trained programmer who has learned business skills. Writing modular
code is a learned behavior and there isn't a lot of time to learn such
things when you're busy dumping new features into an app.

What I'm getting at is that I don't see RI as being a Pick-issue
per-se, just because it's not built into the environment. I see it as
a matter of proper use of the tools we have, and yeah, if 99% of Pick
people insist on duplicating file update code all over their app then
it's fair to say a properly developed relational environment will beat
a Pick app 99% of the time.


This is exactly what I'm talking about above. For a new application,
leaving RI (file IO and management of multivalues) to a tool is fine -
DesignBais, OSMOSiS, Nucleus, and SB+ also do this. In order to use
one of these tools with an existing application, the existing data
management code needs to be properly modularized. Well, if good code
is already properly modularized, then you don't "need" to replace it
with a tool. In order to avoid irrevocably linking their apps into a
third-party tool, some companies buy the tools and then completely
ignore the data management capabilities, using only the UI features.
That's a valid business/technical decision.

yup

T

Random answers & thoughts :

Intersystems/Cache - they will not treat (or promote) mv "differently".
They already promote their (truely) multi-dimensional database, and I
believe that mv will just be another "face" to this, like their SQL and
object support


Code Re-use/Libraries - there certainly is a dirth in terms of
freeare/public domain. Initiatives like PickSource, and a poorly
advertised area of RD's FTP site were as close as we got. That said,
there are plenty of commercial solutions available to most problems,
wether complete "environments" like Visage, or a grab-bag of useful
goodies to virtually anything from Dave Weaver. However, whereas a
"Windows" developer will buy an ActiveX our niche tends to be more
inclined to "roll our own"

As a case in point, we offered to GIVE Pick Systems the routines we
used to ship updates of R5 out to clients, in the hope that we could
help provide the mv equivalent of a "setup.exe". The result was
predictable, and as a result, every software house still has their own
(incompatible, though understandable) way of doing basic tasks like
this



Patterns (code repitition) - I think that what we have done on this
front within Visage (Snippet Technology and Active Code Reduction
Initiative) is really neat here, and isn't tied to a particular
language (can be used with HTML, Javascript & Java at least).

In terms of API's, what about UniObjects? or the AccuTerm host
programs? As I said, the API's tend to be tied to commercial products,
though I do note some initiatives within the U2 camp of late.

However, if you look at products like SB+ or Visage there IS a well
known & published API. (And there are always a wealth of programs to
look at in system accounts like APP.PROGS in UV or DM,BP, in D3)

dawn wrote:
They have downs in skating?!? Maybe I should start watching! =`;^>

--
frosty

"frosty" <frostyj (AT) bogus (DOT) tld> wrote

Illegal use of hands should be interesting too!

BFaux-