Handling outputs (yes, an *on* topic thread!)

From: LX-i (lxi0007_at_netscape.net)
Date: 03/26/05 

Date: Sat, 26 Mar 2005 13:02:14 -0600

Good afternoon.

The project on which I'm currently working involves handling messages
coming from an interface partner. Due to the protocol of the interface,
they can only send up to 3,000 characters or so per message; so, they
often send us multiple responses that comprise a single logical message.
  My design is to move them into a table, appending until we get the
last one, and then sending the message, as a single message, to the
user. This part is fine.

My question is this. It's a mainframe environment, and though most all
of our users have been directed to use the GUI (whose outputs we already
put in another table, then send them a web page with the entire output),
we still have about 10% of our users that are allowed to use the
terminal emulator user interface. For these, we put their outputs in a
"paging file." We then have a program (called GAG) that retrieves these
messages, a screenful of text at a time. (It will also print them,
delete them, etc.)

My question (or topic for discussion, more aptly) is this - how do you
handle outputs that need to be "paged"? Do you use a similar
system-provided file? A database table? Punched tape? ;) I'm just
trying to get a sense of whether the direction I'm going is the same
direction that others in the industry have gone.

Thanks... :) 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          daniel@thebelowdomain         ~
~ _____ /  \      |  ~      http://www.djs-consulting.com     ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Relevant Pages

  • Re: Handling outputs (yes, an *on* topic thread!)
    ... Due to the protocol of the interface, ... >often send us multiple responses that comprise a single logical message. ... a screenful of text at a time. ... So I have a common function that will create a "paging file" from ...
    (comp.lang.cobol)
  • [Full-Disclosure] FW: Cisco Vulnerability forensic protocol analysis results.
    ... AMILABS CISCO IP PROTOCOL EXPLOIT TESTING RESULTS ... Cisco router interfaces using either all or one of the following IP ... of a remote Cisco interface uses all of them. ... output buffer failures, 0 output buffers swapped out Router4# ...
    (Full-Disclosure)
  • Re: [RFC v2] Another approach to IR
    ... This is the same as protocol selection for psmouse ... This has nothing to do with the raw interface nor with lirc. ... happens with the evdev interface and already affects the in-kernel drivers. ... On IR remote receivers, internally, there's just one interface per hardware. ...
    (Linux-Kernel)
  • Re: [RFC v2] Another approach to IR
    ... This is the same as protocol selection for psmouse ... This has nothing to do with the raw interface nor with lirc. ... happens with the evdev interface and already affects the in-kernel drivers. ... since it only applicable to IR, not to input devices in general. ...
    (Linux-Kernel)
  • Re: [RFC v2] Another approach to IR
    ... This is the same as protocol selection for psmouse ... This has nothing to do with the raw interface nor with lirc. ... happens with the evdev interface and already affects the in-kernel drivers. ... since it only applicable to IR, not to input devices in general. ...
    (Linux-Kernel)