Future of Forte

Hi
I'm interested on the future of Fortè
I've heard that iPlanet (the new application server of SUN) does not support
forte and does not intend to do it.
So I'm wandering where Fortè will go.
I hoped to see Fortè integrating with Java and hoped that SUN wuold have given a
strong indication in that direction, but it seems that we will have to decide
wheather to stay on Fortè or start using Java.
Can someone shed some light on the subject.
TIA
Luca

Similar Messages

RE: (forte-users) RE: Forte 3 vs Java -- Productivity ( wasFutur e of F

Bravo. I completely agree. Right now Forte is helping me solve my business
requirements fast and that's all I care about. If Java will do that for me
tomorrow and I will use it. Otherwise I will keep using whatever
language(s)/tool(s) that helps me get the job done.
Ka
-----Original Message-----
From: Genesio, Fabrizio [mailto:fabrizio.genesiodatasign.ch]
Sent: Monday, February 14, 2000 5:22 AM
To: kamranaminyahoo.com
Subject: RE: (forte-users) RE: Forte 3 vs Java -- Productivity ( was
Futur e of Forte )
What an interesting debate....
May I just add some considerations?
- Successful Project capable to produce effective and maintainable
system. That's in my opinion should be our goal as professional IT
actors. Languages are just means to reach this goal. Therefore I would
like to see IT professional considering all the aspects of software
development, and not only the code and the languages.
- About distributed features in Java systems... Sure, you can do
in Java a lot of nice things, but, today, how much would it cost to
develop in Java real mission-critical distributed application?. I am
talking here about the IT "headaches" Forté has been capable to solve
during the past 5 years. Should I make examples? What about distributed
events, what about distributed transactions, what about fail-over, what
about load-balancing? Or, to move towards a more comprehensive view of
software development (and maintenance), what about partitioning (or, to
talk J2EE slang, assembly), what about deployment, what about monitoring
and run-time management? Is there, available today, an alternative to
Forté that cover so many aspects of enterprise-class systems? I
apologize, but I do not see one, or at least not yet. It not only a
matter of languages...Nevertheless, I believe tomorrow is another day,
Java will evolve as well as the environments for it (including Forté for
Java), and the all will be mature enough to really support distributed
application.
- This leads me to express a wish. I like the way one can turned
down the Singleton issue. However this is a perfect example of the
difference from Forté to Java. On one side you have an abstraction, that
hides complexity. On the other side you are (again) back at the
"plumbing" level. Now I do not know what you think about in my opinion
it is about time we move on from the "prehistorical age", making
abstraction, start to worry more about the business requirements (and
the users' needs). We should stop this sort of religious fight for the
best language (the term "crusade" came to my mind), and using our energy
to push for an easier integration, a effort-less plug-in between
components. There is no perfect solutions, all languages have positive
and negatives points. However all we really need is to learn to use each
technologies at the right time and place, and having all pieces
collaborating between each other. Pretty much like a house, where
several material are used, each of them useful but none of them capable
to replace all the others. Of course, it is clever to use sometimes only
wood, and some other times only concrete. However, most of the time you
need both, and you absolutely want them "collaborating" together to be
able to live in your house. Well, that's what "in primis" we have to ask
for to Forté, and to SUN, in particular: easy integration and
collaboration between TOOL and Java, a seamless cooperation between
partitions and EJBs.
I look forward to discuss all this at FORUM2000....
Fabrizio Genesio
Datasign AG für Informatik
ch. d'Eysins 53a
CH-1260 Nyon
Switzerland
Tel.: +41 22 361 04 04
Fax: +41 22 361 01 10
e-mail: fabrizio.genesiodatasign.ch
<mailto:fabrizio.genesiodatasign.ch>
URL: www.datasign.ch <http://www.datasign.ch>
-----Original Message-----
From: David Vydra [SMTP:dvydrajavamentor.com]
Sent: Thursday, 10 February 2000 04:57
To: Thomas Mercer-Hursh, Ph.D.
Cc: kamranaminyahoo.com
Subject: Re: (forte-users) RE: Forte 3 vs Java --
Productivity ( was Future of Forte )
At 03:06 PM 2/10/00 -0800, you wrote:
>At 06:28 AM 2/10/2000 , David Vydra wrote:
>How familiar are you with this product? Does it tell you
something that
>all of the FJEE tools are written in TOOL?
So what? IBM's VisualAge for Java is written in Smalltalk.
Look, if Forte management thought that they could fight the Java
invasion
they would tell their engineers to make TOOL much, much better.
Instead
they put most of the effort into SynerJ and sold the company to
Sun. Smart
move if you ask me.
>As for what is or is not a 4GL, I think that there are so many
>incomparabily different types of languages available these days
and in so
>many flavors, that any kind of division into generations is, at
the very
>best, extremely subjective. Certainly, TOOL isn't very much
like some of
>the classic procedural 4GLs, but personally I am very
comfortable calling
>it an OO4GL in comparison to the more common OO3GLs around,
like Java.
Agreed.
=========================================================================
>Thomas Mercer-Hursh, Ph.D email:
thomascintegrity.com
>Computing Integrity, Inc. sales:
510-233-9329
>550 Casey Drive - Cypress Point support:
510-233-9327
>Point Richmond, CA 94801-3751 fax:
510-233-6950
>
>--
>For the archives, go to: http://lists.xpedior.com/forte-users
and use
>the login: forte and the password: archive. To unsubscribe,
send in a new
>email the word: 'Unsubscribe' to:
forte-users-requestlists.xpedior.com
>
>
David Vydra
dvydrajavamentor.com
www.javamentor.com
(877) 270 - 9003
For the archives, go to: http://lists.xpedior.com/forte-users
and use
the login: forte and the password: archive. To unsubscribe, send
in a new
email the word: 'Unsubscribe' to:
forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

At 06:28 AM 2/10/2000 , David Vydra wrote:
Also, it is a little unfair to compare a product in its third production
release with a beta product. I agree that for certain projects Forte 3 is
the right choice today. The issue for me is: will Sun continue the support
of TOOL? How much of a 4GL is TOOL? Will TOOL become more 4GL in the
future or will it be phased out?How familiar are you with this product? Does it tell you something that
all of the FJEE tools are written in TOOL?
As for what is or is not a 4GL, I think that there are so many
incomparabily different types of languages available these days and in so
many flavors, that any kind of division into generations is, at the very
best, extremely subjective. Certainly, TOOL isn't very much like some of
the classic procedural 4GLs, but personally I am very comfortable calling
it an OO4GL in comparison to the more common OO3GLs around, like Java.
=========================================================================
Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950

RE: (forte-users) RE: Forte 3 vs Java -- Productivity (wasFutur e of Fo

Excellent point David, and right on the money in my opinion.
-----Original Message-----
From: David Vydra [mailto:dvydrajavamentor.com]
Sent: Thursday, February 10, 2000 10:57 AM
To: Thomas Mercer-Hursh, Ph.D.
Cc: kamranaminyahoo.com
Subject: Re: (forte-users) RE: Forte 3 vs Java -- Productivity ( was
Future of Forte )
At 03:06 PM 2/10/00 -0800, you wrote:
At 06:28 AM 2/10/2000 , David Vydra wrote:
How familiar are you with this product? Does it tell you something that
all of the FJEE tools are written in TOOL?So what? IBM's VisualAge for Java is written in Smalltalk.
Look, if Forte management thought that they could fight the Java invasion
they would tell their engineers to make TOOL much, much better. Instead
they put most of the effort into SynerJ and sold the company to Sun. Smart
move if you ask me.
As for what is or is not a 4GL, I think that there are so many
incomparabily different types of languages available these days and in so
many flavors, that any kind of division into generations is, at the very
best, extremely subjective. Certainly, TOOL isn't very much like some of
the classic procedural 4GLs, but personally I am very comfortable calling
it an OO4GL in comparison to the more common OO3GLs around, like Java.Agreed.
=========================================================================
Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com
David Vydra
dvydrajavamentor.com
www.javamentor.com
(877) 270 - 9003
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

At 06:28 AM 2/10/2000 , David Vydra wrote:
Also, it is a little unfair to compare a product in its third production
release with a beta product. I agree that for certain projects Forte 3 is
the right choice today. The issue for me is: will Sun continue the support
of TOOL? How much of a 4GL is TOOL? Will TOOL become more 4GL in the
future or will it be phased out?How familiar are you with this product? Does it tell you something that
all of the FJEE tools are written in TOOL?
As for what is or is not a 4GL, I think that there are so many
incomparabily different types of languages available these days and in so
many flavors, that any kind of division into generations is, at the very
best, extremely subjective. Certainly, TOOL isn't very much like some of
the classic procedural 4GLs, but personally I am very comfortable calling
it an OO4GL in comparison to the more common OO3GLs around, like Java.
=========================================================================
Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950

RE: (forte-users) RE: Forte' vs J2EE

Hi Alexandra,
1) Forte 4GL and FJEE (Forte for Jave Enterprise Edition) are tools.
2) TOOL and Java are languages.
3) TOOL is proprietary and Java is public.
4) J2EE is a proposed, Java-based achitecture. Not a tool, not a language,
not a standard.
5) J2EE looks a lot like the architecture already supported by Forte 4GL,
however J2EE is explicetaly based on Java, EJB, JSP, JDBC and Servlets.
There are 3 versions of Forte for Java. The "Consumer Edition (CE)", the
"Internet Edition (IE)" and the "Enterprise Edition (EE)". CE is really a
remake of "NetBeans" and can be downloaded for free. IE and EE do not exist
yet. However, EE should be a remake of SynerJ, Forte's first Java tool.
You quoted someone who was very negative about Forte. I don't think that's
deserved. He's probably someone who simply didn't manage to understand the
tool. However, he is right in complaining about the support of Forte 4GL.
And it's true that the version people are currently using is at least more
than 2 years old and outdated. Since this period, there have been some
bugfixes, but hardly any real improvements.
From the description of your application, I would really advise to use Forte4GL. However, the lack of improvements, new releases, press releases, etc.
has me worried about the future of that product.
One of the real disadvantages of Java is performance. Java is very slow and
requires very heavy hardware to perform acceptably. Swing is a GUI framework
based on Java, which is notoriously slow even by Java standards. FJCE
development GUI is based on Swing. Download this product, install it and run
it and you'll see what I mean.
Forte applications can run in 2 modes. Interpreted or compiled. If they're
compiled, they're turned into platform dependent executables, which perform
really well. If they're interpreted, they're running inside a Forte Virtual
Machine, which performs less well, but still very acceptable. Java
applications run only in Java Virtual Machines and perform far less.
I would use Forte server side and Forte client side. For the browsers, I
would simply use any available tool to build webpages and use CGI to
interface with Forte. I would not try to use a different client side tool
that should communicate to a Forte server side.
Express is a good tool for developing CRUD (Create Read Update Delete)
applications based on an existing, and relatively static, database model. I
don't know about Rapport. However, don't be fooled into believing that
Express makes it easier for unexperienced developers to build Forte
applications. If anything, it makes it harder. A common look and feel can
easily be achieved by agreeing on the look and feel of windows during the
design-phase, and have all developers conform to this standard. It really
isn't that hard. Just don't create very large window class trees. That
causes strange behaviour.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
-----Original Message-----
From: Alexandra Macedo [mailto:ammeasysoft.pt]
Sent: Tuesday, December 05, 2000 3:55 PM
To: forte-users
Subject: (forte-users) RE: Forte' vs J2EE
Alexandra I presume.
Excuse me for asking but isn't J2EE just a STANDARD? And Forte aprogramming
language that may or may not adhere to that standard?
Now to the question, if the C++ experience is good - what's wrong withusing
C++?
Do you need to build component based distributed systems? Then hire saytwo
experienced architects - to design a practical model (UML perhaps).
Are there already good systems around you could tailor for your needs?
Just a few questions that need to be addressed to make an informeddecision.
What business are you in (your team/company)? If it's not IT then ask
yourself why do it inhouse?
Regards,
Dirk
PS: What country and from where is the Forte support? You mean peoplecode
in a language other than English?----------------------------------------------------------------------
Well, Forté is certainly not a programming language, TOOL is the
language for the Forté 4GL environment.
J2EE is a standard, and there are already some Application servers
that
implement it (as I was told, webSphere, Iplanet and weblogic,
sorry if I am missing someone).
I really do not know the standard, and I am not sure it says it will
have to be implemented in Java, but all these 3 application servers
do it in Java...
The C++ experience is only from part of the team, and is not from
Database applications, the type of application we are doing is not
well suited to do in C++, we all agree, C++ is out of the question.
I have received many answers (not posted in this mailling list
unfortunatly) telling me that Java is best, others told me Forté is
good Java is just a promise, but they really did not know Java
very well, someone even said:
Forte 4GL sucks terribly. It is not supported well by what
is left of 'Forte the company'.
The tools for this proprietary environment suck.
No distributed debugging or profiling!
There is really no adequate profiling support at all
Avoid Forte like the plague that it is.
Any way, a Forté person told us that Forté is good, precisely, for
our kind of application, and as some people made more questions about
it, I am explaining better our application:
- We are doing this application because we are an IT company, our
job is to make and sell back-office applications for the finance
sector (accounting, third-party, bank management, credit
management), now we want to make one application with all of these.
In simple terms we can define it as an ERP for Credit Operations.
- The users will be in-house except for a small set of
functionalitty, which will be available through browsers.
The front-end should run in an ordinary PC running WINDOWS (we
were told that Java is too heavy and PC's should have at least 256Mb
RAM, which, I believe, is to much for all our clients)
If this is true, it puts Java clients (with Swing) or Java applets out,
HTML, we believe is not powerfull enough for all the interface.
The server, will have to work well with about 300 simultaneous
internal users, plus some Web ones (do not know how many)
The application must be multi-lingual, that is, it should be easy to
put it in any language.
The application is based on a big database, with more than 500
tables, some with about 100 columns, some with millions of records.
- We want to be sure that the application will have the same layout
(look and feel) in every screen, so it will be nice something to
generate code or to create similar functionality (table screens,
for instance) in an automatic way ( that is why we are considering
Express for it). Of course this will help also the maintenance of
the sources.
Our questions are:
FORTÉ or JAVA for the server-side.
Which tool for the client-side?
Which framework to use?
-Express or Rapport from albion if using Forté?
-Are there any good frameworks for Java ?
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Gabriel,
I disagree with you on one very important point. You say it's nearly
impossible to predict anything about the future in ICT-world, so it's better
to not predict at all and only look at the here and now. Here and now, Forte
is better than Java. So, the best choice would be Forte.
But you also mention that Forte is best suited for big projects. Big
applications usually have a long lifetime. Many of the current Forte
applications are the legacy systems of tomorrow. While all the VB, Access,
ASP and Java crap that's being produced will be replaced within 6 to 18
months, Forte applications will live for years.
Migrating such large applications to a new environment, even if this
environment is using a similar technology, requires very high investments.
Companies will want to avoid this as much as possible. So, they'll want to
invest in technology that can evolve with the rest of the world. As
operatingsystems change, databases change, middleware architectures become
obsolete (DCE) and new ones are created (EJB), end user interfaces evolve
(from text to GUI to Web), requirements change (data-oriented,
process-oriented, eCommerce), etc.
Of course, flexibility is not only achieved through technology. A good
design is probably more important.
Managers, not developers, will have to make the strategic decisions about
where to spend their millions. So, they have to look at the future, no
matter how hard that is. At the moment, Forte is still superior, even though
it hasn't been truly improved for over 2 years and that's pretty impressive.
Java is still very "hyped" and no one knows what's going to happen to it.
But the future of Java looks much brighter than the future of Forte. If
Forte doesn't put some serious effort in product development and marketing,
like now, the future of this product suite looks very bleak indeed. And I
wouldn't want to spend my millions knowing I have to do it all over again 2
years from now.
Keeping an eye on the future, where the only certainty is change, I would
not focus on platform independance. I would focus on language independance.
CORBA seemed like a very good idea 2 years ago, but it turned out to be too
complex, technical and inflexible. I would definately go for a CBD
architecture, using XML as backbone. XML can be exchanged between components
using HTTP, CORBA, DCOM, FTP, file copy, DCE, C/C++ call in/out, RMI, IIOP,
E-mail, MQSeries, etc. etc. Or any mixture of these systems.
The role of the data architect will become much more important than the role
of the application architect. The choice for a language or tool is reduced
to "the best choice here and now" as long as you design your large
application as loosly coupled components. It's OK if all of these components
are Forte and they're all communicating using Forte native RMI's. As long as
the design is sound, it's not going to be very difficult to exchange
individual components by others, built in Java, VB, Perl, Cobol++, Fortran
for Windows, or what other monsters the future might bring. The only thing
that binds them, is the datamodel (NB: datamodel is not the same as
databasemodel)
I do worry about the trend to use very large, omni-present, closed,
non-component architectures, like the current ERP applications. This locks
organisations into a single, expensive and hard to maintain technology.
However, it is an opportunity for us, OO - C/S - CBD developers, to build
bridges, adapters, wrappers and gateways to hook these systems into the rest
of the organisation.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
-----Original Message-----
From: Gabriel, C200/Fa. GFT, DA [mailto:A.Gabriel3deutschepost.de]
Sent: Wednesday, December 06, 2000 5:44 PM
To: 'forte-userslists.xpedior.com'
Subject: Re: (forte-users) RE: Forte' vs J2EE
If I were you, I would also consider this very important issue ( I think
it's the same for all 4GL users ), WILL THERE BE FORTE 4GL 5.0?I wonder every time I see that... Why is this that important?
(my mail is long.. if you don't like long mails, delete it now :) )
Let's see from the business' point of view:
If you would like to have an application implemented now,
use now, then you choose an environment existing now.
Now Forte 4GL seems to be a better alternative than Java,
because of the issues mentioned by others already.
I seem to be short-sighted, but could anybody tell me
with 100% accuracy, what will happen to Java in two years?
I doubt...
Forte did not changed too much in the last two years, and
still rocks, at least compared to other existing enterprise
level alternatives. So, nothing has changed that dramatically.
If you look behind the marketing-hype, you will probably agree.
I think, for the next two years Forte will be good enough for us too.
And what then? We will find out then, not now. Anybody, who tries to
explain you what will be in two years in the IT, almost certainly lies :)
Of course, using a "two years old technology" is not that cool from the
marketing point of view, but you use a solid technology, most likely
bug-free,
or at least having only known bugs. That is technically important!
If you ask about investment protection ... ?
Forte is very good in this subject too. If you look at it, you will see, it
is
sold as an integration solution (Fusion, Conductor, etc...)
If something is sold as an integration tool, it should be not that difficult
to
integrate :) Forte supports the most important standards, existing now.
If your future system supports it (it should), it will be easy to upgrade to
it,
using the existing product,know-how, etc... Probably without noticeable
downtime.
Scalability issues: Forte scales well from big to very-big to ultra-big.
What is big, you have to decide :)
For example, one million mails per day is not big. :)
For small businesses Forte isn't good. Java is. And a lot of other
environments
are, for example Perl, Python, etc...
My personal opinion is that our future will be heavily influenced by free
software.
They are very good already, and will be only better.
As Forte evolves, one important step would be to port it to free (and thus
independent)
OS's and DB's like Linux or FreeBSD and Postgres or Mysql. Even without
warranty!
I can't see what Sun's goal is with Forte, maybe they wouldn't
like this idea at all, since that may be the market segment what their Java
is thought for.
But that would be the perfect investment production as the company grows,
they don't have
to do anything to the software, just buy machines, and play around in
Environment Console :)
From the personal point of view:Although I don't work with Forte in the moment, I did this till last year,
and I will do
that in the next year too :)
If you would like to protect your "investment" and/or "market value" then
try to learn
platform and language independent things. I think, knowing Forte is 25%
platform dependent
knowledge (so useless anywhere else) and 75% platform independent. Using,
analysing, designing,
programming, and living OO is absolutely platform independent.
Project (and self-) management, presentation techniques, design and
documentation practices, version
and revision management, and so on, they are all platform independent.
Furthermore if you quit the Forte world, and have to program f.e. Java, you
will learn it in weeks.
JFC, Swing, et. al. are nothing, if you know OO. You just need a book or
an online manual, and you
can write programs in the first week. You will have much more problems with
the working environment,
and you will wonder, how the others can use that crap... after the smart
Forte IDE :)
Back to business a bit:
One big advantage of Forte, that came to my mind right now is that you can't
(ok, you can, but it is
difficult) to write bad OO programs (and designs). In Java, it is too
easy... believe me, I saw some examples ... :)
Sorry for the bad english and the long mail...
Best regards,
Akos Gabriel
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

