Re: Proprietary Systems...

> So the Cobol is written to process one field at a time...?

Yes.

> They're all
> displayed as output in one shot,

well, as separate statements. you might display the first part of
the screen, then redraw the bopttom.

> but the input is one field at a time...?

Yes, it was on most minis, I am not positive about HP but I think
so.

 I
> came from a Univac mini, and they sure didn't do it like
that...!

Never worked with those

>
> |
> | I think the applications are likely to be migrated to Unix on
HP,
> | if they haven't already.
>
> I'm fading and couldn't find those articles, but they implied a
large
> installed base was, in the future, going to pushed towards HP
e9000 (I
> thin), or Linux on HP.  And that, at least some of, the
customers were not
> too thrilled.
>
>
> |
> | I'll write a code translator and PC screen handler, but it
will
> | cost about a million to do the project. Only IBM has pockets
that
> | deep - I sure wouldn't do it on spec.
>
> Nup, wouldn't do a $1M project on spec...  But I've never done
anything that
> took more than a few months at most, so I wouldn't know how to
go about
> doing a $1M project...;-)

Did I SAY it was going to take more than a couple of months?

I don't do code I can only sell once, it doesn't make sense. It's
like making one Lincoln Town Car.

If you make code you can only sell once, you better make it really
expensive - cause it wille at your lunch on the back end, not
matter how many maintenance dollars you add.

>  OTOH, sometimes I don't think IBM can worry
> themselves doing a measly $1M project...;-)  In any event, I
don't know if
> IBM will see this as an big enough opportunity, or not...

Doubt it.

> As far a single-field entry screens (again, is THAT what we're
talking
> here...?),

not really, the user wouldn't be able to figure that out.

It would look like an as/400 screen but every time you tab out of
an entry field you are back to the COBOL program

Looks like this (NCR version)

DISPLAY TODAYS-DATE LINE 1 POSITION 1 ERASE.
DISPLAY "CHECK LOOKUP"LINE 1 POSITION 20.
DISPLAY "ENTER CHECK NUMBER " LINE 3 POSITION 1.
ACCEPT WS-CHECK-NO LINE 3 POSITION 20 HIGH REVERSE PROMPT ECHO.

(DO YOUR DATA LOOKUP)

DISPLAY AP-CHECK-NAME LINE 3 POSITION 30.

etc.

had to sit there and count the silly positions - and got them
wrong half the time. (Of course you could lay out the screen on a
layout pad, but that was for weenies - it took too long.)

The nice thing was you could do a lot of logic and conditional
branching between fields. and if the person put in the exact
number of chracters, they didn't need to hit enter - if you had it
set up that way. (It's been 12 years since I was a COBOL
programmer, I got rusty.)

The NCR mini had ONLY COBOL - no basic, assembler, rpg, nothing
else. So I wrote an editor, a macrocompiler, a program generator,
an English language query system (no SQL either) . All in COBOL.
Fun fun fun.

Oh yeah, I wrote a spreadsheet program in COBOL. The good old
days.


> I think the 400 would be pretty ideal...  Not well suited to
> handle screens where each keystroke needs monitored.  (Although,
from what
> I've heard but not done, it appears that's what they attempted
with the
> "text-assist" feature in the I/O controller.)

Maybe on the HP, not on the NCRs.
> difficulties involved in splitting the execution between a PC
and the
> existing Cobol.  Not hard, at all, to set the 400 to process 1
field at a
> time, I wouldn't think...  "Proof in pudding", however...

Don't know how slow it would be.