RE: Proprietary Systems...

Brad,

Thanks a lot...  See questions inline...

| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Brad Jensen
| Sent: Thursday, November 29, 2001 1:01 AM
| To: midrange-l@midrange.com
| Subject: Re: Proprietary Systems...
|
|
|
| ----- Original Message -----
| From: "jt" <jt@ee.net>
| To: <midrange-l@midrange.com>
| Sent: Wednesday, November 28, 2001 10:45 PM
| Subject: RE: Proprietary Systems...
|
|
| > In marketing, some customers are VERY loyal to brand, and some
| aren't.  VERY
| > hard to get the first group to switch brands... (Unless you
| announce that
| > brand isn't going to be available, that is...:-)
| >
| > Never worked on HP...  So what kind of DB does e3000 run on,
|
| indexed files, as I remember (but that was long ago)
|
| > and how hard
| > would it be to convert to DB2/400?  Are the reports true of a
| fair about of
| > in-house CBL?
|
| Yes.
|
| COBOL/400 is something of a strange beast,  (I mean if you are
| coming from minicomputer COBOL, as I did) particularly screen
| files.
|
| The only way you could translate those programs to the AS/400 is
| if you took the screen handling and made it calls to a client
| server module, and put the screen handling on PCs. I could not
| begin to tell you how it might perform, since the program would
| have to wake up and process each field input as an interactive
| cycle - of course if you are avoiding CINT that might be pretty
| fast.

So the Cobol is written to process one field at a time...?  They're all
displayed as output in one shot, but the input is one field at a time...?  I
came from a Univac mini, and they sure didn't do it like that...!

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

|
| The only mini I ever saw do page mode screens was Wang VS, I
| think.
|
| NCR and Burroughs used them on their mainframes, but not minis.
|
| Most minis used screens that came from the glass tty evolution -
| display a bunch of field descriptions on the screen with line and
| position and attribute, then accept them one by one in interactive
| mode.
|
| Uses up a lot of processor but it's easy to write code for.
|
| AS/400 is a downsized mainframe screen - same full screen mode,
| attribute bytes between fields (weird!)
|
| Fill in all the fields and hit transmit - I mean enter.

As far a single-field entry screens (again, is THAT what we're talking
here...?), 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.)  But I wouldn't contemplate
the 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...

Thanks again, and g'nite...


jt