alex fields
I used to work for a company that used a CASE tool called PROGEN, it's
from Business Computer Design in Hinsdale, IL. Their phone# is
(630)986-0800. The support I got was excellent. It generates mostly
interactive programs (but does do batch as well), has a lot of features
and is reasonably priced (as AS/400 stuff goes). Their tech support is
extrmely good, and you can download updates either on the Internet or
via SNADS to their machine.
HTH.
--
Francis Lapeyre flap...@communique.net
--------------------------------------------------------
Opinions are my own. Otherwise, they are someone else's.
I have used two Case tools which generate RPG source code:
1) Asset
2) Lansa
Of the two I like Asset the best. If you have additional questions, you
can send me some e-mail.
Thanks,
--
John Backer
Real World Training Systems, llc
<----------------------------------------------------->
Year 2000 conversion services, consulting, education
AS/400 RPG and COBOL
<----------------------------------------------------->
HTTP://REAL2000.COM<--------------------->(602)437-1515
Treb Gatte
Opinions expressed here are not necessarily those of my employer...
I currently use a product called Synon 2e - which can generate RPG, COBOL, and
some rather miserable client-server and UNIX code. The RPG/COBOL part is a
mature, server-based product. Synon (the name of the company) has also
released a newer client-server product called Obsydian - which I hear good
things about. However, it is a very young (nice way to say immature) product
with some room for growth and improvement.
If you include 4GLs and other RAD products, you might want to consider Progress
4GL and Magic. Both product receive great reviews, are fairly easy to learn,
and you can get demos of them from the Web for your own enjoyment.
Sincerely
Michael S. Raymond
non...@iag.net
Alex Fields wrote:
>
> I teach Computer Science at a college here in Guam. Some of my
> students are learning RPG for the AS/400. I do not know where to find
> any case tools for that environment. Any ideas? Thanks *a lot* in
> advance...
>
The only type of case tools available on the AS/400 is lower case
tools. They are either code generators or 4-GLs that needs an
interpreter during run-time.
Examples of code generators are
a) Synon (generates cobol, rpg and c)
b) AS/SET (generates rpg)
c) Progen (generates rpg)
Eaxmples of interpreted 4-GLs are
a) Lansa
b) Progress
Both synon and lansa also generate client server apps.
The above list is not exhaustive. You may like to
know that Progen is the probably the cheapest but
I have nil experience with it.
Warning! These case tools are relatively slow compilers when compared
to equivalent products running on PCs and unix boxes. Compilation time
is usually of the order of tens of minutes. Taking more than an hour
to compile a huge program is not unusual. Of course actual timing is
dependent on your AS/400's processor, disk space and memory.
There may be upper case tools that claims to support the AS/400 but
they do not run on the AS/400.
Thanks and good luck
Patrick R. Arehart
Owner/Arehart Consulting
** 8 Years of computing EXCELLENCE! **
In article <32f5ef0e...@news.zippo.com>, al...@latte.net (Alex Fields)
writes:
So does Progen (optionally).
> The above list is not exhaustive. You may like to
> know that Progen is the probably the cheapest but
> I have nil experience with it.
>
> Warning! These case tools are relatively slow compilers when compared
> to equivalent products running on PCs and unix boxes. Compilation time
> is usually of the order of tens of minutes. Taking more than an hour
> to compile a huge program is not unusual. Of course actual timing is
> dependent on your AS/400's processor, disk space and memory.
I have not had that problem with Progen, even on a 9402-E04 with only
988MB of DASD and 128MB main storage. It did take about 5 minutes per
program, but that wasn't much worse than compiling similar applications
that were "hand-written". Progen is a lot more efficient than Synon
(I've
use both). the cheif difference between the two is that Synon can
generate
the whole application for you (including the files), but the field names
are incomprehensible. Progen uses your own DDS files, and at least you
can understand what's going on. You need to know RPG fairly well to be
productive using Progen, while I'd say Synon 2/E is more
language-independent.
That is, you need to understand how relational databases work, but not
necessarily how RPG, COBOL, etc., works.
> There may be upper case tools that claims to support the AS/400 but
> they do not run on the AS/400.
Such as?
> Warning! These case tools are relatively slow compilers when compared
> to equivalent products running on PCs and unix boxes. Compilation time
> is usually of the order of tens of minutes. Taking more than an hour
> to compile a huge program is not unusual. Of course actual timing is
> dependent on your AS/400's processor, disk space and memory.
>
In my experience, as long as you are working on a decent sized machine,
the compile times are not THAT much longer. For Asset, the code must
first be converted to RPG source code and then compiled with the RPG/400
compiler. The case tool does this for you and only regenerates the
changed code...
Things change. We are reopening the CASE tool file and I spent a day
looking at LANSA, where it is now, where it is going.
Five years ago I was impressed with their knowledge of the AS/400's
abilities and the code that LANSA generated. This stuff was written to
optimally use the AS/400 - the developers understood the machine. That has
not changed. It appeared they have full knowledge of ILE, triggers,
what's good, what's still too young . Based on their past history and
their growth pattern, I have to believe they have a great future, as does
anyone that jumps on board.
I must admit I almost cried when I realized where we could be to-day, had
we been using the tool since our initial look. All development in
applications would have been fully migratable to all the new application
sets, ie VB, C, and so on.
No investigation would be complete without a good look at LANSA, including
examination of real code. Sorry if it sounds like an ad, but I am a
convert.
That's all,
Jayne Little
jli...@wat.hookup.net
A university professor set an examination question in which he asked what
is the difference between ignorance and apathy. The professor had to give
an A+ to a student who answered: I don't know and I don't care.
-- Richard Pratt, Pacific Computer Weekly, 20 July 1990
>Alex Fields wrote:
>>
>> I teach Computer Science at a college here in Guam. Some of my
>> students are learning RPG for the AS/400. I do not know where to find
>> any case tools for that environment. Any ideas? Thanks *a lot* in
>> advance...
>>
>> alex fields
>>
>> al...@latte.net
>I used to work for a company that used a CASE tool called PROGEN, it's
>from Business Computer Design in Hinsdale, IL. Their phone# is
>(630)986-0800. The support I got was excellent. It generates mostly
>interactive programs (but does do batch as well), has a lot of features
>and is reasonably priced (as AS/400 stuff goes). Their tech support is
>extrmely good, and you can download updates either on the Internet or
>via SNADS to their machine.
You might also want to look at LANSA, which has a nice AS/400 development
environment, as well as some windows client stuff. They are based in
Australia and have a very good web page (for which, of course, I lost the
URL).
George Smith
Knut Berg
>Five years ago I was impressed with their knowledge of the AS/400's
>abilities and the code that LANSA generated. This stuff was written to
>optimally use the AS/400 - the developers understood the machine. That has
>not changed. It appeared they have full knowledge of ILE, triggers,
>what's good, what's still too young .
LANSA must have changed very dramatically between 1990 and 1992. In
1990, when I examined LANSA, it was a very slow interpreted language.
I assumed that it was interpreted because it cannot run without a
runtime module then. The local LANSA distributor was not able to
explain how LANSA work to my satisfaction and until today, LANSA does
not sell well in my country.
I chose AS/SET because the local distributor clearly show their
competency with AS/SET and at that time AS/SET seems to be faster at
code generation when compared to SYNON. Furthermore, we had no
difficulty understanding the RPG code generated by AS/SET even though
we are RPG novices (and still are).
Ironically, today, the technical people who sold us AS/SET has left
that distributor and are selling LANSA!
>Five years ago I was impressed with their knowledge of the AS/400's
>abilities and the code that LANSA generated. This stuff was written to
>optimally use the AS/400 - the developers understood the machine. That has
>not changed. It appeared they have full knowledge of ILE, triggers,
>what's good, what's still too young . Based on their past history and
>their growth pattern, I have to believe they have a great future, as does
>anyone that jumps on board.
I must agree, in 1989-1994 I have worked with Synon/2.
In 1995-1996 I have worked with Lansa and now I'm back at
Synon/2.
Where Lansa is using new things like ILE, Synon/2 has not changed
much.
It seems that Synon the company thid put the time & money in Obsydian
and forgot the good old Synon/2E 5250 tool.
Greetings, Herbert
---
The Trans-Siberian Railroad Page, http://www.xs4all.nl/~hgj/
Ooi SC <oo...@jhlib.pc.my> wrote in article
<32fbe862...@news.jaring.my>...
> On 7 Feb 1997 04:56:26 GMT, "Jayne A Little" <jli...@wat.hookup.net>
> wrote:
>
>
> >Five years ago I was impressed with their knowledge of the AS/400's
> >abilities and the code that LANSA generated. This stuff was written to
> >optimally use the AS/400 - the developers understood the machine. That
has
> >not changed. It appeared they have full knowledge of ILE, triggers,
> >what's good, what's still too young .
>
> I chose AS/SET because the local distributor clearly show their
> competency with AS/SET and at that time AS/SET seems to be faster at
> code generation when compared to SYNON. Furthermore, we had no
> difficulty understanding the RPG code generated by AS/SET even though
> we are RPG novices (and still are).
We did a detail comparisons between AS/SET and LANSA back then. We were
very experienced RPG developers at the time, but were being bogged down by
what we wanted to do, versus the time we had. We needed something which
did screen handling and sub-file processing that our users were used to
seeing. At the time we were disappointed with ASSET's RPG code, as
compared to LANSA. AS/SET's was very basic & failed a lot even in the
classroom demo environment. This might have been a function of the
distributor in our area -- or it might have been a function of the product.
Based on the committed AS/SET users, it must have improved. LANSA's code
was complex, but it optimally handled file i/o, subfiles, error routines,
opens, and so on. It was cool.
I wouldn't mind reading from someone who is an expert in RPG though, to see
if AS/SET has improved.
>
> Ironically, today, the technical people who sold us AS/SET has left
> that distributor and are selling LANSA!
>
I can understand that. Based on what we saw, it was probably a good long
term career move.
Jayne Little
jli...@wat.hookup.net
Cambridge, Ontario, Canada
>In my experience, as long as you are working on a decent sized machine,
>the compile times are not THAT much longer. For Asset, the code must
>first be converted to RPG source code and then compiled with the RPG/400
>compiler. The case tool does this for you and only regenerates the
>changed code...
My idea of a huge program is a display program with about 15 screens,
few hundred lines of AS/SET action code that gets generated as a few
thousand lines of RPG/400 code before being compiled.
On a F35 with 48 MB RAM & V3R1 & AS/SET v4, that took 1 hour. On a 500
with 196 MB RAM & V3R7 & AS/SET v4, that took 27 minutes. Timing is
measured when nothing else is running.
To be fair to AS/SET, the generated AS/SET RPG code takes care of a
lot of things, e.g. automatic help text on a field by field and screen
by screen basis, save a copy of data for comparison just before
updating to avoid unnecessary i/o, etc.
Still, I have an equivalent clipper code generator running on my
Pentium that takes less than a minute to generate, compile and link
equivalent program.
The main reason that I am sticking to AS/SET is that excluding
designer's and programmer's bugs, the generated code is absolutely
rock solid. However, this is probably just a reflection of the
reliability of OS/400 and DB2/400.
> At the time we were disappointed with ASSET's RPG code, as
>compared to LANSA. AS/SET's was very basic & failed a lot even in the
>classroom demo environment.
The key to using AS/SET (and probably any other code generators or
4GLs) is to write programs to do only what AS/SET can do. The other
thing that we did was to document all bugs and workarounds that we
discovered and drum them into the head of every new hiree. We also
never modify the RPG code generated. All modifications were done at
the AS/SET action code.
>This might have been a function of the distributor in our area -- or it might
> have been a function of the product.
In my case, it was definitely because the AS/SET distributor (who had
very experienced RPG programmers) was technically more competent than
the SYNON distributor (at that time).
>> Ironically, today, the technical people who sold us AS/SET has left
>> that distributor and are selling LANSA!
>>
>I can understand that. Based on what we saw, it was probably a good long
>term career move.
Actually it was for an entirely different reason! SSA bought out that
distributor and turned them into an SSA subsidiary. The AS/SET guru
who was one of the company owners decided to leave. Since he could not
distribute AS/SET and SYNON, I guess he chose LANSA in his new
company. One day, when I meet him, I must ask which is the better
product :-) considering that he assured me that AS/SET was the better
product seven years ago.
OBSYDIAN
It's a PC client server application that can be exported to
the AS400.
Ooi SC <oo...@jhlib.pc.my> wrote in article
<32fc6c25...@news.jaring.my>...
> Eaxmples of interpreted 4-GLs are
>
> a) Lansa
> b) Progress
>
> Both synon and lansa also generate client server apps.
>
In actual fact, LANSA is a 4GL which generates and compiles RPG on the
AS/400, and C on all the other platforms it supports (HP, NT, OS/2 etc.).
CODING:
All manual coding and maintenance is done in its 4GL, and LANSA programs
easily interface with native legacy systems either as called objects or
calling objects. Systems may also be written using customizable
interactive question-and-answer templates, or modeled using its object
modeller (Application data/process modeling).
MAINTENANCE:
All maintenance is performed on the original 4GL code, and all debugging is
done at the 4GL level. Never go to the underlying 3GL (RPG, COBOL, C).
PERFORMANCE:
Application performance is optimized for each platform, taking advantage of
native OS and DBMS features, transparent to the programmer.
PRODUCTIVITY:
Programming productivity is increased 5 to 15 times over RPG or COBOL
development on the AS/400 (based on feedback at user conferences and user
group discussions), and AS/400-to-PC client/server systems are delivered
using the same 4GL instruction set as on the AS/400.
RAMP UP TIME:
Programmers are typically productive in a LANSA shop after one week of
training.
COMMITMENT:
LANSA programs written even TEN years ago on a S/38 can simply be
recompiled today to take advantage of advances in OS/400 and DB2/400, and
can even be distributed in a client/server environment with little or no
change.
CONCLUSION:
LANSA is clearly the way to go for anyone developing new systems or
extending existing systems on an AS/400. Check it out at www.lansa.com .
--
Andrew L. Vaiciunas
and...@netcom.ca
I've been reading this thread with interest, as I am an AS/Set
professional. So far I've seen only the "big three" (AS/Set, Synon, and
Lansa) mentioned. I guess that since my CASE sales days at least three
years back, the others (Cognos, et al) have dropped off. I will drop the
sales talk, and try to dispassionately evaluate these three packages.
This should be fairly easy, as AS/Set is no longer sold as an individual
package unless you know to ask for it -- then SSA will gouge you for it
even though they officially no longer sell it.
1) AS/Set (ADK) -- a FANTASTIC tool as long as you don't use it as SSA
instructs you to in the tutorial. The repository is pure bunk. The user
interfaces (other than the screen editor, which FAR outpaces SDA), really
could use work. While data models containing multiple files generate a
quick sub-file program with windows, you establish great overhead by
creating the same windows over and over again in subsequent programs using
the instructed methods. Generates V1R3 RPG, but programs can be installed
on any system within your enterprise without recompiling (unless you have
an OS/400 compatibility problem). Don't try using the IWS option, even if
you already use OS/2.
2) Lansa -- I don't have much info here, other than quotes from a few
people that know both it AND AS/Set stating that "if you hate AS/Set,
you'll LOATH Lansa". It was interpretive at one time, I don't know if it
still is.
3) Synon 2e -- It was posted earlier that it seemed that Synon had placed
all of their efforts into Obsydian. No offense, but Duhhh! Of course --
Obsydian's pretty, client/server, state of the art, and the future "cash
cow" for Synon. Much as SSA dropped significant development on AS/Set ADK
(green screen) in favor of IWS (GUI), so has Synon concentrated its
efforts on Obsydian over 2e. The difference between Obsydian and IWS
being that Obsydian has been successful while AS/Set has been dropped
altogether in all flavors.
ProGen is NOT a CASE tool (in fact, their ad's revel in the "no CASE"
moniker). The problem is that there is no viable CASE tool for the
AS/400. Visible Analyst provides an upper CASE tool that will generate
file DDS, but no referential integrity, inheritance, or polymorphism.
Until recently, the AS/400 did not even support RI natively (and today's
support is poor), and inheritance/polymorphism are unavailable altogether
with the possible exception of UIM constructs. You CAN inherit if you
recompile the file and generate level checks throughout the system.
Anyone that has generated an IEF application on the mainframe can tell you
that CASE is SLOW. In the end, CASE generators are a poor substitute for
a well designed set of in-house templates and a few good programmers. As
with many things, the technology just hasn't caught up with the engineers
yet...
JMHO,
Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC USA
E-Mail: DAsm...@AOL.COM
"A lot of fellows these days have a B.A., an M.D., or a Ph.D. What they
don't have is a J.O.B." -- "Fats" Domino