How can i run a program outside of Forte? (Forte and java/class files)

im making a program with forte... and i have a bunch of class files, i form file and a java file... how can i put these in one file so poeple without forte can run it...
thanks

jmburns wrote:
I am trying to do a silent install of a program I built using LabVIEW 8.5. I also need to call an exe after the installation, so I am using the "run executable after installation" option on the Advanced tab of the installer. I then pass the following command lines to the setup.exe:
/qb /acceptlicenses yes /r
This installs the LabVIEW program successfully, but does not then run the additional exe afterward. If I run the setup.exe normally (with no command line parameters), the additional exe gets run.
Thanks,
Jason
This problem is fixed in a future release of LabVIEW. Here's the CAR ID 67549 for tracking purposes.
Message Edited by Bob P on 07-10-2008 09:10 AM

Re: (forte-users) Fusion for the VAR

Hi,
It is a good idea. In fact, I think that how Forte is
going to integrate her own suite of app. too. ( I
kind of recall that there is a speech on this topic in
Forum ).
However, as Forte will most likely goes toward Java, I
would suggest that you take into account the
abstraction on Conductor ( which is frankly an event
broker ) and Fusion ( which handles the XML mapping )
too. In doing so, you can save guard your investment
on the design without binding tightly with FORTE and I
bet there will be tons of event broker or XML parser
in the future market.
On the other hand, this integration by Fusion would be
perfect for a perfect world. But, in this imperfect
world, it would be hard to do cross-checking between
apps in Fusion.
In the old days, we repulicate data or do file
transfer to integrate apps. In doing so, we also
build-in all the cross-checking procedure / reports.
In the case of Fusion, is there such a safety net to
save guard data integrity. Can I identify a lost
event and trace back to find out whether it is a app.
problem or Conductor problem?
I think the customer would surely like to know.
Regards,
Peter Sham.
--- "Thomas Mercer-Hursh, Ph.D."
<[email protected]> wrote:
Fusion has been positioned as an EAI tool, something
at which it appears to
be very, very good, but in recent months I have been
thinking about its
possible role as an architectural tool for those of
us who build large,
multi-application suites of applications. Having
been tossing some of
these ideas around the halls at Harrison Street, I
thought I would try some
of them on this audience as well to see what
reaction I got.
This concept is based on the context that one has
multiple interacting
applications which are loosely coupled, or at least
which should be. E.g.,
an order processing application may need credit
status information from an
accounts receivable application and may generate
invoices which then need
to be tracked for payment by that application, but
the connections between
these applications are specific, limited, and
readily enumerable. Mind
you, people don't always build their applications so
cleanly modularized,
but I think we all agree these days that they should
be.
The idea is to provide each application with a
specific API, which it may
currently have only indirectly. I.e., today one
might simply have calls
directly from one application to another, but one
would gather all these
links together and define an API, probably in XML
which covered all of the
necessary communciations between applications.
These would then be used to
build a Fusion Proxy and one would build the
necessary Conductor processes
to handle the communications which previously might
have been made directly
between applications. There is probably some
performance loss in this
process, but many of these interfaces are not
performance intensive and my
bet is that if the whole Fusion concept has adequate
performance for the
purposes for which it is being primarily marketed,
then it has the
performance for this sort of usage.
One would get several advantages from this
structure:
1) Interapplication communications would be handled
by a Conductor process
and thus be much more readily configurable than any
hard-coded link.
2) One would gain the ability to unplug one's own
application and plug in a
customer's application when the customer insisted on
using something else.
3) The discipline of working in this structure would
insure clean boundries
between applications, which is not only sound
design, but promotes the
flexibility of the overall suite.
4) Those with untransitioned legacy applications
would have a framework
that would allow a mixture of new and old
applications to co-exist, thus
providing them with a transition strategy until the
full product line was
converted.
Note that I am assuming that one would want to build
the individual
applications so that they also used Conductor for
managing their business
process logic, but that seems to me to be an
independent decision from this
one.
So, comments?
Any downsides?
Any added benefits I haven't covered here?
Are there many out there that would benefit from
this approach or just a few?
Is anyone doing anything like this?
Note that the one downside I have found so far is
that Fusion licensing,
independent of the Conductor aspect, is based on the
number of proxies and
so someone like CI who has 15 or more applications
in a typical site is
going to have 15 or more proxies. My bet is that
this can be handled once
it is clear that use of Fusion by a VAR for
integrating own applications is
not the same use as by an end-user integrating
arbitrary multiple applications.
=========================================================================
Thomas Mercer-Hursh, Ph.D email:
[email protected]
Computing Integrity, Inc. sales:
510-233-9329
550 Casey Drive - Cypress Point support:
510-233-9327
Point Richmond, CA 94801-3751 fax:
510-233-6950
For the archives, go to:
http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To
unsubscribe, send in a new
email the word: 'Unsubscribe' to:
[email protected]
=====

