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

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

On Sat, 26 Mar 2005 13:02:14 -0600, LX-i <lxi0007@netscape.net> wrote:

>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.
I tend to use a indexed file (database file for some). This because it
will be portable across systems.

This also enables me to add/change functionality easily without
depending on the software supplier.

So I have a common function that will create a "paging file" from
whatever information we output to that file.
E.g. on a particular screen I define the paging as 11 line per page,
on others 20 per page or 5 per page. Engine is the same.

Hope the above helps.





Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

LX-i wrote:
> 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++++                                            ~
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

1. Initially I was a bit  by the term "paging file" as I
usually think of it as being related to virtual memory management.

2. Why doesn't GAG handle all of the message text concatenated into one
file? I'm not a mainframer, but I would let the system utilities
available to the terminal emulator user break up the file into screens.
(For example whatever the mainframe equivalent of "less" is.)

3. The other possiblity is that the terminal emulation software itself
has a "screen mode" which buffers output and allows the user to scroll
back and forth.

HTH.

LX-i wrote:
>
> 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.
>
You jest of course about the paper tape. Just out of curiosity are you
aware of paper tape being used at all in the USAF ? It was the first we
used back in '60s and never punch cards. Then we progressed,
key-to-tape, key-to-disk, then supplemented by OMR documents.
VDUs/Screens followed much later.

Jimmy

epc8@juno.com wrote:
> 1. Initially I was a bit  by the term "paging file" as I
> usually think of it as being related to virtual memory management.

Nope - this is the same concept, but for output management.

> 2. Why doesn't GAG handle all of the message text concatenated into one
> file? I'm not a mainframer, but I would let the system utilities
> available to the terminal emulator user break up the file into screens.
> (For example whatever the mainframe equivalent of "less" is.)

GAG *does* handle it.  The problem we're running into is that it's, as
the vendor describes it, a "system-provided, user-maintained" file.
This means that they size it and provide the calls, and we use it (and,
ideally, it "just works").  We're limited to 120 data pages, each with
up to 2,200 characters.  Where our main problem comes in is that
messages from this interface partner can have more than 120 parts, in
extreme cases.  We're filling up a file before the user has seen the
first one.

(GAG actually works very well - before we had the GUI, that's the way
output came up.  You'd pull up the screen, process the inquiry, and the
text would come back, with the cursor on the transaction (in line 24)
that would bring back the next screenful of data.)

Our main problem is that we're having messages go into this file, but we
don't have a way of looking at its contents (outside of the calls).

> 3. The other possiblity is that the terminal emulation software itself
> has a "screen mode" which buffers output and allows the user to scroll
> back and forth.

I don't think so - it's a UTS-60 emulator.  Thanks for your responses,
though.  :)


--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

James J. Gavan wrote:
> LX-i wrote:
> 
> You jest of course about the paper tape. Just out of curiosity are you
> aware of paper tape being used at all in the USAF ? It was the first we
> used back in '60s and never punch cards. Then we progressed,
> key-to-tape, key-to-disk, then supplemented by OMR documents.
> VDUs/Screens followed much later.

I'm not aware of any paper tape still in use.  These days, the
"dinosaurs" still edit their files using the mainframe editors.  :)


--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        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++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

"LX-i" <lxi0007@netscape.net> wrote in message
 news:3fc8f$4245b054$45491f85$15600@KNOLO
GY.NET...
> 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"?

I have used a database table for this since 1985. Create a table statically
or dynamically and lay the message parts into it as separate rows. Have a
column that gives the sequence of messages, and rows within a message, by an
assigned integer. (If you want to be clever you can allow sorting on
different criteria and simply reassign the message numbers to an ORDERED
temporary table, that reflects the required sequence.) You can then provide
a series of "Begin", "Next", "End" and "Previous" buttons or functions that
allow the presentation table to be accessed forwards or backwards. I tried
doing it with cursors using ASC and DESC with ORDERED but it was too messy
and inflexible. Using direct singleton accesses is actually quicker and very
simple, because all you have to worry about is the current row. Start loads
a value of 1, End loads a count of rows, and Next and Previous adjust the
current row number up or down by 1 respectively. The SELECT doesn't change,
and the rows are buffered in memory by the DB software.

You can also provide direct access to any given message number, by loading
that number to the current row number.

(You can even provide dynamic access where the message number isn't known,
by searching on the normal keys and retrieving the required row in the usual
way. You then just load the message number to the current row number so that
next and previous will work correctly from this point.)

Works for me... and has done for a very long time now...

Pete.

<remainder snipped>

On Sat, 26 Mar 2005 13:02:14 -0600 LX-i <lxi0007@netscape.net> wrote:

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

Is GAG a TP monitor? Or does it run under CICS or some other TP monitor?

Is the response guaranteed?

Is the response synchronous?

Is the response on demand?

More information is required.

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

Já pensaste ajudar cá em Portugal quem precisa, em vez de fazer figura,
quiçá de "ignorante" nas matérias ... nos "States" ??? Manias, não é ??? Faz
um esforço, por favor ... que o "nosso" pessoal precisa !!! Não te vejo nos
"nossos" FORUNS !!!

Mário Matos

"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
 news:tjdb411j152e9tr028etm62ubfr9p5jlof@
4ax.com...
> On Sat, 26 Mar 2005 13:02:14 -0600, LX-i <lxi0007@netscape.net> wrote:
> 
> I tend to use a indexed file (database file for some). This because it
> will be portable across systems.
>
> This also enables me to add/change functionality easily without
> depending on the software supplier.
>
> So I have a common function that will create a "paging file" from
> whatever information we output to that file.
> E.g. on a particular screen I define the paging as 11 line per page,
> on others 20 per page or 5 per page. Engine is the same.
>
> Hope the above helps.
>
>
>
>
>
> Frederico Fonseca
> ema il: frederico_fonseca at syssoft-int.com

A propósito, Frederico ...
Qual a tua ideia do NetExpress em Portugal representada pela WebPower
(www.webpower.pt) ???

Como entendes a política de "royalties" atribuidas aos "magnatas" do nosso
amigo "COBOL" ???

A informação, onde está ???

Como se forma um "futuro" apaixonado desta linguagem maravilhosa ???

Como se cria uma pequena aplicação formada em "objectos" no COBOL ... para
ignorantes ???

Como se cria uma "FUNÇÃO" (ISO2000) no COBOL ??? Exemplifica ... em
Portugal.

Fala comigo, Frederico da Fonseca ... já que estás ... por aí (vagamente, no
meu entender) !!!

Faz-te útil, se é que existes ...

Nota importante: Eu já "falei" contigo, um dia ...

Mário Matos

"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
 news:tjdb411j152e9tr028etm62ubfr9p5jlof@
4ax.com...
> On Sat, 26 Mar 2005 13:02:14 -0600, LX-i <lxi0007@netscape.net> wrote:
> 
> I tend to use a indexed file (database file for some). This because it
> will be portable across systems.
>
> This also enables me to add/change functionality easily without
> depending on the software supplier.
>
> So I have a common function that will create a "paging file" from
> whatever information we output to that file.
> E.g. on a particular screen I define the paging as 11 line per page,
> on others 20 per page or 5 per page. Engine is the same.
>
> Hope the above helps.
>
>
>
>
>
> Frederico Fonseca
> ema il: frederico_fonseca at syssoft-int.com