File Read

Gary,

Times change and I have reason to believe that a request such as yours
(if made today) would be responded with something along the lines of:
"We agree with the request, solution is desirable and feasible.  This is
however not a business commitment".

The above may seem a bit wishy-washy, but it also happens to be the
next best response following "available" or "already announced" that
can be given in the REQUEST system responses.

As you point out, there may be significant performance considerations
in having a program involved with every Read operation.  But it does
seem reasonable for the customer to decide if that performance hit is
acceptable (rather than IBM simply saying Rejected).

Bruce

>
>It's somewhat interesting to be reading this thread. It's a deja vu kind
>of thing for me.
>
>A few years ago, I (and my partner) went to IBM database folks and
>presented what we felt was a strong argument for READ triggers. We
>prefaced our discussion with the acknowledgement that there would be
>serious performance considerations, but that we felt that because of
>the, at that time, contemporary reason we wanted READ triggers that the
>performance issue might be acceptable, at least for a limited time.
>
>One could argue that there is a performance issue for INSERT and UPDATE
>triggers, so what's the big deal about READ trigger performance worries.
>The difference is that there are almost always VASTLY more READs issued
>that INSERTs or UPDATEs.
>
>The argument we presented to IBM centered on Y2K. We were considering
>putting together what we felt would have been the quintessential Y2K
>tool. The tool's basic premise was to let normal, everyday operations
>identify (at least to a great extent) where dates were being used and
>keep track of not only where they were used, but keep statistics as to
>the frequency of their use. In so doing, considerable quantification of
>the work necessary to fix Y2K problems would be captured by users simply
>doing their jobs. The tool would "learn" where exposures were and the
>data gathered as to the frequency of use would give us a great impact
>analysis payback. With that data, priorities could be set as to what
>needed attention first, etc.
>
>The tool, in my opinion, would have greatly eased the burden on IBM's
>AS/400 customers. We simply asked IBM for a READ trigger so that we
>could provide the function to customers. We even went down the road of
>mentioning patching the SEPT as Leif has discussed, just so IBM knew we
>had some amount of knowledge.
>
>As you know, we didn't get the READ trigger, even given what I feel was
>compelling reason to consider it. Bottom line -- good luck getting IBM
>to listen, now. Keep trying, though.
>
>Gary Guthrie
>


+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---