Yes, they do & one page is 1KB page. We use the same instrument to check
memory usage & to send alerts in our production system.
Thanks.
Suraj
-----Original Message-----
From: Epari, Madhusudhan [mailto:[email protected]]
Sent: Monday, May 14, 2001 2:37 PM
To: 'Saraf, Suraj'; 'Forte User Forum'
Subject: RE: (forte-users) Instrument for memory used in the partition
Thanks all for the response. I observed "Allocated Pages" instrument doesn't
change as and when memory usage by the partition changes. I was trying to
find a way to measure the actual memory (specifically in bytes or KBs).
Thanks,
Madhu
-----Original Message-----
From: Saraf, Suraj [mailto:[email protected]]
Sent: Thursday, May 10, 2001 12:46 PM
To: 'Epari, Madhusudhan'; 'Forte User Forum'
Subject: RE: (forte-users) Instrument for memory used in the partition
Hello,
I think you can use 'OperatingSystem' service agent & check 'AllocatedPages'
instrument to see how many memory pages are used. You can compare that with
your maximum allocation & send alerts depending on that. Thanks.
Suraj
-----Original Message-----
From: Epari, Madhusudhan [mailto:[email protected]]
Sent: Thursday, May 10, 2001 11:15 AM
To: 'Forte User Forum'
Subject: (forte-users) Instrument for memory used in the partition
Hello Everyone,
Is there an instrument to track the memory used in the partition at a given
point of time. I have a requirement where an alert has to be generated in
the environment when partition uses all its available memory.
Thanks in advance,
Madhu
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]

Conversion of 1.2 JATO project (non-Forte IDE) to S1AF (JATO) 2.0

