Re: Replacing IIS with iSeries 400 -- MIDRANGE-L

-----Original Message-----
From: Joe Pluta <joepluta@PlutaBrothers.com>
To: midrange-l@midrange.com <midrange-l@midrange.com>
Date: 03 October 2001 19:25
Subject: RE: Replacing IIS with iSeries 400


>> > But I thought you hadn't used LANSA at all? to be honest I haven't
tried
>> > BOMs or MRP in LANSA either so I can't comment on those but we have
>> > developed some pretty complex web based systems, standalone and with
and
>> > full legacy system integration.
>>
>> I haven't.  Just wondering if anybody has.  Obviously you
>> haven't.  And you
>> don't write low-level stuff, either.  What do you write?
>
>Given our miscommunications thus faer, I thought I should clarify this
>statement.  "Obviously you haven't" meant you haven't written an MRP gen,
as
>you stated.  And you've also said you don't write middleware.  I don't know
>if anybody has written complex business logic in LANSA, and that's what I
>was asking.  I didn't mean to imply you've never written anything at all in
>LANSA, simply that I don't see any evidence of using LANSA for industrial
>strength programming.


We are writing code just as 'industrial stength' as anything we've ever done
in RPG or Cobol, that's not to say we would not write routines in C, Java,
RPG etc if we thought it was easier or faster for a particular task but the
important thing is we can call them in LANSA just a if they were
subroutines, J......  here I go again on that M.... hype.

>
>In fact, it would be nice if LANSA (or anybody) were capable of a higher
>level of abstraction of programming - I've always hoped someone would get
to
>the next level of application generation.  AS/SET certainly never made it,
>although their data modeling had promise.  Those of us who called it @RPG
>did so for a reason - it really was little more than RPG with aome
>additional built-in features.  And the generated code was horrendous
(though
>in truth not as bad as some others).
>

My utopia would be to just write the business rules (based around a
relational database) and leave the rest to the technology of the day, with
ease of maintenance & execution time being the priorities in that order.
LANSA goes some way towards this and they have seperated out the UI which is
a help (as you have). Our InsureIT product tries to have all the business
rules in a database with no algorithms (even for complex insurance rating
calculations) so that the end user (underwriters in this case) can maintain
existing insurance products & build new ones by cloning.

>I've spent the last decade or so concentrating on the UI side of things,
and
>PSC400 is the result of that.  It's very good at making existing code UI
>independent, but it's not designed to actually create new code.  Perhaps
>it's time to begin rethinking the application development side of the coin.
>
>Anyway, thanks for the interaction.  It's been enlightening.


I've enjoyed it and it's made me think of a few things we need to do, pity
no one joined in on the merits of other products. Is Don anymore enlightned?

PS  I don't write code anymore, just chase invoices, argue about contracts,
pay the bills etc., but I like to think I understand the technical issues.

Mike.
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.
>
>