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

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

> -----Original Message-----
> From: Shaw, David [SMTP:dshaw@spartan.com]
> Sent: Tuesday, April 18, 2000 4:14 PM
> To:   'RPG400-L@midrange.com'
> Subject:      RE: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What's
> the d ifference!!!)
> 
> Dan,
> 
> Sorry for the delay in responding, they keep wanting me to do something
> called "work" here.  Looks like a 4-letter-word to me, but they can be
> pretty persuasive...
> 
> Yeah, in a function-key world using that would be tricky at best.  It
> wouldn't take much, though, for IBM to make it as effective as
> program-described print files.  If they did, would you use it instead of
> DDS
> display files?  Why, or why not?
> 
> Let me be honest for a moment - in reality I'm somewhat agnostic on where
> report layouts are defined, in the program or in DDS.  I have a slight
> preference for DDS, mainly due to the fact that my previous employer had a
> habit of wanting reports changed to do things which are easy to do in DDS
> but not easy to do in RPG.  You only go through the conversion hassle a
> couple of times before you realize that it would have saved time in the
> long
> run if it was coded in DDS in the first place.  This little side trip was
> mainly to see if the display file analogy held up or not - I think it
> does.
> 
> Dave Shaw
> Spartan International, Inc.
> Spartanburg, SC
> 
> > -----Original Message-----
> > From: Bale, Dan [mailto:DBale@lear.com]
> > Sent: Thursday, April 13, 2000 2:22 PM
> > To: 'RPG400-L@midrange.com'
> > Subject: RE: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . 
> > What's the
> > d ifference!!!)
> > 
> > 
> > O.K., well, um, that was ... neat!  I must admit I've never heard of a
> > no-source display file before.  I think I know why.  I _did_ 
> > qualify what I
> > was after, though.  I asked if it was possible to do 
> > _meaningful_ screen
> > I/O.  I dunno, Dave, I'd be hard pressed to let a user work 
> > with a screen
> > like that.  <g>
> > 
> > - Dan Bale
> > 
> > > -----Original Message-----
> > > From:     Shaw, David [SMTP:dshaw@spartan.com]
> > > Sent:     Thursday, April 13, 2000 1:36 PM
> > > To:       'RPG400-L@midrange.com'
> > > Subject:  RE: external *PRTF (was: RE: 'ILE RPG' or 'RPG 
> > IV' . What's
> > > the d ifference!!!)
> > > 
> > > Dan,
> > > 
> > > Responses in-line.
> > > 
> > > > -----Original Message-----
> > > > From: Bale, Dan [mailto:DBale@lear.com]
> > > > 
> > > > Dave,
> > > > 
> > > > I beg to differ.  QPRINT & QSYSPRT are indeed printer file 
> > > > objects, but they
> > > > are not externally described.  
> > > 
> > > DSPFD of QSYSPRT shows that it has 1 record format with 0 
> > fields defined
> > > in
> > > it.  Hmm, I see the system allows me to create a display 
> > file with the
> > > same
> > > type of setup.  Now, if I write a program to use that, what happens?
> > >  
> > > > Still, no one has answered the question.  Is it possible to 
> > > > do meaningful
> > > > screen I/O with a display file created with SRCFILE(*NONE) 
> > > > using only RPG
> > > > I-specs and O-specs?  If there is, I can't see how it could 
> > > > be as simple to
> > > > code as internal printer file O-specs; you and someone else 
> > > > mentioned UDDS -
> > > > enough said?
> > > 
> > > Well, based on a trivial test I just did, I must say YES!  
> > I created a
> > > display file named TEST using SRCFILE(*NONE), then wrote 
> > this ugly little
> > > RPG III program to use it.  I didn't use cycle control 
> > <grin>, but I used
> > > this display file just as I would QSYSPRT if I could read 
> > it and LO!  IT'S
> > > ALIVE!!! <vbg>  I'm not sure whether it could or how it 
> > would support
> > > function keys, since the display file doesn't provide for them, but
> > > function
> > > keys are a convenience that we've gotten used to, not a 
> > requirement for a
> > > practical screen-handling program.  Set up the hex 
> > attributes that you
> > > want
> > > for the screen as constants and just go to program-described town!
> > > 
> > > Here's the RPG:
> > > 
> > >      FTEST    CF  F    1919            WORKSTN              
> > >      ITEST    NS                                            
> > >      I                                        1   1 DUMB    
> > >      C                     MOVEL'TEST'    TEST1   4         
> > >      C                     EXCPT                            
> > >      C                     READ TEST                     90 
> > >      C                     SETON                     LR     
> > >      OTEST    E                                             
> > >      O                         TEST1      4                 
+---
| 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
+---