RE: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What'sthe difference!!!) -- RPG400-L

Dave,

I know you are just testing a concept, but I'd stick with dynamic screen APIs 
over program described display files.  After using the dynamic screen APIs 
almost exclusively for a couple of years and seeing the advantages, I wouldn't 
go back to DDS.

David Morris

>>> dshaw@spartan.com 04/13/00 11:36AM >>>
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                 
 
> Ah yes, workstation files using the primary cycle!  I think 
> there was a
> point where the only choice you had for workstation files on 
> a S/34 was to
> define it as primary.  Only later did we have the option to 
> define it as a
> "D"emand file.  (Or was that just the way it was introduced 
> to me? <g>)

Yeah, I've never worked on a /34 (I was working on Data General NOVAs back
then), but I've heard that.  I think the original version of the program I
described was that old.  Seemed very odd seeing something like that on a
/38.

Dave Shaw
Spartan International, Inc.
Spartanburg, SC

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