On 18 Jan 2013 21:36, Richard Schoen wrote:

I had previously looked at the open database API call and ruled it
out because you could get false positives on a source member if it
were simply opened in read mode.

The /open options/ are exposed by the database open exit point via "each array element of the Referenced File Array"; input, output, update, and delete.

I think there is a first open for SEU that is always read-only, even for option 2=Edit; i.e. the load phase [load data from member into the editor] is identical for browse and edit, and the utility holds an *EXCLRD data lock to prevent any updates. When the /save/ processing occurs, the first read-only open of the member would be closed and then the member would be opened a second time, presumably using a method of /open with clear/ [an open with output\insert and delete options] which would then be used to write all of the data from what was maintained in the editor into the database source member. If instead there was a /clear/ [dataspace reset] method between the first open [for read-only] and the second open [for write], then there would be no data to copy when the second open [open with output\insert option] was intercepted :-( and I suppose only an additional exit for the clear would assist.

Plus I would think all the calls to the exit could slow things down
couldn't it ?

Sure, but presumably called by address. And if coded\compiled with minimal static and automatic storage, and with early return when not applicable, the overall impact might not be noticeable [even in the most excessive environments which would already likely be suffering from so much open activity]. Unfortunately the exit data does not include if the file type is source which is one action that would need to be done for an early exit after the exit data has not already provided a reason to exit early.

As I have suggested in the past, there may be value in requesting the database to add an effective Open Trigger, Close Trigger, and perhaps similar for Add Member and Remove Member as well; i.e. register exits for an action per object, rather than an exit for an action across the entire system.

In RDP's case it appears to lock the source member and then copy the
source member so it seemed to be a better method to trap for the
object lock request and then trigger my source archive scenario
before the actual source member open.

Interesting. How does one intercept a lock request of a source member? Apparently a feature offered of RDP, not of the server.?

In the case of SEU I created a custom replacement for STRSEU that
replaces the OS versions and this gets any PDM/SEU requests for

Intercepted with the command exit, replaced the QSYS copy, replaced the product library copy [so Proxy Commands utilize that], or using a copy in SYSLIBL ahead of QSYS and separately preventing QSYS/STRSEU, QSYS29##/STRSEU, PrdLib/STRSEU? Be aware that replacing objects in product libraries can cause errors with the product and even install failures depending on how the object is replaced on an upgrade [or re-install] and similarly could cause problems with PTFs that would replace the objects; and of course the successful replacement of the object by a PTF or install would require repeating the prior change [in a manner compatible with the possibly updated object].

Except for Rob's EDTF example this seems to work 100% of the time
so far with SEU and RDP and provides a "reasonable measure" of

Because the data in a source member can be updated by any number of other interfaces, basically anything using either of native I\O and SQL DML [e.g. an ODBC-based file editor, a non-RDP client-based editor, STRDFU via LF, RPG or COBOL program, et al], the possibility exists that changes can be effected outside of what is being tracked. That may not be a problem in the intended design, but these other accesses are a reason I had noted what was the *only means* to intercept *every* open of the source member; i.e. the database open exit.

At least when I described it to my team they didn't think I was too
cracked :-)

That inability to effect full control is one part of why I would probably never design for source management over a production set of source members that would be updated directly. Instead I would require that the data would have to be checked out from someplace that the developers have no authority, except via a check-out feature which ensures whatever other access rights and does any other validation of the request, before copying the data someplace they want so they can invoke their /edit/ request against that copy of the data. Any archival or incremental change recordings would be part of the check-in processing which copies their local copy of data into the repository. The developers could /edit/ their copy of data in whatever multitude of ways is available to them, and whatever means was utilized would never have to be intercepted by the utility, because the data they change is their own private copy rather than the production source.

Regards, Chuck

CRPence on Fri, 18 Jan 2013 12:09:10 -0800 wrote:

Anyhow... the only means to effectively intercept all database
source member open activity is to go with the system-wide database
open exit point [and the desirable but non-existent corresponding
close exit point; regardless there may seem to be one, by naming].


This thread ...

Return to Archive home page | Return to MIDRANGE.COM home page