|
|
![]() |
|
|
Reader Feedback and Insights IBM Repositions WebFacing to Convert Interactive Apps to Batch
I was reading your article "IBM Repositions WebFacing to Convert Interactive Apps to Batch", and I have a couple of comments to make about it. First, it's understandable that vendors feel uncomfortable when IBM offers competitive products to their core products. My company (Advanced Systems Concepts) has endured this in the past, and in retrospect we took a difficult, yet worthwhile, path in trying to communicate our unique functional benefits versus the IBM alternative. Unfortunately, this approach seems to be lost on a good portion of the tool vendor community as they try to defend their turf. A few vendors tell me that since IBM is selling FUD (fear, uncertainty, and doubt), they're attacking back in the same manner. In the case of 4GL and refacing tools, the target is the entire WebSphere brand. I guess the thinking goes that if one part of WebSphere gets a bad rap, then you attack the other parts with the same argument. Why let a little thing like the truth get in your way, right? WDSc (WebSphere Development Studio Client) is a part of the umbrella product WebSphere Development Studio. If you need the RPG compiler, you have to buy WDS because it's all part of the same product. So, like it or not, you're going to own WDSc if you're an iSeries development shop. It's been that way for a while now. Once you understand this fact, stating that people have to buy WDSc is misleading, I think. Would people license any refacing tool without the core iSeries development tools to go with it? I doubt it, because you're probably going to have to recompile stuff at one point or another. The vendors' point on the need for Java skills is a vast overstatement of what's required to get WebFacing going. There is no requirement (that I'm aware of) to code in Java in order to get WebFacing going. Besides, I think you would have to be naive to assume that using a third-party tool to reface your screens would eliminate the need to develop skills beyond RPG. Applications are not inert, and RPG developers have to evolve their skills just like everyone else in order to remain competitive in their own job market. In the end, I think everyone would be better served if we relied on the good old-fashioned way of attacking the competition, demonstrated by functional superiority rather than more FUD.
--Chris Wilson DCSoftware's Wizard Throttles Back on Hungry File Reorgs Since iTera is one of the few software vendors that offer an alternative to IBM's RGZPFM command for reorganizing files, I read with interest your article "DCSoftware's Wizard Throttles Back on Hungry File Reorgs." I wanted to make your readers aware that the ability to reorganize files "In Place," which DCSoftware announced with their ReorgWizard, has been available with our Reorganize While Active solution for over a year, and is widely installed. In addition, for years we have offered a "Mirrored File" method (making a copy of the file during reorg). Despite the tremendous benefits of an "In-Place" method, we continue to offer a "Mirrored File" method, because there are certain files that just aren't suitable for the "In-Place" method--for instance, certain files that have triggers, all files with referential constraints, and certain files that are being journaled. In reference to DCSoftware's "throttle" that processes records at one per second to mitigate the overhead caused by the reorg process, the companies that benefit most from reorgs have files with many millions of deleted records, which means that if they have 30 million records in the file, it could take nearly a year for the reorg process to complete! Despite what Mr. Shea says about adjusting the job run priority as an alternative, our customers have found that adjusting the job priority and/or time slice works very effectively to mitigate overhead when large files are processing, yet allows the reorg process to complete in a reasonable amount of time.
--Dan NeVille
|
Editor
Contact the Editors |
| Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved. |