× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



M. Lazarus wrote:

A VIEW w/ a UDF and a trigger have different dynamics. A major
one is that a VIEW requires explicit use by the requester. A
trigger fires regardless of the data access method. This is a
very important distinction.

Understood, and I clearly stated that an enhancement to effect something like that would be desirable, but simply making a Read Trigger change-capable is a bad idea. I stated first that it "is fine to desire a way to manipulate the output of a database file, and enhancements are a great way to provide that" and again that an "enhancement to enable a variation on the Read Trigger concept to enable writing whatever is desired into the buffer may seem worthwhile as an alternative implementation to UDF, but IMO only as an entirely different kind of trigger; *if* even that were its implementation." That does not preclude that whatever conceivable enhancement, would be able to effect similar capability to intercept all rows read as is provided by a Read Trigger. I am saying that a Read Trigger should not be the place for such a function; perhaps a requested enhancement for a ReWrite trigger.?

As to your question "What does it mean to have a DSPPFM which
returns data that is not really what is in the dataspace?", to
paraphrase playground lingo "well, IBM started it!" How are
timestamps stored in the DB? DSPPFM etc. handles that conversion
just fine. Plus, if my job's date format is changed I will get a
different format appearing on the screen. So it may not even
display in the same way that it was originally written to the
data base! This is a desirable behavior - because we want our data
in usable form - even though the DB is "lying" to our applications.

Actually I must apologize for that DSPPFM not matching the dataspace, but it was a requirement forced on the utility due to the [IMO poor implementation] of date/time/timestamp; an implementation chosen solely to enable the languages to offer support a release earlier than had implementation been done differently. In order for DSPPFM to match the DSPFFD, the utility was /forced/ to display the data in its external form; without that consistency, there is no map to the buffer. But the DSPPFM utility is non-functional for dates outside of 100-year window, rendering it useless, when the date format is a 2-digit year; the file must be altered to have a 4-digit year. Thus although the ability to /see/ the date versus an integer value may seem nice, its 'lying' to the user is its fatal flaw. The utility needs to be zero-mapping, but the date-to-string is implicit mapping that is impossible to effect for all dates prior to the year 1940 [for example], when the chosen visualization for the date string is any of the job formats. So the claim that DSPPFM "handles the conversion just fine" is false; that it can not is a "Permanent Restriction" due to the design imposed in v2r1m1.

The arguments you are making can similarly be made with write triggers, and even UDFs. Data can easily be scrambled using either method. Since all methods being discussed run in the same job stack,
they are all just as "debuggable" as the main application program.

No. Insert Trigger act between the trigger program and the database; they have their own contractual obligations. A Read Trigger is between the HLL and the database. That is what makes them totally different. Whether the methodology enables debug capability is moot. The point is that the program would receive anything versus the row. The program was compiled to receive a row, what was in the database, and as it is compiled the application and run-time logic depend on the actual physical row being received.

I have obviously not been articulating well, the flaws in a change capable trigger, since all that comes from it is the repeated argument that "anything can mess with the data, so a Read Trigger should be able to as well." So maybe a theoretical example, assuming the added Read Trigger is change capable:

create table qgpl. T (i int, c char)
addpftrg qgpl/T *after *read pgm(plusone)
-- plusone returns a value one greater than in field i
insert into table qgpl.T values(1, DEFAULT)
call read4upd /* open T for upd, read, upd C='', close */
-- trigger program is called, set i = 2 as /desired/
-- Does the row update to the value 2 or stay 1 ?
-- Well, to pass the row with that value to the program,
-- the buffer was just updated to have the value 2
-- So the program updates without changing the value i,
-- yet the value in the table for i is now 2

The same table now, with the value 2:

select i from qgpl.T where i <= 2 into :ii

The fetched value ii does not meet the selection logic; i.e. ii=3 whereas all coded logic is with respect to selecting only values that were /less than or equal to two/. Where is the logic in that? This is much worse for /native/ programs, where logic is more likely to be deferred to the application and HLL run-time.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.