Home > Archive > Cobol > March 2005 > Handling outputs (yes, an *on* topic thread!)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Frederico Fonseca 2005-03-26, 8:55 pm |
| 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
| |
| epc8@juno.com 2005-03-26, 8:55 pm |
|
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.
| |
| James J. Gavan 2005-03-26, 8:55 pm |
| 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Pete Dashwood 2005-03-27, 3:55 am |
|
"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>
| |
| Binyamin Dissen 2005-03-27, 8:55 pm |
| 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
| |
|
| Pete Dashwood wrote:
> "LX-i" <lxi0007@netscape.net> wrote in message
> news:3fc8f$4245b054$45491f85$15600@KNOLO
GY.NET...
>
>
>
> I have used a database table for this since 1985.
Ah ha! So my design *is* somewhat of a common technique within the
industry. :)
> 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.
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).
> 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...
;> )
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
|
| Binyamin Dissen wrote:
> 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?
GAG is a transaction. (This is a Unisys mainframe, not IBM.)
> Is the response guaranteed?
It's supposed to be - that's what's causing the problem. People will
get a "MsgWait" light (either on their terminal or web browser) - when
they process it, they get "no messages waiting".
> Is the response synchronous?
> Is the response on demand?
It's asynchronous. When we send the initial message to the other
system, an "ok" status means that they actually received it (real-time).
Their response could be sub-second, or it could be 3 days from now
(parts being backordered, for example).
> More information is required.
Well, I've sort of decided on a solution (and, from what I've seen in
here, it's a solution that others have used with success). I appreciate
your willingness to assist me. :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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:880e4$424755a9$45491f85$31707@KNOLO
GY.NET...
> Pete Dashwood wrote: ----WITH SOME LIBERAL CUTTING ;-)
>
> 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.
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.
[color=darkred]
> 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.
>
> 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
| |
| Howard Brazee 2005-03-28, 3:55 pm |
|
On 26-Mar-2005, LX-i <lxi0007@netscape.net> wrote:
> I'm not aware of any paper tape still in use. These days, the
> "dinosaurs" still edit their files using the mainframe editors. :)
Only because we have the option to pick which editors we want to use.
Sometimes I use a PC editor, but usually not.
|
|
|
|
|