Re: Record Deletion on a Remote System

[Blake.Moorcroft@xxxxxxxxxx]

Thanks to everyone for the ideas.  Now to see which one will be most 
suitable.

Have a good day.


Blake Moorcroft
Analyst/Programmer - Corporate
Russell A. Farrow Limited
2001 Huron Church Road, PO Box 333, Windsor, Ontario N9A 2L6
Bus: 519-966-3003 ext. 566
blake.moorcroft@xxxxxxxxxx




Robert Rogerson <rogersonra@xxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
07/05/2011 01:10 PM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the IBM i / System i" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: Record Deletion on a Remote System






I feel like I'm missing something but wouldn't it be as simple as calling
the stored procedure on the remote system and passing the tranaction id?

On Tue, Jul 5, 2011 at 11:38 AM, Morgan, Paul 
<Paul.Morgan@xxxxxxxxxxx>wrote:

> Robert,
>
> How would you design a stored procedure to purge transaction IDs on a
> remote system?
>
> Paul Morgan
>
> Principal Programmer Analyst
> IT Supply Chain/Replenishment
>
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx [
mailto:rpg400-l-bounces@xxxxxxxxxxxx]
> On Behalf Of Robert Rogerson
> Sent: Tuesday, July 05, 2011 11:23 AM
> To: RPG programming on the IBM i / System i
> Subject: Re: Record Deletion on a Remote System
>
> I don't wish to hijack the thread but I wondered why no one suggested 
the
> use of a stored procedure?
>
> Robert Rogerson
>
> On Tue, Jul 5, 2011 at 10:52 AM, Morgan, Paul <Paul.Morgan@xxxxxxxxxxx
> > wrote:
>
> > Blake,
> >
> > Assuming your remote system is another iSeries...
> >
> > If it's not a real time purge then I'd use a CPYF with DDM followed by 
a
> > SBMRMTCMD CMD(SBMJOB...) to process the purge. The remote system job
> could
> > be SQL (source or embedded) previously set up on the remote system 
with
> the
> > transaction record control IDs driving the SQL deletes.
> >
> > For real time I'd set up a DDM data queue monitored by a delete job on
> the
> > remote system.  Push the record control IDs into the data queue so 
they
> get
> > deleted on the remote system.  The remote delete job could also be
> running
> > SQL to delete a specific ID.
> >
> > Paul Morgan
> >
> > Principal Programmer Analyst
> > IT Supply Chain/Replenishment
> >
> > -----Original Message-----
> > From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:
> rpg400-l-bounces@xxxxxxxxxxxx]
> > On Behalf Of Blake.Moorcroft@xxxxxxxxxx
> > Sent: Tuesday, July 05, 2011 9:59 AM
> > To: rpg400-l@xxxxxxxxxxxx
> > Subject: Record Deletion on a Remote System
> >
> > Hello all...
> >
> > I'm got a situation where as part of a transaction record purge, we 
need
> > to remove associated records from a set of files that are stored on a
> > remote system.  This would be done by an automated process.  The basic
> > scenario is as follows:
> >
> > a) Collect transaction record control IDs
> > b) Remove transaction records from files on primary (host) system 
based
> on
> > control ID
> > c) Access remote system and remove auxiliary image records from files
> > resident here based on control ID.
> >
> >
> > I'm wondering if other people have had to do something similar and 
what
> > options they've tried.
> >
> > So far I've been seeing simple FTP and use of DDM.  Never liked DDM
> > personally and I'd prefer something that is SQL based if possible.
> >
> > Have a good day.
> >
> >
> > Blake Moorcroft
> > Analyst/Programmer - Corporate
> > Russell A. Farrow Limited
> > 2001 Huron Church Road, PO Box 333, Windsor, Ontario N9A 2L6
> > Bus: 519-966-3003 ext. 566
> > blake.moorcroft@xxxxxxxxxx
> >
> >
> >
> > Celebrating a Century of Excellence and once again named one of 
Canada's
> > 50 Best Managed Companies!
> >
> > This electronic message contains information from Russell A. Farrow
> > Limited, Russell A. Farrow (U.S.) Inc., canadaplus.com or RAF Express
> > Inc., that may be confidential or privileged. The information in this
> > electronic message is only for the use of the intended recipient.
> > Inappropriate disclosure, copying, distribution or other use of the
> > contents of this electronic message is strictly prohibited. If you 
have
> > received this electronic transmission in error, please notify the 
sender
> > immediately by return e-mail. Thank you.
> > --
> > This is the RPG programming on the IBM i / System i (RPG400-L) mailing
> list
> > To post a message email: RPG400-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> > or email: RPG400-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/rpg400-l.
> >
> >
> > --
> > This is the RPG programming on the IBM i / System i (RPG400-L) mailing
> list
> > To post a message email: RPG400-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> > or email: RPG400-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/rpg400-l.
> --
> This is the RPG programming on the IBM i / System i (RPG400-L) mailing 
list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>
>
> --
> This is the RPG programming on the IBM i / System i (RPG400-L) mailing 
list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.