RE: (forte-users) Conductor Distributed AccessException
Man! you need some Gas. Top it up and give it a go :)
-----Original Message-----
From: mmynatt [mailto:mmynattcomponentsartistry.com]
Sent: Wednesday, 29 March 2000 10:19 am
To: Forte-Users-Digest
Subject: (forte-users) Conductor Distributed Access Exception
Hi,
Has anyone ever seen this error message in the conductor trace window on
starting an engine:
Channel.Open() Distributed Access exception on initiator channel "Ping" from
initiator component dbserv1(db unit) to component DB router primary caused
the channel to be disconnected.
The engine will not start.
Mark Mynatt
Components Artistry, Inc.
303-688-0784
mmynattcomponentsartistry.com <mailto:mmynattcomponentsartistry.com>
Hi Jagadish,
I'm not trying to change it, it's at "Allowed" on all of my superclasses,
and I want it to be "Allowed" on the subclass too. If I remember correctly
there's some blurb in the manual somewhere that objects are smaller and/or
quicker if you turn of the subclass override thing?
Anyway, apparently, according to other replies I've received, it's just a
forte bug, and I need to recreate the service object. I'll give it a go
when I get in to work tomorrow and come back to you all if it still doesn't
work...
Thanks everyone,
Tim Sawyer
Development Consultant
PanCredit
Leeds, UK.
-----Original Message-----
From: [email protected]
To: Tim Sawyer
Cc: '[email protected]'
Sent: 17/04/01 18:39
Subject: Re: (forte-users) Distributed Property
You have the answer. A class should set "Subclass Override" to TRUE (or
ON)
if it wants any of its derived classes to override the behaviour.
If you want your subclass to be able set its Runtime properties
(Distributed, Shared, Transactional, Monitored), then turn ON "Subclass
override" in all the classes above in the hierarchy.
Jagadish
This e-mail and its attachments are for the use of the addressee only.
It may contain information that is legally privileged, confidential and
exempt from disclosure. It is not a contract, and prices, data
and other information are not warranted as to completeness or accuracy.
Any comments or statements made herein do not necessarily
reflect those of PanCredit Systems Limited. If you are not the intended
recipient you must not copy, distribute or disseminate this e-mail
or attachments to anyone other than the addressee.
If you receive this communication in error please advise us by telephone
at once.
PanCredit Systems Limited
Tel: +44 113 250 0260
Fax: +44 113 250 0621
Similar Messages
-
Re: (forte-users) Distributed Property
You have the answer. A class should set "Subclass Override" to TRUE (or ON)
if it wants any of its derived classes to override the behaviour.
If you want your subclass to be able set its Runtime properties
(Distributed, Shared, Transactional, Monitored), then turn ON "Subclass
override" in all the classes above in the hierarchy.
Jagadish
Tim Sawyer
<Tim.Sawyer@panc To: "'[email protected]'"
redit.com> <[email protected]>
cc:
04/17/2001 12:37 Fax to:
Subject: (forte-users) Distributed Property
Hello.
I've just created a service object, based on a new subclass. The new
subclass has distributed property set to allowed, and the other three set
to
disallowed. These are set about four layers further up the inheritance
hierarchy, and have subclass override turned off.
When I try and run my app, I get the following error:
USER ERROR: The class apiAbstractClasses.PanAPIReplicate used as the type
of
service object apiAbstractClasses.PanAPIReplicateSO has the 'Distributed'
property set to 'DISALLOWED', so it cannot be used as the type of a
service
object.
Class: qqsp_UsageException
Error #: [1602, 358]
Detected at: qqcf_GlobalDefinition::ProxyClass at 1
Last TOOL statement: method partws.HandleRunCmd
Error Time: Tue Apr 17 17:33:34
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 2DC37DB0-BD7A-11D4-A08F-220DA12BAA77:0x1ad3:0xb, taskId =
[2DC37DB0-BD7A-11D4-A08F-220DA12BAA77:0x1ad3:0xb.392]) in application
"FTLaunch_cl0", pid 318 on node TORGOS in environment 43DENV.
So I have distributed set to Allowed and the error says "Oh know you don't"
in true panto style.
Anyone like to suggest a direction I start looking in to fix this?
Cheers,
Tim Sawyer
Development Consultant
PanCredit
Leeds, UK.
This e-mail and its attachments are for the use of the addressee only.
It may contain information that is legally privileged, confidential and
exempt from disclosure. It is not a contract, and prices, data
and other information are not warranted as to completeness or accuracy.
Any comments or statements made herein do not necessarily
reflect those of PanCredit Systems Limited. If you are not the intended
recipient you must not copy, distribute or disseminate this e-mail
or attachments to anyone other than the addressee.
If you receive this communication in error please advise us by telephone
at once.
PanCredit Systems Limited
Tel: +44 113 250 0260
Fax: +44 113 250 0621
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]Hi Jagadish,
I'm not trying to change it, it's at "Allowed" on all of my superclasses,
and I want it to be "Allowed" on the subclass too. If I remember correctly
there's some blurb in the manual somewhere that objects are smaller and/or
quicker if you turn of the subclass override thing?
Anyway, apparently, according to other replies I've received, it's just a
forte bug, and I need to recreate the service object. I'll give it a go
when I get in to work tomorrow and come back to you all if it still doesn't
work...
Thanks everyone,
Tim Sawyer
Development Consultant
PanCredit
Leeds, UK.
-----Original Message-----
From: [email protected]
To: Tim Sawyer
Cc: '[email protected]'
Sent: 17/04/01 18:39
Subject: Re: (forte-users) Distributed Property
You have the answer. A class should set "Subclass Override" to TRUE (or
ON)
if it wants any of its derived classes to override the behaviour.
If you want your subclass to be able set its Runtime properties
(Distributed, Shared, Transactional, Monitored), then turn ON "Subclass
override" in all the classes above in the hierarchy.
Jagadish
This e-mail and its attachments are for the use of the addressee only.
It may contain information that is legally privileged, confidential and
exempt from disclosure. It is not a contract, and prices, data
and other information are not warranted as to completeness or accuracy.
Any comments or statements made herein do not necessarily
reflect those of PanCredit Systems Limited. If you are not the intended
recipient you must not copy, distribute or disseminate this e-mail
or attachments to anyone other than the addressee.
If you receive this communication in error please advise us by telephone
at once.
PanCredit Systems Limited
Tel: +44 113 250 0260
Fax: +44 113 250 0621 -
RE: (forte-users) Distributing library - What could preventmy li b fro
Hi Jean..
I remotely remember seeing this kind of a problem before. I think you can
start by cleaning your environment. You can do this by:
1) Exporting your environment definition from econsole or using escript. The
.edf file goes into the forte_root\envdist directory
2) bringing down the environment.
3) removing the .btd and.btx files of the environment in
forte_root\sysdata\envrepos
4) start the environment using bootstrap i.e using the -e option.
Hope that solves it for you..
Ravi Kalidindi
Born Info Svcs Inc
-----Original Message-----
From: Jean-Paul Gabrielli [mailto:[email protected]]
Sent: Wednesday, September 01, 1999 9:04 AM
To: '00 Forte Mailinglist'
Subject: (forte-users) Distributing library - What could prevent my lib
from being made ?
(8) CMD: SetProjType 3
(9) CMD: Partition 3
USER ERROR: The project MYPROJ is already contained in version of
application and cannot be placed into another library application.
Class: qqsp_UsageException
Error #: [1602, 562]
Detected at: qqcf_LibraryConfig::SetProject at 1
Error Time: Wed Sep 1 15:30:25
Exception occurred (locally) on partition "Fscript_cl9_Client",
(partitionId = 4C0B7D30-6055-11D3-B8B3-2E3EAC99AA77:0x126:0x1, taskId
=
[4C0B7D30-6055-11D3-B8B3-2E3EAC99AA77:0x126:0x1.1]) in application
"fscript", pid 18036 on node mynode in environment myenv.
Thanks for any suggestion
j-paul
[Jean-Paul Gabrielli]
NOTE: If you got this twice, sorry but I got a strange mail saying i was not
a subscriber and reposted.
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]Hi,
I'm from germany so no 'best buy' but I think I will lock around sleeve/bag for a different product with same measures. Any tip?
The clear plastic case is not what I want. I would like to use the player without such protections. I just want a sleeve to protect the player while its in my jacket/pants.
Btw, i have bought this version: Creative Zen (maybe european version?). I also doesn't seem to have your mentioned sleeve. I also couldn't find it on the website.
Anyway, thank you,
Chris -
RE: (forte-users) Class compatibility
Pascal,
Basically the way to work with objects as parameters is to ensure that
sending and receiving parties have the same knowledge of the underlying
classes of these objects.
o Partitions in one application, generated at distribution time always are
"in sync" with one another as they use the same class definitions specified
through the supplier plan relationships of the main project
o Applications distributed independently that exchanging objects only
understand the common set of class definitions.
For example, a Forte Conductor engine object is built using the standard
Forte Framework classes. Its API specifies things like "DataValue" objects.
Sending it a TextData is fine, sending it MyOwnTextData is not - the other
application has no clue what that (sub)class is supposed to be as it did not
know at the time it was built.
This is also true in cases where applications use libraries and these are
given objects of (sub)classes it knows nothing about.
All of these generate serialisation errors of some sort since the flattened
object that is sent across the wire cannot be reconstructed at the receiving
end by lack of a blueprint (class definition) on how to create such an
object.
Theo de Klerk
Architecture & Application Integration
Professional Services
Compaq Computer Corp. - the Netherlands
PGP Fingerprint: 5A70 DD56 F3BA FE04 9DCA 1ACE 8581 0A2F F057 FA6ETheo,
I understand all of that. Of course we make sure that all components use the
same blueprints for all classes. However, in case we managed to get these
blueprints out of sync, we don't want the application to simply crash. We
want to trap this exception and print a message that says: "There seems to
be a compatability problem between components. Please make sure the latest
version of all application components have been installed."
Of course we can trap all exceptions (GenericException) and ignore all of
them after displaying them, but that seems like a blunt-axe-approach. I'm
looking for the scalpel.
Pascal Rottier
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: Klerk, Theo de [mailto:Theo.de.Klerkcompaq.com]
Sent: Wednesday, October 18, 2000 5:15 PM
To: Rottier, Pascal; 'Forte Users'
Subject: RE: (forte-users) Class compatibility
Pascal,
Basically the way to work with objects as parameters is to ensure that
sending and receiving parties have the same knowledge of the underlying
classes of these objects.
o Partitions in one application, generated at distribution time always are
"in sync" with one another as they use the same class definitions specified
through the supplier plan relationships of the main project
o Applications distributed independently that exchanging objects only
understand the common set of class definitions.
For example, a Forte Conductor engine object is built using the standard
Forte Framework classes. Its API specifies things like "DataValue" objects.
Sending it a TextData is fine, sending it MyOwnTextData is not - the other
application has no clue what that (sub)class is supposed to be as it did not
know at the time it was built.
This is also true in cases where applications use libraries and these are
given objects of (sub)classes it knows nothing about.
All of these generate serialisation errors of some sort since the flattened
object that is sent across the wire cannot be reconstructed at the receiving
end by lack of a blueprint (class definition) on how to create such an
object.
Theo de Klerk
Architecture & Application Integration
Professional Services
Compaq Computer Corp. - the Netherlands
PGP Fingerprint: 5A70 DD56 F3BA FE04 9DCA 1ACE 8581 0A2F F057 FA6E
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 -
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.comGabriel,
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 -
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] -
RE: (forte-users) Reporting tools/components for ForteApplications?
Hi Robert,
A good place to start when it comes to reporting is Forte Consulting. They
have developed a tool called ReportKit, which is ActiveX integration with
Seagate Software's Crystal Reports tool. Crystal is not really a three-tier
tool (although, your Forte Consultant can probably set it up to mimic a
three-tier tool), but it is a quick, easy way to get quality reports from
your existing Forte applications. If you're interested, give your Forte
Sales Rep (or, better still, your Forte Regional Consulting Director) a
call. They can discuss pricing and scheduling. I've done several
integration projects with Crystal, and I highly recommend ReportKit for
small- to medium-sized reporting requirements. As for costs, I don't recall
how much CrystalReports runs, but I think there are developer licenses and
runtime licenses.
FYI, the actual integration of ReportKit is pretty quick. The more
time-consuming piece of any report tool integration is the design and
implementation of the reports to be used.
I hope this helps.
-Katie
Katie Tierney
Quality Management Analyst
Akili Systems Group
601 Jefferson, Suite 3975
Houston, Texas 77002
Office: (713) 655-1400
Cell: (409) 255-1643
"The bitterness of poor quality remains long after the sweetness of low
price is forgotten" --Larry Anderson
-----Original Message-----
From: Robert Brooke-N502365 [mailto:Robert.Brookeca.michelin.com]
Sent: Monday, February 14, 2000 8:17 AM
To: kamranaminyahoo.com
Subject: (forte-users) Reporting tools/components for Forte
Applications?
Hi all,
We are looking for what is currently in the marketplace to enhance the
reporting
capabilities of Forte. Ideally, we are looking for component libraries that
we
could import into our repository. Do these exist?
Currently, I have found six reporting tools that are out there. The
tools
are Actuate, Crystal Reports, Report Workshop from Indus Consultancy
Services, Brio Technologies (SQR) VisualBRIO, Visual CyberQuery from
Cyberscience Corp., and Beacon from Brahma Software Solutions FORTify
Components. Are there any others for Forte?
If anyone is currently using one of these Reporting Tools for Forte or
any
others, could you give me any indications as to the costs, training, type
of
application using the Reporting tool, would you recommend using the
product
again, does it use wrappering or API, or is it a component based tool, and
any
other relevant information on the product?
Thanks,
Robert Brooke
Application Developer
Michelin North America (Canada) Inc. CA0/CA1
PO Box 399
New Glasgow, Nova Scotia
B2H-3E6
Phone: (902) 753-1977
Fax: (902) 396-2180
Note: We are currently developing in Forte 3.0.L.2. However, we would
like
to select a reporting tool/component within the next month. We are in the
initial phases of our next project, an application to be developed
in-house.
Probably will have two databases, one for real-time data and another one
for
archived data. Probably will need reporting functionality and capabilities
for
both real-time data and archived data.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
The E-Mail System is to be used for business purposes only.
www.mimesweeper.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.comAt 09:33 AM 4/20/01, Rottier, Pascal wrote:
Forte 4GL is:
1) A language, TOOL (Compare to Java)
2) An IDE (Compare to e.g. JBuilder or FJCE)
3) A collaborative development environment, with central repository (Compare
to ????)
4) A distributed application server / object request broker (Compare to J2EE
servers and/or CORBA)Let's not forget WebEnterprise, Express, and especially Fusion.
I think, SUN is not al all interested in TOOL.If TOOL were just a language and had no market yet, you are probably
right. But, not only is TOOL the key to the Forte environment, but it has
an existing and profitable market. Sun still sells FORTRAN, after all, and
continues to put money into ADE development for all its language
products. The real kicker, though, is that I think iPlanet is very clear
that Fusion, now iIS, is a very key product for them. There may be those
who wish it were written in Java and who might lobby for doing a Java
version, but it was clear at the conference that the iPlanet management
recognize that Java just isn't up to the task at this point. It isn't as
if all the iPlanet tools are actually written in Java, after all.
They will only support them for as long as they need.Or, more likely, for as long as they make money.
Now, in response to Microsofts .NET stratagy. We have yet to see how
succesfull this will be, but I expect Microsoft to push this down the
throats of developers and companies quite succesfully.Like they did DCOM?
=========================================================================
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 -
Re: (forte-users) Delays in data transfer..server-to-client
I would try using DOM (distributed object manager) traces. trc:do:20 will
give you information on each messages sent from and received by the
partition. Levels are 1, 2, 5, 7, and 8, and trc:do:*:8 is very
verbose. trc:do:20:1 may tell you what you want to know. trc:do:1:1 will
give you a basic 1-line-per DOM event trace that may also be all you need.
Communications manager traces will tell you about network and socket-level
activity, but not about the sizes of the messages themselves. In addition,
the operating system makes decisions about physical packet size and
send/receive timing, so CM activities only generally map to actual network
activity.
-tdc
iPlanet Integration Server Engineering
At 09:24 AM 5/1/01 -0700, you wrote:
All,
We are experiencing delays in object transfer between server and client. The
delays are longer with large objects (a single object with an array of objects
that reflect the rows returned in a database) than small (ie: 10 rows vs 400).
Does anyone have any (actual) experience using the various Forte' flags in
order
to show the actual size of the object/packets being passed between the server
and client?
We are using input/output between client and server, input on all the SO's
within a partition. Response on the server side is good, roughly 6 seconds or
so. The round trip fare however from the time the client makes the SO call to
the time that it completes is in the 25-30 second range, leaving roughly 20-25
seconds unaccounted for. I have brought in the network guys who are
requesting
the data size and packet information. I did not see what I am looking for
using
the trc:cm:*:4 and trc:cm:*:8 flags. I will be trying the trc:cm:*:10
flag, but
Forte' indicates that this flag is very verbose, the systems group hates
it when
I use up all of THEIR disk space!
Any ideas would be appreciated as always.Jeff,
If the object you are passing does not require changes made to it in the
server partition to be returned, pass the object as copy input (pass by
value not reference). If it is necessary to pass the object as input, try
to pass only the attributes that are required to the remote partition
instead of the whole object.
Input/Output is normaly used with scalar variables. When a scalar is passed
to a remote partition, if the value is changed in that partition, the value
is not returned to the calling partition unless Input/Output is used.
Input/Output should not be used for object type parameters, if you need to
pass a reference, use Input only. If you can pass by value, use Copy Input.
You will notice a huge difference in performance changing from Input to Copy
input when passing large objects.
Hope this helps,
Travis Foote
Fortedeveloper.com Inc.
----- Original Message -----
From: "Jeff Bennett" <[email protected]>
To: <[email protected]>
Sent: Tuesday, May 01, 2001 9:24 AM
Subject: (forte-users) Delays in data transfer.. server-to-client
>
All,
We are experiencing delays in object transfer between server and client.The
delays are longer with large objects (a single object with an array ofobjects
that reflect the rows returned in a database) than small (ie: 10 rows vs400).
>
Does anyone have any (actual) experience using the various Forte' flags inorder
to show the actual size of the object/packets being passed between theserver
and client?
We are using input/output between client and server, input on all the SO's
within a partition. Response on the server side is good, roughly 6seconds or
so. The round trip fare however from the time the client makes the SOcall to
the time that it completes is in the 25-30 second range, leaving roughly20-25
seconds unaccounted for. I have brought in the network guys who arerequesting
the data size and packet information. I did not see what I am looking forusing
the trc:cm:*:4 and trc:cm:*:8 flags. I will be trying the trc:cm:*:10flag, but
Forte' indicates that this flag is very verbose, the systems group hatesit when
I use up all of THEIR disk space!
Any ideas would be appreciated as always.
-jeff
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] -
Troy Burns wrote:
It would definitely be of interest to me, since this is an item on my
"to-do" list. If you can release the code, let me know.Here 'tiz.
The files you're getting are:
SFVosC.pex - "C" wrapper.
Vos.C - The "C" callout.
Vos.H - A header file for Vos.C, used by ...
VosCLI.C - A command-line-driven mainline to test Vos.C
VosObj.CEX - An object that provides a "nice" interface to the "C" wrapper.
We use this in two ways: instantiated as a local object to get the username
under VMS or NT, or as a service object partitioned to an NT server to do
username/password authentication on behalf of clients on other operating
systems.
The following changes have been made throughout the files in an attempt to
keep various people in DuPont happy:
"our_application_root" replaces the actual name of the root directory of
the application.
"our_vms_server" replaces the actual name of the system in question.
"our_nt_server" replaces the actual name of the system in question.
"our_application_name" replaces the actual name of the application.
A copyright notice, the usual disclaimer, and a "fair use" statement (which
is just a reference to the Perl Artistic License) have been inserted.
Except for the "ExternalObjectFiles" declaration in SFVosC.pex, all the
changes appear to have been in comments. But the files come with the usual
freeware warranty (i.e. "use at your own risk".)
Have fun with these!
Tom Wyant
(See attached file: SFvosC.pex)(See attached file: Vos.c)(See attached
file: Vos.h)(See attached file: Voscli.c)(See attached file: VosObj.cex)I would try going to the "lowest common denominator" between WindowsNT and
Windows95 - DOS. Both windowing OS's sort of have their roots in DOS, or at
least both are capable of opening a DOS session.
Therefore, from a DOS prompt type "set" to view the environment variables for
both OS types. Look for a common variable between the two that stores the
userID. If you can find one of these your application will be that much more
portable between these two Windows mutations.
I used "set" on my NT and found my userID assigned to a few variables. I haven't
done this on a Windows95 machine in quite some time, but if the machine is on
the network it should have at least one environment variable with the userID.
I'm just guessing that DOS has a variable to store the userID that will be
common to both machines.
Good luck....
Kelsey PetrychynSaskTel Technical Analyst
ITM - Technology Solutions - Distributed Computing
Tel (306) 777 - 4906, Fax (306) 359 - 0857
Internet:kelsey.petrychynSasktel.sk.ca
Quality is not job 1. It is the only job!
"Olivier Andrieux" <oandrieuxaxialog.fr> on 07/19/2000 09:12:41 AM
To: forte-userslists.xpedior.com
cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
Subject: (forte-users) user name
Hi
I use this command to catch the username:
task.part.operatingsystem.getenv('username')
with NT, there is no problem
but with windows95 or 98 the command doesn't find the username.
Thanks in advance.
Olivier Andrieux
Axialog
Lille
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 -
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.comAt 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 -
RE: (forte-users) FW: (forte-users)
Hi there
Thanks very much for the solution - just wanted to let you know . We
implemented the design that technote 11378 suggested .
It worked .
Thanks very much
Cheers
Jen
-----Original Message-----
From: Adamek, Zenon [mailto:ZAdamekpurolator.com]
Sent: Tuesday, 20 March, 2001 9:21 PM
To: 'forte-userslists.xpedior.com'
Subject: (forte-users) FW: (forte-users)
Hi David,
The problem is that the SO uses an attribute of its class ACBAccount as
the ObjectReference pointer. SO is not a stateless object. The possible
scenario before crash can be that client A and B calls SO at the same
time. A's thread creates ACBAccount gets the ObjectReference. At this
point B's thread is activated, does the same as A creates new
ObjectReference. Probably the next switch between A and B will be in the
Connect() (B should wait for OLE server). If A is reactivated it doesn't
get the original own reference but the B's reference. It can cause the
crash and means that a thread can use reference created in some other
thread.
Regards,
Zenon
-----Original Message-----
From: David McPaul [SMTP:dmcpaullumley.com.au]
Sent: Monday, March 19, 2001 11:52 PM
To: 'forte-userslists.xpedior.com'
Subject: RE: (forte-users)
Jenni,
As Zenon has pointed out, technote 11378 talks about problems that
can occur if the calls made to an OLE object are not from within the same
thread the OLE object was created in. It goes on to show a design to
avoid
this.
However, the code you have given DOES communicate to the OLE object
in the same thread as it was created. So the problem as I see it is more
likely to be that the OLE object is not being garbage collected. Although
you do explicitly NIL out the ACBAccount object there is a technote 12453
that deals with the need to set the ObjectReference of CDispatch objects
to
NIL to allow the OLE object to be completely reclaimed by the garbage
collector. Failure to do so when using code that creates a new OLE object
every time you ask for an account validation will eventually run the
partition out of memory.
As pointed out in a previous post you can also increase
FORTE_STACK_SIZE but this will delay the problem not correct it.
Rather than create the connection each time you may want to think
about redesigning the method as shown in tech note 11378.
Cheers
David
-----Original Message-----
From: Adamek, Zenon [mailto:ZAdamekpurolator.com]
Sent: Tuesday, March 20, 2001 5:05 AM
To: 'Els, Jenni'
Cc: 'forte-userslists.xpedior.com'
Subject: RE: (forte-users)
Hi Jenni,
The most important issue by designing an OLE connection between a Forte
server partition and an OLE component is taking into account that an OLE
object can be referenced from the NT thread in Forte partition that it was
created in. It is the reason that you have no problems with your mini-app
in
single-threaded version.
This problem is discussed in the Technote 11378. You can find a workaround
for your problem there, too.
Regards,
Zenon
-----Original Message-----
From: Els, Jenni [SMTP:JElsnbs.co.za]
Sent: Monday, March 19, 2001 2:28 AM
To: 'forte-userslists.xpedior.com'
Subject: (forte-users)
Hi there
We have this situation
We are calling a Service Object (in the server partition) from ourclient
partition.This service object calls a method which calls a DLLregistered
on our server (VB code) . This VB code access a database on anotherserver
.(DSN set up on our server ).The database is sql server .
We are having the problem where for about 3 hours in the morning , the
system works perfectly. We then get a segmentation violation on this
partition . When we run interpreted we can see that this is an OLEinvoked
exception. The partition does not always show as offline in econsole
and
because it does not , we cannot 'online' another . We cannot take the
entire app down as everything hangs . Eventually our technical depthas
to
down the server
We set up a mini-app looping through and calling the DLL to simulate
the
problem . It worked fine. When we put another asynchronous task in the
method to call the service object , it erred quite soon. We thencreate
an
attribute of type mutex and locked using that. The mini-app worked.
However our app in development eventually hanged (without the
partition
coming though) .
The service Object is an environment visible service object in asingle
(non-replicated partition) . It has a dialog duration = session .
In the project is
ACB : ACBObject
ACBObject : CDispatch (shared = disallowed , distributed =
disallowed, transactional = disallowed, monitored = allowed)
ACBValidator : Object (shared = allowed , distributed =allowed,
transactional = disallowed, monitored = disallowed)
ACBVaidatorSO : ACBValidator
In this method we have this code to call the DLL
self.ACBAccount = new;
self.ACBAccount.CreateUsingCLSID(classID='{2EFD3084-7B05-11D3-857F-00105A4
8CEA0}');
pErrorMessage = new;
acbaccount.BankCode = pBankCode.value;
acbaccount.BranchCode = pBranchCode.value;
at : VariantI2 = new;
at.Value = pAccountType.Value;
acbaccount.AccountType = at.Value;
acbaccount.AccountNo = pAccountNo.value;
begin
acbaccount.Connect();
exception
when e : GenericException do
ex : GenericException = new;
ex.SetWithParams(severity = SP_ER_ERROR,
message = 'There was an error connecting to the database');
raise ex;
end;
begin
err : i2 = acbaccount.ValidateAccount();
if err != 0 then
pErrorMessage.SetValue(acbaccount.ErrDescriptionStr(iErrorCode= err));
acbaccount.Disconnect();
return false;
else
pErrorMessage.SetValue('The account is
valid!!');
acbaccount.Disconnect();
self.ACBAccount = NIL ;
return true;
end if;
exception
when e : GenericException do
acbaccount.Disconnect();
ex : GenericException = new;
ex.SetWithParams(severity = SP_ER_ERROR,
message = 'There was an error Validating the account');
Task.ErrorMgr.AddError(ex);
task.errormgr.ShowErrors();
raise e;
end;
exception
when e : GenericException do
acbaccount.Disconnect();
Task.ErrorMgr.ShowErrors();
raise e;
If anybody has any suggestions , they would be most welcome
Thanks very much
Cheers
Jenni Els************************************************************************Th
is e-mail is intended for the use of the individual or entity named above
and may contain information that is confidential and privileged. If you
are not the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this e-mail is strictly
prohibited. If you have received this e-mail in error, please notify us
immediately at helpdesklumley.com.au and destroy the original message.
While this mail and any attachments have been scanned for common computer
viruses and found to be virus free, we recommend you also perform your own
virus checking processes before opening any attachments.
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
WARNING:
Any unauthorised use or interception of this email is illegal. If this email
is not intended for you, you may not copy, distribute nor disclose the
contents to anyone. Save for bona fide company matters, the BoE Group does
not accept any responsibility for the opinions expressed in this email.
For further details please see: http://www.nbs.co.za/emaildisclaim.htmHi there
Thanks very much for the solution - just wanted to let you know . We
implemented the design that technote 11378 suggested .
It worked .
Thanks very much
Cheers
Jen
-----Original Message-----
From: Adamek, Zenon [mailto:ZAdamekpurolator.com]
Sent: Tuesday, 20 March, 2001 9:21 PM
To: 'forte-userslists.xpedior.com'
Subject: (forte-users) FW: (forte-users)
Hi David,
The problem is that the SO uses an attribute of its class ACBAccount as
the ObjectReference pointer. SO is not a stateless object. The possible
scenario before crash can be that client A and B calls SO at the same
time. A's thread creates ACBAccount gets the ObjectReference. At this
point B's thread is activated, does the same as A creates new
ObjectReference. Probably the next switch between A and B will be in the
Connect() (B should wait for OLE server). If A is reactivated it doesn't
get the original own reference but the B's reference. It can cause the
crash and means that a thread can use reference created in some other
thread.
Regards,
Zenon
-----Original Message-----
From: David McPaul [SMTP:dmcpaullumley.com.au]
Sent: Monday, March 19, 2001 11:52 PM
To: 'forte-userslists.xpedior.com'
Subject: RE: (forte-users)
Jenni,
As Zenon has pointed out, technote 11378 talks about problems that
can occur if the calls made to an OLE object are not from within the same
thread the OLE object was created in. It goes on to show a design to
avoid
this.
However, the code you have given DOES communicate to the OLE object
in the same thread as it was created. So the problem as I see it is more
likely to be that the OLE object is not being garbage collected. Although
you do explicitly NIL out the ACBAccount object there is a technote 12453
that deals with the need to set the ObjectReference of CDispatch objects
to
NIL to allow the OLE object to be completely reclaimed by the garbage
collector. Failure to do so when using code that creates a new OLE object
every time you ask for an account validation will eventually run the
partition out of memory.
As pointed out in a previous post you can also increase
FORTE_STACK_SIZE but this will delay the problem not correct it.
Rather than create the connection each time you may want to think
about redesigning the method as shown in tech note 11378.
Cheers
David
-----Original Message-----
From: Adamek, Zenon [mailto:ZAdamekpurolator.com]
Sent: Tuesday, March 20, 2001 5:05 AM
To: 'Els, Jenni'
Cc: 'forte-userslists.xpedior.com'
Subject: RE: (forte-users)
Hi Jenni,
The most important issue by designing an OLE connection between a Forte
server partition and an OLE component is taking into account that an OLE
object can be referenced from the NT thread in Forte partition that it was
created in. It is the reason that you have no problems with your mini-app
in
single-threaded version.
This problem is discussed in the Technote 11378. You can find a workaround
for your problem there, too.
Regards,
Zenon
-----Original Message-----
From: Els, Jenni [SMTP:JElsnbs.co.za]
Sent: Monday, March 19, 2001 2:28 AM
To: 'forte-userslists.xpedior.com'
Subject: (forte-users)
Hi there
We have this situation
We are calling a Service Object (in the server partition) from ourclient
partition.This service object calls a method which calls a DLLregistered
on our server (VB code) . This VB code access a database on anotherserver
.(DSN set up on our server ).The database is sql server .
We are having the problem where for about 3 hours in the morning , the
system works perfectly. We then get a segmentation violation on this
partition . When we run interpreted we can see that this is an OLEinvoked
exception. The partition does not always show as offline in econsole
and
because it does not , we cannot 'online' another . We cannot take the
entire app down as everything hangs . Eventually our technical depthas
to
down the server
We set up a mini-app looping through and calling the DLL to simulate
the
problem . It worked fine. When we put another asynchronous task in the
method to call the service object , it erred quite soon. We thencreate
an
attribute of type mutex and locked using that. The mini-app worked.
However our app in development eventually hanged (without the
partition
coming though) .
The service Object is an environment visible service object in asingle
(non-replicated partition) . It has a dialog duration = session .
In the project is
ACB : ACBObject
ACBObject : CDispatch (shared = disallowed , distributed =
disallowed, transactional = disallowed, monitored = allowed)
ACBValidator : Object (shared = allowed , distributed =allowed,
transactional = disallowed, monitored = disallowed)
ACBVaidatorSO : ACBValidator
In this method we have this code to call the DLL
self.ACBAccount = new;
self.ACBAccount.CreateUsingCLSID(classID='{2EFD3084-7B05-11D3-857F-00105A4
8CEA0}');
pErrorMessage = new;
acbaccount.BankCode = pBankCode.value;
acbaccount.BranchCode = pBranchCode.value;
at : VariantI2 = new;
at.Value = pAccountType.Value;
acbaccount.AccountType = at.Value;
acbaccount.AccountNo = pAccountNo.value;
begin
acbaccount.Connect();
exception
when e : GenericException do
ex : GenericException = new;
ex.SetWithParams(severity = SP_ER_ERROR,
message = 'There was an error connecting to the database');
raise ex;
end;
begin
err : i2 = acbaccount.ValidateAccount();
if err != 0 then
pErrorMessage.SetValue(acbaccount.ErrDescriptionStr(iErrorCode= err));
acbaccount.Disconnect();
return false;
else
pErrorMessage.SetValue('The account is
valid!!');
acbaccount.Disconnect();
self.ACBAccount = NIL ;
return true;
end if;
exception
when e : GenericException do
acbaccount.Disconnect();
ex : GenericException = new;
ex.SetWithParams(severity = SP_ER_ERROR,
message = 'There was an error Validating the account');
Task.ErrorMgr.AddError(ex);
task.errormgr.ShowErrors();
raise e;
end;
exception
when e : GenericException do
acbaccount.Disconnect();
Task.ErrorMgr.ShowErrors();
raise e;
If anybody has any suggestions , they would be most welcome
Thanks very much
Cheers
Jenni Els************************************************************************Th
is e-mail is intended for the use of the individual or entity named above
and may contain information that is confidential and privileged. If you
are not the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this e-mail is strictly
prohibited. If you have received this e-mail in error, please notify us
immediately at helpdesklumley.com.au and destroy the original message.
While this mail and any attachments have been scanned for common computer
viruses and found to be virus free, we recommend you also perform your own
virus checking processes before opening any attachments.
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
WARNING:
Any unauthorised use or interception of this email is illegal. If this email
is not intended for you, you may not copy, distribute nor disclose the
contents to anyone. Save for bona fide company matters, the BoE Group does
not accept any responsibility for the opinions expressed in this email.
For further details please see: http://www.nbs.co.za/emaildisclaim.htm -
RE: (forte-users) RE: Forte 3 vs Java --Productivity
I think you should compare language to language, product to product
and standard to standard. J2EE is a standard, like CORBA. It's not
a product and it's not a language. J2EE is a standard, based on the
language Java, but the same standard can be used in the context
of Smalltalk, Cobol, Basic or TOOL as well. We have yet to see any
development tool that actually supports full J2EE. And how many
ORB's out there are really 100% CORBA 2.0 complient and offer
full interoperability through IIOP with other CORBA 2.0 complient
products?
The title of this entire thread is wrong. It's not Forte vs. Java, but
TOOL vs. Java or Forte vs. any Java-based ADE.
EJB, J2EE and CORBA are open standards, intended to facilitate
building large, component based applications. But they're only
standards, they're not usable products. Forte is a usable product.
It is a (propriaty) ORB, if offers lots of advanced component based
features and it uses a propriaty OO language called TOOL. Forte
was doing all this way before the world was debating CORBA, then
Java, then EJB and now J2EE.
Sure, when you really look at it, these standards are more complete
and include more design patterns than the way Forte solved the
problem, but the situation is still that, despite all those wonderfull
standards, Forte is still the product with the most advanced capa-
bilities that actually delivers.
The challenge to Forte is to incorporate those standards within their
own product. Are they going to build 2 products, one TOOL-based
and one Java-based, or are they going to integrate TOOL and Java,
or are they going to drop TOOL? Are they going to support J2EE
and will they keep offering those wonderfull distributed features that
are currently in Forte and are not part of J2EE? Will they switch
completely to JDBC or will they integrate DBSessions with JDBC?
Will their ORB functionality remain closed or will the Forte environ-
ment become a full CORBA 2.0 complient environment? Will they
keep supporting DCOM? Will they allow JavaBeans, EJB, Forte
service objects, OLE-objects, Servlets and Active-X components
to co-exist or will that remain SF? Are they going to support Swing?
Are they going to include an HTML-Browser widget? Are they going
to, natively, support JavaScript? What about VB-script? What
about Perl-script? What about TOOL-script??? Will they include
an object-based reporting tool, so you don't have to circumvent
the application and report against the relational database? Will
this reporting tool be Java-based, TOOL-based, both, EJB-based,
CORBA-based or whatever? Will they support JPEG and PNG as
well as BMP and GIF? Will they allow you to store these images in
the repository? Will they include a full-featured web-publisher that
supports HTML and XML as well as seemlessly integrate with Forte
applications? Will they allow you to deploy your (static) web-pages
on a web-server using E-console?
-----Original Message-----
From: Thomas Mercer-Hursh, Ph.D. [SMTP:thomascintegrity.com]
Sent: Monday, February 14, 2000 6:10 PM
To: 'kamranaminyahoo.com'
Subject: (forte-users) RE: Forte 3 vs Java -- Productivity
At 09:04 AM 2/14/2000 , Genesio, Fabrizio wrote:
Our users/customers are waiting for application right now, and
today with Java you may do it, but how expensive and reliable are all
the "+" signs of your equation? I am sure, in the moment somebody (Forté
For Java?) will propose an integrated Java environment capable to
seriously support development/assembly/deployment/maintenance, everybody
will immediately consider it as an alternative to Forté.Not an alternative ... check out FJEE, formerly known as SynerJ. They did
it right with TOOL, now they have done it right with Java. I still prefer
TOOL as the more productive, more elegant language, but if you have to use
Java, Forte has given you the way to do it right.
=========================================================================
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.comI think you should compare language to language, product to product
and standard to standard. J2EE is a standard, like CORBA. It's not
a product and it's not a language. J2EE is a standard, based on the
language Java, but the same standard can be used in the context
of Smalltalk, Cobol, Basic or TOOL as well. We have yet to see any
development tool that actually supports full J2EE. And how many
ORB's out there are really 100% CORBA 2.0 complient and offer
full interoperability through IIOP with other CORBA 2.0 complient
products?
The title of this entire thread is wrong. It's not Forte vs. Java, but
TOOL vs. Java or Forte vs. any Java-based ADE.
EJB, J2EE and CORBA are open standards, intended to facilitate
building large, component based applications. But they're only
standards, they're not usable products. Forte is a usable product.
It is a (propriaty) ORB, if offers lots of advanced component based
features and it uses a propriaty OO language called TOOL. Forte
was doing all this way before the world was debating CORBA, then
Java, then EJB and now J2EE.
Sure, when you really look at it, these standards are more complete
and include more design patterns than the way Forte solved the
problem, but the situation is still that, despite all those wonderfull
standards, Forte is still the product with the most advanced capa-
bilities that actually delivers.
The challenge to Forte is to incorporate those standards within their
own product. Are they going to build 2 products, one TOOL-based
and one Java-based, or are they going to integrate TOOL and Java,
or are they going to drop TOOL? Are they going to support J2EE
and will they keep offering those wonderfull distributed features that
are currently in Forte and are not part of J2EE? Will they switch
completely to JDBC or will they integrate DBSessions with JDBC?
Will their ORB functionality remain closed or will the Forte environ-
ment become a full CORBA 2.0 complient environment? Will they
keep supporting DCOM? Will they allow JavaBeans, EJB, Forte
service objects, OLE-objects, Servlets and Active-X components
to co-exist or will that remain SF? Are they going to support Swing?
Are they going to include an HTML-Browser widget? Are they going
to, natively, support JavaScript? What about VB-script? What
about Perl-script? What about TOOL-script??? Will they include
an object-based reporting tool, so you don't have to circumvent
the application and report against the relational database? Will
this reporting tool be Java-based, TOOL-based, both, EJB-based,
CORBA-based or whatever? Will they support JPEG and PNG as
well as BMP and GIF? Will they allow you to store these images in
the repository? Will they include a full-featured web-publisher that
supports HTML and XML as well as seemlessly integrate with Forte
applications? Will they allow you to deploy your (static) web-pages
on a web-server using E-console?
-----Original Message-----
From: Thomas Mercer-Hursh, Ph.D. [SMTP:thomascintegrity.com]
Sent: Monday, February 14, 2000 6:10 PM
To: 'kamranaminyahoo.com'
Subject: (forte-users) RE: Forte 3 vs Java -- Productivity
At 09:04 AM 2/14/2000 , Genesio, Fabrizio wrote:
Our users/customers are waiting for application right now, and
today with Java you may do it, but how expensive and reliable are all
the "+" signs of your equation? I am sure, in the moment somebody (Forté
For Java?) will propose an integrated Java environment capable to
seriously support development/assembly/deployment/maintenance, everybody
will immediately consider it as an alternative to Forté.Not an alternative ... check out FJEE, formerly known as SynerJ. They did
it right with TOOL, now they have done it right with Java. I still prefer
TOOL as the more productive, more elegant language, but if you have to use
Java, Forte has given you the way to do it right.
=========================================================================
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 -
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.comYou 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: (forte-users) access violation caught in debugmode
Eric,
There has been a problem with Forte debug mode for sometime now when the app
is silent. If you attempt to inspect the variables when the app is in the
'silent' mode, i.e., waiting on an event loop for a user input or a system
event, then you get the "Access violation caught ..." exception message and
the workspace including the launch server crashes.
If you are getting this problem in the 'step-through' mode, you should look
at the lauch server immediately after you get the exception before
everything disappears. There could be a stack backtrace due to some illegal
reference. We have faced a similar situation before but the error appeared
both in the 'debug' and 'run' modes.
Hope this helps.
Braja K Chattaraj.
From: Eric Decossaux <[email protected]>
To: forte mailing <[email protected]>
Subject: (forte-users) access violation caught in debug mode
Date: Thu, 23 Sep 1999 17:31:39 +0200
Hello,
I have a problem using Forte in debug mode. If I run my program on my NT
machine from the partition workshop (distributed run), the program works
fine except that some object does not display what I'm expecting. So I
want to use the debug mode to inspect the objets of this window. When I
choose the "local variables" option to see the content of my window, I
have a "access violation caught" and forte disappears. If I just let my
program run without choosing this option, everything is the same than
with the distributed run.
Does somebody have an idea what to look for ? I really want to look the
inside the attributes of this window.
We recently upgraded from release 30G2 to release 30L2. Could it be the
problem ?
Eric Decossaux
Cliniques Universitaires St Luc
Informatique des Laboratoires
av Hippocrate 10 / 1730
1200 Bruxelles
+32+2+764 17 53
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]Eric,
Another possibility has to do with the repository. You said you recently
migrated 30G2 to release 30L2.
Many strange problems have been traced to release migrations with old
repositories. If the repository was properly migrated another thing you can try
is to export the project(s) to PEX files, delete them from the repository, and
then re-import. I know this can be time consuming but I have solved more than
one unexplained problem in the IDE by doing it.
---------------------- Forwarded by Charlie Shell/Bsg/MetLife/US on 09/23/99
01:19 PM ---------------------------
"Ajith Kallambella" <[email protected]> on 09/23/99 12:08:54 PM
To: [email protected], [email protected]
cc: (bcc: Charlie Shell/Bsg/MetLife/US)
Subject: Re: (forte-users) access violation caught in debug mode
Eric,
Sometimes( 90% ) you can solve this problem by
checking out the class that is causing the crash
and force-compiling it.
If it doesn't help, run through this checklist.
1. Do you have enough memory resources.?
2. Is the object you are inspecting held in a lock ?
( mutex, transaction lock etc )
3. Does it work when you wait for sometime at the
breakpoint before inspecting the values? I mean
are you interrupting some process thread?
4. Does it work if you log the attributes using logmgr?
5. Are you using any call-outs/call-ins? Any external
systems integration? Sometimes( for reasons beyond
my comprehension ) the objects allocated outside
Forte gets corrupted when its passed back and forth.
6. ...finally...Santa Clause, help me!
Ajith Kallambella M.
Forte Systems Consultant.
From: Eric Decossaux <[email protected]>
To: forte mailing <[email protected]>
Subject: (forte-users) access violation caught in debug mode
Date: Thu, 23 Sep 1999 17:31:39 +0200
Hello,
I have a problem using Forte in debug mode. If I run my program on my NT
machine from the partition workshop (distributed run), the program works
fine except that some object does not display what I'm expecting. So I
want to use the debug mode to inspect the objets of this window. When I
choose the "local variables" option to see the content of my window, I
have a "access violation caught" and forte disappears. If I just let my
program run without choosing this option, everything is the same than
with the distributed run.
Does somebody have an idea what to look for ? I really want to look the
inside the attributes of this window.
We recently upgraded from release 30G2 to release 30L2. Could it be the
problem ?
Eric Decossaux
Cliniques Universitaires St Luc
Informatique des Laboratoires
av Hippocrate 10 / 1730
1200 Bruxelles
+32+2+764 17 53
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]
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] -
RE: (forte-users) (Fwd) ODBC & Dynamically Choosing aDatabase Ve ndor
The error you are getting is saying that the data source is not correctly
specified. Make sure the data source(or the name of the ODBC driver you
created) is correctly specified in your code.
ka
-----Original Message-----
From: Duncan Kinnear [mailto:[email protected]]
Sent: Sunday, December 19, 1999 6:26 PM
To: [email protected]
Subject: (forte-users) (Fwd) ODBC & Dynamically Choosing a Database
Vendor
I am trying to dynamically create a DBSession to connect to the
Microsft SQL Server ODBC Driver on a Forte Server Node.
I have tested the ODBC connection on the Local Machine and it works fine.
I have connected to the SQL Server on that machine with a Static
DBSession Object and that works fine.
I have used the same code to create a DBSession to Informix on Unix
and that worked fine.
The error I get is a converted ODBC one:
SYSTEM ERROR: Attempt to load partition named TestWinProject_cl0_Part1
failed.
Class: qqsp_ResourceException
Error #: [1001, 4]
Detected at: qqrt_ForteExecAgent::LoadPartition at 2
Error Time: Mon Dec 20 12:05:37
Distributed method called: qqrt_ForteExecAgentProxy.LoadPartition!7
(object name Unnamed) from partition "Node Manager", (partitionId =
40114BC0-B0FC-11D3-B4D6-E87D6941AA77:0x11c, taskId =
[40114BC0-B0FC-11D3-B4D6-E87D6941AA77:0x11c.38]) in application
"System
Manager", pid 250 on node ALLY in environment testenv
Exception occurred (remotely) on partition "Forte_Executor",
(partitionId
= 40114BC0-B0FC-11D3-B4D6-E87D6941AA77:0x11e, taskId =
[40114BC0-B0FC-11D3-B4D6-E87D6941AA77:0x11e.22]) in application
"TestWinProject_cl0", pid 235 on node ALLY in environment TestEnv.
SYSTEM ERROR: Failed to create service object TestDataProject.TestService.
Class: qqsp_ResourceException
Last TOOL statement: method TestServiceMgr.
Error Time: Mon Dec 20 12:05:37
Exception occurred (remotely) on partition "Forte_Executor",
(partitionId
= 40114BC0-B0FC-11D3-B4D6-E87D6941AA77:0x11e, taskId =
[40114BC0-B0FC-11D3-B4D6-E87D6941AA77:0x11e.22]) in application
"TestWinProject_cl0", pid 235 on node ALLY in environment TestEnv.
USER ERROR: (This error was converted)
Failed to connect to database: ForteSQLServer , username: justin .
[Microsoft][ODBC Driver Manager] Data source name not found and no
default
driver specified
Class: qqdb_RemoteAccessException with ReasonCode:
DB_ER_DBMSCONNECTION
DBMS SQLSTATE: IM002
Class: qqsp_ErrorDescriptor
Detected at: qqdb_OdbcVendorInfo::DoSQLConnect at 10
Last TOOL statement: method ServiceMgr.SetDBSession
Error Time: Mon Dec 20 12:05:37
Exception occurred (remotely) on partition "Forte_Executor",
(partitionId
= 40114BC0-B0FC-11D3-B4D6-E87D6941AA77:0x11e, taskId =
[40114BC0-B0FC-11D3-B4D6-E87D6941AA77:0x11e.22]) in application
"TestWinProject_cl0", pid 235 on node ALLY in environment TestEnv.
Versions:
SQL SERVER 6.5
ODBC Driver SQL Server 2.65.0240
ODBC Manager 3.0.28.22
NT 4 sp4
Forte 3.0.J.1
The code I'm using is almost identical to that given in the "Dynamically
Choosing a Database Vendor" section of the "Making a Database
Connection" chapter of the "Accessing Databases" manual.
Any suggestions would be greatly appreciated
Thanks in advance.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email:
[email protected]
PO Box 764, McLean Towers, Phone: +64 6 834 3360
Shakespeare Road, Napier, New Zealand. Fax: +64 6 834 3369
Providing Integrated Software to the Meat Processing Industry for over 10
years
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]
Maybe you are looking for
-
Why doesn't animated GIF play?
I have made 2 animated Gifs one plays fine the other doesn't. When I preview in Safari all that shows is the full image and nothing happens. It runs fine in the timeline but in save-for-web the play buttons are greyed out and all I see is the full co
-
Browser can't find a text file opened via the save as dialogue box
Hi there, I have a servlet which outputs a file using the servlet output stream, with the following lines set: response.setContentType("application/msword"); response.setHeader("Content-Disposition", "attachement; filename="+ fileName); servletOutStr
-
How to avoid cancellation of invoice for payment recevied
Short Description: Cancellation of Invoice raised on customer after receipt of Payment from him Description: There is an Invoice dated 22.10.2008. We have received the payment for this Invoice vide document number posting date 06.12.2008. So the Invo
-
X2100 M2 hard drives missing power adapter part?
We just ordered a X2100 M2 with 2 250GB SATA hard drives. The system and hard drives came from two different vendors because of our procurement system. The hard drives are Sun branded, and they have the neat little pull lever on the front. They slide
-
how do I delete.. when logging into my email.. it populates my entire email address.. how do I stop this ?????