RE: Exit Point When Opening a Source Member with RDP ?

Thanks for the info Chuck.

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.

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

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.

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.

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.

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

Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT

------------------------------

message: 3
date: Fri, 18 Jan 2013 12:09:10 -0800
from: CRPence <CRPbottle@xxxxxxxxx>
subject: Re: Exit Point When Opening a Source Member with RDP ?

On 18 Jan 2013 06:24, Richard Schoen wrote:

Do you know if there is an exit point that gets called from EDTF ?

If one were to use the existing model of database source members as
the model for the source repository then there is more than just SEU\RDP
would need to be intercepted to ensure tracking of source changes. Thus
the mention of EDTF [of a source (not stream) file] by Rob. However
what about DFU and SQL, or any HLL?

In writing a feature to manage a source repository, I would probably
choose not to use the original source database members for storing the
data [and incremental changes]. Sure they could be checked-out into a
member if that was where they needed to be, but such a utility might
best hold all of the data privately where only those profiles deemed to
have authority within that utility can override any controls. But it
seems the primary goal here is to fit the RDP in with the typical model
whereby a production source in existing members must be controlled; i.e.
not building a separate entity as source repository from which the data
is copied for checkout to perform change activity.

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].

http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/xopendbf.htm
_i Open Database File Exit Program i_
" Required Parameter Group:

1 Open Database File Input Information Input Char(*)
2 Return Code Output Binary(4)

Exit Point Name: QIBM_QDB_OPEN
Exit Point Format Name: DBOP0100
QSYSINC Member Name: EDBOPNDB

The Open Database File exit program is called when a job is opening a
database file. This exit is called in the job that is attempting to open
the file. The exit program is passed a list of files referenced in the
open request and the open options. The exit program may set a return
code value to end the open request. When an open request is issued, the
operating system calls the user-written exit program through the
registration facility. For information about adding an exit program to
an exit point, see the Registration Facility APIs.
...
Exit program introduced: V5R3"