RE: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What's the d ifference!!!)

Dan,

re: asbestos suits

I don't use the things myself, they probably cause cancer in lab rats and I
don't like being responsible for making the little critters sick. (BA-DUM,
DUM!)

re: the tool issue

I HEARD THAT! (please forgive the lapse into redneck, can't help myself
sometimes ;).  

re: the source file issue

Well, that's really a tool issue, too - both Flex and Code have features
which make that transparent to the programmer, as do project-based change
management systems like TurnOver, Aldon CMS, and even (shudder!) IBM's ADMS.
Even cross reference tools like Hawkeye Pathfinder and ASC Abstract/Probe
have mechanisms built-in for that.  The tool that you're working on sounds
cool, but do realize that this wheel has been invented before, in fact you
can specify alloys or hubcaps. :)

In my mind, the whole concept of storing the source code for an object
outside of the object in a file member is the root of the problem, anyway.
The intermediate representation of a program is stored in the object, why
shouldn't the source be, too?  Obviously, vendors need the ability to create
copies that omit the source, but that's not a big deal - make the source
attached, with an option to detach it (without deleting it of course), and
another to re-attach it again if necessary.  That would simplify all sorts
of things.  But enough dreaming - they want some more of that "work" stuff
done.  You'd think I was costing them money or something... <VBG>

Dave Shaw
Spartan International, Inc.
Spartanburg, SC

> -----Original Message-----
> From: Bale, Dan [mailto:DBale@lear.com]
> 
> Dave, sorry, I've already taken off my asbestos suit for the external
> printer file topic... well, lessee, I guess the one I have on 
> now for the
> DOU & DOW topic will suffice <g>
> 
> After reflecting thoughtfully on all the discussion, 
> including, especially,
> your response here, it occurs to me that it is, in fact, the 
> design tool
> that really sets me off.  You asked _if_ we could do all 
> modern display file
> coding in RPG, would I do it?  So, I'm thinking to myself:  
> Of course not.
> Why not?  Because 1) I've never known until now that you 
> could do it in RPG
> and 2) SDA is a very good tool for the job.  Well, now that 
> you know that
> (presuming for the sake of this argument that IBM would 
> "enhance"(?) RPG to
> do full-function internal display file processing) you could 
> do it in RPG,
> would you, regardless of SDA?  Well, you really can't take 
> SDA out of the
> equation, since that's all I've ever known for screen design 
> since my S/36
> days.  The question, I think, becomes, why would I choose 
> internal display
> file specs over external?  I wouldn't.  If I'm really honest 
> here, I don't
> think it has anything to do with whether the display file is 
> internally or
> externally defined, what I care about is which is the easiest 
> & fastest
> method to design and modify display specifications.
> 
> Now, take the same course of logic for display files and 
> apply it to printer
> files.  Although SDA is a very good tool for display file 
> design, RLU, quite
> plainly, s**ks for printer file design.  Even though I had 
> only a brief
> exposure to RDA, I saw enough to be able to form the opinion 
> that I would
> have never started this war in the first place had IBM had 
> the foresight to
> design its RLU to what RDA is.  And, therefore, every AS/400 with ADT
> installed would have "RDA" instead of the kludge known as RLU.
> 
> One other thing that goes along with my previous positions on external
> printer file definitions:  One of the biggest pains in the 
> rear is having
> RPG source in one source file, CL in another, and PRTF / DSPF 
> in another.
> This is still the shop standards in all of the clients I have 
> been in.  JBA
> even goes to further extremes, but that's another flame war.  
> This QRPGSRC,
> QDDSSRC, QCLSRC stuff is carryover crap from the S/38 days of 
> the programmer
> menu, before IBM gave us PDM.  I have one source file in my 
> development
> library.  WRKMBRPDM QSRC AR123* shows RPG member AR123R, CLP 
> member AR123C,
> DSPF member AR123DF, and PRTF member AR123PF all together on 
> one screen.
> Note that I still keep database PF & LF definitions in a 
> separate source
> file.  I am currently working on a WRKMBRPDM-like utility 
> that disregards
> the library & file selection, i.e., think of a WRKMBRPDM 
> AR123*, and it will
> show _all_ source members beginning with AR123 in any source 
> file in any
> library.  It's mostly done, but I'm working on the PDM-like 
> user options and
> the underlying outfile update function.
> 
> Confession is good for the soul.
> 
> - Dan Bale
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---