|
midrange.com
Ignore most of what I said on the last message. You don't have to invite
unless you want time outs, or to read from multiple devices. All you have
to do is override the display and change the dev parameter to the name of
the workstation that you want to take over. The workstation must have a
signon display for this to work. If you don't expect user input, and will
only be writing to the display, then you will probably have to change the
DFRWRT parameter to *NO, otherwise your screen will stay blank.
Sample follows. Invoke as CALL DSPC DSP01
Member DSP
A R DSP01
A COUNT 2S 0O 10 40
Member DSPC
/* PASS IN THE NAME OF THE WORKSTATION THAT YOU WANT +
TO TAKE OVER */
PGM (&TUBE)
DCL &TUBE *CHAR 10
CHGDSPF DSP DFRWRT(*NO)
OVRDSPF DSP DEV(&TUBE)
CALL DSPR
DLTOVR DSP
Member DSPR
FDSP CF E WORKSTN
C*
C 1 DO 10 COUNT
C WRITEDSP01
C EXSR @DELAY
C ENDDO
C*
C SETON LR
C*
C*****************************************************************
C* DELAY JOB FOR 2 SECONDS
C*****************************************************************
C*
C @DELAY BEGSR
C*
C CALL 'QCMDEXC'
C PARM 'DLYJOB 2'CMD 100
C PARM 100 LEN 155
C*
C ENDSR
C*
C*****************************************************************
C* FAKE READ TO THE DISPLAY TO SATISFY THE COMPILER
C*****************************************************************
C*
C @FAKE BEGSR
C*
C EXFMTDSP01
C*
C ENDSR
At 09:58 AM 12/19/00 -0600, you wrote:
>Actually, it is possible. As I said before, I haven't done it in quite
>awhile, and there are a couple minor changes that need to be made to the
>display file, and perhaps the RPG program. The technique uses the
>'Invite' keyword, and is referred to as 'read from invited
>devices'. Perhaps another list member has a sample.
>
>Regards,
>Rich
>
>At 09:56 AM 12/19/00 +0100, you wrote:
>>At 16:53 18.12.00 -0800, you wrote:
>>
>>
>>>Um.. uhh.. wow. This is intriguing. Tell me this then...
>>>
>>>Wouldn't it be possible to take a dumb tube and stick it out in an area
>>>and not sign it on. Then have an RPG program that had the job do an
>>>Override to this display file write to the screen without waiting for
>>>a response. All this going on in a never ending batch job. So now I
>>>have a green screen slide show going on to a device that is not really
>>>secure, but it's not signed onto the system anyway, so no body can get
>>>access that way?
>>
>>Nope. Prior to answering, i overrode (ist that correct? :-) the DSPF of
>>one of my menu programs to my fifth Client Access session with sign-on
>display.
>>
>>I went into my menu program. The session was locked.
>>
>>On the allocated "device", i was in my menu program and could enter menu
>>choices and saw other menus as long as i stayed in my overriden dspf.
>>Then i called an application, another un-overriden dspf, and the original
>>session awoke. As you expect, i could work there as usual. Then i
>>returned to the menu.
>>
>>Don't mix up - this is not a multi-job communication feature - it's just
>>the use of more than one input device; processing is done by a single
>>job, as it was before.
>>
>>
>>
>>>Or even better yet, have it wait for a response now and then. Or allow for
>>>input into the display file. Then the program could change what it shows
>>>or whatever depending on what the person enters. There is absolutely no way
>>>the person can get into the system since it's not signed on. There is no
>>>interactive session waiting to get a command line too.
>>
>>see the above...
>>
>>
>>>Or am I missing something?
>>
>>yep.
>>
>>
>>
>>Mit freundlichen Grüssen / best regards
>>
>>Anton Gombkötö
>>
>>Avenum Technologie GmbH
>>Wien - Mattsee - Stuttgart
>>e-mail Office : mailto:Anton.Gombkoetoe@avenum.com
>>Homepage : http://www.avenum.com
>>
>>Lest das Redbook / read the redbook "Who knew you could do that with RPG?":
>>http://www.redbooks.ibm.com/abstracts/sg245402.html
>>
>>+---
>>| 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
>>+---
>
>Regards,
>Rich
>
>+---
>| 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
>+---
Regards,
Rich
+---
| 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 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.
