Non-Delivery of:forte-users-digest V1 #1073
forte-users-digest Sunday, 20 September 1998 Volume 01 : Number 1073
In this issue:
RE: PrintDocument
From: Joseph Mirwald <[email protected]>
Date: Sun, 20 Sep 1998 18:41:13 +0200
Subject: RE: PrintDocument
Hi Peter,
the workaround we get from support is to use a shareware tool named
FinePrint www.singletrack.com.
This tool works with prinitng more than one side through all printers
because it's a printer driver itself. This solution is only a temporary
solution for us. Some printers may work if their driver is updated to the
newest available on the internet.
The problem occurs only on Win95 with local printer! If the printer is
on a NT-Server, the problem does not occur during print from 95.
The problem is in a bug queue at forte with the state "waits on fix".
Sorry for this bad message
Joseph Mirwald
At 18:38 18.09.98 +0800, you wrote:
Hi,
I work with Agnes.
Yes. We run the program under Window 95 with a local printer. Did you=come
up with any work-around?
Regards,
Peter Sham.
-----Original Message-----
From: Joseph Mirwald [SMTP:[email protected]]
Sent: Friday, September 18, 1998 6:26 PM
To: [email protected]
Subject: Re: PrintDocument
Hello Agnes,
does this occur under Windows 95 prints direct to Printer?
We have this problem under '95 with most of printers we use.
Joseph Mirwald
At 16:11 18.09.98 +0800, you wrote:
When I tried to use the PrintDocument to print a document with 2pages
(cloned userwindows),
Forte always print an empty page 2 for me.
I've used something like this
..... =09
//Open Doc
=09
doc.SetWorkingPage(page =3D clonedWindow1);
=20
doc.PrintWorkingPage();
=09
doc.SetWorkingPage(page =3D clonedWindow2);
doc.PrintWorkingPage();
=09
//Close Doc
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive<URL:http://pinehurst.sageit.com/listarchive/>
forte-users-digest Sunday, 20 September 1998 Volume 01 : Number 1073
In this issue:
RE: PrintDocument
From: Joseph Mirwald <[email protected]>
Date: Sun, 20 Sep 1998 18:41:13 +0200
Subject: RE: PrintDocument
Hi Peter,
the workaround we get from support is to use a shareware tool named
FinePrint www.singletrack.com.
This tool works with prinitng more than one side through all printers
because it's a printer driver itself. This solution is only a temporary
solution for us. Some printers may work if their driver is updated to the
newest available on the internet.
The problem occurs only on Win95 with local printer! If the printer is
on a NT-Server, the problem does not occur during print from 95.
The problem is in a bug queue at forte with the state "waits on fix".
Sorry for this bad message
Joseph Mirwald
At 18:38 18.09.98 +0800, you wrote:
Hi,
I work with Agnes.
Yes. We run the program under Window 95 with a local printer. Did you=come
up with any work-around?
Regards,
Peter Sham.
-----Original Message-----
From: Joseph Mirwald [SMTP:[email protected]]
Sent: Friday, September 18, 1998 6:26 PM
To: [email protected]
Subject: Re: PrintDocument
Hello Agnes,
does this occur under Windows 95 prints direct to Printer?
We have this problem under '95 with most of printers we use.
Joseph Mirwald
At 16:11 18.09.98 +0800, you wrote:
When I tried to use the PrintDocument to print a document with 2pages
(cloned userwindows),
Forte always print an empty page 2 for me.
I've used something like this
..... =09
//Open Doc
=09
doc.SetWorkingPage(page =3D clonedWindow1);
=20
doc.PrintWorkingPage();
=09
doc.SetWorkingPage(page =3D clonedWindow2);
doc.PrintWorkingPage();
=09
//Close Doc
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive<URL:http://pinehurst.sageit.com/listarchive/>
Similar Messages
-
Re: forte-users-digest V1 #89
forte-users-digest Tuesday, 8 October 1996 Volume 01 : Number 089
From: Alexander Ananiev <[email protected]>
Date: Tue, 08 Oct 1996 16:36:14 -0500
Subject: "Single DBSession" approach
The standard Forte approach for the database access assumes
that one DBSession handles requests from several users
(clients), so the database connection is not associated with
the particular user. This significantly impacts the
architecture of the Forte application. Some of the problems
caused by this approach are:
1) An application-level security system should be developed
instead of using the DBMS security system. Suffice it to say
that application-level security system cannot provide the
protection from back-door access to the database.
2) The application cannot utilize the DBMS locking mechanism
for the case when the record is retrieved to the client for
editing purposes ("long" transaction).
It means that SecurityManager and LockManager should be
developed to resolve these problems. This does not seem to be
very good solution because these objects are intended to repeat
the functionality of the DBMS. And these parts of the
application may become pretty complicated. For example, my
project's experience shows that the development of the lock
manager is not a trivial task and most likely this lock manager
will be worse than the DBMS locking mechanism in terms of
reliability and performance just because it acts as an outside
program to the database. Besides, this approach could cause
serious problems if the database can be updated by non-Forte
applications (e.g., by some legacy system or batch process).
"One DBSession per several users" approach makes sense if each
user connection to the database is implemented as one
server process.(Another good argument in favor of single
DBsession is a heterogeneous environment where there is no
stable connection to one database, but here I'm talking about a
"regular" application that uses only one DBMS.) Since most of
the time this process is idle, then, of course, decreasing the
number of processes leads to better server utilization and
performance. But by its sense, database connection is just the
current transaction ID (with the user id, of course). So the
connection could be just a number that should be passed to the
DBMS along with each request and then DBMS can create a thread
to handle the request or forward it to the next available
process if it does not support multithreading.
DBMS vendors realize this and some of them already implemented
this approach (I know that Oracle and Informix did that and
Sybase was mentioned in the recent "one-threaded DBSession"
discussion). And one-threaded DBSession that lives on the
server doesn't fit well to that. The better approach would be
to make DBSession the attribute of the TransactionHandle
object, so the current connection will always be passed from
the client to the service and this service can work through
this connection.
So, my point is that the application should let DBMS do its
work and use as much of the functionality of the DBMS as
possible and the "single DBsession" approach doesn't help it to
do that.
I would be glad to hear any other opinion on this topic. I
think that the "DBsession" problem is extremely important for
any multi-tier application (for example, all Web applications
are facing this problem). I'm also interested in how people
are dealing with this problem on other projects, for example if
there are some projects where the alternative approach (one
DBSession per each user) was implemented and what problems were
encountered during that.
Alexander Ananyev
Price Waterhouse
End of forte-users-digest V1 #89
One of the first issues that needs to be addressed is that passing
DBSessions from partition to partition is a huge performance hit. When
Forte executes a SQL SELECT or FETCH statement on a DBSession that exists
outside the current partition (DBSessions are "anchored" objects that are
accessed via proxies.) Forte fetches the result set into the partition
containing the DBSession and then passes proxies or creates copies into
the partition where the SQL code is located. These are some of the
largest performance hits you can take in Forte.forte-users-digest Tuesday, 8 October 1996 Volume 01 : Number 089
From: Alexander Ananiev <[email protected]>
Date: Tue, 08 Oct 1996 16:36:14 -0500
Subject: "Single DBSession" approach
The standard Forte approach for the database access assumes
that one DBSession handles requests from several users
(clients), so the database connection is not associated with
the particular user. This significantly impacts the
architecture of the Forte application. Some of the problems
caused by this approach are:
1) An application-level security system should be developed
instead of using the DBMS security system. Suffice it to say
that application-level security system cannot provide the
protection from back-door access to the database.
2) The application cannot utilize the DBMS locking mechanism
for the case when the record is retrieved to the client for
editing purposes ("long" transaction).
It means that SecurityManager and LockManager should be
developed to resolve these problems. This does not seem to be
very good solution because these objects are intended to repeat
the functionality of the DBMS. And these parts of the
application may become pretty complicated. For example, my
project's experience shows that the development of the lock
manager is not a trivial task and most likely this lock manager
will be worse than the DBMS locking mechanism in terms of
reliability and performance just because it acts as an outside
program to the database. Besides, this approach could cause
serious problems if the database can be updated by non-Forte
applications (e.g., by some legacy system or batch process).
"One DBSession per several users" approach makes sense if each
user connection to the database is implemented as one
server process.(Another good argument in favor of single
DBsession is a heterogeneous environment where there is no
stable connection to one database, but here I'm talking about a
"regular" application that uses only one DBMS.) Since most of
the time this process is idle, then, of course, decreasing the
number of processes leads to better server utilization and
performance. But by its sense, database connection is just the
current transaction ID (with the user id, of course). So the
connection could be just a number that should be passed to the
DBMS along with each request and then DBMS can create a thread
to handle the request or forward it to the next available
process if it does not support multithreading.
DBMS vendors realize this and some of them already implemented
this approach (I know that Oracle and Informix did that and
Sybase was mentioned in the recent "one-threaded DBSession"
discussion). And one-threaded DBSession that lives on the
server doesn't fit well to that. The better approach would be
to make DBSession the attribute of the TransactionHandle
object, so the current connection will always be passed from
the client to the service and this service can work through
this connection.
So, my point is that the application should let DBMS do its
work and use as much of the functionality of the DBMS as
possible and the "single DBsession" approach doesn't help it to
do that.
I would be glad to hear any other opinion on this topic. I
think that the "DBsession" problem is extremely important for
any multi-tier application (for example, all Web applications
are facing this problem). I'm also interested in how people
are dealing with this problem on other projects, for example if
there are some projects where the alternative approach (one
DBSession per each user) was implemented and what problems were
encountered during that.
Alexander Ananyev
Price Waterhouse
End of forte-users-digest V1 #89
One of the first issues that needs to be addressed is that passing
DBSessions from partition to partition is a huge performance hit. When
Forte executes a SQL SELECT or FETCH statement on a DBSession that exists
outside the current partition (DBSessions are "anchored" objects that are
accessed via proxies.) Forte fetches the result set into the partition
containing the DBSession and then passes proxies or creates copies into
the partition where the SQL code is located. These are some of the
largest performance hits you can take in Forte. -
RE: forte-users-digest V1 #1490
Jim -
We had the same issues when we were running multiple production
environments.
The best way to handle the logging of application exceptions from multiple
environments, is to use a database.
Plus the database allows for easier reporting.
Give us a call if you'd like to discuss.
Larry McCartney
[email protected]
(203)459-7959 - Trumbull
From:
[email protected][SMTP:[email protected]
om]
Sent: Monday, June 07, 1999 6:00 PM
To: [email protected]
Subject: forte-users-digest V1 #1490
forte-users-digest Monday, 7 June 1999 Volume 01 : Number
1490
In this issue:
Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
Off topic: Database Unique IDs
From: "Field, Jim" <[email protected]>
Date: Mon, 7 Jun 1999 09:49:07 -0700
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing environments installed
on
a Unix box and a development environment on a Windows NT box. For our
error
handling, we write messages to a custom log file. If an error occurs on a
service object, the error message is written to a copy of this log file on
the client as well as to a copy of the file on the server where the
service
object is running. Currently, the path to the file begins with the
FORTE_ROOT environment variable and then the specific path is concatenated
to the end of the path. However, when trying to write the log file to the
Unix box, the application seems to be getting confused between the paths
for
the different environments and hangs. Does anyone know of a good way to
manage paths for writing files to multiple server environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: "Lopez, Len CWT-MSP" <[email protected]>
Date: Mon, 7 Jun 1999 13:34:33 -0500
Subject: RE: Multiple Forte environments on one machine
The environment variable $FORTE_ROOT will be the value you exported =
when you
started the environment on the unix server. This is usually specified =
in
your fortedef.sh (csh). It will not get confused between environments =
since
your application is only deployed to one environment and that =
environment
has only one value for FORTE_ROOT. The problem you are more likely =
having
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are =
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Fort=E9 portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: Muthuramalingam Venkataraman <[email protected]>
Date: Mon, 07 Jun 1999 12:56:19 PDT
Subject: RE: Multiple Forte environments on one machine
An alternative solution could be, define different environment variables
in
the fortedef.sh shell script which will avoid confusion in refering to the
FORTE ROOT directories for the respective environments.
From: "Lopez, Len CWT-MSP" <[email protected]>
Reply-To: "Lopez, Len CWT-MSP" <[email protected]>
To: "'Field, Jim'" <[email protected]>, forte users group
<[email protected]>
Subject: RE: Multiple Forte environments on one machine
Date: Mon, 7 Jun 1999 13:34:33 -0500
The environment variable $FORTE_ROOT will be the value you exported when
you
started the environment on the unix server. This is usually specified in
your fortedef.sh (csh). It will not get confused between environments
since
your application is only deployed to one environment and that environment
has only one value for FORTE_ROOT. The problem you are more likelyhaving
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Forté portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: Muthuramalingam Venkataraman <[email protected]>
Date: Mon, 07 Jun 1999 13:02:28 PDT
Subject: RE: Multiple Forte environments on one machine
More over, my line of thinking is that once you are able to open the file
in
the appropriate mode, the problem could also attribute to disk space
availability, as you have mentioned that it hangs while writing to the
file!!
Quote :
However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs.Unquote.
Hope this helps.
From: "Lopez, Len CWT-MSP" <[email protected]>
Reply-To: "Lopez, Len CWT-MSP" <[email protected]>
To: "'Field, Jim'" <[email protected]>, forte users group
<[email protected]>
Subject: RE: Multiple Forte environments on one machine
Date: Mon, 7 Jun 1999 13:34:33 -0500
The environment variable $FORTE_ROOT will be the value you exported when
you
started the environment on the unix server. This is usually specified in
your fortedef.sh (csh). It will not get confused between environments
since
your application is only deployed to one environment and that environment
has only one value for FORTE_ROOT. The problem you are more likelyhaving
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Forté portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: "Duncan Kinnear" <[email protected]>
Date: Tue, 8 Jun 1999 09:26:56 +1200
Subject: Off topic: Database Unique IDs
Hi folks,
This is a little off-topic, but I figure that there may be other people
out
there whose Forte development would benefit from the discussion.
I am currently building a development framework for our new software
product. As part of that framework I'd like to include the facility for
generating unique, user-invisible, integer database IDs.
Now there is some doubt here that this is actually required and that the
primary key should be whatever the programmer wants it to be, including
multiple columns if necessary.
I was wondering if anyone can give us some rules-of-thumb regarding
the use of unique IDs as primary keys. Or if someone can point me to
some on-line resources (or even a good book) that can guide us in this
area.
The arguments I have given for using integer IDs are:
- - Single, integer columns should be faster
- - User invisible integer ID allows editing/duplicates of all
user-visible fields
- - Single, integer foreign keys would reduce storage requirements
- - Standardising on integer IDs would allow generic functionality built
into
framework
- - More object-oriented as objects have "built-in" unique identity
I would appreciate any comments people have. We can take this
discussion off-list if that is preferable.
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
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
End of forte-users-digest V1 #1490
To unsubscribe, email '[email protected]' with
'unsubscribe $LIST' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Jim -
We had the same issues when we were running multiple production
environments.
The best way to handle the logging of application exceptions from multiple
environments, is to use a database.
Plus the database allows for easier reporting.
Give us a call if you'd like to discuss.
Larry McCartney
[email protected]
(203)459-7959 - Trumbull
From:
[email protected][SMTP:[email protected]
om]
Sent: Monday, June 07, 1999 6:00 PM
To: [email protected]
Subject: forte-users-digest V1 #1490
forte-users-digest Monday, 7 June 1999 Volume 01 : Number
1490
In this issue:
Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
RE: Multiple Forte environments on one machine
Off topic: Database Unique IDs
From: "Field, Jim" <[email protected]>
Date: Mon, 7 Jun 1999 09:49:07 -0700
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing environments installed
on
a Unix box and a development environment on a Windows NT box. For our
error
handling, we write messages to a custom log file. If an error occurs on a
service object, the error message is written to a copy of this log file on
the client as well as to a copy of the file on the server where the
service
object is running. Currently, the path to the file begins with the
FORTE_ROOT environment variable and then the specific path is concatenated
to the end of the path. However, when trying to write the log file to the
Unix box, the application seems to be getting confused between the paths
for
the different environments and hangs. Does anyone know of a good way to
manage paths for writing files to multiple server environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: "Lopez, Len CWT-MSP" <[email protected]>
Date: Mon, 7 Jun 1999 13:34:33 -0500
Subject: RE: Multiple Forte environments on one machine
The environment variable $FORTE_ROOT will be the value you exported =
when you
started the environment on the unix server. This is usually specified =
in
your fortedef.sh (csh). It will not get confused between environments =
since
your application is only deployed to one environment and that =
environment
has only one value for FORTE_ROOT. The problem you are more likely =
having
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are =
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Fort=E9 portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: Muthuramalingam Venkataraman <[email protected]>
Date: Mon, 07 Jun 1999 12:56:19 PDT
Subject: RE: Multiple Forte environments on one machine
An alternative solution could be, define different environment variables
in
the fortedef.sh shell script which will avoid confusion in refering to the
FORTE ROOT directories for the respective environments.
From: "Lopez, Len CWT-MSP" <[email protected]>
Reply-To: "Lopez, Len CWT-MSP" <[email protected]>
To: "'Field, Jim'" <[email protected]>, forte users group
<[email protected]>
Subject: RE: Multiple Forte environments on one machine
Date: Mon, 7 Jun 1999 13:34:33 -0500
The environment variable $FORTE_ROOT will be the value you exported when
you
started the environment on the unix server. This is usually specified in
your fortedef.sh (csh). It will not get confused between environments
since
your application is only deployed to one environment and that environment
has only one value for FORTE_ROOT. The problem you are more likelyhaving
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Forté portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: Muthuramalingam Venkataraman <[email protected]>
Date: Mon, 07 Jun 1999 13:02:28 PDT
Subject: RE: Multiple Forte environments on one machine
More over, my line of thinking is that once you are able to open the file
in
the appropriate mode, the problem could also attribute to disk space
availability, as you have mentioned that it hangs while writing to the
file!!
Quote :
However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs.Unquote.
Hope this helps.
From: "Lopez, Len CWT-MSP" <[email protected]>
Reply-To: "Lopez, Len CWT-MSP" <[email protected]>
To: "'Field, Jim'" <[email protected]>, forte users group
<[email protected]>
Subject: RE: Multiple Forte environments on one machine
Date: Mon, 7 Jun 1999 13:34:33 -0500
The environment variable $FORTE_ROOT will be the value you exported when
you
started the environment on the unix server. This is usually specified in
your fortedef.sh (csh). It will not get confused between environments
since
your application is only deployed to one environment and that environment
has only one value for FORTE_ROOT. The problem you are more likelyhaving
is your so was developed and tested on an NT server and the path was
specified MS DOS style with back slashes not forward slashes ie.
$FORTE_ROOT/log/mylogfile.txt. Another probable cause is that you are
using
%FORTE_ROOT% rather than $FORTE_ROOT. A solution may be to specify
directories and path names in Forté portable form ie.
%{FORTE_ROOT}/log/myLog.txt. That should work whether your service is
executing on an NT box or Unix box.
Hope this helps.
Len Lopez
Carlson Wagonlit Travel
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, June 07, 1999 11:49 AM
To: forte users group
Subject: Multiple Forte environments on one machine
Hello all,
We have a situation where we have 3 Forte testing
environments installed on
a Unix box and a development environment on a Windows NT
box. For our error
handling, we write messages to a custom log file. If an
error occurs on a
service object, the error message is written to a copy of
this log file on
the client as well as to a copy of the file on the server
where the service
object is running. Currently, the path to the file begins
with the
FORTE_ROOT environment variable and then the specific path
is concatenated
to the end of the path. However, when trying to write the
log file to the
Unix box, the application seems to be getting confused
between the paths for
the different environments and hangs. Does anyone know of a
good way to
manage paths for writing files to multiple server
environments?
Jim Field
Systems Engineer
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
From: "Duncan Kinnear" <[email protected]>
Date: Tue, 8 Jun 1999 09:26:56 +1200
Subject: Off topic: Database Unique IDs
Hi folks,
This is a little off-topic, but I figure that there may be other people
out
there whose Forte development would benefit from the discussion.
I am currently building a development framework for our new software
product. As part of that framework I'd like to include the facility for
generating unique, user-invisible, integer database IDs.
Now there is some doubt here that this is actually required and that the
primary key should be whatever the programmer wants it to be, including
multiple columns if necessary.
I was wondering if anyone can give us some rules-of-thumb regarding
the use of unique IDs as primary keys. Or if someone can point me to
some on-line resources (or even a good book) that can guide us in this
area.
The arguments I have given for using integer IDs are:
- - Single, integer columns should be faster
- - User invisible integer ID allows editing/duplicates of all
user-visible fields
- - Single, integer foreign keys would reduce storage requirements
- - Standardising on integer IDs would allow generic functionality built
into
framework
- - More object-oriented as objects have "built-in" unique identity
I would appreciate any comments people have. We can take this
discussion off-list if that is preferable.
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
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
End of forte-users-digest V1 #1490
To unsubscribe, email '[email protected]' with
'unsubscribe $LIST' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
RE: forte-users-digest Digest V00 #186
Just a follow up to the TIFF Problem.
Try using the WANG Image edit control (supports 32-bit OLE) Copyright
Wang Laboratories, Inc. 1995-1996..
It should be available free on the net or if you have Microsoft Visual
Studio 6.0 it comes with it. make sure you make the control invisible so
that it does not show up.
- Ravi.
Intel Corporation.
-----Original Message-----
From: forte-users-digest-requestlists.xpedior.com
[SMTP:forte-users-digest-requestlists.xpedior.com]
Sent: Wednesday, May 17, 2000 8:05 AM
To: forte-users-digestlists.xpedior.com
Subject: forte-users-digest Digest V00 #186
forte-users-digest Digest Volume 00 : Issue
186
Today's Topics:
RE: forte-users-digest Digest V00 #185
Intermittent database problems
Administrivia:
* BEFORE YOU ASK - please search the archives at:
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-digest-requestlists.xpedior.com
Date: Tue, 16 May 2000 18:30:00 -0700
From: "Balakrishna, RavikumarX" <ravikumarx.balakrishnaintel.com>
To: forte-userslists.xpedior.com, forte-users-digestlists.xpedior.com
Subject: RE: forte-users-digest Digest V00 #185
Message-ID:
<0428AD6295E1D211AC4400A0C969E8A2045C29FAorsmsx43.jf.intel.com>
Content-Type: text/plain
Hi,
The only work around I can see to your problem is to convert the TIFF
to
any other format that forte supports. You could use Microsoft's Image
Composer to do this. As far as I can see your requirement is runtime. I
would suggest using Windows imaging ( an image edit control, that is an
active-x control ). Use this control to perform a SaveAs operation on the
TIFF file to save it as a GIF and then use the converted GIF to place it
in
your Forte Object. I know it works in C++ so it should surely work in
forte too. I don't have the documentation for the image edit control,
but
Iam sure there are lot of similar controls out there . And make sure
you
save the file in a format that supports mutiple page formats. ( i.e
prefer
GIF to BMP when you convert)
Hope this Helps,
- Ravi Balakrishna
Automation Software Engineer
Intel Corporation.
-----Original Message-----
From: forte-users-digest-requestlists.xpedior.com
[SMTP:forte-users-digest-requestlists.xpedior.com]
Sent: Tuesday, May 16, 2000 3:05 PM
To: forte-users-digestlists.xpedior.com
Subject: forte-users-digest Digest V00 #185
forte-users-digest Digest Volume 00 : Issue
185
Today's Topics:
Tiff images again.....
Administrivia:
* BEFORE YOU ASK - please search the archives at:
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-digest-requestlists.xpedior.com
Date: Tue, 16 May 2000 11:07:25 -0400
From: "Jones, Gail A" <gail.joneseds.com>
To: "'kamranaminyahoo.com'" <kamranaminyahoo.com>
Subject: Tiff images again.....
Message-ID: <F455E4114C4AD211BCDF00805F31BCF305C206DCUSSAM203>
Content-Type: text/plain;
charset="iso-8859-1"
I need to place TIFF images in a Forte Object to display on a client
window.
Does anyone have any tips or code that you would be willing to sharethat
can help me do that. I checked with Forte the other day and found theydo
not support the TIFF format.
Thanks much,
Gail Jones
EDS Medi-Cal
Sacramento, Ca.
End of forte-users-digest Digest V00 Issue #185
Date: Wed, 17 May 2000 08:34:01 -0600
From: joe.wolfesasktel.sk.ca
To: kamranaminyahoo.com
Subject: Intermittent database problems
Message-Id: <062568E2.00500AC5.00regn0683nt.sasktel.sk.ca>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
We have a Forte server running on HP_UX 10.2. It connects to an Oracle
database
on AIX. Over the past several months we have received intermittent
failures
that neither we nor our Oracle support team have been able to resolve
(example
below). Prior to the error occuring the partition can be operating
successfully for several days. When this error occurs the IsConnected
instrument on the DBSession is still shown as TRUE, and there are no error
counts on the instruments. After cycling the partition everything runs
fine for
between a day and a month. If anybody has a resolution, or even a good
hunch
I'd appreciate hearing it.
Attached to manager for node capri.
SYSTEM ERROR: OpenCursor failed for SQL statement in project CTISvcs,
class
LookUpInfoMgr, method LoadAgent, methodId 4, line 55, error from
database is:
ORA-02019: connection description for remote database not found
Class: qqdb_ResourceException
Detected at: qqdb_OracleVendorInfo::DoOexn
Error Time: Wed May 17 07:42:42
Oracle error: 2019, Server: DBP13, UserName: forte_c3
Database Statement: select a.cctr_agt_id CareCentreAgentID , a.emp_id
EmployeeID , a.eff_fr_dat EffectiveFromDate , a.eff_to_dat
EffectiveToDate
, a.cctr_agt_gr_id CareCentreGroupID , RTrim ( InitCap ( b.fst_nm )
EmployeeFirstName , RTrim ( InitCap ( b.srnm ) ) EmployeeLastName
from
t_cctr_agt a , t_emp b where a.emp_id = b.emp_id
Exception occurred (locally) on partition "TServRM1_cl0_Part2",
(partitionId = A5E41FA0-D91F-11D3-8F7D-FFCBBA23AA77:0x31d, taskId =
[A5E41FA0-D91F-11D3-8F7D-FFCBBA23AA77:0x320.777]) in application
"TServRM1_cl0", pid 24249 on node capri in environment prodenv.
TIA,
Joe Wolfe, External Programmer Analyst
SaskTel
email: joe.wolfesasktel.sk.ca
End of forte-users-digest Digest V00 Issue #186Just a follow up to the TIFF Problem.
Try using the WANG Image edit control (supports 32-bit OLE) Copyright
Wang Laboratories, Inc. 1995-1996..
It should be available free on the net or if you have Microsoft Visual
Studio 6.0 it comes with it. make sure you make the control invisible so
that it does not show up.
- Ravi.
Intel Corporation.
-----Original Message-----
From: forte-users-digest-requestlists.xpedior.com
[SMTP:forte-users-digest-requestlists.xpedior.com]
Sent: Wednesday, May 17, 2000 8:05 AM
To: forte-users-digestlists.xpedior.com
Subject: forte-users-digest Digest V00 #186
forte-users-digest Digest Volume 00 : Issue
186
Today's Topics:
RE: forte-users-digest Digest V00 #185
Intermittent database problems
Administrivia:
* BEFORE YOU ASK - please search the archives at:
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-digest-requestlists.xpedior.com
Date: Tue, 16 May 2000 18:30:00 -0700
From: "Balakrishna, RavikumarX" <ravikumarx.balakrishnaintel.com>
To: forte-userslists.xpedior.com, forte-users-digestlists.xpedior.com
Subject: RE: forte-users-digest Digest V00 #185
Message-ID:
<0428AD6295E1D211AC4400A0C969E8A2045C29FAorsmsx43.jf.intel.com>
Content-Type: text/plain
Hi,
The only work around I can see to your problem is to convert the TIFF
to
any other format that forte supports. You could use Microsoft's Image
Composer to do this. As far as I can see your requirement is runtime. I
would suggest using Windows imaging ( an image edit control, that is an
active-x control ). Use this control to perform a SaveAs operation on the
TIFF file to save it as a GIF and then use the converted GIF to place it
in
your Forte Object. I know it works in C++ so it should surely work in
forte too. I don't have the documentation for the image edit control,
but
Iam sure there are lot of similar controls out there . And make sure
you
save the file in a format that supports mutiple page formats. ( i.e
prefer
GIF to BMP when you convert)
Hope this Helps,
- Ravi Balakrishna
Automation Software Engineer
Intel Corporation.
-----Original Message-----
From: forte-users-digest-requestlists.xpedior.com
[SMTP:forte-users-digest-requestlists.xpedior.com]
Sent: Tuesday, May 16, 2000 3:05 PM
To: forte-users-digestlists.xpedior.com
Subject: forte-users-digest Digest V00 #185
forte-users-digest Digest Volume 00 : Issue
185
Today's Topics:
Tiff images again.....
Administrivia:
* BEFORE YOU ASK - please search the archives at:
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-digest-requestlists.xpedior.com
Date: Tue, 16 May 2000 11:07:25 -0400
From: "Jones, Gail A" <gail.joneseds.com>
To: "'kamranaminyahoo.com'" <kamranaminyahoo.com>
Subject: Tiff images again.....
Message-ID: <F455E4114C4AD211BCDF00805F31BCF305C206DCUSSAM203>
Content-Type: text/plain;
charset="iso-8859-1"
I need to place TIFF images in a Forte Object to display on a client
window.
Does anyone have any tips or code that you would be willing to sharethat
can help me do that. I checked with Forte the other day and found theydo
not support the TIFF format.
Thanks much,
Gail Jones
EDS Medi-Cal
Sacramento, Ca.
End of forte-users-digest Digest V00 Issue #185
Date: Wed, 17 May 2000 08:34:01 -0600
From: joe.wolfesasktel.sk.ca
To: kamranaminyahoo.com
Subject: Intermittent database problems
Message-Id: <062568E2.00500AC5.00regn0683nt.sasktel.sk.ca>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
We have a Forte server running on HP_UX 10.2. It connects to an Oracle
database
on AIX. Over the past several months we have received intermittent
failures
that neither we nor our Oracle support team have been able to resolve
(example
below). Prior to the error occuring the partition can be operating
successfully for several days. When this error occurs the IsConnected
instrument on the DBSession is still shown as TRUE, and there are no error
counts on the instruments. After cycling the partition everything runs
fine for
between a day and a month. If anybody has a resolution, or even a good
hunch
I'd appreciate hearing it.
Attached to manager for node capri.
SYSTEM ERROR: OpenCursor failed for SQL statement in project CTISvcs,
class
LookUpInfoMgr, method LoadAgent, methodId 4, line 55, error from
database is:
ORA-02019: connection description for remote database not found
Class: qqdb_ResourceException
Detected at: qqdb_OracleVendorInfo::DoOexn
Error Time: Wed May 17 07:42:42
Oracle error: 2019, Server: DBP13, UserName: forte_c3
Database Statement: select a.cctr_agt_id CareCentreAgentID , a.emp_id
EmployeeID , a.eff_fr_dat EffectiveFromDate , a.eff_to_dat
EffectiveToDate
, a.cctr_agt_gr_id CareCentreGroupID , RTrim ( InitCap ( b.fst_nm )
EmployeeFirstName , RTrim ( InitCap ( b.srnm ) ) EmployeeLastName
from
t_cctr_agt a , t_emp b where a.emp_id = b.emp_id
Exception occurred (locally) on partition "TServRM1_cl0_Part2",
(partitionId = A5E41FA0-D91F-11D3-8F7D-FFCBBA23AA77:0x31d, taskId =
[A5E41FA0-D91F-11D3-8F7D-FFCBBA23AA77:0x320.777]) in application
"TServRM1_cl0", pid 24249 on node capri in environment prodenv.
TIA,
Joe Wolfe, External Programmer Analyst
SaskTel
email: joe.wolfesasktel.sk.ca
End of forte-users-digest Digest V00 Issue #186 -
RE: forte-users-digest V1 #322
Re: "We wish to eliminate any object references to the service object's
partition. Any insight would be greatly appreciated." from Van Vuong
<[email protected]>
This was in regards to copying a set of object from a server to client.
An implicit clone is being done. This also copyies objects they want to
remain on the server.
I believe the normal method of doing this is to anchor the server side
objects. Then when the deep clone occurs, it stops at the anchored
objects generating a proxy. That can also have other affects you do not
want but will at least stop the copying.
From: owner-forte-users-digest
Sent: Tuesday, April 15, 1997 8:09 AM
To: forte-users-digest
Subject: forte-users-digest V1 #322
forte-users-digest Tuesday, 15 April 1997 Volume 01 :
Number 322
How does deep copy apply to arrays?
Re: Global Variables
Re: Global Variables
Using the Edit commands in a menu
Re: Global Variables
Re: How does deep copy apply to arrays?
From: Van Vuong <[email protected]>
Date: Mon, 14 Apr 1997 17:16:46 -0500
Subject: How does deep copy apply to arrays?
I have a service object that has a method that returns an array of
objects. The return type for the method is defined with the copy option.
I found documentation that states that the copy option creates a deep
copy of the return variable on the partition that called the method.
My question is: If the return type for the method is an array of
objects, will the copy option create copies of all objects/elements in
the array?
We wish to eliminate any object references to the service object's
partition. Any insight would be greatly appreciated.
Thanks in advance,
Van Vuong
Phone: 972.985.5289
Pager: 972.320.2232
VoiceNow Pager: 972.330.0822
E-mail: [email protected]
PAGE NET
From: David Bell <[email protected]>
Date: Mon, 14 Apr 1997 22:44:19 +0000
Subject: Re: Global Variables
I got so much mail about and the object location manager, so
I'll continue ...
To make the thing truly portable, regardless of partition,
you need to register the object with a name that is made
up on the fly.
The easisest way to do this is to make up a name composed of
nodename (hopefully unique) plus the process ID. This should
guarantee that you get to the correct object even if there are
several instances around.
Get the nodename from the operating system, then use the partition
agent to ask for the PID. Form a unique name by concatenating these
two piecies of information.
// set up this app's subdirectory namespace
ObjName : TextData = new(Value = '/MyApp/');
// add nodename
ObjName.Concat(task.part.operatingsystem.nodename);
// get PID
Partition : ActivePartitionAgent
= ActivePartitionAgent(task.part.ActPartAgent);
Instrument : ConfigValueInst
= ConfigValueInst(Partition.FindInstrument('ProcessID'));
// add PID to name
Objname.Concat(Instrument.GetData.TextValue);
Now register an anchored object with the object location
manager
// get the object location manager
olm : ObjectLocationMgr;
olm = task.Part.ObjectLocationMgr;
// register my object with the name
olm.RegisterObject(name = Objname, object = MyObj);
Once it's registered, ask the object location manager for a handle
so we can use it. Build the name, get hold of the object
location manager, as above, then invoke BindObject on it.
theObj =
(ClassOfMyObj)(olm.BindObject(name=Objname, classType=ClassOfMyObj));
If the names are formed in the same way, this call should return
a handle to the object of message duration - you can set up
session or transaction duration if required in the RegisterObject
call.
In some versions of Forte, before V.2.F.0, this call not work for
objects located in the same partition.
To get at the instruments, you will need to include the SystemMonitor
Library.
To come back to some other points, as Tom Wynant points out, you can
have a user visible service object in a server partition.
The problem comes when what you really want is the same user visible
service object in lots of different partitions so that you can offer
the same service - but locally.
Today there is no way to do this oustide of client partitions without
resorting to something similar to that presented above.
- David
David Bell Tel : +44 1344 482100
Voice mail : +44 1344 353716
Forte Software Limited Mobile : +44 378 300613
Apex House
London Road Email : mailto: [email protected]
Bracknell Web : http://www.forte.com
Berkshire
RG12 2XH
UK
From: Pierre Gelli <[email protected]>
Date: Tue, 15 Apr 1997 09:09:39 +0200
Subject: Re: Global Variables
Hello folks,
Here is my idea on the topic.
Although one normally doesn't need global variables in a OO system, there
are cases when it's useful : a read cache of data available in the local
active partition. This saves the overhead of accessing the data on a
remote=
SO.
I read the solutions described by David Bell (location manager) and David
Krieger (hack of the partition.appTitle).
There is another way I think is a bit cleaner.
It takes benefit of the fact that a custom system agent can be attached
an
object (in our case the local cache containing the global variables).
Any active partition of the application then contains one such custom
agent.
Any class needing a global variable instantiates a small object, which is
a
manager of the custom agent. Its purpose is to ask the active partition
for
the custom agent, and then for the cache. If the agent doesn't exist it
creates it as well has the local cache; if the agent exists, it returns
the
cache.
There is a cache class.
It is derived into one class to be the "cache server" broadcasting an
event
when some cache data changes. This class is used to create a cache
server=
SO.
The cache class is also derived into a "local cache" class. It knows how
to
initialize it from the cache server. It listens to the event for updating
its local data from the cache server SO when needed.
Enough for the machinery.
Then, for any instance of a class that needs a global variable,
only two lines of code are needed, at initialization time, to get a
reference to the local cache of the partition, then a global variable
isaccessed as if part of a local object. This is quite affordable.
This design guaranties that there is automatically one and only one
up-to-date cache object in any active partition (running on a client or
on a
server). The local cache is seen as a local object by all objects that
use
it (no SO there). This design makes no assumption on the partitioning
that
will take place later. Which is I think one key strength of Fort=E9.
If one is interested I can ship some code that illustrates these ideas.
Hope this helps.
Pierre Gelli
ADP GSI
Payroll and Human Resources Management
72-78, Grande Rue, F-92310 SEVRES
phone : +33 1 41 14 86 42 (direct) +33 1 41 14 85 00 (reception desk)
fax : +33 1 41 14 85 99
From: Bryan Gentile <[email protected]>
Date: Tue, 15 Apr 1997 09:01:35 -0400
Subject: Using the Edit commands in a menu
I was wondering if anyone knows how to code for the edit menu submenu
items
like cut, copy, and paste. I am trying to use these in my menu, but I
cannot find anything about how to code for them. Is there anything in
the
help or any examples to look at. I have been unsuccessful in finding
anything about this.
Thanks
From: [email protected]
Date: Tue, 15 Apr 1997 9:08:01 -0400 (EDT)
Subject: Re: Global Variables
[email protected] writes:
<Snip!>
Unfortunately all Forte Service Objects share a single name
space. I thought from the documentation that User Visible
Service Objects would work for me. However, when I tried User
Visible Service Objects, they didn't quite do the trick because
what I wanted was identically named service objects that resolve
to a different local instance for each partition.You're right. You can put the user-visible service object in any
partition you like, but it must go in one and only one
partition. Rats. I can see why it's this way (based on the
minimal implementation of the name server), but I can think of
some good reasons why it shouldn't be. In fact, I may need to
move some methods around based on this discussion. Again, rats!
Tom Wyant
"The greatest danger of communication is the illusion that it has
occurred." (wish I knew who said that!).
From: [email protected]
Date: Tue, 15 Apr 1997 09:54:10 -0500
Subject: Re: How does deep copy apply to arrays?
Copy option always copies deep. Remember, also if you pass the array
accross partitions, whether you specify copy or not, it is going to copy
and copy deep.
In an array, I am not sure if have the problem, because unless the array
in-turn holds a huge tree, the array object may be wide, but not deep.
Some thing to think about??
Venkat
End of forte-users-digest V1 #322
*********************************Re: "We wish to eliminate any object references to the service object's
partition. Any insight would be greatly appreciated." from Van Vuong
<[email protected]>
This was in regards to copying a set of object from a server to client.
An implicit clone is being done. This also copyies objects they want to
remain on the server.
I believe the normal method of doing this is to anchor the server side
objects. Then when the deep clone occurs, it stops at the anchored
objects generating a proxy. That can also have other affects you do not
want but will at least stop the copying.
From: owner-forte-users-digest
Sent: Tuesday, April 15, 1997 8:09 AM
To: forte-users-digest
Subject: forte-users-digest V1 #322
forte-users-digest Tuesday, 15 April 1997 Volume 01 :
Number 322
How does deep copy apply to arrays?
Re: Global Variables
Re: Global Variables
Using the Edit commands in a menu
Re: Global Variables
Re: How does deep copy apply to arrays?
From: Van Vuong <[email protected]>
Date: Mon, 14 Apr 1997 17:16:46 -0500
Subject: How does deep copy apply to arrays?
I have a service object that has a method that returns an array of
objects. The return type for the method is defined with the copy option.
I found documentation that states that the copy option creates a deep
copy of the return variable on the partition that called the method.
My question is: If the return type for the method is an array of
objects, will the copy option create copies of all objects/elements in
the array?
We wish to eliminate any object references to the service object's
partition. Any insight would be greatly appreciated.
Thanks in advance,
Van Vuong
Phone: 972.985.5289
Pager: 972.320.2232
VoiceNow Pager: 972.330.0822
E-mail: [email protected]
PAGE NET
From: David Bell <[email protected]>
Date: Mon, 14 Apr 1997 22:44:19 +0000
Subject: Re: Global Variables
I got so much mail about and the object location manager, so
I'll continue ...
To make the thing truly portable, regardless of partition,
you need to register the object with a name that is made
up on the fly.
The easisest way to do this is to make up a name composed of
nodename (hopefully unique) plus the process ID. This should
guarantee that you get to the correct object even if there are
several instances around.
Get the nodename from the operating system, then use the partition
agent to ask for the PID. Form a unique name by concatenating these
two piecies of information.
// set up this app's subdirectory namespace
ObjName : TextData = new(Value = '/MyApp/');
// add nodename
ObjName.Concat(task.part.operatingsystem.nodename);
// get PID
Partition : ActivePartitionAgent
= ActivePartitionAgent(task.part.ActPartAgent);
Instrument : ConfigValueInst
= ConfigValueInst(Partition.FindInstrument('ProcessID'));
// add PID to name
Objname.Concat(Instrument.GetData.TextValue);
Now register an anchored object with the object location
manager
// get the object location manager
olm : ObjectLocationMgr;
olm = task.Part.ObjectLocationMgr;
// register my object with the name
olm.RegisterObject(name = Objname, object = MyObj);
Once it's registered, ask the object location manager for a handle
so we can use it. Build the name, get hold of the object
location manager, as above, then invoke BindObject on it.
theObj =
(ClassOfMyObj)(olm.BindObject(name=Objname, classType=ClassOfMyObj));
If the names are formed in the same way, this call should return
a handle to the object of message duration - you can set up
session or transaction duration if required in the RegisterObject
call.
In some versions of Forte, before V.2.F.0, this call not work for
objects located in the same partition.
To get at the instruments, you will need to include the SystemMonitor
Library.
To come back to some other points, as Tom Wynant points out, you can
have a user visible service object in a server partition.
The problem comes when what you really want is the same user visible
service object in lots of different partitions so that you can offer
the same service - but locally.
Today there is no way to do this oustide of client partitions without
resorting to something similar to that presented above.
- David
David Bell Tel : +44 1344 482100
Voice mail : +44 1344 353716
Forte Software Limited Mobile : +44 378 300613
Apex House
London Road Email : mailto: [email protected]
Bracknell Web : http://www.forte.com
Berkshire
RG12 2XH
UK
From: Pierre Gelli <[email protected]>
Date: Tue, 15 Apr 1997 09:09:39 +0200
Subject: Re: Global Variables
Hello folks,
Here is my idea on the topic.
Although one normally doesn't need global variables in a OO system, there
are cases when it's useful : a read cache of data available in the local
active partition. This saves the overhead of accessing the data on a
remote=
SO.
I read the solutions described by David Bell (location manager) and David
Krieger (hack of the partition.appTitle).
There is another way I think is a bit cleaner.
It takes benefit of the fact that a custom system agent can be attached
an
object (in our case the local cache containing the global variables).
Any active partition of the application then contains one such custom
agent.
Any class needing a global variable instantiates a small object, which is
a
manager of the custom agent. Its purpose is to ask the active partition
for
the custom agent, and then for the cache. If the agent doesn't exist it
creates it as well has the local cache; if the agent exists, it returns
the
cache.
There is a cache class.
It is derived into one class to be the "cache server" broadcasting an
event
when some cache data changes. This class is used to create a cache
server=
SO.
The cache class is also derived into a "local cache" class. It knows how
to
initialize it from the cache server. It listens to the event for updating
its local data from the cache server SO when needed.
Enough for the machinery.
Then, for any instance of a class that needs a global variable,
only two lines of code are needed, at initialization time, to get a
reference to the local cache of the partition, then a global variable
isaccessed as if part of a local object. This is quite affordable.
This design guaranties that there is automatically one and only one
up-to-date cache object in any active partition (running on a client or
on a
server). The local cache is seen as a local object by all objects that
use
it (no SO there). This design makes no assumption on the partitioning
that
will take place later. Which is I think one key strength of Fort=E9.
If one is interested I can ship some code that illustrates these ideas.
Hope this helps.
Pierre Gelli
ADP GSI
Payroll and Human Resources Management
72-78, Grande Rue, F-92310 SEVRES
phone : +33 1 41 14 86 42 (direct) +33 1 41 14 85 00 (reception desk)
fax : +33 1 41 14 85 99
From: Bryan Gentile <[email protected]>
Date: Tue, 15 Apr 1997 09:01:35 -0400
Subject: Using the Edit commands in a menu
I was wondering if anyone knows how to code for the edit menu submenu
items
like cut, copy, and paste. I am trying to use these in my menu, but I
cannot find anything about how to code for them. Is there anything in
the
help or any examples to look at. I have been unsuccessful in finding
anything about this.
Thanks
From: [email protected]
Date: Tue, 15 Apr 1997 9:08:01 -0400 (EDT)
Subject: Re: Global Variables
[email protected] writes:
<Snip!>
Unfortunately all Forte Service Objects share a single name
space. I thought from the documentation that User Visible
Service Objects would work for me. However, when I tried User
Visible Service Objects, they didn't quite do the trick because
what I wanted was identically named service objects that resolve
to a different local instance for each partition.You're right. You can put the user-visible service object in any
partition you like, but it must go in one and only one
partition. Rats. I can see why it's this way (based on the
minimal implementation of the name server), but I can think of
some good reasons why it shouldn't be. In fact, I may need to
move some methods around based on this discussion. Again, rats!
Tom Wyant
"The greatest danger of communication is the illusion that it has
occurred." (wish I knew who said that!).
From: [email protected]
Date: Tue, 15 Apr 1997 09:54:10 -0500
Subject: Re: How does deep copy apply to arrays?
Copy option always copies deep. Remember, also if you pass the array
accross partitions, whether you specify copy or not, it is going to copy
and copy deep.
In an array, I am not sure if have the problem, because unless the array
in-turn holds a huge tree, the array object may be wide, but not deep.
Some thing to think about??
Venkat
End of forte-users-digest V1 #322
********************************* -
RE: forte-users-digest Digest V00 #185
Hi,
The only work around I can see to your problem is to convert the TIFF to
any other format that forte supports. You could use Microsoft's Image
Composer to do this. As far as I can see your requirement is runtime. I
would suggest using Windows imaging ( an image edit control, that is an
active-x control ). Use this control to perform a SaveAs operation on the
TIFF file to save it as a GIF and then use the converted GIF to place it in
your Forte Object. I know it works in C++ so it should surely work in
forte too. I don't have the documentation for the image edit control, but
Iam sure there are lot of similar controls out there . And make sure you
save the file in a format that supports mutiple page formats. ( i.e prefer
GIF to BMP when you convert)
Hope this Helps,
- Ravi Balakrishna
Automation Software Engineer
Intel Corporation.
-----Original Message-----
From: forte-users-digest-requestlists.xpedior.com
[SMTP:forte-users-digest-requestlists.xpedior.com]
Sent: Tuesday, May 16, 2000 3:05 PM
To: forte-users-digestlists.xpedior.com
Subject: forte-users-digest Digest V00 #185
forte-users-digest Digest Volume 00 : Issue
185
Today's Topics:
Tiff images again.....
Administrivia:
* BEFORE YOU ASK - please search the archives at:
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-digest-requestlists.xpedior.com
Date: Tue, 16 May 2000 11:07:25 -0400
From: "Jones, Gail A" <gail.joneseds.com>
To: "'kamranaminyahoo.com'" <kamranaminyahoo.com>
Subject: Tiff images again.....
Message-ID: <F455E4114C4AD211BCDF00805F31BCF305C206DCUSSAM203>
Content-Type: text/plain;
charset="iso-8859-1"
I need to place TIFF images in a Forte Object to display on a client
window.
Does anyone have any tips or code that you would be willing to share that
can help me do that. I checked with Forte the other day and found they do
not support the TIFF format.
Thanks much,
Gail Jones
EDS Medi-Cal
Sacramento, Ca.
End of forte-users-digest Digest V00 Issue #185Hi,
The only work around I can see to your problem is to convert the TIFF to
any other format that forte supports. You could use Microsoft's Image
Composer to do this. As far as I can see your requirement is runtime. I
would suggest using Windows imaging ( an image edit control, that is an
active-x control ). Use this control to perform a SaveAs operation on the
TIFF file to save it as a GIF and then use the converted GIF to place it in
your Forte Object. I know it works in C++ so it should surely work in
forte too. I don't have the documentation for the image edit control, but
Iam sure there are lot of similar controls out there . And make sure you
save the file in a format that supports mutiple page formats. ( i.e prefer
GIF to BMP when you convert)
Hope this Helps,
- Ravi Balakrishna
Automation Software Engineer
Intel Corporation.
-----Original Message-----
From: forte-users-digest-requestlists.xpedior.com
[SMTP:forte-users-digest-requestlists.xpedior.com]
Sent: Tuesday, May 16, 2000 3:05 PM
To: forte-users-digestlists.xpedior.com
Subject: forte-users-digest Digest V00 #185
forte-users-digest Digest Volume 00 : Issue
185
Today's Topics:
Tiff images again.....
Administrivia:
* BEFORE YOU ASK - please search the archives at:
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-digest-requestlists.xpedior.com
Date: Tue, 16 May 2000 11:07:25 -0400
From: "Jones, Gail A" <gail.joneseds.com>
To: "'kamranaminyahoo.com'" <kamranaminyahoo.com>
Subject: Tiff images again.....
Message-ID: <F455E4114C4AD211BCDF00805F31BCF305C206DCUSSAM203>
Content-Type: text/plain;
charset="iso-8859-1"
I need to place TIFF images in a Forte Object to display on a client
window.
Does anyone have any tips or code that you would be willing to share that
can help me do that. I checked with Forte the other day and found they do
not support the TIFF format.
Thanks much,
Gail Jones
EDS Medi-Cal
Sacramento, Ca.
End of forte-users-digest Digest V00 Issue #185 -
Re: forte-users-digest Digest V01 #149
Please disregard the "this month sponsored by" line. iPlanet has taken
permanent control of the payment and sponsorship of this list
service. Barring technical interruptions, the list service is here to stay.
- John EmersonPlease disregard the "this month sponsored by" line. iPlanet has taken
permanent control of the payment and sponsorship of this list
service. Barring technical interruptions, the list service is here to stay.
- John Emerson -
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 -
RE: (forte-users) Killing the Nones - solved
Thanks to all of you who helped ... this pex file works great.
Allan
-----Original Message-----
From: kelsey.petrychynsasktel.sk.ca [SMTP:kelsey.petrychynsasktel.sk.ca]
Sent: Thursday, August 24, 2000 9:51 AM
To: Pomeroy, Allan
Cc: kamranaminyahoo.com
Subject: Re: (forte-users) Killing the Nones
Try the code contained in this pex file.
We got it from someone in Forte quite a while ago and found that it worked
pretty good. I haven't used it for a long time since, and it was probably
written using an old version of Forte. However, it should still work, or
at
least you may find some salvageable code that can be "modernized" to what
ever
version you are using.
(See attached file: FtExecShutDown.pex)
PS
You would almost think that by version 3+ of a product Forte would have
nailed
down their empty and orphaned (defunct in UNIX) processes bugs. The
environment
manager should be able to auto-magically shut them down or at least keep
them
down to an acceptable number. But alas, we still find ourselves
occasionally
exceeding our finite server resources due to rouge processes doing
nothing.
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!
"Pomeroy, Allan" <Allan.PomeroyLibertyMutual.com> on 08/24/2000 07:09:16
AM
To: kamranaminyahoo.com
cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
Subject: (forte-users) Killing the Nones
Venerable Forte Gurus,
Aside from using the Econsole, is there a way to kill the "None" ftexecs
that sometimes hang around after forte partitions are shut down?
In Econsole, if you view->node outline, then select the Forte Executor,
you
may see some running ftexecs with no application assigned -- they show up
as
"None". When I subsequently launch applications, I want them to start in
new ftexecs, not in the old "none"s, which have old command-line parms,
memory settings, etc.
Thanks!
Allan
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
<< File: FtExecShutDown.pex >>Try the code contained in this pex file.
We got it from someone in Forte quite a while ago and found that it worked
pretty good. I haven't used it for a long time since, and it was probably
written using an old version of Forte. However, it should still work, or at
least you may find some salvageable code that can be "modernized" to what ever
version you are using.
(See attached file: FtExecShutDown.pex)
PS
You would almost think that by version 3+ of a product Forte would have nailed
down their empty and orphaned (defunct in UNIX) processes bugs. The environment
manager should be able to auto-magically shut them down or at least keep them
down to an acceptable number. But alas, we still find ourselves occasionally
exceeding our finite server resources due to rouge processes doing nothing.
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!
"Pomeroy, Allan" <Allan.PomeroyLibertyMutual.com> on 08/24/2000 07:09:16 AM
To: kamranaminyahoo.com
cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
Subject: (forte-users) Killing the Nones
Venerable Forte Gurus,
Aside from using the Econsole, is there a way to kill the "None" ftexecs
that sometimes hang around after forte partitions are shut down?
In Econsole, if you view->node outline, then select the Forte Executor, you
may see some running ftexecs with no application assigned -- they show up as
"None". When I subsequently launch applications, I want them to start in
new ftexecs, not in the old "none"s, which have old command-line parms,
memory settings, etc.
Thanks!
Allan
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 -
Non-Delivery of:RE: 4 Forte questions, sitting in arow
Hi Carl,
a. With regards to Forte "wrappering". Presumably the 'C' program that
you want to interface to, must have an API that you can access, and then
you call those functions from within Forte ?
If its a vanilla C program (you need the *.obj file) its quite straightforward.
You create a Forte project with an appropriately named class and method stubs
in an editor (not in Forte). This then gets imported into Forte and partitioned
as an external library. Forte then generates the appropriate C++ stubs, which
you compile with the appropriate C++ compiler. This will link the desired C
program into your Forte generated C++ stubs and all is well. If its a C++
program, typically they are DLL's, or if you don't have the *.obj file, you
have to jump through some (more) hoops as another user put it. Then you need to
write a C (not C++) program that calls the desired C++ DLL. And repeat as
above. So you then end up with 2 sets of stubs. Its quite cumbersome, but it
does work !
b. How does Forte support external, real-time, interrupt driven
applications ?
I'm not sure I uderstand the question - possibly the same as answer to d below.
c. Does Forte support 'Business Objects' datamining tool, and if not,
does it support any other data mining tool ?
As far as I know it does support Business Objects. At the interface level Forte
supports the C API or OLE2 automation (and next version (3) will support
Active-X as well) and most API's will give you one of those options.
d. Apparently Forte can interface to external applications using
messages, like it does internally between objects. How can it do this ?
Interfacing to external objects can done via three mechanisms :
1. CORBA. It uses the DEC ORB to interface fully to CORBA 2 compliant clients
(from Forte SO's) or servers (from Forte client partitions).
2. DCE. Similar to above
3. The ExternalConnection Class (Framework) is probably the easiest. We have
just received the documentation and it looks really good. Essentially you open
a TCP/IP pipe to another process on which you can both send and receive raw
data. You obviously need to design some higher level coding scheme, but it
looks very straightforward to implement and from what I know of TCP/IP pipes
its the best performing interface mechanism. In answer to your earlier
question, realtime external interrupts would probably work best with this. In
fact I know of implementations where they are busy doing exactly this with
continous datafeeds (and machine PLC control) via their own (!!) C-wrappered
Unix pipes interface.
Any insight would be appreciated,
- Carl
Carl Schei | Dexel (Pty) Ltd (Durban) |
Software Engineer | Tel : 27 31 2669273 |
email : [email protected] | Fax : 27 31 2660340 |
------ Message Header Follows ------
Received: from pebble.Sagesoln.com by notes.bsginc.com
(PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm))
id AA-1996Sep20.134600.1787.19161; Fri, 20 Sep 1996 13:46:02 -0500
Received: (from sync@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
JAA13740 for forte-users-outgoing; Fri, 20 Sep 1996 09:40:31 -0700
Received: (from uucp@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
JAA13734 for <[email protected]>; Fri, 20 Sep 1996 09:40:29 -0700
Received: from lin01.global.co.za(196.3.164.2) by pebble.sagesoln.com via smap
(V1.3)
id sma013732; Fri Sep 20 09:40:12 1996
Received: from anx_99.global.co.za (anx_99.global.co.za [196.3.168.109]) by
lin01.global.co.za (8.7.3/8.7.3) with SMTP id SAA14527; Fri, 20 Sep 1996
18:38:14 -0200 (GMT)
Received: by anx_99.global.co.za with Microsoft Mail
id <01BBA723.B4E4AD40@anx_99.global.co.za>; Fri, 20 Sep 1996 18:44:08 +-200
Message-ID: <01BBA723.B4E4AD40@anx_99.global.co.za>
From: Anton van Niekerk <[email protected]>
To: "'Dexel - Durban'" <[email protected]>
Cc: "'Forte user group'" <[email protected]>
Subject: RE: 4 Forte questions, sitting in a row
Date: Fri, 20 Sep 1996 18:39:50 +-200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Sender: [email protected]
Precedence: bulk
Reply-To: [email protected]-Your IP number is not blacklisted in the majr blacklist (doesn't mean this is true for all, but you should be OK=
-Your mail server is not an open relay, but is also not particularly well configured (nothing you can do about other than change provider).
This means, that it is close to impossible to tell you where the problem is from distance. I have never heard of your ISP so I cannot express any opinion.
If things are like you explained in points 1 and 2 of your post, chances are your ISPs mailserver has a very aggressive spamfilter generating false positives or has some other major configuration issue.
Do you have to authenticate to send mail?
Can you please reply to the testmail I sent you, so I can check it from my side.
Alex
P.S. Point 4 of your original post is part of life in the internet. Nothing you can do about. That's what spam filters are for.
P.P.S. All of this has nothing to do with Mac OS X Server so you are actually in the wrong place. Doesn't matter now as you'll have to have your provider sort this out anyway. -
RE: (forte-users) 3J= 3M new to me error
Hi Thomas,
Thanks for your email but I think it will be interesting for Brenda not me.
It is exactly what I have expected from Forte Support: detailed information
about bugs and workarounds. But what I cannot understand is that #53398 was
released without any information about possible reasons for this problem or
suggested workarounds. My first reaction after reading this bugreport was to
open a new case at CallCenter to get more information about it. Please
release more information with your bug reports !
Regards
Zenon Adamek
Information Services
Senior Programmer Analyst
Tel: 905 712-1084 ext. 3628
Fax: 905 712-6709
E-mail: zadamekpurolator.com
-----Original Message-----
From: Thomas Degen - Sun Germany Forte Tools - Bonn
[SMTP:thomas.degensun.com]
Sent: Wednesday, September 27, 2000 9:49 AM
To: Adamek, Zenon
Cc: 'Brenda Cumming'; Forte-userslists.xpedior.com
Subject: RE: (forte-users) 3J=>3M new to me error
Hi Zenon,
bug #53398 is not a bug which will likely get fixed, it's an informational
bugreport.
You might see an errorstack like Brenda has reported (and described in
informational
bugreport #53398) probably when you are doing something illegal that is
possible
via Forte Tool but Forte is not trapping it for performance reasons. Hence
you will see
the error coming from your illegal operation only at runtime, probably
only
while
running interpreted in the Forte IDE, but in worst case it might be even a
segmentation
violation.
Technotes 12448 'Sudden client partition crashes at runtime' and 11225
'Don't reparent
mapped Widgets between UserWindows at runtime' explain this matter . See
attached.
But maybe Brenda is much more experiencing a problem as described by Forte
Technote 11398 'Read Only Workspace Errors using ListViews or ActiveX
control'
that might get easily resolved via setting of FORTE_YIELD_THROTTLE=0.
Good Luck and Best Regards !
BTW: I've logged bug #53398, so I've felt responsible to explain its real
background.
Thomas
Thomas Degen
Sun Microsystems - Forte Tools
Forte CTE & Sustaining Group
Technical Support Germany
tel.:+49.228/91499-50
MailTo:thomas.degensun.com
Technote 11398 Read Only Workspace Errors using ListViews or ActiveX
control
SCENARIO:
Getting some unusual interpreter errors that result in an error stating
that
the workspace has been set to read only. Please see Enclosures for the
two
most common error stacks that have been encountered. The abbreviated
versions of the errors are:
- Can't read record (record size = -1)
- Id in index does not match id in record header in data file
- Recursive deserialization attempted.
- Unknown Mark type in deserialization
- Could not read record (64,74615) from repository data file.
Header
is corrupt.
These errors can be happening in either the development environment when
running from one of the development workshops, or with the deployed
application.
The bug outlined in this Technote may be the culprit if the errors above
are
seen when running a client on Windows NT or Motif and the user interface
incorporates ActiveX controls or ListView/TreeView widgets.
CAUSE:
Basically what is happening is that in rare circumstances Forte may invoke
a
nested copy of the interpreter while the first interpreter has yielded.
This
is not a problem in and of itself, but in the case where the original
interpreter was in the middle of a repository fetch when it yielded, and
the second interpreter needs to fetch code as well, we will get one of the
errors listed above, depending on the exact timing. The reason for the
errors is that the repository code at this level is thread-safe but not
re-entrant. It is protected by a mutex that is already owned by the
current task. Which, given the scenario outlined here, where the two
interpreters are running inside of the same task, results in the nested
interpreter being allowed to change data out from under the first.
While for every fetch one or more calls to WindowSystem.Yield will be made
(this is there to prevent the semblance of system lock-up on Win 3.1,
where
Yield is the only way other applications can be allowed to run), there is
a parameter which controls how often to actually yield, which by default
is
set to one out of every 100 calls. This is the reason the problem is
intermittent--you need a yield to occur during a repository fetch
which starts another interpreter which also needs to fetch code from
disk.
The reason this has only surfaced recently is that the nested interpreter
scenario can only happen in 2 cases that we know of:
- ActiveX controls which respond to events/Windows messages
- Outline fields/ListViews with column(s) mapped to virtual
attributes
In all other normal cases, the yield can process the message (typically a
paint message) without starting another interpreter, so regardless of
whether
the first interpreter yielded during a repository operation or not, there
is
no conflict.
SOLUTION:
The workaround is to prevent yields altogether by setting the
FORTE_YIELD_THROTTLE environment variable equal to 0 in the client's
environment. This should have no detrimental effects since the yield code
is in place solely for Windows 3.1x clients.
ERROR STACK 1
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to
prevent the application from attempting to write to the repository. The
repository and work you have saved to the repository are safe. If your
workspace
contains unsaved work, you may use the following procedure to save this
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import
the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::GetObjectById
Last TOOL statement: method EFWindowController.EFEventLoop
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
The remainder of the Error Manager stack is:
SYSTEM ERROR: Internal Error attempting to deserialize element (64,67470)
(fetch
bitmask is 0x20). Your workspace is now read-only to prevent the
application
from attempting to write to the repository. The repository and work you
have
saved to the repository are safe. If your workspace contains unsaved work,
you
may use the following procedure to save this work. First, export the
changed
components. Then, shut down and restart this application and reopen this
workspace in read-write mode. Finally, import the changed components and
save
your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Last TOOL statement: method EFTabManagerNew.EFNoteBookHandler
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
SYSTEM ERROR: Unknown Mark type in deserialization.
Class: qqsp_ImplementationException
Error #: [1101, 34]
Detected at: qqrp_DeSerializeObject::ProcessHdr
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
ERROR STACK 2
SYSTEM ERROR: A serious error has occurred in Repository
(c:\PROGRA~1\CSSPTEST\conplu0). Corrective action may be necessary.
Notify
your repository administrator.
Class: qqsp_ImplementationException
Error #: [1101, 198]
Detected at: qqrp_Repository::Fetch
Last TOOL statement: method
SalesDevelopment_NWC.DEVNotifyofTabSetCurrent
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
SYSTEM ERROR: Could not read record (64,74615) from repository data file.
Header is corrupt.
Class: qqsp_ImplementationException
Error #: [1106, 612]
Detected at: qqbt_BtreeAccess::FetchDataFileRecord
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
Technote 11225 Don't reparent mapped Widgets between UserWindows at
runtime
It is sometimes tempting to unparent a widget from one UserWindow and
reparent
it into another at runtime. However, this can cause crashes if the widget
(or
its decendants) are "mapped" to data. Here's why...
Suppose you have two UserWindows, UW1 and UW2. UW1 contains a DataField
(DF1)
which is mapped to a TextData. UW2 contains a RadioList (RL2) which is
mapped to
a scalar Integer. At compile time, every mapped attribute is internally
assigned
a "Map ID" (a small integer) which is used to tie the Widget to its
corresponding attribute. These Map IDs are used by the Widget to look up a
pointer to their data in a "Map" which is maintained by the UserWindow.
Each
UserWindow is assumed be to independent of the others, so there is nothing
wrong
with Widgets in different UserWindows being assigned the same Map IDs.
In
this
case, let's assume that DF1 and RL2 both got assigned the same Map ID of
3. No
problem so far, since each lives in a separate UserWindow with a separate
map.
Now suppose at runtime the application "detaches" or unparents DF1 from
its
UserWindow and reparents it somewhere into UW2. When it comes time for DF1
to
paint itself the Display System it must ask the Runtime System for the
value of
DF1's mapped attribute. To do that it says "give me the value of the
TextData
for DF1. You'll find it in the Map for this UserWindow (UW1), and its Map
ID is
3". When the runtime system goes to do this it expects to find a TextData
in
this "slot" of the map, but instead it picks up the integer which is
mapped to
RL2. At best this leads to bad data being returned; more likely you get a
segfault and a crash.
If DF1 was not a mapped attribute (say, a Rectangle) there would be no
problem
because there is no data mapped to a Rectangle. If instead of moving DF1
you
created a brand new DataField on the fly there would be no problem,
because the
dynamic DataField would not have any Map ID and so couldn't conflict with
any
IDs in UW2.
So how do you solve this problem? This is exactly what Nested Windows are
all
about. While you can't move DF1 into the middle of UW2, you can nest
UW1.
This
works because UW1 brings its map with it, and when you access DF1 it knows
to
look up its value in UW1's map.
UserWindows are intended to be the "unit of compilabilty" that can be
nested
inside other UserWindows. It is dangerous to "transplant" anything from
inside
one UserWindow into another at runtime.
(Note that you can't avoid this problem by cloning DF1 because the MapID
gets
copied along with it, and the clone will fail in the same way.)
Further details explained in related technote 12448 'Sudden client
partition
crashes at runtime.'
Technote 12448 Sudden client partition crashes at runtime
Scenario : You have two UserWindows, A and B. When Window A starts up, it
instantiates an instance of B and reparents some component of B into A's
window
hierarchy.
This is not allowed and almost always leads to an error at best or at
worse a
segmentation fault.
Here's why :
When you compile a UserWindow in Forte, each "mapped attribute" (whether a
form
element or menu element) is assigned an internal ID which represents an
offset into
that UserWindow's table of mapped attributes. This offset is only valid
in the
context of the UserWindow in which it was compiled. If you detach a
FieldWidget or
MenuWidget from one compiled Window ("tmpMenu" for example) and then
parent
into another compiled window ("tmpWindow") the internal ID comes with it.
When Forte tries to make use of that copied widget it uses the ID as an
offset
into tmpWindow's table of mapped attributes. But that copied offset is
meaningless in the context of tmpWindow's table, so you get some kind off
error.
In this case it found that the data type of the variable in the slot
wasn't
what
was expected. But you might even index off the end of the table and get a
segmentation fault.
There is nothing to prevent you from dynamically creating menu items and
adding
them to a window at runtime; that will work fine. Although of course you
can't
access them via mapped attributes, since those can only be created at
compile time.
But you are not allowed to reparent a widget from one compiled UserWindow
into
the hierarchy of another.
More information may be found in technote 11225 'Don't reparent mapped
Widgets
between UserWindows at runtime'.
Possible errorstacks seen at runtime instead of a complete crash or
segmentation
violation while you are illegally reparenting a widget or menuitem between
windows
at runtime:
Map::SetSubjectData: Invalid conversion from map type 0 to subject type 22
SYSTEM ERROR: Bad parameter at location 3 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 3
Error Time: Wed Aug 09 13:03:57
Exception occurred (locally) on partition "testproject_CL0_Client",
(partitionId = D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd,
taskId =
[D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd.68]) in application
"FTLaunch_cl0", pid 672 on node ONEWAY in environment Audi3M2Env.
At 13:14 26.09.00 -0400, Adamek, Zenon wrote:
Hi,
It is the unfixed defect 53398. Please contact Forte support.
Zenon
-----Original Message-----
From: Brenda Cumming [SMTP:brenda_cummingtranscanada.com]
Sent: Tuesday, September 26, 2000 1:15 PM
To: Forte User group
Subject: (forte-users) 3J=>3M new to me error
Hi,
We are in the process of going from 3J1 to 3.0.M.2, and I am getting
this error that I am unfamiliar with on a GUI that works fine in 3J.
It
does not happen all the time, and I have been unable to establish the
pattern that kicks it off. Has anyone seen this before?
PS- this error is not occurring in the deployed (non-compiled) app,but
when I am running locally from my workspace.
SYSTEM ERROR: Bad parameter at location 6 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 6
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2,
taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Can't find scope 20070 for a class.
Class: qqsp_Exception
Error #: [201, 11]
Detected at: qqlo_ClassTableLoadScope at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to prevent the application from attempting to write to the repository.
The repository and work you have saved to the repository are safe. If
your
workspace contains unsaved work, you may use the following procedure
to save this work. First, export the changed components. Then, shut down and
restart this application and reopen this workspace in read-write mode.
Finally, import the changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::IsDistributed
Last TOOL statement: method PPMeasWin.
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Internal Error attempting to deserialize element
(64,120684) (fetch bitmask is 0x20). Your workspace is now read-onlyto
prevent
the application from attempting to write to the repository. The
repository
and work you have saved to the repository are safe. If your workspace
contains unsaved work, you may use the following procedure to savethis
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Recursive Deserialization attempted, Internal Error!
Class: qqsp_UsageException with ReasonCode: SP_ER_INVALIDSTATE
Error #: [301, 231]
Detected at: qqsp_DeSerializeDriver::Run at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in anew
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.comHi Thomas,
Thanks for your email but I think it will be interesting for Brenda not me.
It is exactly what I have expected from Forte Support: detailed information
about bugs and workarounds. But what I cannot understand is that #53398 was
released without any information about possible reasons for this problem or
suggested workarounds. My first reaction after reading this bugreport was to
open a new case at CallCenter to get more information about it. Please
release more information with your bug reports !
Regards
Zenon Adamek
Information Services
Senior Programmer Analyst
Tel: 905 712-1084 ext. 3628
Fax: 905 712-6709
E-mail: zadamekpurolator.com
-----Original Message-----
From: Thomas Degen - Sun Germany Forte Tools - Bonn
[SMTP:thomas.degensun.com]
Sent: Wednesday, September 27, 2000 9:49 AM
To: Adamek, Zenon
Cc: 'Brenda Cumming'; Forte-userslists.xpedior.com
Subject: RE: (forte-users) 3J=>3M new to me error
Hi Zenon,
bug #53398 is not a bug which will likely get fixed, it's an informational
bugreport.
You might see an errorstack like Brenda has reported (and described in
informational
bugreport #53398) probably when you are doing something illegal that is
possible
via Forte Tool but Forte is not trapping it for performance reasons. Hence
you will see
the error coming from your illegal operation only at runtime, probably
only
while
running interpreted in the Forte IDE, but in worst case it might be even a
segmentation
violation.
Technotes 12448 'Sudden client partition crashes at runtime' and 11225
'Don't reparent
mapped Widgets between UserWindows at runtime' explain this matter . See
attached.
But maybe Brenda is much more experiencing a problem as described by Forte
Technote 11398 'Read Only Workspace Errors using ListViews or ActiveX
control'
that might get easily resolved via setting of FORTE_YIELD_THROTTLE=0.
Good Luck and Best Regards !
BTW: I've logged bug #53398, so I've felt responsible to explain its real
background.
Thomas
Thomas Degen
Sun Microsystems - Forte Tools
Forte CTE & Sustaining Group
Technical Support Germany
tel.:+49.228/91499-50
MailTo:thomas.degensun.com
Technote 11398 Read Only Workspace Errors using ListViews or ActiveX
control
SCENARIO:
Getting some unusual interpreter errors that result in an error stating
that
the workspace has been set to read only. Please see Enclosures for the
two
most common error stacks that have been encountered. The abbreviated
versions of the errors are:
- Can't read record (record size = -1)
- Id in index does not match id in record header in data file
- Recursive deserialization attempted.
- Unknown Mark type in deserialization
- Could not read record (64,74615) from repository data file.
Header
is corrupt.
These errors can be happening in either the development environment when
running from one of the development workshops, or with the deployed
application.
The bug outlined in this Technote may be the culprit if the errors above
are
seen when running a client on Windows NT or Motif and the user interface
incorporates ActiveX controls or ListView/TreeView widgets.
CAUSE:
Basically what is happening is that in rare circumstances Forte may invoke
a
nested copy of the interpreter while the first interpreter has yielded.
This
is not a problem in and of itself, but in the case where the original
interpreter was in the middle of a repository fetch when it yielded, and
the second interpreter needs to fetch code as well, we will get one of the
errors listed above, depending on the exact timing. The reason for the
errors is that the repository code at this level is thread-safe but not
re-entrant. It is protected by a mutex that is already owned by the
current task. Which, given the scenario outlined here, where the two
interpreters are running inside of the same task, results in the nested
interpreter being allowed to change data out from under the first.
While for every fetch one or more calls to WindowSystem.Yield will be made
(this is there to prevent the semblance of system lock-up on Win 3.1,
where
Yield is the only way other applications can be allowed to run), there is
a parameter which controls how often to actually yield, which by default
is
set to one out of every 100 calls. This is the reason the problem is
intermittent--you need a yield to occur during a repository fetch
which starts another interpreter which also needs to fetch code from
disk.
The reason this has only surfaced recently is that the nested interpreter
scenario can only happen in 2 cases that we know of:
- ActiveX controls which respond to events/Windows messages
- Outline fields/ListViews with column(s) mapped to virtual
attributes
In all other normal cases, the yield can process the message (typically a
paint message) without starting another interpreter, so regardless of
whether
the first interpreter yielded during a repository operation or not, there
is
no conflict.
SOLUTION:
The workaround is to prevent yields altogether by setting the
FORTE_YIELD_THROTTLE environment variable equal to 0 in the client's
environment. This should have no detrimental effects since the yield code
is in place solely for Windows 3.1x clients.
ERROR STACK 1
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to
prevent the application from attempting to write to the repository. The
repository and work you have saved to the repository are safe. If your
workspace
contains unsaved work, you may use the following procedure to save this
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import
the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::GetObjectById
Last TOOL statement: method EFWindowController.EFEventLoop
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
The remainder of the Error Manager stack is:
SYSTEM ERROR: Internal Error attempting to deserialize element (64,67470)
(fetch
bitmask is 0x20). Your workspace is now read-only to prevent the
application
from attempting to write to the repository. The repository and work you
have
saved to the repository are safe. If your workspace contains unsaved work,
you
may use the following procedure to save this work. First, export the
changed
components. Then, shut down and restart this application and reopen this
workspace in read-write mode. Finally, import the changed components and
save
your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Last TOOL statement: method EFTabManagerNew.EFNoteBookHandler
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
SYSTEM ERROR: Unknown Mark type in deserialization.
Class: qqsp_ImplementationException
Error #: [1101, 34]
Detected at: qqrp_DeSerializeObject::ProcessHdr
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
ERROR STACK 2
SYSTEM ERROR: A serious error has occurred in Repository
(c:\PROGRA~1\CSSPTEST\conplu0). Corrective action may be necessary.
Notify
your repository administrator.
Class: qqsp_ImplementationException
Error #: [1101, 198]
Detected at: qqrp_Repository::Fetch
Last TOOL statement: method
SalesDevelopment_NWC.DEVNotifyofTabSetCurrent
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
SYSTEM ERROR: Could not read record (64,74615) from repository data file.
Header is corrupt.
Class: qqsp_ImplementationException
Error #: [1106, 612]
Detected at: qqbt_BtreeAccess::FetchDataFileRecord
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
Technote 11225 Don't reparent mapped Widgets between UserWindows at
runtime
It is sometimes tempting to unparent a widget from one UserWindow and
reparent
it into another at runtime. However, this can cause crashes if the widget
(or
its decendants) are "mapped" to data. Here's why...
Suppose you have two UserWindows, UW1 and UW2. UW1 contains a DataField
(DF1)
which is mapped to a TextData. UW2 contains a RadioList (RL2) which is
mapped to
a scalar Integer. At compile time, every mapped attribute is internally
assigned
a "Map ID" (a small integer) which is used to tie the Widget to its
corresponding attribute. These Map IDs are used by the Widget to look up a
pointer to their data in a "Map" which is maintained by the UserWindow.
Each
UserWindow is assumed be to independent of the others, so there is nothing
wrong
with Widgets in different UserWindows being assigned the same Map IDs.
In
this
case, let's assume that DF1 and RL2 both got assigned the same Map ID of
3. No
problem so far, since each lives in a separate UserWindow with a separate
map.
Now suppose at runtime the application "detaches" or unparents DF1 from
its
UserWindow and reparents it somewhere into UW2. When it comes time for DF1
to
paint itself the Display System it must ask the Runtime System for the
value of
DF1's mapped attribute. To do that it says "give me the value of the
TextData
for DF1. You'll find it in the Map for this UserWindow (UW1), and its Map
ID is
3". When the runtime system goes to do this it expects to find a TextData
in
this "slot" of the map, but instead it picks up the integer which is
mapped to
RL2. At best this leads to bad data being returned; more likely you get a
segfault and a crash.
If DF1 was not a mapped attribute (say, a Rectangle) there would be no
problem
because there is no data mapped to a Rectangle. If instead of moving DF1
you
created a brand new DataField on the fly there would be no problem,
because the
dynamic DataField would not have any Map ID and so couldn't conflict with
any
IDs in UW2.
So how do you solve this problem? This is exactly what Nested Windows are
all
about. While you can't move DF1 into the middle of UW2, you can nest
UW1.
This
works because UW1 brings its map with it, and when you access DF1 it knows
to
look up its value in UW1's map.
UserWindows are intended to be the "unit of compilabilty" that can be
nested
inside other UserWindows. It is dangerous to "transplant" anything from
inside
one UserWindow into another at runtime.
(Note that you can't avoid this problem by cloning DF1 because the MapID
gets
copied along with it, and the clone will fail in the same way.)
Further details explained in related technote 12448 'Sudden client
partition
crashes at runtime.'
Technote 12448 Sudden client partition crashes at runtime
Scenario : You have two UserWindows, A and B. When Window A starts up, it
instantiates an instance of B and reparents some component of B into A's
window
hierarchy.
This is not allowed and almost always leads to an error at best or at
worse a
segmentation fault.
Here's why :
When you compile a UserWindow in Forte, each "mapped attribute" (whether a
form
element or menu element) is assigned an internal ID which represents an
offset into
that UserWindow's table of mapped attributes. This offset is only valid
in the
context of the UserWindow in which it was compiled. If you detach a
FieldWidget or
MenuWidget from one compiled Window ("tmpMenu" for example) and then
parent
into another compiled window ("tmpWindow") the internal ID comes with it.
When Forte tries to make use of that copied widget it uses the ID as an
offset
into tmpWindow's table of mapped attributes. But that copied offset is
meaningless in the context of tmpWindow's table, so you get some kind off
error.
In this case it found that the data type of the variable in the slot
wasn't
what
was expected. But you might even index off the end of the table and get a
segmentation fault.
There is nothing to prevent you from dynamically creating menu items and
adding
them to a window at runtime; that will work fine. Although of course you
can't
access them via mapped attributes, since those can only be created at
compile time.
But you are not allowed to reparent a widget from one compiled UserWindow
into
the hierarchy of another.
More information may be found in technote 11225 'Don't reparent mapped
Widgets
between UserWindows at runtime'.
Possible errorstacks seen at runtime instead of a complete crash or
segmentation
violation while you are illegally reparenting a widget or menuitem between
windows
at runtime:
Map::SetSubjectData: Invalid conversion from map type 0 to subject type 22
SYSTEM ERROR: Bad parameter at location 3 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 3
Error Time: Wed Aug 09 13:03:57
Exception occurred (locally) on partition "testproject_CL0_Client",
(partitionId = D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd,
taskId =
[D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd.68]) in application
"FTLaunch_cl0", pid 672 on node ONEWAY in environment Audi3M2Env.
At 13:14 26.09.00 -0400, Adamek, Zenon wrote:
Hi,
It is the unfixed defect 53398. Please contact Forte support.
Zenon
-----Original Message-----
From: Brenda Cumming [SMTP:brenda_cummingtranscanada.com]
Sent: Tuesday, September 26, 2000 1:15 PM
To: Forte User group
Subject: (forte-users) 3J=>3M new to me error
Hi,
We are in the process of going from 3J1 to 3.0.M.2, and I am getting
this error that I am unfamiliar with on a GUI that works fine in 3J.
It
does not happen all the time, and I have been unable to establish the
pattern that kicks it off. Has anyone seen this before?
PS- this error is not occurring in the deployed (non-compiled) app,but
when I am running locally from my workspace.
SYSTEM ERROR: Bad parameter at location 6 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 6
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2,
taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Can't find scope 20070 for a class.
Class: qqsp_Exception
Error #: [201, 11]
Detected at: qqlo_ClassTableLoadScope at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to prevent the application from attempting to write to the repository.
The repository and work you have saved to the repository are safe. If
your
workspace contains unsaved work, you may use the following procedure
to save this work. First, export the changed components. Then, shut down and
restart this application and reopen this workspace in read-write mode.
Finally, import the changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::IsDistributed
Last TOOL statement: method PPMeasWin.
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Internal Error attempting to deserialize element
(64,120684) (fetch bitmask is 0x20). Your workspace is now read-onlyto
prevent
the application from attempting to write to the repository. The
repository
and work you have saved to the repository are safe. If your workspace
contains unsaved work, you may use the following procedure to savethis
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Recursive Deserialization attempted, Internal Error!
Class: qqsp_UsageException with ReasonCode: SP_ER_INVALIDSTATE
Error #: [301, 231]
Detected at: qqsp_DeSerializeDriver::Run at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in anew
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 -
Re: (forte-users) Accessing Technote 10398
Ketie,
let's see, I have been using FORTE since November of
1994. since the beginning those flags have been common
knowledge within the FORTE community and widely
disseminated.
the FORTE flags have been invaluable to me and HAVE
NEVER caused any downtime. sure, there are a few
wildcards in there that can cause trouble, but to
throw out the baby with the bathwater is ridiculous.
what would life be without trc:lo:25? to trace
exceptions.
or trc:os:1:1 and trc:os:5:5 to tune memory
consumption?
Should i have to call a consultant or FORTE tech
support to do the deep dive on exceptions or tune my
applications? I think not.
Overreaction? No.
Mark.
--- Katie Tierney <katiethetierneys.com> wrote:
I think y'all are overreacting. There are log flags
that are detailed in
Technote 10398 that can cause serious implications
if used improperly. I
think Forte/Sun just wants to make sure that people
don't make mistakes that
cost them valuable time.
As a Forte Consultant for many years, I have seen a
good number of people
misuse information that was not completely
understood. In some cases, this
caused excessive downtime for production
applications. The only time I ever
saw Technote 10398 being provided to a customer was
when they were utilizing
Forte Consulting, or when a Technical Support
Engineer was heavily involved.
I was extremely surprised to learn that it was
available to non-employees via
the website - that sounds as if someone may have
inadvertantly marked it as
customer-viewable (incorrectly, obviously) in Sun's
internal systems.
Again, I think you're overreacting. I am sure that
this isn't a case of Sun
thinking anyone is "stupid." It's a matter of
providing the support that
people need to properly utilize the tools available.
-Katie
mark joyce wrote:
read: Sometimes, the technotes are markedunviewable
to customers because they might need further
explanation. Let me know if you need to log acase.
in other words, you are TOO STUPID to use FORTElogger
flags, although they have been widely distributedand
used for years by FORTE users.
i can't believe it either. i don't know what iwould
have done for the last 5 years without using theFORTE
flags. such a wealth of good output!
what an excuse! "they might need furtherexplanation"
.. if i had to log every problem with FORTE,instead
of resolving them myself through the information
obtained by using flags, i would have lost my joba
long time ago.
mark.
--- Jeff Bennett <jeff_bennettsehamerica.com>wrote:
I thought it might be prudent to share with youthe
response I received from Sun
regarding the inability to access technote 10398
(Forté logger flags). I was
able to access it 3+ weeks ago, and fortunatelykept
a hard-copy. But, how are
we supposed to do our job effectively and
expediently if we do not have
(complete) access to this resource?
I thought the technotes were completely open tothe
Forté development
community.... wrong.
-jeff
---------------------- Forwarded by JeffBennett/SEH
on 09/11/2000 09:02 AM
Forte Support <supportforte.com> on 09/08/2000
10:05:17 AM
To: Jeff Bennett/SEHsehamerica.com
cc:
Subject: Re: Accessing Technote 10398
Fax to:
Hello Jeff,
Were you at one point able to access thistechnote?
You know why -- it's
because this technote is marked for employeeviewing
only and not available
for customer viewing. If you need further
assistance or need to look at
this technote, what you would need to do is loga
call with us and then a
tech support specialist will give you a callback.
Sometimes, the
technotes are marked unviewable to customersbecause
they might need
further explanation. Let me know if you need tolog
a case.
Thanks!
At 09:57 AM 9/8/00 -0700, you wrote:
I am no longer able to access technote 10398
(forte
logger flags)... why?
-jeff~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Sun® microsystems
Jeannie Lee
Phone: (510) 451-5400
Fax (510) 869-2010
Email: jeannie.leesun.com
Forte Tools Response Coordinator
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
http://mail.yahoo.com/
For the archives, go to:
http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. Tounsubscribe, send in a new
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
http://mail.yahoo.com/Ketie,
let's see, I have been using FORTE since November of
1994. since the beginning those flags have been common
knowledge within the FORTE community and widely
disseminated.
the FORTE flags have been invaluable to me and HAVE
NEVER caused any downtime. sure, there are a few
wildcards in there that can cause trouble, but to
throw out the baby with the bathwater is ridiculous.
what would life be without trc:lo:25? to trace
exceptions.
or trc:os:1:1 and trc:os:5:5 to tune memory
consumption?
Should i have to call a consultant or FORTE tech
support to do the deep dive on exceptions or tune my
applications? I think not.
Overreaction? No.
Mark.
--- Katie Tierney <katiethetierneys.com> wrote:
I think y'all are overreacting. There are log flags
that are detailed in
Technote 10398 that can cause serious implications
if used improperly. I
think Forte/Sun just wants to make sure that people
don't make mistakes that
cost them valuable time.
As a Forte Consultant for many years, I have seen a
good number of people
misuse information that was not completely
understood. In some cases, this
caused excessive downtime for production
applications. The only time I ever
saw Technote 10398 being provided to a customer was
when they were utilizing
Forte Consulting, or when a Technical Support
Engineer was heavily involved.
I was extremely surprised to learn that it was
available to non-employees via
the website - that sounds as if someone may have
inadvertantly marked it as
customer-viewable (incorrectly, obviously) in Sun's
internal systems.
Again, I think you're overreacting. I am sure that
this isn't a case of Sun
thinking anyone is "stupid." It's a matter of
providing the support that
people need to properly utilize the tools available.
-Katie
mark joyce wrote:
read: Sometimes, the technotes are markedunviewable
to customers because they might need further
explanation. Let me know if you need to log acase.
in other words, you are TOO STUPID to use FORTElogger
flags, although they have been widely distributedand
used for years by FORTE users.
i can't believe it either. i don't know what iwould
have done for the last 5 years without using theFORTE
flags. such a wealth of good output!
what an excuse! "they might need furtherexplanation"
.. if i had to log every problem with FORTE,instead
of resolving them myself through the information
obtained by using flags, i would have lost my joba
long time ago.
mark.
--- Jeff Bennett <jeff_bennettsehamerica.com>wrote:
I thought it might be prudent to share with youthe
response I received from Sun
regarding the inability to access technote 10398
(Forté logger flags). I was
able to access it 3+ weeks ago, and fortunatelykept
a hard-copy. But, how are
we supposed to do our job effectively and
expediently if we do not have
(complete) access to this resource?
I thought the technotes were completely open tothe
Forté development
community.... wrong.
-jeff
---------------------- Forwarded by JeffBennett/SEH
on 09/11/2000 09:02 AM
Forte Support <supportforte.com> on 09/08/2000
10:05:17 AM
To: Jeff Bennett/SEHsehamerica.com
cc:
Subject: Re: Accessing Technote 10398
Fax to:
Hello Jeff,
Were you at one point able to access thistechnote?
You know why -- it's
because this technote is marked for employeeviewing
only and not available
for customer viewing. If you need further
assistance or need to look at
this technote, what you would need to do is loga
call with us and then a
tech support specialist will give you a callback.
Sometimes, the
technotes are marked unviewable to customersbecause
they might need
further explanation. Let me know if you need tolog
a case.
Thanks!
At 09:57 AM 9/8/00 -0700, you wrote:
I am no longer able to access technote 10398
(forte
logger flags)... why?
-jeff~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Sun® microsystems
Jeannie Lee
Phone: (510) 451-5400
Fax (510) 869-2010
Email: jeannie.leesun.com
Forte Tools Response Coordinator
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
http://mail.yahoo.com/
For the archives, go to:
http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. Tounsubscribe, send in a new
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
http://mail.yahoo.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) Forte ADE
In addition to this confusion, I'd like to see some statement by Forte to
indicate
WHEN the next Forte R4 is scheduled (before the Sun era is was said to be
Summer 2000) and
WHAT exactly it will contain (major headings will do).
With the cancellation of the Forte Forum event doubt and uncertainty are
spreading in the
Forte communities that I talk with and no one seems to counterbalance these
doubts with an
official statement. How serious does Sun take TOOL Forte for the coming few
years? Release
of Fusion V2 seems to say "serious". The deafning silence with regard to R4
indicates the
opposite. And the users are divided (as always).
Theo de Klerk
Architecture & Application Integration
Professional Services
Compaq Computer Corp. - the Netherlands
-----Original Message-----
From: Rottier, Pascal [mailto:Rottier.Pascalpmintl.ch]
Sent: Tuesday, 18 April, 2000 17:49
To: 'kamranaminyahoo.com'
Subject: (forte-users) Forte ADE
A long, long time ago
In a galaxy far away....
I saw a demonstration of Forte's new Application Development
Environment,
which was more userfriendly than the current one. It also looked more
similar to the interface of the other development tools out
there, with a
tree structure and capabilities to browse through the
inheritance tree, and
not opening a new window for every project, class and method that is
accessed.
This new interface was supposed to be included in Forte 4, which would
combine TOOL and Java and would be released soon.
Since then, we've seen SynerJ and now FJEE, but Forte 4 is still not
released. And when it will be released, it still won't
support TOOL and Java
simultaneously. That's OK. I understand that.
But now I've heard that this improved ADE won't even be
included in Forte 4.
Is this true? And if so, why?
Pascal
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe,
send in a new
email the word: 'Unsubscribe' to:
forte-users-requestlists.xpedior.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
Maybe you are looking for
-
Rather that putting or getting files from the server, how do I delete them off of the server? I've been clicking on a file, then right clicking and selecting delete, but does this actually remove the file off of the server? I've perused the internet
-
How do I lock some form fields, but not all?
How do I create a form with interactive form fields where certain fields can be locked after being filled in, and others remain unlocked so the customer can interact with it? My workflow looks like this: I created a PDF with open form fields for my c
-
How do I view ical in spanish?
Since I updated to Mountain Lion OSX I view iCal one part in Spanish (Upper bar) and the other part in English (the name of the months, weekdays, date formats). Same thing happens with Contactos (AddressBook). How can I unify everything in only one l
-
Sybase oracle heterogeneous connection
Hi all, I created a connection from oracle to sybase using oracle heterogeneous connection. However I have a problem with numeric characters, I cannot get floating parts of numbers. when I use create as syntax it maps to correct data types(with the c
-
Sapscript, turn the window
Hallo, I have an sapscript, where the pages are in landscape format. In the last page, I want to display the address of the business partner on the back side of the paper, but it must be shown from up to down and not from left to the rigth, because i