Forte NodeMgr...
Forte Users,
I was using Forte when my disk crashed ( someone steped on the
cable!) , but after that ( rebooting the machine to re-mount the disk ), I
just cant get the NodeMgr running. It always times out the attempt to
connect to the repository.
Fast help is appreciated!
Thanks,
C. M. Motta
This may help -worth a try
- make sure the node manager process is truly "dead" by issuing the kill
command if it isn't
- make sure the repository process is truly "dead" and not running by
issuing the kill command if it is still "up"
- make sure you have no ftexec processes running for this
nodemanager/repository
- make sure your environment settings are set
(like setenv FORTE_REPOSNAME CentralRepository
setenv FORTE_ENVNAME CentralEnv, etc.)
- now issue the start_nodemgr -e <node manager name> command
- issue the start_repos -fr ob:central -n CentralRepository (the names
will vary for your repos names)
May or may not help or you may have already tried it - worth a shot.
Regards,
Peggy Adrian Eli Lilly & Co. [email protected]
Similar Messages
-
RE : Multiple environments on NT
Hello Veronika,
I have just tested on NT4 a multiple configuration with 2 environments
On one user session NT : it works very well.
I also use multi-version (R2 and R3) on the same PC.
I use the next command :
"C:\forteR3\install\bin\nodemgr.exe -e TstEnv1 -fnd Node1 -fns
HOSTNAME:5000" for the first environment
"C:\forteR3\install\bin\nodemgr.exe -e TstEnv2 -fnd Node2 -fns
HOSTNAME:5010" for the second one
I don't need any re-installation of Forte only one FORTE_ROOT.
You should be able to to the same with NT services using the
srvcinst.exe
utility on FORTE_ROOT/install/bin.
Hope this helps.
Daniel Nguyen.
Freelance Forte Consultant.Dan,
The problem you are describing with the system agents and partitions not
being visible sounds like a problem with how you are starting the
partitions. In configurations such as these, you need to specify which
node manager the partition is being started under. This is done
automatically when you start an application from the environment, but from
the command line, you should use something like:
ftexec -fi ... -fnd node_name -ftsvr 0 .....
Don
At 09:46 AM 1/13/98 +0100, Daniel Nguyen wrote:
Hello Ray,
You are right : I didn't explain enough.
The aim is to define different context for each environment.
One solution is to make (just as on Unix) a command file (.bat) to
define Forte environment variable and to use it in other command files
to start an environment for instance. This is very usefull for testing
but I think that it is difficult to manage. The other solution is to
define a specific account on NT for each context redefining in the
registry the FortesoftwareInc entries for each account (especially
FORTE_NS_ADDRESS).
These are two ways to obtain the same result, but using the registry
I only use one system referential and I don't have to redefine each
Forte command which has to become a service.
For the second part, I start my partitions using ftexec -fi command
(with -ftsvr option for server partition).
It seems that Forte nodemgr reuses the environment variables of
the context of the process and not the options you used and
in that case the System Agents aren't well refreshed. The nodes are
visible, but the processes on the nodes you start by hand aren't
visible. I have the same problem with Repository agent on multiple
environments on Aix : some agents , may be, aren't well instanciated.
On Aix, I used standard solution : defining specific user and specific
fortedef.sh for each environment.
Happy new year.
Daniel Nguyen.
Freelance Forte Consultant
Ray(mond) Blum wrote:
Daniel Nguyen wrote:
Hello,
After discussing about it with Forte and making new tests,
beware on the solution you choose :
if you use the same login for your services, you will have some
problems to start your applications. You need to use different
logins(NT accounts) for earch nodemgr.Ummm.... I do not think that this is right. We have had (under Forte
R2) several nodemgrs on one machine and (under R3) several launch
servers all started from the same NT (4.0) login. All they needed to
differentiate themselves was different environments.
If you don't, Forte wont start your application properly.
Then if you start your partitions by hand (using DOS),
the application starts well, but the Forte agents don't
see the application partitions (even ftexec processes).
What do you mean by the above? Forte System agents? Our client
machines described above have always been visible in EConsole/EScript.
Hope this helps.
Daniel Nguyen
Freelance Forte Consultant.--
---Raymond Blum
[Yet Another Forte Consultant]
Hurry Star Force!
Planet Earth has just 164 days left!!!
Name: vcard.vcf
Part 1.2 Type: text/x-vcard
Encoding: 7bit
Description: Card for Raymond Blum
============================================
Don Nelson
Regional Consulting Manager - Rocky Mountain Region
Forte Software, Inc.
Denver, CO
Phone: 303-265-7709
Corporate voice mail: 510-986-3810
aka: [email protected]
============================================
"We tigers prefer to inflict excitement on others." - Hobbes -
Bus error in the Forte executable
Hi,
We have an environment with forte' (ver. 3.0.G.2) running
on AIX 4.1 (The name of central server is cld_app1 and the nodemgr start
with the name cld_TDR). In our environment we are using two differnet
repository. In rep1 we have a very simple project (called 'aaa') that
use one small class with two methods. One method print the date & time.
The second method communicate with a serviceobject that use MQSeries to
put/get some messages in the queues.
The project work correctly in test run and in distribuite mode.
If we export the same project (aaa) and we import in other repository
(rep2 in the same environment) the project doesn't work. Infact,
during test run forte' return the following:
Begin Stack Backtrace
=========================================================
=
Trace caused by a bus error in the Forte executable:
ftexec Version 3.0.G.2
IBM RS6000/Aix 4.1
Forte Application Environment (tm), Forte Runtime Environment (tm),
Forte Conductor (tm):
Copyright (c) 1994-1998, Forte Software, Inc. and its licensors.
US Patent No. 5,457,797
Forte Express (tm), Forte WebEnterprise (tm):
Copyright (c) 1995-1998, Forte Software, Inc.
All Rights Reserved.
Unpublished rights reserved under the copyright laws of the United
States.
Fri Mar 13 16:07:45 1998
Fault at 25-Mar-1999 10:42:53, pid '2292', node 'cld_app1':
0xd0b8886c = d0b8886c()
0xd0b88ae4 = d0b88ae4()
qqos_StkTrc: Cannot print stack trace.
Recursive stack trace detected. Exiting.
If we try to run in partitioning mode, the same error appears when
forte' "loading partition into server" with the following adding
message:
Unable to start the partition aaa_cl0_Part1 on any of nodes to wich
been assigned. See the remainder of the error stack for more
information.
In the "more" informations we have the following:
SYSTEM ERROR: Unable to start the partition aaa_cl0_Part1 on any of the
nodes to which it has been assigned. See the remainder of the error
stack for more
information.
Class: qqsp_ResourceException
Error #: [1602, 593]
Detected at: qqcf_StandardConfig::LoadRemotePartition at 5
Last TOOL statement: method overview.StartApplication
Error Time: Thu Mar 25 09:22:21
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
SYSTEM ERROR: Unable to start partition aaa_cl0_Part1 on node cld_TDR.
Class: qqsp_ErrorDescriptor
Error #: [1602, 592]
Detected at: qqcf_StandardConfig::LoadRemotePartition at 3
Error Time: Thu Mar 25 09:22:21
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
SYSTEM ERROR: Lost contact with remote server while trying to load
partition
aaa_cl0_Part1. Check server log file for more information about the
specific
problem.
Class: qqsp_ResourceException
Error #: [1301, 102]
Detected at: qqem_IPartitionAgent::Startup at 5
Error Time: Thu Mar 25 09:22:21
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
INFORMATION: The connection to the partner was terminated by the
Communication
Manager for the reasons below.
Class: qqsp_DistAccessException
Detected at: qqdo_PartitionMgr::StopLocation at 1
Error Time: Thu Mar 25 09:22:20
Distributed method called: qqrt_ForteExecAgentProxy.LoadPartition!6
(object name Unnamed) from partition "Forte_Executor",
(partitionId =
546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158.19]) in application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
INFORMATION: Network partner closed connection. This usually means the
process at the other end of the wire failed. Please go look there and
find
out why.
Class: qqsp_DistAccessException
Detected at: qqcm_HoseFSM::ReceivedClose at 2
Error Time: Thu Mar 25 09:22:20
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
INFORMATION: Error parameters for Set:0 Msg:0:
Class: qqsp_DistAccessException
Detected at: qqcm_HoseFSM::ReceivedClose at 1
Error Time: Thu Mar 25 09:22:20
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
Thanks in advance
Luz Marina e Massimiliano
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/>Hi,
We have an environment with forte' (ver. 3.0.G.2) running
on AIX 4.1 (The name of central server is cld_app1 and the nodemgr start
with the name cld_TDR). In our environment we are using two differnet
repository. In rep1 we have a very simple project (called 'aaa') that
use one small class with two methods. One method print the date & time.
The second method communicate with a serviceobject that use MQSeries to
put/get some messages in the queues.
The project work correctly in test run and in distribuite mode.
If we export the same project (aaa) and we import in other repository
(rep2 in the same environment) the project doesn't work. Infact,
during test run forte' return the following:
Begin Stack Backtrace
=========================================================
=
Trace caused by a bus error in the Forte executable:
ftexec Version 3.0.G.2
IBM RS6000/Aix 4.1
Forte Application Environment (tm), Forte Runtime Environment (tm),
Forte Conductor (tm):
Copyright (c) 1994-1998, Forte Software, Inc. and its licensors.
US Patent No. 5,457,797
Forte Express (tm), Forte WebEnterprise (tm):
Copyright (c) 1995-1998, Forte Software, Inc.
All Rights Reserved.
Unpublished rights reserved under the copyright laws of the United
States.
Fri Mar 13 16:07:45 1998
Fault at 25-Mar-1999 10:42:53, pid '2292', node 'cld_app1':
0xd0b8886c = d0b8886c()
0xd0b88ae4 = d0b88ae4()
qqos_StkTrc: Cannot print stack trace.
Recursive stack trace detected. Exiting.
If we try to run in partitioning mode, the same error appears when
forte' "loading partition into server" with the following adding
message:
Unable to start the partition aaa_cl0_Part1 on any of nodes to wich
been assigned. See the remainder of the error stack for more
information.
In the "more" informations we have the following:
SYSTEM ERROR: Unable to start the partition aaa_cl0_Part1 on any of the
nodes to which it has been assigned. See the remainder of the error
stack for more
information.
Class: qqsp_ResourceException
Error #: [1602, 593]
Detected at: qqcf_StandardConfig::LoadRemotePartition at 5
Last TOOL statement: method overview.StartApplication
Error Time: Thu Mar 25 09:22:21
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
SYSTEM ERROR: Unable to start partition aaa_cl0_Part1 on node cld_TDR.
Class: qqsp_ErrorDescriptor
Error #: [1602, 592]
Detected at: qqcf_StandardConfig::LoadRemotePartition at 3
Error Time: Thu Mar 25 09:22:21
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
SYSTEM ERROR: Lost contact with remote server while trying to load
partition
aaa_cl0_Part1. Check server log file for more information about the
specific
problem.
Class: qqsp_ResourceException
Error #: [1301, 102]
Detected at: qqem_IPartitionAgent::Startup at 5
Error Time: Thu Mar 25 09:22:21
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
INFORMATION: The connection to the partner was terminated by the
Communication
Manager for the reasons below.
Class: qqsp_DistAccessException
Detected at: qqdo_PartitionMgr::StopLocation at 1
Error Time: Thu Mar 25 09:22:20
Distributed method called: qqrt_ForteExecAgentProxy.LoadPartition!6
(object name Unnamed) from partition "Forte_Executor",
(partitionId =
546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158.19]) in application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
INFORMATION: Network partner closed connection. This usually means the
process at the other end of the wire failed. Please go look there and
find
out why.
Class: qqsp_DistAccessException
Detected at: qqcm_HoseFSM::ReceivedClose at 2
Error Time: Thu Mar 25 09:22:20
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
INFORMATION: Error parameters for Set:0 Msg:0:
Class: qqsp_DistAccessException
Detected at: qqcm_HoseFSM::ReceivedClose at 1
Error Time: Thu Mar 25 09:22:20
Exception occurred (locally) on partition "Forte_cl0_Client",
(partitionId
= 546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1, taskId =
[546BCA70-E125-11D2-BFFF-B37364EDAA77:0x158:0x1.17]) in
application
"Forte_cl0", pid 20236 on node cld_app1 in environment
Collaudo_TDR.
Thanks in advance
Luz Marina e Massimiliano
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/> -
Re: (forte-users) Unstable server ENV after upgrade to Forte30M2.
I see/suggest a few things:
1) In your #1, you mention ".... development and test environments which use the
same Forte 3M installs through links ...". This concerns me. On our UNIX box
each environment has it's own directory containing it's own install. If your
environments are some how sharing a node manager, log directory or processes (to
name a few things) that is a recipe for disaster. They may be competing for
resources and usually the first one started will win.
2) I haven't done a lot with compatibility levels, but if an application built
in dev is to run in test it may be important that node managers and services
(autocompile, codegen etc.) be at the same level (????).
3) Check the definition files, to make sure the two environments operate
independently. If they are both trying to write to the same log file the one
started up first will work while the second will not as the file will be "busy".
4) We usually use rpcreate (newer version) to create brand new repositories.
Than we export/import the source code that we need. Also it is important to
force compile ALL plans in a workspace at least once after doing the import.
This will ensure that all of the code is "speaking the same language". The other
compile, only compiles those pieces of code that changed from the last compile.
Hope this helps.
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!
"Braja Chattaraj" <forte_brajachotmail.com> on 09/13/2000 03:43:57 PM
Please respond to chattaraj_braja_NONLILLYlilly.com
To: forte-userslists.xpedior.com
cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
Subject: (forte-users) Unstable server ENV after upgrade to Forte 30M2.
We are running Forte 3M2 clients and server in our test environment with
clients on NT and server on Solaris 2.6. Eversince the upgrade from 3L to 3M
we have been having an unstable environment that does not remain alive for >
10 mins. These are the details of the Forte installs and server setups :
1. The server hosts the development and test environments which use the same
Forte 3M installs through links (same ftcmd, ftexec, nodemgr, etc.). The
environments are at compatibility levels 0 and 1 respectively.
2. The two environments have the same definition files (defining the ENV
variables), though seperate copies and the two environments are hosted on
different ports on the same server.
3. While building the new 3M environmnets in DEV and TST, we exported the
old 3L repositories and imported them into the new 3M repositories and
deployed the applications.
While the DEV environment is stable the TST environment is not. This has
been observed while moving plans between the environments (export and
import) using fscript commands, deploying the apps after the move using
fscript, and testing the apps. Sometimes it has come down right after a
startup. There is no programatic reference to the environment agent in the
code. So, a programatic shutdown is ruled out.
Does anybody have a clue or a similar experience ?
Thanks.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BRAJA KISHORE CHATTARAJ
Consultant, Analysts International.
Work : Sphinx Pharmaceuticals (A division of Eli Lilly & Co.)
(919) 314-4134
Home : 1801, Williamsburg Rd., #41H, Durham, NC 27707.
(919) 463-7802
E-mail : forte_brajachotmail.com
Visit us www.analysts.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://profiles.msn.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.comWe found a solution to our issue.Their desktops were in a lockdown environment and the essbase.id file located in the windows directory was locked as well. This file is responsible for assigning ports etc and it couldn't be updated for the 6.5.4p2 upgrade. Once the file was deleted and the user reconnected to Essbase, the essbase.id was reset and they could connect.
-
Unstable server ENV after upgrade to Forte 30M2.
We are running Forte 3M2 clients and server in our test environment with
clients on NT and server on Solaris 2.6. Eversince the upgrade from 3L to 3M
we have been having an unstable environment that does not remain alive for >
10 mins. These are the details of the Forte installs and server setups :
1. The server hosts the development and test environments which use the same
Forte 3M installs through links (same ftcmd, ftexec, nodemgr, etc.). The
environments are at compatibility levels 0 and 1 respectively.
2. The two environments have the same definition files (defining the ENV
variables), though seperate copies and the two environments are hosted on
different ports on the same server.
3. While building the new 3M environmnets in DEV and TST, we exported the
old 3L repositories and imported them into the new 3M repositories and
deployed the applications.
While the DEV environment is stable the TST environment is not. This has
been observed while moving plans between the environments (export and
import) using fscript commands, deploying the apps after the move using
fscript, and testing the apps. Sometimes it has come down right after a
startup. There is no programatic reference to the environment agent in the
code. So, a programatic shutdown is ruled out.
Does anybody have a clue or a similar experience ?
Thanks.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BRAJA KISHORE CHATTARAJ
Consultant, Analysts International.
Work : Sphinx Pharmaceuticals (A division of Eli Lilly & Co.)
(919) 314-4134
Home : 1801, Williamsburg Rd., #41H, Durham, NC 27707.
(919) 463-7802
E-mail : forte_brajachotmail.com
Visit us www.analysts.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Hi Michael,
thanks for your reply. Sorry I forgot to mention that our application server is running on windows 2003 server. Our variable and the corresponding value is uppercase. It is not the name of our reports server. For the test I used a hard coded reports server name. The same reports server name is also included in the call to web.show_document whitch worked fine.
I also tried to read other variables defined in .env file. The only variable I could read was 'FORMS_PATH' which is defined in our application specific .env files. But the value I got had nothing in common with the value defined in these files ???
regards gisela. -
RE: (forte-users) Phantom Nodes
Yes both the client and server have to have the same setting and it does not
work all the time.
-----Original Message-----
From: Samer Kanjo [mailto:[email protected]]
Sent: Thursday, May 10, 2001 11:33 PM
To: Amin, Kamran; Forte Users
Subject: RE: (forte-users) Phantom Nodes
Kamran,
Just so I am clear on the use of keep alive settings,
the settings are required on both the server and the
client, correct? If so then should the settings on
both client and server nodes be equal?
Again to be clear, are you saying that the keep alive
settings alone will prevent phantom nodes?
Kelsey & Pascal, do you still have the problem even
though you are using keep alive settings?
Samer Kanjo
--- "Amin, Kamran" <[email protected]> wrote:
The socket time is an OS level setting and is
different on each OS. I had
open up a ticket with Forte 2 years ago and the only
quick solution was to
change the name of the client computer which faked
Forte into thinking its a
different node. This way the client was able to get
back into their
application quickly. The only problem was that the
clients had to reboot
their computer. The other way to prevent this was
to use the keep alive
settings to force a clean up on the Forte central
environment side.
ka
-----Original Message-----
From: Samer Kanjo [mailto:[email protected]]
Sent: Thursday, May 10, 2001 6:26 PM
To: [email protected]; Forte Users
Subject: RE: (forte-users) Phantom Nodes
Kelsey,
We use model nodes exclusively. Occasionally, a
client
node would crash and would be inaccessbile for two
hours but would still appear active under the model
node. After two hours the client could access the
environment again. My only option thus far has been
to
bounce the environment but that can only be done
after
work hours, which may not be convenient for the
affected user.
Kamran Amin just wrote me to say that the two hour
delay is the result of the default socket timeout
setting on UNIX boxes. Perhaps reducing the socket
timeout from two hours to something more reasonable
would fix the problem without manipulating the
environment configuration.
I am not sure how I would determine a good socket
timeout setting for my application. Does anyone have
any ideas? Is my assumption about reducing the
socket
timeout to avoid manipulating the environment
configuration to remove the phantom nodes in a more
timely fashion correct?
Samer Kanjo
--- [email protected] wrote:
"... have you reported this to Forte as a bug or
looked through the defect
reports?..."
No and No. I just kind of "stumbled" upon this
solution this week. I just
opened the properties windows when it just all ofa
suddened dawned on me:
"Maybe, if none of the boxes are checked then the
node effectively serves
no usefull purpose in the environment. Therefore,
maybe Forte will be more
apt to release it - like the garbage collectordoes
with an object that is
not referenced".
" ... Have you tried this technique when usingmodel
nodes? ..."
No I haven't. So far our model nodes have beenwell
behaved. If a member
was online the node was online, otherwise, if "no
one was home" then it was
off-line. Model nodes aren't real nodes; I viewthem
as a sort of virtual
node. Only real nodes have ocassionally behaved
goofy. I think what happens
is either the user's machine is improperlyshutdown
or they just all of
sudden loose connection to the network. Exception
handling was never Forte
ADE's forte.
Kelsey Petrychyn, P. Eng. SaskTel TechnicalAnalyst
ITM - Technology Solutions - Distributed Computing
Tel (306) 777 - 4906, Fax (306) 359 - 0857
Internet:[email protected]
Quality is not job 1. It is the only job!
Samer Kanjo
<skanjo@yahoo To:
"Forte Users" <[email protected]>
.com> cc:
Subject:
RE: (forte-users) Phantom Nodes
05/10/2001
01:57 PM
Pascal,
This is very inetresting. I have experienced the
same
problem and have noted the mysterious two hourdelay
in getting the client node back up and running. I
thought it may have had something to do with the
keepalive settings, which seem to work otherwise.
Kelsey, have you reported this to Forte as a bugor
looked through the defect reports? Have you tried
this
technique when using model nodes? I will give your
fix
of reconfiguring the node a try the next time I
encounter the problem. However, I use model nodesso
perhaps it may not have the same effect.
Samer Kanjo
--- "Rottier, Pascal" <[email protected]>
wrote:
I've seen this problem many times myself and the
cause was always the same.
The nodemanager of the phantom node was notproperly
shutdown. Usually,
because this node was running on NT and somebody
simply shutdown the
machine. A "kill -9" on unix will also have thesame
effect.
Part of the shutdown process of a node, which
you
should always invoke from
e-console or e-script, is to inform theenvironment
that it's going away.
Then Forte will mark it as offline, rather then
online. However, it the
nodemgr suddenly dies, there is no such signal.
=== message truncated ===Therefore, how to remotely start a node manager ? :-p
j-p
-----Message d'origine-----
De: John Parks [mailto:jparkss1.com]
Date: vendredi 15 septembre 2000 20:07
À: Jean-Paul.Gabriellisema.fr
Cc: 'Forte Users'
Objet: Re: (forte-users) [Model Nodes] What prevents Server Parts to be
assigned there ?!:?
Jean-Paul,
The ModelNode is a client node by definiton, no matter what properties you
change. I've previously asked for an enhancement to allow a
model node to be a
server node, but I don't expect much to happen. To install
server applications
to several nodes, you have to make sure that the node manager on
each node is
active. There really is no built-in support for distributing
applications in
mass to servers like there is for clients (using the model node feature).
Regards,
John Parks
S1 Corporation
Jean-Paul Gabrielli wrote:
Hi,
I want to have a separate node to provide a dedicated service,
and therefore when I start my environment server and declared that
node as ModelNode, with 'client' disabled, i still can't assign to it
my server partition.
And if I declare it as regular node, the installation of the application
failed if the node is not online.
What choice do I have ?
What prevents that ModelNode, client disabled, to host serverpartition ?!,
j-paul gabrielli
sema dts
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 -
Forte / Conductor not deploying the Conductor libraries tothe clients
Good day!
We have a Forte 3.0.L.2 (NT) server for development, as well as a 3.0.L.2
(Unix) server for development and one for deployment. The developers code
in the NT environment, then we export the workspace to Unix. Recently we've
added Conductor (1.0.L.1) and WebEnterprise (1.0.D.1). All was working
fine, until I renamed the environment on the Unix development environment.
Previously, when clients pulled deployments, they would receive the
Conductor-related libraries, but now (after the environment name change) the
"wfclient" library no longer comes over with the deployment, as it used to.
I've rebuilt the environment (recreated via nodemgr and rebuilt the node
templates, as well as reinstalling it all back) but this didn't take care of
the problem. Forte states we need to install the Conductor client on the
client machines. However, our other three environments will still deploy
the "wfclient" and other conductor-related libraries to the clients. Do you
have any information on this behavior?
thanks in advance,
Sean BooneHi,
I had the same issue but I just managed to fix it. You must upgrade and/or regenerate you proxy. This creates new classes (possibily in a new package) that you must use in your code. I had this error because the classes directory was not clean after the rebuild and the old classes (in the old package) were still present, so the compilation was successful with the old classes. So clean your classes directories, regenerate your proxy and use the new classes in your code.
Regards,
Sylvain -
Using third party tool to initiate a Forte batchprogram
Hello Forte Users,
Our company has acquired a software product called Maestro. It's a
production scheduling facility that manages tasks for batch mode execution.
We would like to know if anyone out there has had any experience using this
product with Forte. One recommendation that we discussed was to have
Maestro start a script on Escript to communicate to an agent that would
start the batch process at a specified time. Has anyone done something
similar or can offer any suggestions ?
Thanks in advance,
Jean Mercier
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Jean,
We use Maestro for all our scheduling scripts. To start\stop the
environment and start\stop applications. We create a shell script that uses
escript to start/stop applications. Maestro just calls the shell scripts
and monitor it for completion. I think you have to write the shell script
in a standard way to return an error if it does not finish properly. Here
is an example:
#!/bin/csh
source /appls/forte/fortedef.csh
$FORTE_ROOT/install/bin/start_nodemgr -fm "(x:300000)" -e TR2ProdEnv
ps -fu forte | grep -v grep|grep nodemgr>/appls/forte/production/scripts/KBB
set KBB=/appls/forte/production/scripts/KBB
if (-z $KBB) then
exit 1
else
exit 0
endif
Hope this helps.
ka
Kamran Amin
Forte Technical Leader, Core Systems
(203)-459-7362 or 8-204-7362 - Trumbull
[email protected]
From: Jean Mercier[SMTP:[email protected]]
Sent: Monday, April 12, 1999 10:36 AM
To: Forte-Users (E-mail)
Subject: Using third party tool to initiate a Forte batch program
Hello Forte Users,
Our company has acquired a software product called Maestro. It's a
production scheduling facility that manages tasks for batch mode
execution.
We would like to know if anyone out there has had any experience using
this
product with Forte. One recommendation that we discussed was to have
Maestro start a script on Escript to communicate to an agent that would
start the batch process at a specified time. Has anyone done something
similar or can offer any suggestions ?
Thanks in advance,
Jean Mercier
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/> -
RE: (forte-users) FW: central environment hanging
Doug,
We have our repository servers on Windows NT 4.0 (Alpha), however our
environment manager is on the same node as the repository servers, so our
experiences may not fit your case.
We use Windows NT services to start/stop the repository servers and have
defined them to start up as the appropriate Windows NT account so that its
registry is populated properly.
We use the Schedule service via WinAT for our nightly cleanups. We use the
Forte srvcinst.exe utility to shutdown the repository server before running
a batch script to perform the rpclean before starting up the repository
server within the same srvcinst.exe session.
We have never experienced environment console hangs, however this technique
doesn't cope with people leaving repository sessions active overnight as
rpstop -k would.
Sample srvcinst.exe Script
%FORTE_ROOT%\bin\srvcinst.exe
SetName "<Repositoty-Server-Name>"
Stop
Delay 10000
ExecCmd "cmd /c call RPClean_This.bat > RPClean_This.log 2>
RPClean_This_2.log"
Delay 10000
Start
Delay 10000
Exit
Mario Emmi
British Aerospace Australia
-----Original Message-----
From: Wheeler, Douglas CWT-MSP [SMTP:[email protected]]
Sent: Thursday, 23 September 1999 02:40
To: '[email protected]'
Subject: (forte-users) FW: central environment hanging
Our development environment consists of a SUN box as the environment
manager with an NT box acting as the host for all of the repositories.We
have a number of repositories and an NT service set up for each one.Each
night WinAT runs bat files the shutdown each of the rpserver, runrpclean
against each of the repositories, and then starts up each of therpserver.
The problem that we are seeing is the central environment hangs at some
point during this process. The central environment manager process is
still running under UNIX (via checkforte) but you cannot connect via
escript or econsole. In addition there are no log messages indicating
what is causing the environment to hang.
Does anybody have a similar development environment?
Some specific Forte questions:
1. Is it better to bring the repositories down via rpstop or anescript?
2. We are using rpstop -k could this be causing a problem?
3. Should we be bring down the node manager on the NT box also?
Some NT specific questions:
1. We use WinAT with a call to a batch file that calls a batch file the
runs the "rpstop ... -k" and "netsrv "name" \\machine /stop" Thisshould
work, right? Specifically, will the rpserver shut down gracefully?2. For the NT services that are set up for the Forte process should the
"Log On As" property be set to "System Account" or "This Account: forte"?
Thanks,
Doug Wheeler
Voice: (612) 594-2519
BORN Information Services voicemail: (612) 404-4379
[email protected]
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]Hi Douglas,
You experience problems after a nightly refresh of your repositories.
You do not mention this explicitely in your mail, but am I correct in
assuming you also reboot the NT-server? And, am I correct in
assuming the E-script and E-console that won't start, are being
started (or at least, trying to be started) on this same NT-server,
after the reboot?
If that is the case, then there is your problem. You stopped the
repositories correctly, cleaned them and then restarted the computer,
without first stopping the nodemgr correctly. If the same node is
started again, and de nodemgr is started, it is unable to re-attach
to the cental node. First, the central node must understand that
the original node is gone, which it will after a network timeout, which
usually is a TCP/IP timeout of about 1 hour.
Solutions.
1) Wait 1 hour after reboot before attempting any E-script.
2) Before rebooting the machine, use E-script to shutdown the
nodemgr.
3) Use the KEEP_ALIVE settings (see Forte docu), to bring this
timeout back to a few minutes, in stead of 1 hour.
Pascal Rottier
STP - MSS Support & Coordination Group
Philip Morris Europe
e-mail: [email protected]
Phone: +49 (0)89-72472530
+++++++++++++++++++++++++++++++++++
Origin IT-services
Desktop Business Solutions Rotterdam
e-mail: [email protected]
Phone: +31 (0)10-2428100
+++++++++++++++++++++++++++++++++++
/* All generalizations are false! */
-----Original Message-----
From: Wheeler, Douglas CWT-MSP [SMTP:[email protected]]
Sent: Wednesday, September 22, 1999 6:40 PM
To: '[email protected]'
Subject: (forte-users) FW: central environment hanging
Our development environment consists of a SUN box as the environment
manager with an NT box acting as the host for all of the repositories.We
have a number of repositories and an NT service set up for each one.Each
night WinAT runs bat files the shutdown each of the rpserver, runrpclean
against each of the repositories, and then starts up each of therpserver.
The problem that we are seeing is the central environment hangs at some
point during this process. The central environment manager process is
still running under UNIX (via checkforte) but you cannot connect via
escript or econsole. In addition there are no log messages indicating
what is causing the environment to hang.
Does anybody have a similar development environment?
Some specific Forte questions:
1. Is it better to bring the repositories down via rpstop or anescript?
2. We are using rpstop -k could this be causing a problem?
3. Should we be bring down the node manager on the NT box also?
Some NT specific questions:
1. We use WinAT with a call to a batch file that calls a batch file the
runs the "rpstop ... -k" and "netsrv "name" \\machine /stop" Thisshould
work, right? Specifically, will the rpserver shut down gracefully?2. For the NT services that are set up for the Forte process should the
"Log On As" property be set to "System Account" or "This Account: forte"?
Thanks,
Doug Wheeler
Voice: (612) 594-2519
BORN Information Services voicemail: (612) 404-4379
[email protected]
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected] -
Re: Forte Environment on OpenVMS Cluster - doubling up forno reason?
Hi,
I tested Forte on OpenVMS more than one year ago. So, it's only
what I remember and it was on Forte R2. Normally, it should work
exactly as you described if you have one TCP alias for the two nodes.
The test I made (one year ago) prouved that Forte does not
know the active cluster of Digital.
Now I work on RS6000 and we have planned to use HACMP (but the cluster
is not active). We use one TCP alias for the two machines, and the same
socket number. So if Machine 1 fails, HACMP will startup Forte and the
environment on the Machine 2. The application is made to be able to
reconnect
to a new environment (and name server). For the deployment, we should
deploy
only once, because the environment sees only one alias and socket on the
TCP
level. On that Idea, you should try to start the same environement on
the
2 machines with one alias and the same socket. The deployment should be
done
only once, but you should need to load distrib twice. You may need to
deploy
(Appdist directory to have a local load) manually.
I'm really interested on the result if you make the test.
Hope it helps,
Daniel Nguyen
Freelance Forte Consultant
Dirk Haben (Tel +61 (0)3 6230 5300) wrote:
>
G'Day
Anyone out here using Forte on a OpenVMS CLUSTER?
I'm running an environment over a cluster and want to know if I can cut
down on any builds since both nodes use the same directory on the same
disk(s) via the same controller etc.
For a start I don't want Forte to "distribute" the new appdist and userapp
to the clustered node - it's already "there".
If I can cut down on the loading of the app and on the install that would
be good to.
BTW, so far I only replicate a loadbalanced EntityManager part to attach to RDB dbs on the two machines - 5 each node. Same database.
Dirk
[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/>I have found it possible to do "stand-alone" development without a node
manager or environment manager (under both Windows NT 3.51 & 4.0) by:
1) Creating a shadow repository
2) Detaching the shadow repository
3) Running Forte stand-alone against the shadow (switched using Forte
Control Panel)
All application resources must be installed & running local (ODBC connection
to databases, etc...)
-- Greg
=======================
[email protected]
www.sagesoln.com
415.329.7243 x 305
=======================
George,
There are a couple of ways you can do testing on a single PC.
1. If you have NT 3.5.1 or 4.0 on your PC, you can run the
environment manager (nodemgr -e YourEnvName). With an environment
manager running, you can then run Forte Distributed, partition, and
run distributed which will start server partitions on the NT box, etc.
2. If you have Win 3.1 or Win 95, then you cannot run an environment
manager or server partitions, but you can still connect to an ODBC database.
Setting up an ODBC resource manager is very straight-forward. You do some
of the work in the ODBC control panel (ie. mapping a name to a particular
data source such as Access file, flat file, etc.). You then run Forte
Standalone which will automatically use ODBC for any DBSessions or
DBResourceMgr
service objects that need to get created by a run. You don't need to
change your service object to point to an ODBC Resource Mgr, the system
does it automagically.
Hope this helps,
Bobby -
RE: Environment Nodemgr Crashes Unexpectedly
If you didn't install with a fresh repository, I'd suggest it (but that should
give you
a repository problem -just a good idea). Also, did you install 3.G and
not just certain files to upgrade. I assume you did and this is best. Do you
have any more info re:
the platform - is this IBM RS6000 as this message suggests? Have you tried
re-installing? I
assume your environments are compatible with this release?
Good luck.
---------------------- Forwarded by Peggy Lynn Adrian/AM/LLY on 09/16/98 02:52
PM ---------------------------
"Ratcliffe, Walter" <[email protected]> on 09/16/98 02:22:30
PM
Please respond to "Ratcliffe, Walter" <[email protected]>
To: "'[email protected]'" <[email protected]>
cc:
Subject: Environment Nodemgr Crashes Unexpectedly
Hello fellow Forte System Managers,
We have been having unpredictable crashes of the environment
nodemgr ever since we upgraded from Forte 3.F to 3.G. Forte's advice so
far has been to increase FORTE_STACK_SIZE to 150000 . This does not
seem to have helped the situatation. We are fairly sure we are not
running out of memory on the nodemgr, and the nodemgr log has very
little information, typically something like this:
Begin Stack Backtrace
==========================================================
Trace caused by a diagnostic trap in the Forte executable:
nodemgr Version 3.0.G.2
IBM RS6000/Aix 4.1
Forte Application Environment (tm), Forte Runtime Environment (tm),
Forte Conductor (tm):
Copyright (c) 1994-1998, Forte Software, Inc. and its licensors.
US Patent No. 5,457,797
Forte Express (tm), Forte WebEnterprise (tm):
Copyright (c) 1995-1998, Forte Software, Inc.
All Rights Reserved.
Unpublished rights reserved under the copyright laws of the United
States.
Fri Mar 13 16:06:08 1998
Fault at 12-Sep-1998 19:01:30, pid '37084', node 'ratbert':
0xd1ef686c = d1ef686c()
0xd1ef6ae4 = d1ef6ae4()
0xd2735524 = d2735524()
0xd27351c4 = d27351c4()
0xd1eef180 = d1eef180()
0xd273514c = d273514c()
0xd20402bc = d20402bc()
0xd1f17354 = d1f17354()
0xd1ef14e4 = d1ef14e4()
0xd1ef5f5c = d1ef5f5c()
0xd1ef18e4 = d1ef18e4()
0xd1ef61fc = d1ef61fc()
0xd1ef2780 = d1ef2780()
0xd1eefb88 = d1eefb88()
0xd1f56e9c = d1f56e9c()
0xd22c1448 = d22c1448()
0xd22bc0b4 = d22bc0b4()
0xd22bca0c = d22bca0c()
0xd206c570 = d206c570()
0xd2122d30 = d2122d30()
0xd1f504b0 = d1f504b0()
0xd1eee4b8 = d1eee4b8()
0xd1eee710 = d1eee710()
0xd27364e4 = d27364e4()
0x2039353c = 2039353c()
0x20397c08 = 20397c08()
Has anyone seen similar crashes?
Is there a workaround?
Thanks in advance for any help.
Walter H. Ratcliffe
Liberty Mutual Insurance Group
(603) 431-7545 X52797
Walter.Ratcliffe @LibertyMutual.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/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Walter,
Is your client the same version as your server? We have had mysterious
problems in the past when we upgraded the client only. For example, you
upgrade your client to 3.G. but your server is still running 3.F. When we
upgraded our server to the same version as our client the mysterious
problems went away. However, Forte claims that this shouldn't be a problem
and it really shouldn't.
I don't know if this will solve your problem but it is sure worth
looking into.
Regards,
Dominick Perritano
[email protected] on 09/16/98 12:56:20 PM
Please respond to [email protected]
To: [email protected]
cc: (bcc: Dominick Perritano/QAD1)
Subject: RE: Environment Nodemgr Crashes Unexpectedly
If you didn't install with a fresh repository, I'd suggest it (but that
should
give you
a repository problem -just a good idea). Also, did you install 3.G and
not just certain files to upgrade. I assume you did and this is best. Do
you
have any more info re:
the platform - is this IBM RS6000 as this message suggests? Have you tried
re-installing? I
assume your environments are compatible with this release?
Good luck.
---------------------- Forwarded by Peggy Lynn Adrian/AM/LLY on 09/16/98
02:52
PM ---------------------------
"Ratcliffe, Walter" <[email protected]> on 09/16/98
02:22:30
PM
Please respond to "Ratcliffe, Walter" <[email protected]>
To: "'[email protected]'" <[email protected]>
cc:
Subject: Environment Nodemgr Crashes Unexpectedly
Hello fellow Forte System Managers,
We have been having unpredictable crashes of the environment
nodemgr ever since we upgraded from Forte 3.F to 3.G. Forte's advice so
far has been to increase FORTE_STACK_SIZE to 150000 . This does not
seem to have helped the situatation. We are fairly sure we are not
running out of memory on the nodemgr, and the nodemgr log has very
little information, typically something like this:
Begin Stack Backtrace
==========================================================
Trace caused by a diagnostic trap in the Forte executable:
nodemgr Version 3.0.G.2
IBM RS6000/Aix 4.1
Forte Application Environment (tm), Forte Runtime Environment (tm),
Forte Conductor (tm):
Copyright (c) 1994-1998, Forte Software, Inc. and its licensors.
US Patent No. 5,457,797
Forte Express (tm), Forte WebEnterprise (tm):
Copyright (c) 1995-1998, Forte Software, Inc.
All Rights Reserved.
Unpublished rights reserved under the copyright laws of the United
States.
Fri Mar 13 16:06:08 1998
Fault at 12-Sep-1998 19:01:30, pid '37084', node 'ratbert':
0xd1ef686c = d1ef686c()
0xd1ef6ae4 = d1ef6ae4()
0xd2735524 = d2735524()
0xd27351c4 = d27351c4()
0xd1eef180 = d1eef180()
0xd273514c = d273514c()
0xd20402bc = d20402bc()
0xd1f17354 = d1f17354()
0xd1ef14e4 = d1ef14e4()
0xd1ef5f5c = d1ef5f5c()
0xd1ef18e4 = d1ef18e4()
0xd1ef61fc = d1ef61fc()
0xd1ef2780 = d1ef2780()
0xd1eefb88 = d1eefb88()
0xd1f56e9c = d1f56e9c()
0xd22c1448 = d22c1448()
0xd22bc0b4 = d22bc0b4()
0xd22bca0c = d22bca0c()
0xd206c570 = d206c570()
0xd2122d30 = d2122d30()
0xd1f504b0 = d1f504b0()
0xd1eee4b8 = d1eee4b8()
0xd1eee710 = d1eee710()
0xd27364e4 = d27364e4()
0x2039353c = 2039353c()
0x20397c08 = 20397c08()
Has anyone seen similar crashes?
Is there a workaround?
Thanks in advance for any help.
Walter H. Ratcliffe
Liberty Mutual Insurance Group
(603) 431-7545 X52797
Walter.Ratcliffe @LibertyMutual.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/>
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/> -
300 MB to 1.2 GB Forte log file automatically created
General information
===================
-One server: Windows NT 4.0 Server Enterprise Edition (service pack 6a), PC/x86, dual Pentium Pro 200 MHz.
-Five workstations: Windows NT 4.0 Workstation (service pack 6a), PC/x86.
-Forte 4GL 3.0.N.0.
-SQL Server 7.0 (service pack 3), clustered.
-Forte application partitioned into 1 server process (runs on server) and 1 client process (runs on all workstations).
Has anyone seen this?...
Problem description
===================
About once per month, our Forte server partition log file grows to 300+ MB, and then the process crashes. This problem is not reproducible, and I don't yet know if there is any pattern in the sequence of events that leads to the error. All the log files appear to be similar because the traceback shows the same method.
The error started happening after upgrading from Forte 3.0.G.2 to Forte 3.0.N.0.
All of the client and server log files have the string "<unknown>" where the Forte environment name normally is. I believe that nodemgr.exe crashes, and usually it cannot be restarted. When the Forte Environment Manager is manually restarted, a Windows NT "Services" error window appears that says - "Could not start the Forte Environment Manager 3.0.N.0 service on \\SERVERA. Error 1067: The process terminated unexpectedly." Rebooting the server always recovers.
Here is an example of the text extracted from one of the huge Forte log files...
NOTE:
-Some of the text lines may be wrapped (in the actual file, none of the lines are wrapped).
-forte_ex_274.log was 263,119 KB.
-The string "..." means that many lines are not included.
-All hex values, except for addresses, have been changed to "0x00000000".
-Note that "Page:45713 @ 0x02CA4400" is included, but appears to be empty.
********** BEGINNING OF FILE **********
ftexec Forte Version 3.0.N.0
Windows NT
Forte Application Environment (tm), Forte Runtime Environment (tm),
Forte Conductor (tm):
Copyright (c) 1994-2000, Forte Software, Inc. and its licensors.
US Patent No. 5,457,797
Forte Express (tm), Forte WebEnterprise (tm):
Copyright (c) 1994-2000, Forte Software, Inc.
All Rights Reserved.
Unpublished rights reserved under the copyright laws of the United States.
Wed Oct 11 21:52:48 2000
Process ID 274
Attached to manager for node SERVERA.
Loading partition IBIS_cl0_Part1 built on 23-Aug-2001 07:10:49.
aud Sun Aug 26 05:45:17 : Loading partition IBIS_cl0_Part1 built on 23-Aug-2001
07:10:49.
Attached to manager for node SERVERA.
! Interpreter Traceback
Traceback:
IbisCommunicationHandler.ReadSocket at offset 268
# Page 45713 contains Object 0x02CA4408 that has bad SIZE(0)
# Scanning for value in range 0x2ca4400:0x2ca4410
# Found 0x2ca4408 at qqin_ActivationRecord+0x28(0x2ca3bb8)
! Page:45713 @ 0x02CA4400 { Small Object Mobile } Current
# Page 45714 should be marked SPAN.
# Page 45715 should be marked SPAN.
# Page 45716 should be marked SPAN.
# Page 45717 should be marked SPAN.
# Page 45718 should be marked SPAN.
# Page 45719 should be marked SPAN.
# Page 45720 should be marked SPAN.
# Page 45721 should be marked SPAN.
# Page 45722 should be marked SPAN.
# Page 45723 should be marked SPAN.
# Page 45724 should be marked SPAN.
# Page 45725 should be marked SPAN.
# Page 45726 should be marked SPAN.
# Page 45727 should be marked SPAN.
# Page 45728 should be marked SPAN.
# Page 45729 should be marked SPAN.
# Page 45730 should be marked SPAN.
# Page 45731 should be marked SPAN.
# Page 45732 should be marked SPAN.
# Page 45733 should be marked SPAN.
# Page 45734 should be marked SPAN.
# Page 45735 should be marked SPAN.
# Page 45736 should be marked SPAN.
# Page 81525 should be marked SPAN.
# Page 81526 should be marked SPAN.
# Page 81527 should be marked SPAN.
# Page 81528 should be marked SPAN.
# Page 81529 should be marked SPAN.
# Page 81530 should be marked SPAN.
# Page 81531 should be marked SPAN.
# Page 81532 should be marked SPAN.
# Page 81533 should be marked SPAN.
# Page 81534 should be marked SPAN.
# Page 81535 should be marked SPAN.
! Page:17536 @ 0x01120000 { Small Object Mobile } Current
! 0x01120000: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120010: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120020: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120030: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120040: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120050: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120060: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120070: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120080: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120090: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011200A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011200B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011200C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011200D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011200E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011200F0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120100: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120110: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120120: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120130: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120140: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120150: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120160: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120170: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120180: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120190: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011201A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011201B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011201C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011201D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011201E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011201F0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120200: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120210: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120220: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120230: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120240: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120250: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120260: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120270: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120280: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120290: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011202A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011202B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011202C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011202D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011202E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011202F0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120300: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120310: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120320: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120330: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120340: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120350: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120360: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120370: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120380: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120390: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011203A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011203B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011203C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011203D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011203E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011203F0: 0x00000000 0x00000000 0x00000000 0x00000000
! Page:17537 @ 0x01120400 { Small NonObject Mobile } Current
! 0x01120400: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120410: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120420: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120430: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120440: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120450: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120460: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120470: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120480: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120490: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011204A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011204B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011204C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011204D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011204E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011204F0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120500: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120510: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120520: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120530: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120540: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120550: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120560: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120570: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120580: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120590: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011205A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011205B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011205C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011205D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011205E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011205F0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120600: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120610: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120620: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120630: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120640: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120650: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120660: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120670: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120680: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120690: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011206A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011206B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011206C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011206D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011206E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011206F0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120700: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120710: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120720: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120730: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120740: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120750: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120760: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120770: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120780: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x01120790: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011207A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011207B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011207C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011207D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011207E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x011207F0: 0x00000000 0x00000000 0x00000000 0x00000000
! Page:17538 @ 0x01120800 { Large Object Mobile } Current
! Page:45712 @ 0x02CA4000 { Small NonObject Mobile } Current
! 0x02CA4000: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4010: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4020: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4030: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4040: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4050: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4060: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4070: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4080: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4090: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA40A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA40B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA40C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA40D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA40E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA40F0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4100: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4110: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4120: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4130: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4140: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4150: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4160: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4170: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4180: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4190: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA41A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA41B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA41C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA41D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA41E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA41F0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4200: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4210: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4220: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4230: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4240: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4250: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4260: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4270: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4280: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4290: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA42A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA42B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA42C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA42D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA42E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA42F0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4300: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4310: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4320: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4330: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4340: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4350: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4360: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4370: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4380: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4390: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA43A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA43B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA43C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA43D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA43E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA43F0: 0x00000000 0x00000000 0x00000000 0x00000000
! Page:45713 @ 0x02CA4400 { Small Object Mobile } Current
! Page:45714 @ 0x02CA4800 { Small Object Mobile } Current
! 0x02CA4800: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4810: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4820: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4830: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4840: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4850: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4860: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4870: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4880: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4890: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA48A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA48B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA48C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA48D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA48E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA48F0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4900: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4910: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4920: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4930: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4940: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4950: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4960: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4970: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4980: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA4990: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA49A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x02CA49B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F030: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F040: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F050: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F060: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F070: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F080: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F090: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F0A0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F0B0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F0C0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F0D0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F0E0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F0F0: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F100: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F110: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F120: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F130: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F140: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F150: 0x00000000 0x00000000 0x00000000 0x00000000
! 0x0495F160: 0x00000000 0x00000000 0x00000000 0x00000000
********** END OF FILE **********This appears to the general output generated when a partition gets a SEGV or AccessViolation type problem. The runtime code always performs a memory check to determine if a possible cause for the problem was a memory corruption. In this case it thinks it found a problem and is attempting to dump information related to the problem. There was a bug in this routine that caused to dump more stuff than was really needed (I believe that this was fixed in 5.0)
The actual error was someone wrote a 0 on the header of an object that describes the size of the object. Given that this was the first object on the page it could be a problem with someone overrunning the end of an object on the previous page.
This can either be a runtime problem or an application problem. Its a little hard to tell from this output. The best way to collect more information would be to install MSDEV/Visual Studio on the machine and enable
JustInTimeDebugging (this is normally enabled for you) and then add the following environment variable
FORTE_NOHANDLER=yes
This bypasses the exception handling and causes the MSDEV debugger to start. This should allow you to get a stack trace which will give more clues as to the problem. -
Nodemgr process running away with memory
We have 3 different applications that this has happened to. All of a
sudden, the nodemgr for the application environment will start consuming
memory on the Unix Solars 2.6 box. The nodemgr process gets up to
2 gig of virtual memory usage and seems to 'die', not to mention sometimes
consuming all the available memory on the box, locking up the box and
requiring a box reboot. I'm getting paged when a process starts consuming
memory so at least a box reboot has been avoided lately.
One application is using 3G2, two 3f2 and one is a web sdk application.
I suspect that there is a bug in Forte causing this to happen. Maybe a
bug with the way Forte is not handling something from the version of Solaris
we're using.
I've been working with a Forte tech rep. and they have said they haven't
seen any customers with the problem and don't have a reason for it.
Has anyone else seen this happen and can you please shed some light
on it?
Thanks,
Peggy Adrian
[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/>Peggy:
I have DEFINITELY seen this problem and strongly believe that it is related to
3G2 running on Solaris 2.6. As you know, 3G2 is not supported on Solaris 2.6.
We upgraded to 3J1 and Solaris 2.6 in late November, and have never seen this
problem since. However, we did see this problem a number of times when trying
to run 3G2 on Solaris 2.6.
By the way, we did find that if we killed the nodemgr and then restarted it
VERY quickly, it would rebind properly and all would be well (except for
having to start all the router partitions again.)
-Martin
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
Nodemgr process consuming memory
All,
We have a problem we've been experiencing for some time where the nodemgr
process starts consuming over 2gig of memory - at the OS level and locking up
our server at times. This happened on Solaris 2.6
with various older versions of Forte and we were told that upgrading to
version 3J1 would resolve it.
Unfortunately, it hasn't resolved the problem. It has happened again to an
application written in 3J1 on Unix Sun Solaris 2.6.
Forte is saying that no other company has experienced this problem with 3J1 on
Solaris 2.6. Please let me know if you have so I can relate this to Forte.
Thanks,
Peggy Adrian
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>On Fri, 5 Mar 1999, Peggy Lynn Adrian wrote:
Unfortunately, it hasn't resolved the problem. It has happened again to an
application written in 3J1 on Unix Sun Solaris 2.6.We have experienced it too, with the previous releases man times.
With J1 I don't remember it happened ...
But, my 2cents : to save the OS , set a user limit of virtual memory
usage:
I use bash, I set it with ulimit -v 256000 to 256MB.
Interestingly when Forte crashes, it uses almost that amount of memory,
and one processor (we have a dual machine). And not more (that's why the
system can't kill it :) )
By the way, we have experienced some ftexec failures (memory and CPU
consumption) with J1 too, but since they were not reproducable, we did not
reported them. My tip : there may be a problem around the garbage
collection routine (that is just a tip from the outside). It seem to
happen when something made lots of objects, and consumed lots of memory.
GA'BRIEL, A'kos ([email protected]) FAX: (+36-1) 4312-977
UNIX & Internet consultant Phone: (+36-1) 4312-979
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) 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
Maybe you are looking for
-
Understanding itunes in the enterprise
Hi all. We are preparing to roll out ipads and iphones to our corporate users and I am trying to understand the functioning of itunes in the corporate environment. We will be providing devices to some people but some will be using their own persona
-
SM: EXEC SERVICES Job is Cancelling
Hello everyone- I have seen a few posts about this job cancelling however I haven't been able to gather a solution from what I have read. After appling SP15 in our Solution Manager system, the SM: EXEC SERVICES job is failing. We sent a note off to S
-
Playback has frozen in Premiere Pro CS6, it started when I added some after effects compositions to
Playback has frozen in Premiere Pro CS6. I am running a 1080p timeline and it appeared to start when I added some after effects renders to my timeline. The playback head still runs through the timeline and audio plays normally but the video complet
-
How do I upgrade OS to 4.4 on droid razr? I never got the notice
How do I upgrade to 4.4?
-
Good day all. I have the following components: a JSP that takes a couple of parameters and gives a text output, a Class that builds an URL to the JSP and specifying all required parameters, reads the response and acts accordingly. The Problem: - I bu