× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What's the difference!!!)
  • From: "Shaw, David" <dshaw@xxxxxxxxxxx>
  • Date: Thu, 13 Apr 2000 13:36:14 -0400

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.