JATO Team,
First of all, thank you very much for the Studio integration. It
looks very promising in terms of development time consumption,
deployment to S1AS7, etc., etc. It is impossible to observe all
advantages for so short period of time.
The SOAF (JATO) 2.0 is installed on the top of the Sun ONE Studio 4,
update 1 (EE) with JDK 1.4 along with the Sun One Application Server
7 (W2000). Everything looks okay, at least all basic tasks listed in
the "Getting Started" manual (project/view/model creation, basic db
connection, running of a test application with the usage of the
Studio's default Tomcat container, etc.) work proper.
During the installation of S1AF module on the top of the Sun ONE
Studio 4, update 1 (EE) I've got an invitation to convert the
existing project to the new environment. As I realized the only JATO
project integrated/created with Forte IDE is applicable for this auto-
conversion (please correct me, if I am wrong. It could solve a lot of
my problems).
Since we are using JBuilder5 IDE and our JATO 1.2 project is
integrated with this IDE I manually re-created project in the Studio
with its file structure, adjusted the project web.xml file, etc. This
new project looks like a proper one (Studio recognize all methods,
fields, bean patterns, e.g.) except at least one "small" thing. All
java files (project viewBeans, Models, custom viewBeanHelpers a.k.a.
pure java) came up with the same wizard image:java class. Stutio with
the S1AF module reserves the special images (and appropriate studio
properties, of course!) for View and Model. Namely this allows to see
the following structure for a ViewBean, for example, in the Studio:
Modules
ProjectName.ModuleName
FooViewBean
JavaSource
JSPs
Non-Visual Components
View Components
On the other hand, I could add either new View or Model in my
manually converted project and add any View Component or bind the
Model fields, for example. Also, the ProjectModuleServlet has been
converted proper. I tried to convert each View/Model class inside the
Studio to its proper wizard image and failed. Addition of a View
Components (with an appropriate code fragments) via the Studio or
auto-binding of model fields is an essential part of 2.0 and should
drastically speed up the development process as it is designed.
Questions:
1. What I missed in my manual conversion of 1.2 JATO project to the
SOAF (JATO) 2.0 realm? What should I correct in my JATO 1.2
compatible classes (Views and Models) to be recognizable by Studio
wizard (JATO 2.0)?
To be more specific. Some deltas between JATO 1.2 and JATO 2.0 are as
follows (related to a ViewBean):
====++++++++++++++======
JATO 1.2 viewBean extension upon creation:
public class FooViewBeanViewBean extends ViewBeanBase
implements ViewBean
========================
JATO 2.0 (S1AF) version: viewBean extension upon creation:
public class FooViewBean extends BasicBeanBase
====++++++++++++++======
JATO 1.2 viewBean createChild(...) method for one static looks
like:
protected View createChild(String name)
if (name.equals(CHILD_STATICTEXT1))
StaticTextField child = new StaticTextField
(this,
getDefaultModel(),
CHILD_STATICTEXT1,
CHILD_STATICTEXT1,
CHILD_STATICTEXT1_RESET_VALUE,
null);
return child;
========================
JATO 2.0 (S1AF) version: viewBean createChild(...) is renamed (as
a least) to createChildReserved(...):
protected View createChildReserved(String name) {
if (name.equals(CHILD_STATICTEXT1)) {
com.iplanet.jato.view.BasicDisplayField child =
new com.iplanet.jato.view.BasicDisplayField(this,
STATICTEXT1);
return child;
====++++++++++++++======
JATO 1.2 viewBean registerChildren() method for the basic field
types looks like:
private void registerChildren() {
registerChild(CHILD_STATICTEXT1, StaticTextField.class);
registerChild(CHILD_TEXTFIELD1, TextField.class);
registerChild(CHILD_BUTTON1, Button.class);
========================
JATO 2.0 (S1AF) version: viewBean registerChildren() method:
private void registerChildren() {
registerChild(CHILD_STATICTEXT1,
com.iplanet.jato.view.BasicDisplayField.class);
registerChild(CHILD_TEXTFIELD1,
com.iplanet.jato.view.BasicDisplayField.class);
registerChild(CHILD_BUTTON1,
com.iplanet.jato.view.BasicCommandField.class);
Is it correct to say that all existing custom Views/Models
(compatible with JATO 1.2) should be converted to their JATO 2.0
variants to be visible by the Studio?
On the other hand, fast overview of 2.0 API shows that the JATO 1.2
is a sub-set of the 2.0 (BasicViewBean extends ViewBeanBase, for
example). What exactly (only deprecated methods?) should be adjusted
in the project code (1.2), if necessary, to be visible by Studio as a
View or Model component?
2. Where it is possible to find the list of deprecated methods (from
JATO 1.2 to JATO 2.0 versions). It is difficult sometimes to compare
two versions of API docs (1.2 and 2.0) or compare logs between
versions. Also, JATO 2.0 is significantly larger than 1.2 version. If
the later obviously inherits the ND conversion stage (via the
previous versions), the former obviously has additions incoming from
the integration with the Studio (a.k.a. Forte 4.0).
3. What is the current/future Sun/JATO Team policy with regards to
JATO source code access (version 2.0, at least)? The reason of this
question is as follows: in order to display dates formatted on the
screens we adjusted a couple of JATO 1.2 core classes, for example.
The only minimal, absolutely necessary changes in JATO 1.2 was made,
but anyway...
Sorry for so long multiple question. As Todd wrote in his
announcement mail: "We think you will be very pleased with the new
product...". This is exciting moment, I believe, for JATO Team as
well as for any team involved into the conversion of the full size
application/product from ND to J2EE realm with the JATO as
an application framework (1.0, 1.1.x, 1.2.X, and 2.0 finally). The
last step is left in this spiral process to enjoy the ND_Studio
attractive features in the open source environment.
Thank you very much in advance.
Vladimir Ivanov

I'll get some file templates ASAP and provide them to the group.
As for source code, I'm not sure what the policy is. JATO 1.2 is very
close to what JATO 2.0 is, so that should suffice for now.
The community will be informed when we know more about source availibility.
craig
vivanov4114 wrote:
Craig,
Thank you for the answer. To be honest with you I tried to do exactly
the same: I created the small test project and made an attempt to
adjust the existing *.xml files to the new ones. I got some results,
otherwise I couldn't even see my original 1.2 project in the Studio.
Since I am a newcomer in the Studio, I definitely missed something in
my adjustments. I'll try to observe my changes with the fresh head.
On the other hand, I am afraid that my samples are very pure. If you
could post or send me examples of jatoapp.xml and web.xml files (say
for any of you test project) or excerptions from them with the
appropriate patterns (ViewBean and Model peers, at least), I would be
very appreciated. My mail is: vivanov@b...
In the worst-case scenario I see the workaround: to re-create the
project for one of our releases with the Forte 4.1 IDE and auto-
convert it into the JATO 2.0/Studio world using the Studio
facilities. We must get the current project fully
integrated/converted with/to the Studio (at certain point) because,
first, we expect massive coding with the GUI components involved soon
and, secondly, we have around thousand classes related to JATO only
(and a lot of extras).
Coming back to the question #3 from this post. Now we have full
access to the version 1.2, not only to the JATO 1.2 jar file(I
explained some reasons below). Would we expect the same Sun/JATO Team
policy with JATO 2.0?
Thank you again,
Vlad
--- In SunONE-JATO@y..., "cvconover" <craig.conover@s...> wrote:
It doesn't appear that anyone has responded to this so I am goingto
give you the short answer:
The reason you don't see your ViewBeans and Models showing up with
there "wizard created" icons is because of just that. They weren't
created via the wizards. The wizards create xml formatted filesthat
contain metadata of how/what to generate for the ViewBeans and
Models.
ViewBeans will have a .viewbean fiel, Models will have a .sqlmodel
file (for SQL Models), etc. The content of these files describesthe
code that needs to be generated in the corresponding Java classfile.
So LoginViewBean.java will have a peer LoginViewBean.viewbean file.
The code that is generated is place in protected code blocks thatcan
not be modified in the Studio and should not be modified outsidethe
Studio because the code will likely be regenerated and custom mods
inside the protected blocks will be lost.
Now you can make a JATO 1.2 app appear in the Studio just like aJATO
2.0 app by adding a jatoapp.xml file with the proper content and
adjusting your web.xml properly, but it's much more work to getyour
v1.2 ViewBeans and Models to show up like wizard created versions.
Furthermore, even more work to get the display fields to show up
visually.
The good news is that v1.2 ViewBeans will work with newly wizard
created ViewBeans. And if you do go through the trouble of making
your ViewBeans Studio visible like your wizard created ViewBeans,
adding new display fields visually will work along side yourmanually
created fields.
Try creating a new JATO app using the Studio wizards and then go to
the Filesystems tab and look for the jatoapp.xml file and theweb.xml
file.
I am looking for an email that I have that explains how to do a
partial, manual upgrade.
Also, you will get rid of your JATO 1.2 jar and replace with theJATO
2.0 jar in your lib dir.
Hope this will suffice for now.
craig
--- In SunONE-JATO@y..., "vivanov4114" <vivanov@b...> wrote:
JATO Team,
First of all, thank you very much for the Studio integration. It
looks very promising in terms of development time consumption,
deployment to S1AS7, etc., etc. It is impossible to observe all
advantages for so short period of time.
The SOAF (JATO) 2.0 is installed on the top of the Sun ONE Studio4,
update 1 (EE) with JDK 1.4 along with the Sun One ApplicationServer
7 (W2000). Everything looks okay, at least all basic tasks listedin
the "Getting Started" manual (project/view/model creation, basic
db
connection, running of a test application with the usage of the
Studio's default Tomcat container, etc.) work proper.
During the installation of S1AF module on the top of the Sun ONE
Studio 4, update 1 (EE) I've got an invitation to convert the
existing project to the new environment. As I realized the onlyJATO
project integrated/created with Forte IDE is applicable for thisauto-
conversion (please correct me, if I am wrong. It could solve a
lot
of
my problems).
Since we are using JBuilder5 IDE and our JATO 1.2 project is
integrated with this IDE I manually re-created project in theStudio
with its file structure, adjusted the project web.xml file, etc.This
new project looks like a proper one (Studio recognize all
methods,
fields, bean patterns, e.g.) except at least one "small" thing.All
java files (project viewBeans, Models, custom viewBeanHelpersa.k.a.
pure java) came up with the same wizard image:java class. Stutiowith
the S1AF module reserves the special images (and appropriate
studio
properties, of course!) for View and Model. Namely this allows tosee
the following structure for a ViewBean, for example, in the
Studio:
Modules
ProjectName.ModuleName
FooViewBean
JavaSource
JSPs
Non-Visual Components
View Components
On the other hand, I could add either new View or Model in my
manually converted project and add any View Component or bind the
Model fields, for example. Also, the ProjectModuleServlet hasbeen
converted proper. I tried to convert each View/Model class insidethe
Studio to its proper wizard image and failed. Addition of a View
Components (with an appropriate code fragments) via the Studio or
auto-binding of model fields is an essential part of 2.0 and
should
drastically speed up the development process as it is designed.
Questions:
1. What I missed in my manual conversion of 1.2 JATO project tothe
SOAF (JATO) 2.0 realm? What should I correct in my JATO 1.2
compatible classes (Views and Models) to be recognizable byStudio
wizard (JATO 2.0)?
To be more specific. Some deltas between JATO 1.2 and JATO 2.0are
as
follows (related to a ViewBean):
====++++++++++++++======
JATO 1.2 viewBean extension upon creation:
public class FooViewBeanViewBean extends ViewBeanBase
implements ViewBean
========================
JATO 2.0 (S1AF) version: viewBean extension upon creation:
public class FooViewBean extends BasicBeanBase
====++++++++++++++======
JATO 1.2 viewBean createChild(...) method for one static looks
like:
protected View createChild(String name)
if (name.equals(CHILD_STATICTEXT1))
StaticTextField child = new StaticTextField
(this,
getDefaultModel(),
CHILD_STATICTEXT1,
CHILD_STATICTEXT1,
CHILD_STATICTEXT1_RESET_VALUE,
null);
return child;
========================
JATO 2.0 (S1AF) version: viewBean createChild(...) is renamed(as
a least) to createChildReserved(...):
protected View createChildReserved(String name) {
if (name.equals(CHILD_STATICTEXT1)) {
com.iplanet.jato.view.BasicDisplayField child =
new com.iplanet.jato.view.BasicDisplayField(this,
STATICTEXT1);
return child;
====++++++++++++++======
JATO 1.2 viewBean registerChildren() method for the basic field
types looks like:
private void registerChildren() {
registerChild(CHILD_STATICTEXT1,
StaticTextField.class);
registerChild(CHILD_TEXTFIELD1, TextField.class);
registerChild(CHILD_BUTTON1, Button.class);
========================
JATO 2.0 (S1AF) version: viewBean registerChildren() method:
private void registerChildren() {
registerChild(CHILD_STATICTEXT1,
com.iplanet.jato.view.BasicDisplayField.class);
registerChild(CHILD_TEXTFIELD1,
com.iplanet.jato.view.BasicDisplayField.class);
registerChild(CHILD_BUTTON1,
com.iplanet.jato.view.BasicCommandField.class);
Is it correct to say that all existing custom Views/Models
(compatible with JATO 1.2) should be converted to their JATO 2.0
variants to be visible by the Studio?
On the other hand, fast overview of 2.0 API shows that the JATO1.2
is a sub-set of the 2.0 (BasicViewBean extends ViewBeanBase, for
example). What exactly (only deprecated methods?) should beadjusted
in the project code (1.2), if necessary, to be visible by Studio
as
a
View or Model component?
2. Where it is possible to find the list of deprecated methods(from
JATO 1.2 to JATO 2.0 versions). It is difficult sometimes tocompare
two versions of API docs (1.2 and 2.0) or compare logs between
versions. Also, JATO 2.0 is significantly larger than 1.2
version.
If
the later obviously inherits the ND conversion stage (via the
previous versions), the former obviously has additions incomingfrom
the integration with the Studio (a.k.a. Forte 4.0).
3. What is the current/future Sun/JATO Team policy with regards
to
JATO source code access (version 2.0, at least)? The reason ofthis
question is as follows: in order to display dates formatted onthe
screens we adjusted a couple of JATO 1.2 core classes, forexample.
The only minimal, absolutely necessary changes in JATO 1.2 wasmade,
but anyway...
Sorry for so long multiple question. As Todd wrote in his
announcement mail: "We think you will be very pleased with the
new
product...". This is exciting moment, I believe, for JATO Team as
well as for any team involved into the conversion of the fullsize
application/product from ND to J2EE realm with the JATO as
an application framework (1.0, 1.1.x, 1.2.X, and 2.0 finally).The
last step is left in this spiral process to enjoy the ND_Studio
attractive features in the open source environment.
Thank you very much in advance.
Vladimir IvanovTo download the latest version of JATO, please visit:
http://www.sun.com/software/download/developer/5102.html
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
[Non-text portions of this message have been removed]

Re: (forte-users) Minimal Fusion

Thomas,
A response which may contain no answers...and may lead to more questions...
As a novice fusion user, one of the largest obstacles to using Fusion is the lack of XML API's in an application, be it a customer's in-house or vendor's software product. Corresponding to this is simply the lack of any API's in the application. As Forte (abet Sun, now iPlanet) says in their training manual 'A nontrivial task is to build new adapters for your programs if you wish to enable them to interact using XML documents over HTTP'. This is probably an understatement.
The question that come to mind is:
Does the warehouse have published API's their product?
If not, then, IMHO, you have steep hill to climb, not the least being communication, cooperation, and coordination from the warehouse vendor (another one of those 'nontrivial tasks') in trying to create the required API's
if so, then it is a matter of building an adapter, in a language that is compatible with the warehouse's API (hopefully C or some derivation of) , that contains (1) a DOM (Document Object Module) to API Translator, (2) an XML Parser (converts XML to DOM and visa-versa) , and (3) a HTTP server (again, another one of those 'nontrivial tasks').
Forte (abet Sun, now iPlanet) suggests, and I would concur (with reservations), that if you haven't done this before you should probably hire their services from the Forte Integration Services group. Their costs (admittible high) should be offset be the time it would take to develop one on your own. A side benefit is working with them, you learn the process for making other adapters in the future. If Fusion is a marketing success, then the benefits should out weigh the costs.
The Forte Integration Services group markets, or will market, a Fusion Adapter Designer, some sort of a SDK, which assists in the creation of Adapters. I do not know the availability of that product at this time.
As to your question "Is it reasonable to consider doing this project under Fusion as a
getting-feet-wet experience?" If you (or your customer) can afford the costs, and the warehouse has published API's, I would say that you gotta get-your-feet-wet somehow. If the warehouse doesn't have published API's and are not willing to put forth the effort and resources to do so, I would say your chances of success are considerably less.
In any case, IMHO, it will be a 'non trivial' undertaking.
-later
-labeaux
"Thomas Mercer-Hursh, Ph.D." <thomascintegrity.com> 10/31/00 04:49PM >>>This may be one of those questions which has no answer, but ...
Our long term plan is to develop XML APIs to each of the modules in our
suite of non-Forte applications and to integrate these under Fusion, thus
gaining Conductor management of the inter-module work flows and a cleaner
loose coupling of the applications along with other benefits such as the
ease of integration with other packages, a clean way to migrate to Forte
modules, and an ease of interconnecting "mini-applications" to address
specific customer needs.
I have an existing customer who has made a decision to migrate to a third
party warehouse from an in-house warehouse. I.e., were this transition to
the new structure complete, this would correspond to unhooking some of our
modules and replacing these with an adapter to the corresponding modules in
the third party warehouse.
In fact, as it looks now, I will need to build the logical equivalent of
these APIs anyway -- might as well do it in XML, right? And these APIs
will communicate with a daemon responsible for the message traffic to and
from. I tried to get this traffic to be XML and to use MQSeries or JMS as
the transport, but the folks at the warehouse end don't seem to be able to
handle such things, so I am stuck doing something fairly stupid for the
actual communication.
So, the question for those out there who have already paid their Fusion
dues, is it reasonable to consider doing this project under Fusion as a
getting-feet-wet experience. There are only half a dozen APIs to do and I
have to do those anyway and am inclined to make them XML regardless. There
will be one communication daemon to which all these connect and the
business processes originally implemented in Conductor will basically be
just point to point connects, except for routing traffic from the daemon to
the right API based on message type. That's really all I need it to do,
i.e., far too simple to actually need Fusion, but a possible opportunity
to get started and then to expand to other uses.
Crazy?
=========================================================================
Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

At 07:55 AM 11/1/00, Labeaux Schiek wrote:
As a novice fusion user, one of the largest obstacles to using Fusion is
the lack of XML API's in an application, be it a customer's in-house or
vendor's software product.In this case, the good news is that one of the applications in question is
our own, so whipping up an XML API to suit each required transaction on
that side is no more, probably less, work than importing or exporting a
flat file or whatever. Moreover, my current expectation of how this
interaction will work is something like this:
</pre>
---Fusion------
| |
WACS<-->WACS_Daemon<----VPN socket
connection---->IS_Daemon I/S
</pre>
I.e., I/S, our application, and the IS_Daemon which handles the connection
traffic across the internet link are both mine. For I/S, I will create XML
APIs to suit. For the IS_daemon, I might use the transform facilities to
convert this XML to the pipe-delimited format they are expected at the
other end and make the daemon a simple manager of the connection or, the
daemon could do the conversion, but the former seems like the more
appropriate approach. The API between the two daemons is something we are
defining now (unfortunately I lost the argument to make that XML).
Corresponding to this is simply the lack of any API's in the
application. As Forte (abet Sun, now iPlanet) says in their training
manual 'A nontrivial task is to build new adapters for your programs if
you wish to enable them to interact using XML documents over HTTP'.My neophyte understanding is that, since I am defining the API to I/S in
the diagram above and I can make this XML, then the adapter issue
disappears there. I might have to create an adapter for the daemon, but if
necessary, I could make that the same XML on a pass through and do the
translation in the daemon.
If not, then, IMHO, you have steep hill to climb, not the least being
communication, cooperation, and coordination from the warehouse vendor
(another one of those 'nontrivial tasks') in trying to create the required
API'sWe are well through this process anyway. ... which is not to say that it
has been or will be easy, but it must be done whether I use Fusion or
not. Given that the vote has gone in favor of simple messages of
pipe-delimited records, i.e., basically flat file, the technical issues
there are minimal.
if so, then it is a matter of building an adapter, in a language that is
compatible with the warehouse's API (hopefully C or some derivation of) ,
that contains (1) a DOM (Document Object Module) to API Translator, (2)
an XML Parser (converts XML to DOM and visa-versa) , and (3) a HTTP server
(again, another one of those 'nontrivial tasks').I'm not sure I quite understand what you are saying here. The HTTP part
won't be there since we will apparently be connecting via a VPN sockets
connection. But, how are you distinguishing DOM and XML since DOM is a
particular form of XML? The XML API I build for I/S will be DOM compliant.
Forte (abet Sun, now iPlanet) suggests, and I would concur (with
reservations), that if you haven't done this before you should probably
hire their services from the Forte Integration Services group. Their
costs (admittible high) should be offset be the time it would take to
develop one on your own. A side benefit is working with them, you learn
the process for making other adapters in the future. If Fusion is a
marketing success, then the benefits should out weigh the costs.I am familiar with the "party" line. If I were building a complete
interface to another major product (I/S is roughly equivalent to JDEC in
coverage) in the context of an EAI project, I would happily invite them in
and hope to pick up pointers. Here, though, there are only 8 or 9 total
transaction types and either all of the interfaces are XML, i.e., no
adapter required as I understand it, or only the daemon will need an
adapter and that will be a choice I can make depending on how things
go. One does wish it were possible to sample a small piece of that
knowledge store without having to buy the whole thing, though.
The Forte Integration Services group markets, or will market, a Fusion
Adapter Designer, some sort of a SDK, which assists in the creation of
Adapters. I do not know the availability of that product at this time.Last I checked, one couldn't get this without the consulting ... hence the
last sentence above.
Thanks for your input.
=========================================================================
Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950

Testing in Forte: Good News :-)

Hi
The purpose of this message is to address some inaccuracies in the attached
message regarding testing tools. I thought I would share with you all what
I found out about testing tools that work with Forte.
I heard back from Forte users about two testing tools:
1) Mercury LoadRunner / WinRunner etc.
2) ClassIQ's product called IQTest
Mercury
I spoke with a Mercury representative today who listed for me several sites
which are successfully using Forte with Mercury (one of these sites is even
located here in Australia!). The problems described in the attached
message or accurate; however, the workarounds are documented and easy to
understand.
You can use Mercury today with Forte.
In addition, Mercury has been working for several months now on an even
tighter integration with Forte. This project has been extremely
successful. There is at least one Forte site in the USA which is using
this Forte/Mercury integrated product. According to the Mercury rep, the
Mercury/Forte tighter integration is now in beta testing and should be
production in May/June 1997. This information was verified by my contacts
at Forte HQ. If any of you need more detailed information than this please
contact me or your Mercury representative.
ClassIQ
ClassIQ currently has a small number of sites using its testing tools which
are written in Forte. Needless to say, ClassIQ is very tightly integrated
with the Forte environment. If you would like to know more about ClassIQ
contact Joe Burns at 105210,[email protected].
I am sure there are many other people using other testing tools with
Forte....these are just the two I have heard about in the initial responses
to my query. I would love to hear about other testing tools which work
well with Forte.
Regards,
Eric
At 11:19 AM 2/19/97 +0530, you wrote:
Hi,
We evaluated quite a few test tools in relation to the forte
environment. All of them have the same problem : The inability to
correctly map Forte widgets. Most of them cannot recognise
Outlinefields, ArrayFields etc. Even if they do recognise a forte widget
only basic properties like the size of the widget, its position on the
screen etc. are recorded. Data contents of the widget are not
recognized.
To clarify the above points : Given a screen with a TextData widget, you
can record and playback this sequence without any problems with most
Test tools :- Position the mouse on the widget, Type 'Testing' .
Ideally, the TextData widget should have a property 'Content' or 'Value'
(different test tools call it differently) which will have the value
'Testing'. In case of forte this does not happen. What is recorded are
the low level mouse movements or keyboard strokes. The position on the
screen where the value is typed is recorded and played back.
Low level recording maybe acceptable in some circumstances but say - you
have a widget which gets populated by a database query. How will you
test the values displayed ?
Some of the test tools are customizable i.e. you can actually create a
widget class of your own and try to map it to a recognized (by the Tool)
widget class. This will be a time consuming process with a great deal of
trial and error and no guarantees of success.
If the sole objective is navigate through screens and record and
playback, then most of the automated test tools work. If you want to
make full use of a test tools capabilities and want to go further and
intelligently record and playback, most test tools have very very
limited use.
Discussions with Test tool vendors have revealed the following :
- Forte has not released a Test API to any particular vendor or the
market at large
- Forte implementation sites are at the moment too few for any test tool
vendor to invest in Research and Development and come out with a Test
API.
So as it goes the chances of a fully compatible Forte test tool in the
near future are remote.
Forte's own AutoTester project has a limited usage. My own evaluation is
that it cannot be used for big sized implementations. Along with other
limitations, test management facilities that are particularly relevant
for big sized implementations simply don't exist with AutoTester.
The only product in the market that is Forte specific and is more a
testing Framework than a tool is TestIQ from ClassIQ. I am keen to get
information about TestIQ from any of its implementation sites. Again I
am not sure about its test management capabilities.
Hope the information helps,
Parvathi Iyer,
[email protected]
From: David Campbell[SMTP:[email protected]]
Sent: Tuesday, February 18, 1997 2:08PM
To: [email protected]
Subject: Development tools
Hi all,
We are about to embark on a sizable Forte development and are interested
in hearing from anybody who has successfully used automated test tools
with Forte. Also, does anybody know of a problem tracking tool that can
be linked to the Forte source repository for the purpose of tracking the
status software bugs, fixes etc.
Thanks,
David Campbell
System Consultant
CSC Australia
From: [email protected][SMTP:[email protected]]
Sent: Tuesday, February 18, 1997 11:58 PM
To: [email protected]
Subject: Automated test tools
I've read about Capture/Replay and played with the AutoTester project a
little. I'm curious as to the experiences that developers have had with
using these tools to automate testing of GUI applications. Has anyone
actually deployed an application that successfully uses these tools? How
does it compare against other automated test tools?
One limitation that I see with using Capture/Replay is that any non-Forte
client interfacing with my Forte code would not be able to use this
mechanism to perform its auto testing. Also, while playing with the
AutoTester I actually got a playback which was slightly different than what
I did while doing the capture.
Thanks,
Jim Hancock
[email protected]
--_|\ Eric Gold
/ \ Technical Director
\_.--._* Forte Australia
v Voice: 61-2-9926-1403
Fax: 61-2-9926-1401
http://www.forte.com
He is happiest who advances more gradually to greatness.
-- Adam Smith

Thanks for the news Nancy!

RE: (forte-users) Sv: (forte-users) The Death ofForte

This is what I got today:
Statement of Direction
Sun Microsystems, Inc.
Forté 4GL(tm) Product (formerly the Forté Application Environment)
Product Context
· Forté 4GL is an award-winning, proven product with many unique
advantages for building enterprise business systems that are distributed,
that involve the integration of existing business systems as well as new
functionality, and that target heterogeneous runtime environments.
· Forté 4GL is recognized by Gartner Group as the most successful
Enterprise Application Development Tool.
· The Sun Microsystems, Inc. (SMI) development tools group (formerly
Forté Software, Inc.) has a strong internal commitment to Forté 4GL. Forté
Fusion is written with, and is currently being enhanced with Forté 4GL.
· The SMI development tools group intends to actively enhance and
promote Forté 4GL for the indefinite future. The best opportunity for
attracting new customers is to leverage the ability of Forté 4GL to easily
build powerful shared business services (server components) that can be
accessed by non-Forté clients (e.g., browsers, Java clients) and that can
easily integrate with new and existing business systems.
· The product enhancement plan calls for continuing to issue
incremental releases approximately twice a year. To speed the release of new
functionality, new features will be included with "preview status." This
means that the overall release can support production deployments, but that
the features marked "preview" are certified for development and demos.
· The planned contents of the next two releases are indicated below.
Users should not expect any features other than those on the list. The
contents of subsequent releases will be determined approximately a year in
advance.
· SMI has retained the Forté field sales organization as an
independent unit whose primary product offerings are Forté 4GL and Forté
Fusion. Continued volume sales of Forté 4GL remain the foundation of our
business plan.
Mid-Year Release
· Tentatively labeled "release 3.5" to be distributed as a free
product enhancement for customers under maintenance
· Scheduled for Summer 2000
· Defining features
· Introspection (reflection) - the ability for an object to describe
itself at runtime
· Improved integration with applications developed using
Forté-for-Java Community Edition(tm) (formerly NetBeans)
· Platform support improvements to track important operating system
and database vendor activity
· Target features
· Display system enhancements (e.g., Motif 2 support, line arrowheads,
window refresh control, editable outline fields)
· Dynamic library loading
· Improved CORBA/IIOP support
· Improved XML and XSLT class support
· JMQ support
End-Year Release
· Tentatively labeled "release 3.6" to be distributed as a free
product enhancement for customers under maintenance
· Scheduled for year end 2000
· Defining features
· Any Release 3.5 target features that were not included in 3.5
· Generation of EJB interfaces for R3 service objects
· Platform support improvements to track important operating system
and database vendor activity
· Target features
· COBOL record handling as part of the OS390 transaction adapter
· Improved runtime security
· Interface classes for access to Netscape Server 4.0 and possibly
other web servers
Longer Term Product Directions
1. TOOL code to Java code migration. Neither release 3.5 nor 3.6 will
contain an automated solution in this area. Technical differences between
TOOL and Java make a 100% automated conversion all but impossible. A
workable solution is likely to involve a combination of tools and services.
2. Common repository between the 4GL and Java products. The recently
devised Java Tools Strategy has necessitated a change in the technology base
for our Java products to make them compatible with both the iPlanet
Application Server and the Forté for Java Community Edition. This, in turn,
has complicated our original vision of a common repository to the point that
we will not embark on this project. Instead, we have elevated
interoperability a short-term priority. In addition, we plan to migrate the
Fusion process definition tools to Java, thereby enabling Fusion definitions
to be stored in a common repository with Java code and components.
3. Other long-term enhancements will be determined by additional
customer and market feedback. A major criterion for new functionality will
be enhancing the revenue generating ability of the product, thereby
fostering its long-term health in the marketplace.
As our products continue to evolve, the features and specifications
described in this document are subject to change without notice. Sun
Microsystems cannot guarantee the completion of any future products or
product features mentioned in this Statement of Direction. By signing
below, the receiving Company agrees that it has not relied on, is not
relying on and will not rely on the potential availability of any future Sun
product, functionality or feature in making any purchases from Sun.
Executed by the Receiving Company Executed by Sun
Microsystems, Inc.
Signature:________________________
Signature:________________________
Name:___________________________
Name:___________________________
(Please Print) (Please
Print)
Title:____________________________
Title:____________________________
Date:____________________________
Date:____________________________

This is what I got today:
Statement of Direction
Sun Microsystems, Inc.
Forté 4GL(tm) Product (formerly the Forté Application Environment)
Product Context
· Forté 4GL is an award-winning, proven product with many unique
advantages for building enterprise business systems that are distributed,
that involve the integration of existing business systems as well as new
functionality, and that target heterogeneous runtime environments.
· Forté 4GL is recognized by Gartner Group as the most successful
Enterprise Application Development Tool.
· The Sun Microsystems, Inc. (SMI) development tools group (formerly
Forté Software, Inc.) has a strong internal commitment to Forté 4GL. Forté
Fusion is written with, and is currently being enhanced with Forté 4GL.
· The SMI development tools group intends to actively enhance and
promote Forté 4GL for the indefinite future. The best opportunity for
attracting new customers is to leverage the ability of Forté 4GL to easily
build powerful shared business services (server components) that can be
accessed by non-Forté clients (e.g., browsers, Java clients) and that can
easily integrate with new and existing business systems.
· The product enhancement plan calls for continuing to issue
incremental releases approximately twice a year. To speed the release of new
functionality, new features will be included with "preview status." This
means that the overall release can support production deployments, but that
the features marked "preview" are certified for development and demos.
· The planned contents of the next two releases are indicated below.
Users should not expect any features other than those on the list. The
contents of subsequent releases will be determined approximately a year in
advance.
· SMI has retained the Forté field sales organization as an
independent unit whose primary product offerings are Forté 4GL and Forté
Fusion. Continued volume sales of Forté 4GL remain the foundation of our
business plan.
Mid-Year Release
· Tentatively labeled "release 3.5" to be distributed as a free
product enhancement for customers under maintenance
· Scheduled for Summer 2000
· Defining features
· Introspection (reflection) - the ability for an object to describe
itself at runtime
· Improved integration with applications developed using
Forté-for-Java Community Edition(tm) (formerly NetBeans)
· Platform support improvements to track important operating system
and database vendor activity
· Target features
· Display system enhancements (e.g., Motif 2 support, line arrowheads,
window refresh control, editable outline fields)
· Dynamic library loading
· Improved CORBA/IIOP support
· Improved XML and XSLT class support
· JMQ support
End-Year Release
· Tentatively labeled "release 3.6" to be distributed as a free
product enhancement for customers under maintenance
· Scheduled for year end 2000
· Defining features
· Any Release 3.5 target features that were not included in 3.5
· Generation of EJB interfaces for R3 service objects
· Platform support improvements to track important operating system
and database vendor activity
· Target features
· COBOL record handling as part of the OS390 transaction adapter
· Improved runtime security
· Interface classes for access to Netscape Server 4.0 and possibly
other web servers
Longer Term Product Directions
1. TOOL code to Java code migration. Neither release 3.5 nor 3.6 will
contain an automated solution in this area. Technical differences between
TOOL and Java make a 100% automated conversion all but impossible. A
workable solution is likely to involve a combination of tools and services.
2. Common repository between the 4GL and Java products. The recently
devised Java Tools Strategy has necessitated a change in the technology base
for our Java products to make them compatible with both the iPlanet
Application Server and the Forté for Java Community Edition. This, in turn,
has complicated our original vision of a common repository to the point that
we will not embark on this project. Instead, we have elevated
interoperability a short-term priority. In addition, we plan to migrate the
Fusion process definition tools to Java, thereby enabling Fusion definitions
to be stored in a common repository with Java code and components.
3. Other long-term enhancements will be determined by additional
customer and market feedback. A major criterion for new functionality will
be enhancing the revenue generating ability of the product, thereby
fostering its long-term health in the marketplace.
As our products continue to evolve, the features and specifications
described in this document are subject to change without notice. Sun
Microsystems cannot guarantee the completion of any future products or
product features mentioned in this Statement of Direction. By signing
below, the receiving Company agrees that it has not relied on, is not
relying on and will not rely on the potential availability of any future Sun
product, functionality or feature in making any purchases from Sun.
Executed by the Receiving Company Executed by Sun
Microsystems, Inc.
Signature:________________________
Signature:________________________
Name:___________________________
Name:___________________________
(Please Print) (Please
Print)
Title:____________________________
Title:____________________________
Date:____________________________
Date:____________________________

Problem compiling a project with FORTE

Hi, thanks in advance ,
I've installed FORTE 6 update 2 and all has gone ok .
I've built two projects without problems.
But building a big project i've found nexts problems :
bash-2.03# /opt/SUNWspro/bin/makeprd myproject_file.prd
ild: (undefined symbol) st_key_create -- referenced in the text segment of output/b.o
ild: (undefined symbol) st_key_create -- referenced in the text segment of output/a.o
ild: (undefined symbol) mysql_store_result -- referenced in the text segment of output/a .o
ild: (undefined symbol) mysql_num_rows -- referenced in the text segment of output/b.o
*** Error code 5
dmake: Fatal error: Command failed for target `output/final_file'
All the files has compiled ok less files makes calls to a MYSQL and ST library .
I've already tell to my prd where found a library in mysql ( /usr/local/mysql/lib and include ) and ST library ( $HOME/st.h and st.a" ), but i don't understand why ild can't found this symbols ...
In mysql.h you can find :
mysql_store_result , mysql_num_rows
and in the st.h the other functions ...
I've found declarations( in .h) and functions ( in .a )
What's the problem ?, anybody can help me ?
Thanks

I'm sorry Mike, but I want to be clear on what you are saying. Are you saying NOT to include it in my project but rather include it in the "always included" box in the application builder?
What do you mean by "You shouldn't do it, because your fixed path would be wrong." What shouldn't I do? Add it to my project? I asked a lot of questions and am not sure to what you are referring.
Thanks again for the reply.
Reese
Reese, (former CLAD, future CLD)
Some people call me the Space Cowboy!
Some call me the gangster of love.
Some people call me MoReese!
...I'm right here baby, right here, right here, right here at home

RE: (forte-users) Forte ADE

In addition to this confusion, I'd like to see some statement by Forte to
indicate
WHEN the next Forte R4 is scheduled (before the Sun era is was said to be
Summer 2000) and
WHAT exactly it will contain (major headings will do).
With the cancellation of the Forte Forum event doubt and uncertainty are
spreading in the
Forte communities that I talk with and no one seems to counterbalance these
doubts with an
official statement. How serious does Sun take TOOL Forte for the coming few
years? Release
of Fusion V2 seems to say "serious". The deafning silence with regard to R4
indicates the
opposite. And the users are divided (as always).
Theo de Klerk
Architecture & Application Integration
Professional Services
Compaq Computer Corp. - the Netherlands
-----Original Message-----
From: Rottier, Pascal [mailto:Rottier.Pascalpmintl.ch]
Sent: Tuesday, 18 April, 2000 17:49
To: 'kamranaminyahoo.com'
Subject: (forte-users) Forte ADE
A long, long time ago
In a galaxy far away....
I saw a demonstration of Forte's new Application Development
Environment,
which was more userfriendly than the current one. It also looked more
similar to the interface of the other development tools out
there, with a
tree structure and capabilities to browse through the
inheritance tree, and
not opening a new window for every project, class and method that is
accessed.
This new interface was supposed to be included in Forte 4, which would
combine TOOL and Java and would be released soon.
Since then, we've seen SynerJ and now FJEE, but Forte 4 is still not
released. And when it will be released, it still won't
support TOOL and Java
simultaneously. That's OK. I understand that.
But now I've heard that this improved ADE won't even be
included in Forte 4.
Is this true? And if so, why?
Pascal
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe,
send in a new
email the word: 'Unsubscribe' to:
forte-users-requestlists.xpedior.com

You may be interested in the following which comes from a statement of direction
recently issued by Sun.
Product Context
+ Forté 4GL is an award-winning, proven product with many unique advantages for
building
enterprise business systems that are distributed, that involve the integration
of existing
business systems as well as new functionality, and that target heterogeneous
runtime
environments.
+ Forté 4GL is recognized by Gartner Group as the most successful Enterprise
Application
Development Tool.
+ Forte 4GL has a substantial customer base that has been successful with the
product and that
looks forward to using Forté 4GL for new applications.
+ The Sun Microsystems, Inc. (SMI) development tools group (formerly Forté
Software, Inc.)
has a strong internal commitment to Forté 4GL. Forté Fusion is written with, and
is currently
being enhanced with Forté 4GL.
+ SMI has retained the Forté field sales organization as an independent unit
whose primary
product offerings are Forté 4GL and Forté Fusion. Continued volume sales of
Forté 4GL
remain the foundation of our business plan.
Product Future
+ We intend to actively enhance and promote Forté 4GL for the indefinite
future.
+ We believe Forté 4GL will flourish in the long term, especially if we are
able to harness the
considerable selling power of the entire SMI field sales organization. To make
the product
more attractive and easier to sell, we will continue to make the product more
modular and
easier to integrate with heterogeneous software environments.
+ We believe that the best opportunity for attracting new customers is to
leverage the ability of
Forté 4GL to easily build powerful shared business services (server components)
that can be
accessed by non-Forté clients (e.g., browsers, Java clients) and that can easily
integrate with
new and existing business systems.
+ We believe that Forté 4GL?s continued success is enhanced by continuing to
issue small and
frequent product releases. Our target is two such releases per year.
+ There is a great potential for our three product lines (Forté 4GL, Forté
Fusion, and Forté for
Java) to complement and reinforce each other. Interoperability among the three
product lines
is seen as a critical success factor for Forté 4GL.
Forte 4GL Statement of Direction Page 2
Sun Microsystems, Inc Proprietary and Confidential
Product Priorities
1. Interoperability with third party software components
+ External (non-4GL) client support (e.g., browsers, Java clients)
+ External server integration (e.g., messaging, component support, data
exchange)
2. Enhanced productivity
+ Increased automation (i.e., less coding)
+ Support for platform updates (e.g., new versions of OS, DBMS)
3. TOOL code to Java code migration
4. Unified developer look and feel with other Forte development products
5. Common repository
Short Term Product Plans
Mid-year release
+ New features available as ?preview? per the standard Forte maintenance
release procedures
+ Tentatively labeled ?release 3.5? and distributed as a free product
enhancement for
customers under maintenance
+ Scheduled for Summer 2000
+ Defining features
+ Introspection (reflection) ? the ability for an object to describe itself at
runtime
+ Improved integration with applications developed using Forté-for-Java
Community
Edition
+ Platform support improvements to track important operating system and
database
vendor activity
+ Target features
+ Display system enhancements (e.g., Motif 2 support, line arrowheads, window
refresh control, editable outline fields)
+ Dynamic library loading
+ Improved CORBA/IIOP support
+ Improved XML and XSLT class support
+ JMQ support
New year release
+ New features available as ?preview? per the standard Forte maintenance
release procedures
+ Tentatively labeled ?release 3.6? and distributed as a free product
enhancement for
customers under maintenance
+ Scheduled for year end 2000
+ Defining features
+ Any Release 3.5 target features that were not included in 3.5
+ Generation of EJB interfaces for R3 service objects
+ Platform support improvements to track important operating system and
database
vendor activity
+ Target features
+ COBOL record handling as part of the OS390 transaction adaptor
+ Improved runtime security
+ Interface classes for access to Netscape Server 4.0 and possibly other web
servers
Long Term Product Plans
+ To be determined by customer and market feedback.
+ A major criterion for new functionality will be enhancing the revenue
generating ability of
the product, thereby fostering its long-term health in the marketplace.
+ Substantial emphasis will be placed on creating new capabilities that enhance
the
attractiveness of the product for new users.
+ The contents of Release 3.7 (or whatever it will be called) will be
solidified just after release
3.5 ships. Subsequent planning visibility will be two forward releases.
"Klerk, Theo de" <Theo.de.Klerkcompaq.com> on 04/18/2000 12:27:36 PM
To: "'Rottier, Pascal'" <Rottier.Pascalpmintl.ch>,
"'kamranaminyahoo.com'" <kamranaminyahoo.com>
cc: (bcc: Charlie Shell/Bsg/MetLife/US)
Subject: RE: (forte-users) Forte ADE

Re: tracing execution and standard Forte messagefilters

Pierre,
There is a tech note describing some of the trace flags that will show
you interpreter profile information. This interface, the information
produced, etc. may change in future releases that's why it's a tech
note and not in the documentation set.
Hope this helps,
Bobby
This note describes how to use the execution profile collector built into
the Tool Interpreter.
NOTE: THIS INTERFACE IS UNSUPPORTED BUT IS MADE AVAILABLE AS IS TO USERS
UNTIL A SUPPORTED INSTANCE OF THE FEATURE EXISTS.
THE SUPPORTED VERSION WILL HAVE A DIFFERENT FUNCTIONALITY AND FORM.
The Tool Interpreter contains an execution profile data collector. The
collection
information can be displayed as trace output or the raw data can be collected
by the program for further manipulation and display. This information
describes the current level of support available. It is possible that this
mechanism will be updated in future releases and/or integrated into the
TOOL debugger.
The profiler only counts intructions executed in the interpreter, it doesn't
account for time spent in C++ code. However it is sill useful in finding
problems in interpreted code and for viewing the dynamic call flow of the
application.
The following trace information is available:
TRACE CALL-RETURN
This trace outputs a single indented line for each method call and
another single line for each method return. The line is indented an
amount equal to the call depth of the task calling the method. The
following information is displayed:
Task Id
Task Name
Method Name
Method Instruction Count
Task(Id=5,Name=InitialLom)Method(Name=Forte.TopClass.StartUp)
Task(Id=5,Name=InitialLom)Method(Instructions=10)
This is enabled using trace setting trc:in:50:1.
This trace can also be used to see the control flow of an application.
TRACE TASK BY METHOD
This trace outputs information about a task and all of the methods that
where called during it's execution. Each method contains information
about the number of times that the method was called and the total
number of instructions consumed by the methods execution. The task
contains the totals of all calls and instructions performed by the
task. The methods are sorted in descending order of instructions
executed.
The following in an example of the output:
TaskByMethod(Id=9,Name=projws.display,Instructions=2212)
ide.projws.updateMenus(Called=1,Instuctions=556)
ide.projws.addBlockComponentsToTree(Called=1,Instuctions=321)
ide.projwsPrefs.LoadPrefs(Called=1,Instuctions=247)
ide.projwsPrefs.Apply(Called=1,Instuctions=206)
UtilsDisplay.PrefMgr.FetchUserPref(Called=12,Instuctions=168)
ide.projws.computeWindowSize(Called=1,Instuctions=168)
ide.projws.refreshBrowser(Called=1,Instuctions=76)
UtilsBase.CompileSession.SetScope(Called=1,Instuctions=68)
ide.projws.fillToolObjTree(Called=1,Instuctions=65)
ide.projws.setTitle(Called=1,Instuctions=53)
UtilsBase.CompileSession.Init(Called=1,Instuctions=48)
UtilsBase.InterfaceBrokerBase.GetCompileSession(Called=1,Instuctions=41)
UtilsBase.InterfaceBrokerBase.LockSession(Called=1,Instuctions=30)
AppModel.abSurrogateRepositoryClient.GetRepository(Called=3,Instuctions=21)
UtilsBase.InterfaceBrokerBase.UnlockSession(Called=1,Instuctions=20)
UtilsDisplay.Workshop.Events(Called=1,Instuctions=20)
UtilsDisplay.Workshop.HelpEvents(Called=1,Instuctions=19)
ide.projws.lookupMask(Called=1,Instuctions=17)
UtilsBase.CompileSession.GetVersionStateForPlan(Called=1,Instuctions=14)
ide.projws.LoadPrefs(Called=1,Instuctions=13)
AppModel.abSurrogateRepositoryClient.GetVersionStateForPlan(Called=1,Instuct
ions=8)
AppModel.abSurrogateRepositoryClient.FindProject(Called=1,Instuctions=8)
ide.projws.resetCurrentNode(Called=1,Instuctions=7)
AppModel.abSurrogateRepositoryClient.IsDetached(Called=1,Instuctions=7)
ide.projws.selectComponent(Called=1,Instuctions=6)
ide.projwsPrefs.Init(Called=1,Instuctions=5)
This is enabled using trace setting trc:in:51:1.
TRACE APP BY METHOD
This trace outputs information about an application and all of the
methods that were called during its execution. Each method contains
information about the number of times that the method was called and
the total number of instructions consumed by the methods execution.
The application contains the totals of all calls and instructions
performed by the task.
The output is similar to the previous case.
This is enabled using trace setting trc:in:53:1.
TRACE TASK BY CALLTREE
This trace outputs the call tree of the task. The call tree shows a
method and all of the methods that it called. And for each of the
called methods the same output is displayed. This can be used to
see more of the call structure of a task. It call also be used to
find the paths in the call tree that consumed most of the instructions.
The methods are sorted in descending order of instructions executed
within each level of the call tree.
TRACE APP BY CALLTREE
This trace outputs the call tree of the application. The call tree
shows a method and all of the methods that it called. And for each of
the called methods the same output is displayed. This can be used to
see more of the call structure of an application. It call also be used
to find the paths in the call tree that consumed most of the
instructions.
The output is similar to the previous case.
This is enabled using trace setting trc:in:54:1.
The following collected information is available:
NOTE: None of the collection options are available at this time.
COLLECT TASK BY METHOD
COLLECT APP BY METHOD
COLLECT TASK BY CALLTREE
COLLECT APP BY CALLTREE
Other potential future features:
The profiler doesn't record when some interpreted TOOL code invokes a method
on a object which in implemented in C++. This causes some profile
information to be lost. If the C++ code invokes a method that is
implemented as interpreted TOOL the BYCALLTREE profile will not show the
C++ code. Thus it could be confusing because it appears that the
interpreted code called something totally different than the what is
expected.
At 10:41 AM 7/31/96, Pierre Gelli wrote:
Hello,
During the process of tuning an application, or just of making it work, it
is useful to trace the flow of processing.
There are two ways of doing it :
1) add your own trace instructions (calls to the LogMgr) at the appropriate
places,
2) use the traces of the Forte Interpreter !
If one relies on solution 1, then it relies on what the developers have
written (and thus sometime forgotten to write !) in their code.
If one relies on solution 2, then potentially it can get as much information
as is available to the interpreter (and the debugger ?), in a fully
independant way since it uses directly the code itself and not added trace
instructions.
So solution 2 seems quite interesting.
Unfortunately there are some potential problems :
a) I haven't found in the documentation an exhaustive description of the
logs the Forte tools do. The only and very short description is on page 148
of the System management Guide. It's far from being exhaustive. So it
requires playing with the filters.
I recommand trying trc:in:1-63. I guess "in" stands for the interpreter.
- level 1 seems to give the call tree,
- level 255 seems to give almost the code !
b) since the flags are not documented by Forte, how reliable and stable will
they be in future versions ?
c) what happens for compiled partitions is not clear to me (I have not tried
it yet).
So my question : are the message filters used by the Forte Tools like the
interpreter described somewhere, i.e. in some Tech Note (I don't have access
to them yet) ?
best regards,
Pierre Gelli
ADP GSI
Payroll and Human Resources Management
72-78, Grande Rue, F-92310 SEVRES
phone : +33 1 41 14 86 42 (direct) +33 1 41 14 85 00 (reception desk)
fax : +33 1 41 14 85 99

From: Pierre Gelli <[email protected]>
Subject: tracing execution and standard Forte message filters
Hello,
During the process of tuning an application, or just of making it work, it
is useful to trace the flow of processing.
There are two ways of doing it :
1) add your own trace instructions (calls to the LogMgr) at the appropriate
places,
2) use the traces of the Forte Interpreter !
So solution 2 seems quite interesting.
Unfortunately there are some potential problems :
a) I haven't found in the documentation an exhaustive description of the
logs the Forte tools do. The only and very short description is on page 148
of the System management Guide. It's far from being exhaustive. So it
requires playing with the filters.
I recommand trying trc:in:1-63. I guess "in" stands for the interpreter.
- level 1 seems to give the call tree,
- level 255 seems to give almost the code !
b) since the flags are not documented by Forte, how reliable and stable will
they be in future versions ?
Pierre Gelli,
level 255 is the most detailed you are right on tracing..... As for documentation
you will want to get ahold of several good tech notes that your Forte
rep or support can get you which provide alot of the info you are after.
Let me know if you can't do this and I can send you some of this info, but you are
best to get the latest and greatest directly from Forte.
Len Leber
ATG Partners

RE : Who would benefit from Forte?

RE : Jerry Fatcheric's message about "Who would benefit from Forte?"
With regards the point mentioned in the attached message from Jerry
Fatcheric below, I would like to illustrate my point. I implemented in both
Visual Basic and Delphi, the example that is mentioned in the attached
message, about a browser application, having the capability to browse
thousands of records with the inital screenful needing to come ASAP. It took
me less than 2 minutes to implement this in VB (I timed it). Just threw a
"remote data" control and a "DBGrid" control on a form, set a few properties
and wrote a "select *" sql specifying that only 30 records be returned at a
time. For a table with 4K records, the first 30 came in and got displayed in
less than 2 seconds. In Delphi, the response was even better and whole 4K of
record could be retrieved in less than 4 second. (Yes less than 4 seconds
for retrieving 4000 records from a DB2/NT database running on a remote
machine). Even I could not believe the performance of Delphi which I haven't
used that much. These tools are THE fastest way to get the data from a
database server to a windows client. These will perform any day better than
FORTE. One of the problem that I came across FORTE in one of situations like
this was data movement across nodes is very costly. In one of our
applications, since we stored the data as objects, in a similar situation as
you have mentioned, the performance of moving a lot of data form the server
to the client was not very good and in consulation with FORTE technical
support we had to convert the data in objects to scalar (delimited string),
move across node, and convert the data back to object at a client.
Performance increase - 40 secs. vs 120 secs. earlier.
About my background. I have worked about 8 years in application development
and for the past 4 years have been working in a client server environment.
Being a consultant, I have used many tools, including FORTE for one year, to
provide my clients with the most bang for their buck, which to me is the
topmost priority as a Consultant. I do not decide for my clients what
technology they should use but sure evaluate the various options they have
and recommend more than one solutions, listing the advantages and
disadvantages.
Currently working on coming up with a solution for a client with a customer
service application need with around 50 users now, scaling up to 100 users
in the future. The best solution that I could come up with was a logical
3-tier with the presentation and the business layer running on NT
workstation (client) and the database on NT server (server). With all the
processing on a powerful and healthy (not "fat") client the system, I feel
can scale very well. For a 500 user system, you literally have 500
application server (physically on the client machine) being served by one
data server. To the data server, having a physical middle tier between the
client and the data server, I feel would not help, at least in our
situation. Almost everything that the middle tier could do to reduce the
load on the data server can be handled by the "business layer" running on
the client machine. It does mean that each user connects to the database
directly so in a case of 500 user, there are 500 connections to the database
but lately with the sophisticated DBMS, this is no longer an issue. The DBMS
can manage this many user very economically (read the benchmark about SQL
server with 5000, yes 5k user at "www.microsoft.com/sql") and almost as well
as a middle tier. It is fault tolerant - nothing can bring down the system
except a client failure, the data server failure or a network failure, the
same failure points as a N-Tier solution unless you are replicating or
duplicating the database. In our solution our application is as scaleable as
the database is, and the databases available today are very scaleable if you
look at the current database technology offerings.
As you may have guessed the abovementioned solution is cheaper with a very
fast "time to market" than a forte solution (we started this about 6 months
back and are in production for the past 1 month). This may not have all the
features that FORTE offers, but for our purposes and I feel in similar
applications, what we got was what we needed. By no means, this is going to
meet all information tecnology needs for everyone and in many situations I
believe FORTE would be well suited than any other tool.
I still use FORTE can would continue to do so for some of the solutions that
we develop, but I do not think that one shoud be using FORTE for "any
development that is bigger than a breadbox" as Mr. Fatcheric suggests in the
attached message, simply because if I do that, than I think that in some
cases I would be selling the user a tank when the user just needs a rifle.
I consider giving my clients the most value for their money in getting this
solution developed. I would suggest my clients FORTE when I think they needs
them but would definitely suggest another solution if I think that they can
get their solution developed and get more value for their money using some
other tool. Towards this end I would like to find out what kind of solutions
people are developing and what kind of performance they are getting
specially related to Windows platform.
Any information about the benefits (actual benefits) you are getting from
FORTE would be highly appreciated which would let a lot of us decide when to
use FORTE and when not to use FORTE to meet ours and our clients'
everchanging information technology needs.
- Ari Singh
[email protected]
Ari Singh wrote a provocative piece questioning the benefits of Forte
in "Windows only", non-large scale applications. Rather than get into
a large philosopical discussion, I would like to illustrate my point
with an example taken from a current Forte project.
First, my background: 10+ years in Client server applications. Worked
for several years at Oracle and have experience with Sybase. Worked
extensively with a 2 tiered CS product (Uniface) and write C and C++.
NOT a Windows expert.
In our current application, the requirement is to allow the user to
browse literally thousands of records on the Windows Client. There will
never be lots of users doing this, but the ones that do must have
reasonable performance. Our initial tests indicated that if we simply
had the server pump the data to the client, we would have significant
performance problems and face memory limitations on the PC. SO we
utilized Forte's N-tiered capabilities. When the user starts a query
(using dynamic sql with user controlled WHERE and ORDER BY), we start
an asynchronous retrieval on the server with data is cached in an
anchored object on the server. When the query has found the first
THIRTY (30) records (2 screens worth), it posts an event to the client
and the client request the first thirty. The retrieval process continues
independently while the user can browse data on the client. Not until
the user scrolls down far enough does the client again request more
data. If the user quits from the screen or starts a new query, the
first one is cancelled. Otherwise, the query runs to completion on the
server.
This approach gives us 3-5 second response time regardless of the size
of the query result set. It minimizes the data on the client (moving
us toward a thin client). The kicker is that with the help of Martha
Lyman from Forte, we developed this technique in about 4 hours! Add
to this all the standard inheritance, OO stuff, partitioning,
customized monitoring, etc, etc, and IT IS MY OPINION that Forte
is a GOOD tool for any development that is bigger than a breadbox
and worth the $$$. And that's the way it is.... SO there...
Jerry Fatcheric
Relational Options, Inc.
Florham Park, New Jersey
201-301-0200
201-301-00377 (FAX)
[email protected]

RE : Jerry Fatcheric's message about "Who would benefit from Forte?"
With regards the point mentioned in the attached message from Jerry
Fatcheric below, I would like to illustrate my point. I implemented in both
Visual Basic and Delphi, the example that is mentioned in the attached
message, about a browser application, having the capability to browse
thousands of records with the inital screenful needing to come ASAP. It took
me less than 2 minutes to implement this in VB (I timed it). Just threw a
"remote data" control and a "DBGrid" control on a form, set a few properties
and wrote a "select *" sql specifying that only 30 records be returned at a
time. For a table with 4K records, the first 30 came in and got displayed in
less than 2 seconds. In Delphi, the response was even better and whole 4K of
record could be retrieved in less than 4 second. (Yes less than 4 seconds
for retrieving 4000 records from a DB2/NT database running on a remote
machine). Even I could not believe the performance of Delphi which I haven't
used that much. These tools are THE fastest way to get the data from a
database server to a windows client. These will perform any day better than
FORTE. One of the problem that I came across FORTE in one of situations like
this was data movement across nodes is very costly. In one of our
applications, since we stored the data as objects, in a similar situation as
you have mentioned, the performance of moving a lot of data form the server
to the client was not very good and in consulation with FORTE technical
support we had to convert the data in objects to scalar (delimited string),
move across node, and convert the data back to object at a client.
Performance increase - 40 secs. vs 120 secs. earlier.
About my background. I have worked about 8 years in application development
and for the past 4 years have been working in a client server environment.
Being a consultant, I have used many tools, including FORTE for one year, to
provide my clients with the most bang for their buck, which to me is the
topmost priority as a Consultant. I do not decide for my clients what
technology they should use but sure evaluate the various options they have
and recommend more than one solutions, listing the advantages and
disadvantages.
Currently working on coming up with a solution for a client with a customer
service application need with around 50 users now, scaling up to 100 users
in the future. The best solution that I could come up with was a logical
3-tier with the presentation and the business layer running on NT
workstation (client) and the database on NT server (server). With all the
processing on a powerful and healthy (not "fat") client the system, I feel
can scale very well. For a 500 user system, you literally have 500
application server (physically on the client machine) being served by one
data server. To the data server, having a physical middle tier between the
client and the data server, I feel would not help, at least in our
situation. Almost everything that the middle tier could do to reduce the
load on the data server can be handled by the "business layer" running on
the client machine. It does mean that each user connects to the database
directly so in a case of 500 user, there are 500 connections to the database
but lately with the sophisticated DBMS, this is no longer an issue. The DBMS
can manage this many user very economically (read the benchmark about SQL
server with 5000, yes 5k user at "www.microsoft.com/sql") and almost as well
as a middle tier. It is fault tolerant - nothing can bring down the system
except a client failure, the data server failure or a network failure, the
same failure points as a N-Tier solution unless you are replicating or
duplicating the database. In our solution our application is as scaleable as
the database is, and the databases available today are very scaleable if you
look at the current database technology offerings.
As you may have guessed the abovementioned solution is cheaper with a very
fast "time to market" than a forte solution (we started this about 6 months
back and are in production for the past 1 month). This may not have all the
features that FORTE offers, but for our purposes and I feel in similar
applications, what we got was what we needed. By no means, this is going to
meet all information tecnology needs for everyone and in many situations I
believe FORTE would be well suited than any other tool.
I still use FORTE can would continue to do so for some of the solutions that
we develop, but I do not think that one shoud be using FORTE for "any
development that is bigger than a breadbox" as Mr. Fatcheric suggests in the
attached message, simply because if I do that, than I think that in some
cases I would be selling the user a tank when the user just needs a rifle.
I consider giving my clients the most value for their money in getting this
solution developed. I would suggest my clients FORTE when I think they needs
them but would definitely suggest another solution if I think that they can
get their solution developed and get more value for their money using some
other tool. Towards this end I would like to find out what kind of solutions
people are developing and what kind of performance they are getting
specially related to Windows platform.
Any information about the benefits (actual benefits) you are getting from
FORTE would be highly appreciated which would let a lot of us decide when to
use FORTE and when not to use FORTE to meet ours and our clients'
everchanging information technology needs.
- Ari Singh
[email protected]
Ari Singh wrote a provocative piece questioning the benefits of Forte
in "Windows only", non-large scale applications. Rather than get into
a large philosopical discussion, I would like to illustrate my point
with an example taken from a current Forte project.
First, my background: 10+ years in Client server applications. Worked
for several years at Oracle and have experience with Sybase. Worked
extensively with a 2 tiered CS product (Uniface) and write C and C++.
NOT a Windows expert.
In our current application, the requirement is to allow the user to
browse literally thousands of records on the Windows Client. There will
never be lots of users doing this, but the ones that do must have
reasonable performance. Our initial tests indicated that if we simply
had the server pump the data to the client, we would have significant
performance problems and face memory limitations on the PC. SO we
utilized Forte's N-tiered capabilities. When the user starts a query
(using dynamic sql with user controlled WHERE and ORDER BY), we start
an asynchronous retrieval on the server with data is cached in an
anchored object on the server. When the query has found the first
THIRTY (30) records (2 screens worth), it posts an event to the client
and the client request the first thirty. The retrieval process continues
independently while the user can browse data on the client. Not until
the user scrolls down far enough does the client again request more
data. If the user quits from the screen or starts a new query, the
first one is cancelled. Otherwise, the query runs to completion on the
server.
This approach gives us 3-5 second response time regardless of the size
of the query result set. It minimizes the data on the client (moving
us toward a thin client). The kicker is that with the help of Martha
Lyman from Forte, we developed this technique in about 4 hours! Add
to this all the standard inheritance, OO stuff, partitioning,
customized monitoring, etc, etc, and IT IS MY OPINION that Forte
is a GOOD tool for any development that is bigger than a breadbox
and worth the $$$. And that's the way it is.... SO there...
Jerry Fatcheric
Relational Options, Inc.
Florham Park, New Jersey
201-301-0200
201-301-00377 (FAX)
[email protected]

Forte access to AS/400 Databases

Does anyone have any experiences accessing an AS/400 database from a
Forte partition? If so, we would like to know if ODBC or some other
technique was used. If ODBC was used, what vendor supplied the ODBC
connection?
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Thanks for the ideas, but nothing works so far. Trying other versions was an excellent idea. How silly of me that I didn't try that right off. We were actually using an older version of the toolbox (our software is regulated by the FDA as a medical device so changing our platform is a major process). I tried several newer versions and it was the same.
Oh well, no big for now. In the future we'd still like to use record level access, but for now we are okay. This came up over an issue of record locking--needing to maintain a record lock during some calculations. We got it working using jdbc's updatable statements/resultsets.

Future of Forte

Similar Messages

Maybe you are looking for