× 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: DSPF with SRCFILE(*NONE) Re: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What's the difference!!!)
  • From: Anton Gombkötö <Gombkoetoe@xxxxxxxxxx>
  • Date: Thu, 13 Apr 2000 21:43:34 +0200

OK, nice, but won't this lead to "display files" as they were on the S/34,
in the end?

One created them via SDA and one used them in RPG, program described
I-statements (with non displayed fields to identify the record!) and
O-Statements, using such nice things like coding the name of the format to
be excepted like

O                     K5 'FMT01'

(Yes, the 5 was the length of the string 'FMT01'!)

Weren't we happy to leave that desert, (or to express it in time, not
geography) the dark ages without external references? We "suddenly" (after
long years of slave's work :-) coded things only once and reduced errors
resulting from this radically! And - everybody sees the need for an external
description of the >device dependant> attributes of the fields (non-display,
white, red, blinking, ...), even at the cost of the soooo ugly indicators
(great how i avoided "sucking", ha? :-) - funny, how different this is on
the output side - the printer file... (Cheers, Dan, great discussion!)
- - -
And - what about input fields in *your* example?
- - -
Didn't anybody on this world - nowadays i can ask the "whole" world (at
last!) - program a tool, that outputs real 5250 data stream, like i
sometimes suggest(ed) the UPDDTA to work, as performance for creating the
display formats was quite good even at earlier releases *and* the screens do
behave slightly different from the ones created by a "stored" DFU "program".
---

Best regards,

Anton Gombkötö

----- Original Message -----
From: "Shaw, David" <dshaw@spartan.com>
To: <RPG400-L@midrange.com>
Sent: Thursday, April 13, 2000 7:36 PM
Subject: RE: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What's the
difference!!!)


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

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

Replies:

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.