RE: need help with this rpg application

Dave,

Importing data is really no different from entering data interactively. Only the entry source, or client if you choose, differs. Interactive entry is replaced with some other data source. The data source is up to you. You could have the user enter, or select from a list, say an order number which the edit process accepts and then edits the order header and all its children. If something doesn't pass editing you notify the user who then corrects the errors and re-imports the order.


Data to import ----> edit process ---Pass---> update production with imported data
|
| Fail
<---Back to user to fix--+

It helps to have the edit and data update processes set up to be independent of the client.


Gary Monnier


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Dave
Sent: Monday, July 16, 2012 1:27 PM
To: RPG programming on the IBM i / System i
Subject: Re: need help with this rpg application

Thanks, Gary. I don't know the "import to production" concept. The auditing is a good point, but the user will still have to validate all the screens to make the transaction and all controls will be in place.
If rejected, the unfinished transaction is deleted. I'd have liked them to complete the transaction in the sandbox with all controls in place before simply copying it to production but this has not been accepted.

2012/7/16 Monnier, Gary <Gary.Monnier@xxxxxxxxx<mailto:Gary.Monnier@xxxxxxxxx>>:

I don't think your auditors will approve copying uncontrolled sandbox data to production unless you have some controls in place. How about using the "import to production" concept? All data is edited as part of the import. If the editing process fails then the transaction is rejected until all issues are corrected. If someone complains about being responsible for the data point them to the auditors to obtain an exemption.

Gary Monnier

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx<mailto:rpg400-l-bounces@xxxxxxxxxxxx>
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]<mailto:[mailto:rpg400-l-bounces@xxxxxxxxxxxx]> On Behalf Of Dave
Sent: Monday, July 16, 2012 11:53 AM
To: RPG programming on the IBM i / System i
Subject: need help with this rpg application

Imagine an application for entering client information to create
transactions. Users have been granted their wish to create
transactions with very little controls by using a "sandbox". Basically
they've been given a library containing copies of all the necessary
production files. That way they can create as much as they like with
the information they have as soon as it becomes available. Now for the
hard part: If the transaction is accepted, the user needs to be able
to select it in a subfile, which will then take them to the normal
creation application I mentioned at the start. At this point, the
library list will have changed to the normal production environment,
so that the sandbox files are no longer on line. The application will
display several screens before finalising the transaction. Each screen
needs to be populated with the information available in the sandbox,
the user completing the missing information. The idea is that the user
will not have to retype all the i

nf

ormation on all the screens.

It has been suggested to call the application in a separate activation group after having copied the sandbox information to the production files. In case of abandoning the transaction, the application already knows how to delete the information from the database.

Copying the uncontrolled sandbox data to the production files just doesn't seem right to me, even if it can be successfully deleted and even though the user will have to correct any incorrect data. Has anyone another idea how this might be achieved? What about a special file containing all the information from the sandbox files? Is that possible?
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:RPG400-L-request@xxxxxxxxxxxx>
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.