|
Good information and points Mark. Thanks. I should probably clarify a bit though. I do not use RSEor CPO because I use TurnOver. I tried RSE and CPO (Yep, RSE is better than CPO) but TurnOver handles projects better than any software or plugin yet for our environment. You can see the TurnOver Change Management software at www.softlanding.com. No, I'm not a spokesman, I just really like the product. Maybe RSE as a PDM alternative but until WSSDA speeds up, it is PDM and TurnOver. My thought on RSE is to actually WebFace PDM as another perspective since I think that is JavaScript but that is just my opinion. PDM and TurnOver are already plugged into CODE anyway. I might use RSE just to get the help search. Anyone know why help can't be made available online or on a server? I have REXX macros in CODE I would want in the LPEX editor. Anyone know of macros, examples of macros, or a help tutorial on writing (or converting to) LPEX macros? I don't write Java regularly. That is fine if they want to integrate the Designer and Debugger to the Eclipse framework, I just still want to make sure those "plugins" and the others in PDM and TurnOver will still go somewhere like they do today. I think I heard TurnOver was excited about WDSC so that is good to hear. Excuse my bluntness, but what is wrong with CODE? Am I missing something? What is the big push to rewrite everything from scratch when CODE is already stable, many years old, and is way ahead of that LPEX editor? Why can't we improve what we already have instead of reinventing the wheel? It seems like as soon as everything is in Java and is finally stable, everything will be rewritten again to whatever the current language and technology is. I think it is good to keep up with technology but I want to make sure the options will still be open for using stable products like CODE. For example, being able to use old and stable PDM instead of RSE I know is a given. Personally, I think formal training in WDSC would be an overall waste of time right now. Is there going to be an LPEX Designer and how much different is that supposed to be than CODE? We and maybe others should be using TurnOver for projects anyway. CODE hasn't changed much and the LPEX editor seems to need so much work to be considered fit for productive and stable programming that it seems ludicrous to learn and use something that is below CODE and will change anyway. Of course, I know CODE better though. Maybe WebFacing training for people who would do WebFacing or Java development would be worth it. I am not even going to get into how training rooms would either require you bring your own PC or upgrade some or all PC's for the WDSC install. I am all for new technology and features but I want to make sure we still have the choice to use the old stable software. Then we get back to installing WDSC as a bundle by default but giving another option to customize the installation for people who know what they want. I expect to always have the option of running good old stable CODE until LPEX surpasses CODE in a couple years. Then CODE will probably be like SEU to some? I guess it is better to voice my opinion now than when it is too late but I mean no offense to the WDSC. I am all for new technology but I want to make sure I still have the freedom to choose. Thanks, Craig Strong ** Mark wrote: Craig, My guess on the way it is currently bundled has to do with most of us wouldn't have known what to install to get the features we need so they just made it install everything. I think this is something that will get worked out over time. For example, they could at least make installing VA RPG a separate option since it is clearly a standalone item. I wouldn't give up on WDSc just yet. I personally find RSE more productive than the old CPO, and it has some nice integrated options such as browsing record formats or displaying object descriptions. It lauches the Code editor pretty smoothly so you are not sacrificing a lot for using it. In general, I would say that the memory and CPU requirements for WDSc are unlikely to make any huge leaps in the near future. The big caveat there, however, is that is also depends on the projects you are working on. If you have a 1,000+ file JSP/Java project you need more horsepower because of all of the "features" it provides when you are changing a file. If you are just using RSE and working with iSeries objects the it shouldn't matter how many objects you are dealing with since the IDE becomes more of a "Client/Server" application and less is done on your PC. As Buck pointed out, if you get into big WebFacing projects, your requirements go up quickly. LPEX is the name of the editor component in Code/400. That core editor was rewritten in Java and made an Eclipse plugin called the LPEX editor. >From an editor standpoint, the two therefore are very similar, although I believe none of the REXX macros in Code/400 can be used in the Eclipse version. What the Eclipse version lacks is some of the extra things that were added to the editor in Code/400 like the program verifier. These will hopefully be ported to plugins soon and you will not need to launch the external Code/400 editor any more unless you rely on any REXX macros that cannot be ported to Eclipse. As I have already hinted, RSE is meant to replace CPO, which just leaves the screen/report design component and I guess the debugger as things that need to be ported to the Eclipse framework. I hope these items get ported, but I would rather see some editor enhancements first such as more wizards and smart guides and refactoring would be great. Hope this helps. Mark
As an Amazon Associate we earn from qualifying purchases.
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.