× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.