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
changes.
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
management.
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:
<<SNIP>>
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].
<<SNIP>>
midrange.com
