|
Doc, OK, not sure I agree with your assessment of where linker information should be kept, but that's a small point and I'll not argue.... Service programs. That to me is the most direct and logical approach to ILE development, as it separates the programmer (somewhat) from the teduim of mass rebuild. Throw in a little Binder source, and you can modify underlying code without requiring mass recompiles (unless your prototypes change, which hopefully is not happening too often). I freely admit my lack of experience in "unstable environments" as you describe, so I may just not understand what you're saying. However, I still can't see how TMKMAKE makes things better, only how it makes it more "Unix-like". Perhaps that's an advantage to some, but not for me. Sorry if I'm just being dense...... Eric DeLong Sally Beauty Company MIS-Project Manager (BSG) 940-898-7863 or ext. 1863 -----Original Message----- From: E Doc [mailto:doc6502@yahoo.com] Sent: Tuesday, February 11, 2003 10:10 AM To: rpg400-l@midrange.com Subject: Re: RPG400-L Digest, Vol 2, Issue 38 My choice in IDE, for which I knew I was going to get slammed... Jon Paris said... >Apart from #1 (CODE is big) most of the items on your list can be performed >by CODE. Sorry but your list reflects more about your lack of knowledge >about CODE than it does about anything else. Jon, apologies prefixing insults are no apologies at all. No need to be defensive-- I don't care if you use COCONUTS to write code. Whatever works for you. >Things like selecting >rectangular blocks, recording macros, etc. has been part of CODE from the >outset. If you prefer your tool then fine, but at least when building a >list like this it behooves you to find out what the other tool _can_ do. If you read the last part of my post, I said I *need to look at CODE now that it's part of Eclipse*. I also need to look at UltraEdit and a few other things. Blah-blah, woof-woof. TMKMAKE >Sorry, just don't understand the need..... >TMKMAKE utility? Why do I need it? I've had wonderful success with binding >directories and their corresponding H specs, and I just can't understand >what problem is addressed by the make tool. Can you elaborate? H-specs? Aye, there's the rub. OK... if you're going to write RPG only, sure. Use H-specs. I don't like the notion of hardcoding linker information into program source (hell I can barely stand #ifdef because the poor thing's so abused), but it works. This is OK for the average shop that's pulled it's RPG/400 codebase into ILE RPG, and converted a dozen or so functions (message handling, date manipulation, account number formatting, etc). The functions referenced are more-or-less set in stone, and that's just fine. It's a stable business computing environment. Now what about the environments that aren't stable, like software product development? Changes are so rapid that the entire system, hundreds of programs, thousands of modules, require nightly rebuilds? TMKMAKE is an ideal tool because it can either rebuild the entire system or rebuild the portions of the system that have been through code change, or will be affected as the result of code change. There are other ILE languages that don't have H-specs either-- namely C, C++, and Java. In order to do mass compiles, you have to either write lots of CL code or make scripts. Otherwise, you're gonna do a LOT of typing to get everything built. -Doc __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@midrange.com 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 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.