Charles Wilt
--
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307

wiltc@xxxxxxxxxx

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Craig Jacobsen
Sent: Thursday, August 14, 2008 11:03 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Auto advancing display screen

Charles,


I guess I don't understand why sending an enter key to the buffer won't
work.

It works for a barcode reader with the same program we are talking about.
I scan something, it puts it on the screen and auto enters it. It must be
appending the 5250 data stream somehow. (It must send an extra code of
some
type when you configure the reader for auto enter because if not
configured,
the data waits for the enter key.) The reader acts like the keyboard, so
I
don't think the O/S or emulation software has anything to do with it. It
just sends the enter key appended to the data it read to the screen if
configured.

Is the barcode reader that works connected to a keyboard port on your System I? Does your working
application read directly from a keyboard port?

Of course not.

So there are lots of pieces between the bytes the barcode reader sent and the bytes you finally see in
your program. Those pieces are in the 5250 terminal or emulation software the i OS itself.

To put it another way, the 5250 data stream exists only between the 5250 terminal and i OS itself.
Your working program does i/o to i OS and the working barcode reader sends input to the 5250 terminal.

On the other hand, with the data queue, you program is (basically) reading directly from the RFID
device.

Now do you understand why just "sending an enter" that bypasses all those other pieces isn't going to
work?


The Pocket PC is too small to use for the Packers as a telnet session.
All they will be used for is scanning. Sometimes they scan RFID and other
times they scan 2d or regular bar codes (even on the same Pack), thus the
need for a Pocket PC. If you can tell me where to get a keyboard scanner
that alternates between RFID, 2d, and regular barcodes, that would work
too
(and be a lot cheaper).

You wouldn't have to actually display a telnet session window.

Example 3 is the way I'm doing it now.

Problem seems to be if I read from the dataq, the sfl doesn't seem to be
available. If I get the *DSPF in the dataq, I do a read and all is good.
If I can get a good chain to the subfile, I wouldn't have any issues.

Maybe instead of trying to chain back to the subfile, just reload it. So basically you're using the
screen two different ways. First is for i/o with the existing process. Second is output-only for the
RFID process.

Otherwise, as I see it. You need to manipulate the 5250 buffer from your program and get the program
re-invoked as if someone at the terminal had hit enter. Only thing I know of to look at would by the
Dynamic Screen Manager APIs.
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/dsm.htm


Might be easier to restructure the program, pulling the needed business logic into a SRGVGM and having
two separate programs using it.

Charles


This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.

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-2019 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].