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

From: jce (defaultuser_at_hotmail.com)
Date: 03/28/05 

Date: Mon, 28 Mar 2005 06:40:45 GMT

"LX-i" <lxi0007@netscape.net> wrote in message
news:880e4$424755a9$45491f85$31707@KNOLOGY.NET...
> Pete Dashwood wrote: ----WITH SOME LIBERAL CUTTING ;-)
>> "LX-i" <lxi0007@netscape.net> wrote in message
>> news:3fc8f$4245b054$45491f85$15600@KNOLOGY.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.
>
> Ah ha! So my design *is* somewhat of a common technique within the
> industry. :)

If this is a CICS transaction we have previously used anything from TDQs to
MQ Series and DB2.

I think these days it's _so_ easy to create temporary dynamic tables that it
really makes the decision easy.
A static table looks more to fit the role. I would always have two
identifiers to identify a record, one being an id, one being a correlation
id.
I would then also have a segment number.

A robust solution would be to use a JMS. I know Oracle AQ has JMS
implementation as has DB2. This would enable you to setup a pub-sub model,
or a req-response model.
Perhaps, in the future, ordering a part would create as response for
multiple people.

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

Perhaps you should use scrollable cursors? This does the buffering for
you...most drivers support this now (I would think) - now that was going out
on a limb with a CYA clause if I ever saw one.

> I think my design will accommodate most of that - but, the messages I'm
> looking at have a really short-term life expectancy. If they have to do
> with a particular part ordered for a specific airplane, they'll hang
> around 4-5 days. Anything else will be deleted when the user logs out
> (our software has a 15-minute time-out - so, folks don't stay logged on
> during lunch).
If you have a part ordered wouldn't you think that someone would care to
look at the response?
Seems like those nice web sites = do not click submit twice because our
crappy solution will order two......Wait for a response, because after that
it's too late.

>> Works for me... and has done for a very long time now...
>
> Great! Like I said, for the GUI, we're already using a table. Right now,
> I'm using multiple rows with a sequence number and 6,000-character rows of
> text (this is due to a limitation on the size of an auditable event - much
> bigger, and it can't be audited). I think that CLOB might work better,
> but handling them in 6k chunks isn't too bad. Besides, for the GUI, all
> we do is concatenate the chunks together and send it in one big output.
> (Web browsers aren't limited to 24 lines, that goodness... ;> )
6000 characters is not big, there is no reason to use CLOBs that I can see.

But why oh why spend the time to support 10% of your users? Why not move
them? I find usually when pressed the rational for needing the old interface
goes from "it's important because we have robots/scripts that run"
to....."i'm too old to worry about a new web based thingymajiggy....".

I would always wish that the replacement offers a significant improvement
over the older to make the decision so easy that it's not a decision.

JCE

Quantcast