Making records available to other RPG programs without using force ratio 1
Hi
Records are entered in one program and they need to be available to other programs before the first program ends. Programmer has used OVRDBF with force ratio 1 and RPGLE block(*no) in the past to accomplish this.
Environment is v7r1 RPG/400 and RPGLE. Many programs involved in legacy application, so complete rewrite or redesign is not practical. No commitment control or journalling in use.
For performance, we want to remove the force ratio 1 but still need the app to work.
Thoughts?
Records are entered in one program and they need to be available to other programs before the first program ends. Programmer has used OVRDBF with force ratio 1 and RPGLE block(*no) in the past to accomplish this.
Environment is v7r1 RPG/400 and RPGLE. Many programs involved in legacy application, so complete rewrite or redesign is not practical. No commitment control or journalling in use.
For performance, we want to remove the force ratio 1 but still need the app to work.
Thoughts?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
In this case, yes. Un-blocked RPG WRITE, FEOD, or Force Ratio on file = 1.
Not sure I understand the concern. Journaling performance and force ratio don't have much impact on each other (especially true if you enable journal caching).
Do you have a performance problem now?
If so, please provide details during peak usage time for this application. Not usually that difficult to asses journaling impact, even if you aren't set up to load test. Just start journaling small groups of files and monitor performance of your critical applications as you increase the number of files journaled.
OS is very smart about when it does journaling work, and even smarter if you enable journal caching (when appropriate for your replication SLA's):
CRTJRN JRNCACHE(*YES)
If you plan to journal a lot of files for replication purposes that aren't currently journaled, there is definitely some planning that needs to be done. More than I can reasonable cover here, though, since some considerations are specific to your environment. More info you can provide - for example, do you have current performance data you can share here? - the better.
I do occasionally see problems with journaling performance, but usually that is in applications that perform commitment control;;
http://garyrpatterson.net/ibm-i-performance/
Not sure I understand the concern. Journaling performance and force ratio don't have much impact on each other (especially true if you enable journal caching).
Do you have a performance problem now?
If so, please provide details during peak usage time for this application. Not usually that difficult to asses journaling impact, even if you aren't set up to load test. Just start journaling small groups of files and monitor performance of your critical applications as you increase the number of files journaled.
OS is very smart about when it does journaling work, and even smarter if you enable journal caching (when appropriate for your replication SLA's):
CRTJRN JRNCACHE(*YES)
If you plan to journal a lot of files for replication purposes that aren't currently journaled, there is definitely some planning that needs to be done. More than I can reasonable cover here, though, since some considerations are specific to your environment. More info you can provide - for example, do you have current performance data you can share here? - the better.
I do occasionally see problems with journaling performance, but usually that is in applications that perform commitment control;;
http://garyrpatterson.net/ibm-i-performance/
In general, journaling one file shouldn't have any significant impact on system performance. Adds a small amount of CPU overhead, and some disk I/O overhead, depending on volume of journaled data and journal setup.
Enabling general-purpose journaling for the purposes of replication is a different matter, and typically involves doing a little capacity analysis before flipping the switch. In a large, busy system, IO overhead can be significant, though system handles it well in even the largest busiest systems I work on. That means looking at your current system performance characteristics, estimating the additional workload, and verifying that you have adequate headroom for the new work.
Disk arm utilization is a key metric to watch when talking about journaling. Look WRKDSKSTS during your peak utilization times. Any arms consistently over 40%? If so, large-scale journaling is more likely to have a noticeable impact on performance, and you'll probably need to consider adding disk arms to support the additional disk IO workload.
Lots of ways to minimize the performance impact of journaling:
Journal caching
Minimized journal entries
Journal after images instead of *BOTH.
Don't journal busy work files not required for recovery
Enable soft commit when using commitment control.
Sometimes we also modify high-volume programs in order to minimize journaling impact, for example by consolidating multiple update operations into one, or other IO-saving changes.
Enabling general-purpose journaling for the purposes of replication is a different matter, and typically involves doing a little capacity analysis before flipping the switch. In a large, busy system, IO overhead can be significant, though system handles it well in even the largest busiest systems I work on. That means looking at your current system performance characteristics, estimating the additional workload, and verifying that you have adequate headroom for the new work.
Disk arm utilization is a key metric to watch when talking about journaling. Look WRKDSKSTS during your peak utilization times. Any arms consistently over 40%? If so, large-scale journaling is more likely to have a noticeable impact on performance, and you'll probably need to consider adding disk arms to support the additional disk IO workload.
Lots of ways to minimize the performance impact of journaling:
Journal caching
Minimized journal entries
Journal after images instead of *BOTH.
Don't journal busy work files not required for recovery
Enable soft commit when using commitment control.
Sometimes we also modify high-volume programs in order to minimize journaling impact, for example by consolidating multiple update operations into one, or other IO-saving changes.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you for your guidance! I will open a new question regarding performance if needed.
Barry
Barry
ASKER
It is from a high volume order entry system, so many interactive programs and users are involved in the entering and picking of orders.
We want to use journalling for replication but are concerned about the performance impact of force ratio 1 and journalling together.
Do records have to be forced to auxiliary storage before they are visible to other programs?