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

Just thougt I'd jump into the fray.

Re: Abestos causing cancer in labratory animals.

Actually, it has been shown that scientists cause cancer in labratory animals. 
<g>

Re: External reports .vs. Internal Reports (RLU .vs. O Specs)

When I first started on the AS/400 most of the code was in S/36 RPG.
Almost all of the programs used O specs.  I came across one program that
used an external printer file, and I decided to try out RLU and to see what
it was all about.  I created a quick report program in RPG III and created
the report, and designed it, and ran it, and worked out all the bugs and though
it was pretty good.

Then I came across another program I was trying to debug that had an
external print file.  Okay, I was going to have to open up the source for
that one.  I searched for the report file, and couldn't find it.  I then went to
the OCL and saw that the print file was overridden and was another name.
I fouind the print file, then went to find the source, I couldn't find it.  
After
at least half an hours search I found  the source in a completely differet
library, someone had moved the report file, but didn't take the source
with it.

So, after 2 to 3 hours I was able to fix the bug that should of taken me
10 or 15 minutes at the most.  I have never used RLU since.  This is the
fault of the program designer for overiding the print file and moving the
print file?  True.  But, we all know, this stuff happens.  It just doesn't
happen if the O specs are in the RPG source in the first place.

Re: Internal Screen Design .vs. Screen design in RPG

If possible, would I design screens in RPG instead of SDA?  Yes and
No.  There have been some cases when I would have found it very
helpful and a lot easier to do screen design in RPG.  But, in most cases,
perhaps 95%, it is much easier and faster to do them in SDA.

Regards,

Jim Langston

If at first you don't succeed, get a bigger hammer.

"Shaw, David" wrote:

> 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
> +---

+---
| 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
+---