Re: (forte-users) size policy in TabFolder

There should be a file named: <reposname>.rop in the repos directory of your
Forte environment. It is a log of the repository operations. You may get some
clue as to what is happening there.
Thanks
Amos.G.Radfordbankofamerica.com wrote:
Do you do rpcleans on your reposity on a regular basis. It sounds like your
repository is starting to roll over. Check it's size, right before it's
ready to blow it will start to grow abnormally.
"Jones, Kerreck" <Kerreck.JonesGD-ES.COM> on 03/07/2001 07:31:28 AM
To: forte-users-digestlists.xpedior.com
cc:
Subject: (forte-users) Hanging Save in partition workspace.
I have my workspace preferences set to "save before running"
Now when I run in the partition workshop, I get the message "Saving
Workspace" in the
Workshop status line, and then it saves.... And saves..... and saves until
finally I have to
Kill forte by going to the forte menu and selecting launch server shutdown.
Anyone else been having this problem with forte 3.5 on NT?
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

Similar Messages

RE: (forte-users) tabfolder

No, but to ask the obvious, are you deep cloning it??
-----Original Message-----
From: Aissa Amazzal [mailto:aamazzalaxialog.fr]
Sent: Wednesday, July 19, 2000 5:06 AM
To: forte-userslists.xpedior.com
Subject: (forte-users) tabfolder
hi,
When i want to add the same panel to a tabfolder i used a cloned object.
This way allow me to add dynamically the same panel several times.
The problem is that the widgets attributes in the panel cloned have all a
nil value.
Any idea to resolve this problem will be appreciated.
Aissa AMAZZAL
Axialog Lille
France.

Hi Jean-Paul,
As described in the Technote 10981 some Forte programs (Nodemanager and
router) handle correct the high-file descriptor-use problem. It is possible
that Forte interpreter do it correct too.
Zenon
-----Original Message-----
From: Jean-Paul Gabrielli [SMTP:Jean-Paul.Gabriellisema.fr]
Sent: Monday, September 25, 2000 12:11 PM
To: Adamek, Zenon
Cc: Forte-userslists.xpedior.com
Subject: RE: (forte-users) [UNIX] "Too many open files" 3.0.M2
question
Actually, the stuff works in interpreted mode.
It's only when having the server partition compiled that this happen.
j-p
-----Message d'origine-----
De: Adamek, Zenon [mailto:ZAdamekpurolator.com]
Date: lundi 25 septembre 2000 17:13
À: 'Jean-Paul.Gabriellisema.fr'
Cc: Forte-userslists.xpedior.com
Objet: RE: (forte-users) [UNIX] "Too many open files" 3.0.M2 question
see Technote 10981
-----Original Message-----
From: Jean-Paul Gabrielli [SMTP:Jean-Paul.Gabriellisema.fr]
Sent: Monday, September 25, 2000 11:02 AM
To: zeForte-users
Subject: (forte-users) [UNIX] "Too many open files" 3.0.M2 question
Hi,
running a server partition that reads a configuration file,
and apparently doen't close it after, I have that exception:
SYSTEM ERROR: System Error: Too many open files, opening '....'with mode
'r'
Class: qqos_FileResourceException
1) Is there such a limit, or does this rely only on the OS one ?
2) How is this error not trapped, as I only got itinteractively, whereas
my server log does a exception trap/segmentation fault,
thanlks
j-p
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

RE: (forte-users) Domain Classes

Hi,
This thread coinsides with a recent posting I made on formatting percents
(attached at end).
The complication here is that the data field is part of an array field and
is:
1) editable
2) part of an array of BObjects that are mapped to the array field
There is no separation therefore between a BO and a DO, at least in the
current implementation. Furthermore, the user may or may not want percent to
be the display format. What I think I need is one field that actually has
two values, a display value and a 'true' value, and each would probably need
its own numeric format as well (one for data entry and one for display).
I've never used a domain class, but do you know if such a beast be possible?
-----Original Message-----
I want to provide the option for a user to display values in percents or
not, and finding this surprisingly tricky.
Although its easy to make a DecimalData with a value of .08 look like 8% by
changing the scale and multiplying by its value by 100, I don't see how to
do this in a way that the variable still knows its value is .08.

Jason,
Domain Classes can also store FieldWidget information associated with them.
For example, Widget type, Max Characters, Input Mask, Size Policy, Help
Text, etc. This means that when a developer adds the domain to the window
workshop it will automatically have all the settings that were previously
defined on the domain, therefore giving a standard look and feel, as well
as, behaviour(fillstring and SetValue).
Regards,
Allister
Xpedior
www.xpedior.com
Ph: +61-8-9320-7604
Fax: +61-8-9486-8650
-----Original Message-----
From: Jason de Cean [mailto:[email protected]]
Sent: Thursday, 21 October 1999 9:30
To: 'Forte Users'
Subject: (forte-users) Domain Classes
Hi,
Can anyone tell me the advantage of using a domain class ?
We have subclassed DecimalData (FormattedDecimal) and overridden the
FillString and SetValue methods to implement other formatting. This is
then used as an attribute on our data classes and appears to work fine
when mapped to forms.
So, why would we use a Domain Class instead of just sub classing
DecimalData ?
Jace.
Jason de Cean
Genisys Team
Lumley Technology Ltd.
Lvl. 8, 55 Sussex St
Sydney, NSW 2000 Australia
Ph: 02 9248 1321
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]

RE: (forte-users) 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.com

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.com

Re: (forte-users) Delays in data transfer..server-to-client

I would try using DOM (distributed object manager) traces. trc:do:20 will
give you information on each messages sent from and received by the
partition. Levels are 1, 2, 5, 7, and 8, and trc:do:*:8 is very
verbose. trc:do:20:1 may tell you what you want to know. trc:do:1:1 will
give you a basic 1-line-per DOM event trace that may also be all you need.
Communications manager traces will tell you about network and socket-level
activity, but not about the sizes of the messages themselves. In addition,
the operating system makes decisions about physical packet size and
send/receive timing, so CM activities only generally map to actual network
activity.
-tdc
iPlanet Integration Server Engineering
At 09:24 AM 5/1/01 -0700, you wrote:
All,
We are experiencing delays in object transfer between server and client. The
delays are longer with large objects (a single object with an array of objects
that reflect the rows returned in a database) than small (ie: 10 rows vs 400).
Does anyone have any (actual) experience using the various Forte' flags in
order
to show the actual size of the object/packets being passed between the server
and client?
We are using input/output between client and server, input on all the SO's
within a partition. Response on the server side is good, roughly 6 seconds or
so. The round trip fare however from the time the client makes the SO call to
the time that it completes is in the 25-30 second range, leaving roughly 20-25
seconds unaccounted for. I have brought in the network guys who are
requesting
the data size and packet information. I did not see what I am looking for
using
the trc:cm:*:4 and trc:cm:*:8 flags. I will be trying the trc:cm:*:10
flag, but
Forte' indicates that this flag is very verbose, the systems group hates
it when
I use up all of THEIR disk space!
Any ideas would be appreciated as always.

Jeff,
If the object you are passing does not require changes made to it in the
server partition to be returned, pass the object as copy input (pass by
value not reference). If it is necessary to pass the object as input, try
to pass only the attributes that are required to the remote partition
instead of the whole object.
Input/Output is normaly used with scalar variables. When a scalar is passed
to a remote partition, if the value is changed in that partition, the value
is not returned to the calling partition unless Input/Output is used.
Input/Output should not be used for object type parameters, if you need to
pass a reference, use Input only. If you can pass by value, use Copy Input.
You will notice a huge difference in performance changing from Input to Copy
input when passing large objects.
Hope this helps,
Travis Foote
Fortedeveloper.com Inc.
----- Original Message -----
From: "Jeff Bennett" <[email protected]>
To: <[email protected]>
Sent: Tuesday, May 01, 2001 9:24 AM
Subject: (forte-users) Delays in data transfer.. server-to-client
>
All,
We are experiencing delays in object transfer between server and client.The
delays are longer with large objects (a single object with an array ofobjects
that reflect the rows returned in a database) than small (ie: 10 rows vs400).
>
Does anyone have any (actual) experience using the various Forte' flags inorder
to show the actual size of the object/packets being passed between theserver
and client?
We are using input/output between client and server, input on all the SO's
within a partition. Response on the server side is good, roughly 6seconds or
so. The round trip fare however from the time the client makes the SOcall to
the time that it completes is in the 25-30 second range, leaving roughly20-25
seconds unaccounted for. I have brought in the network guys who arerequesting
the data size and packet information. I did not see what I am looking forusing
the trc:cm:*:4 and trc:cm:*:8 flags. I will be trying the trc:cm:*:10flag, but
Forte' indicates that this flag is very verbose, the systems group hatesit when
I use up all of THEIR disk space!
Any ideas would be appreciated as always.
-jeff
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]

RE: (forte-users) memory management

Brenda,
When a partition starts, it reserves the MinimumAllocation. Within this
memory space, objects are created and more and more of this memory is
actually used. When objects are no longer referenced, they remain in memory
and the space they occupy remains unusable.
When the amount of free memory drops below a certain point, the garbage
collector kicks in, which will free the space occopied by all objects that
are no longer referenced.
If garbage collecting can't free enough memory to hold the additional data
loaded into memory, then the partition will request another block of memory,
equal to the IncrementAllocation size. The partition will try to stay within
this new boundary by garbage collecting everytime the available part of this
memory drops below a certain point. If the partition can't free enough
memory, it will again request another block of memory.
This process repeats itself until the partition reaches MaximumAllocation.
If that amount of memory still isn't enough, then the partition crashes.
Instrument ActivePages shows the memory reserved by the partition.
AllocatedPages shows the part of that memory actually used.
AvailablePages shows the part ot that memory which is free.
Note that once memory is requested from the operating system, it's never
released again. Within this memory owned by the partition, the part actually
used will always be smaller. But this part will increase steadily, until the
garbage collecter is started and a part of it is freed again.
There are some settings that determine when the garbage collector is
started, but I'm not sure which ones they are.
The garbage collector can be started from TOOL using
"task.Part.OperatingSystem.RecoverMemory()", but I'm not sure if that will
always actually start the garbage collector.
If you track AllocatedPages of a partition, it's always growing, even if the
partition isn't doing anything. I don't know why.
If you add AllocatedPages and AvailablePages, you shoud get the value of
ActivePages, but you won't. You always get a lower number and sometimes even
considerably lower. I don't know why.
Pascal Rottier
Atos Origin Nederland (BAS/West End User Computing)
Tel. +31 (0)10-2661223
Fax. +31 (0)10-2661199
E-mail: Pascal.Rottiernl.origin-it.com
++++++++++++++++++++++++++++
Philip Morris (Afd. MIS)
Tel. +31 (0)164-295149
Fax. +31 (0)164-294444
E-mail: Rottier.Pascalpmintl.ch
-----Original Message-----
From: Brenda Cumming [mailto:brenda_cummingtranscanada.com]
Sent: Tuesday, January 23, 2001 6:40 PM
To: Forte User group
Subject: (forte-users) memory management
I have been reading up on memory management and the
OperatingSystemAgent, and could use some clarification...
When a partition is brought online, is the ActivePages value set to the
MinimumAllocation value, and expanded as required?
And what is the difference between the ExpandAtPercent and
ContractAtPercent functions?
Thanks in advance,
Brenda
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

The Forte runtime is millions of lines of compiled C++ code, packaged into
shared libraries (DLL's) which are a number of megabytes in size. The
space is taken by the application binary, plus the loaded DLL's, plus
whatever the current size of garbage collected memory is.
Forte allocates a garbage-collected heap that must be bigger than the size
of the allocated objects. So if you start with an 8MB heap, you will always
have at least 8MB allocated, no matter what objects you actually
instantiate. See "Memory Issues" in the Forte System Management Guide.
-tdc
Tom Childers
iPlanet Integration Server Engineering
At 10:37 PM 6/11/01 +0200, [email protected] wrote:
Hi all,
I was wondering if anyone had any experience in deploying clients on NT
concerning
the memory use of these client apps.
What is the influence of the various compiler options (optimum
performance, memory use etc)?
We seem to see a lot of the memory is taken by the Forte client apps (seen
in the Task Manager
of NT) in respect to the other native Window apps. For example an
executable of approx 4Mb takes up to
15Mb of memory. When I look at the objects retained in memory after
garbage collection, these are about
2Mb. Where do the other Mb's come from?

RE: (forte-users) Call to the load-balanced SO not throughrouter

We never call an SO from within an SO. Instead we do the following :
MySO is mapped to MySOclass.
MySOclass is a facade which has an attribute for every Policy Manager
related to this SO.
Each Policy manager is instanciated in MySOclass.
Each Policy manager has an attribute called Parent.
Parent is defined by MySOclass to be self.
If two Policy managers need to work together we invoke methods via the
parent attribute :
Example
I have a partition for Enrolments.
It has three Policy Managers within it
a Students Policy Manager (with a Add, Delete, Get methods)
a Courses Policy Manager (with a Add, Delete, Get methods).
an Enrolments Policy Manager (with a Add, Delete, Get methods).
To enable this partition we have defined :
EnrolmentsSO (environment visible, message duration) with the EnrolmentsMgr
class as its related class.
The EnrolmentsMgr class has the following methods and attributes :
Methods :
AddStudent
AddCourse
AddEnrolment
GetStudent
GetCourse
GetEnrolment
DeleteStudent
DeleteCourse
DeleteEnrolment
All of these methods do a one line return statement, simply passing the
method invocation to
the appropriate Policy Manager. For example AddStudent would say
Return theStudentPM.AddStudent(pInStudentParams : pInStudentParams)
: pOutStudentParams
In the Init method for the EnrolmentsMgr we instanciate the following
attributes :
theStudentPM (which is typed to the StudentPM class)
theCoursePM (which is typed to the CoursePM class)
theEnrolmentsPM (which is typed to the EnrolmentsPM class)
Also in the Init method we set an attribute (called parent) on each
PM to the value of Self.
Then when one PM needs to invoke a method on another PM we simply do :
For example in the theEnrolmentPM.GetEnrolment method we need to get
Students and Courses
thus we code :
Parent.GetStudent(pInStudentParams = pInStudentParams) : pOutStudentParams
Parent.GetCourse((pInCourseParams = pOutStudentParams.CourseStuff) :
pOutCourseParams
Build Enrol details based on student / course stuff.
Return EnrolmentParams.
Hope this makes sense.
Regards,
Chris Will, Dept. of Educ. Training, ITB, Sydney, Australia
-----Original Message-----
From: Peter Sham [mailto:[email protected]]
Sent: Friday, 8 October 1999 9:35
To: [email protected]; [email protected]
Subject: Re: (forte-users) Replicating the PersistenceMgrSO
Hi,
Whenever you make a call to your load-balanced SO, it
would go through the router. That is what I
understand. No matter you make the call from inside
or outside the SO.
Secondly, you can turn on the "fail-over" option of a
router but not load-balanced it. On these routers,
you can check their instruments to see which one is
really running.
Hope this help.
Regards,
Peter Sham.

We never call an SO from within an SO. Instead we do the following :
MySO is mapped to MySOclass.
MySOclass is a facade which has an attribute for every Policy Manager
related to this SO.
Each Policy manager is instanciated in MySOclass.
Each Policy manager has an attribute called Parent.
Parent is defined by MySOclass to be self.
If two Policy managers need to work together we invoke methods via the
parent attribute :
Example
I have a partition for Enrolments.
It has three Policy Managers within it
a Students Policy Manager (with a Add, Delete, Get methods)
a Courses Policy Manager (with a Add, Delete, Get methods).
an Enrolments Policy Manager (with a Add, Delete, Get methods).
To enable this partition we have defined :
EnrolmentsSO (environment visible, message duration) with the EnrolmentsMgr
class as its related class.
The EnrolmentsMgr class has the following methods and attributes :
Methods :
AddStudent
AddCourse
AddEnrolment
GetStudent
GetCourse
GetEnrolment
DeleteStudent
DeleteCourse
DeleteEnrolment
All of these methods do a one line return statement, simply passing the
method invocation to
the appropriate Policy Manager. For example AddStudent would say
Return theStudentPM.AddStudent(pInStudentParams : pInStudentParams)
: pOutStudentParams
In the Init method for the EnrolmentsMgr we instanciate the following
attributes :
theStudentPM (which is typed to the StudentPM class)
theCoursePM (which is typed to the CoursePM class)
theEnrolmentsPM (which is typed to the EnrolmentsPM class)
Also in the Init method we set an attribute (called parent) on each
PM to the value of Self.
Then when one PM needs to invoke a method on another PM we simply do :
For example in the theEnrolmentPM.GetEnrolment method we need to get
Students and Courses
thus we code :
Parent.GetStudent(pInStudentParams = pInStudentParams) : pOutStudentParams
Parent.GetCourse((pInCourseParams = pOutStudentParams.CourseStuff) :
pOutCourseParams
Build Enrol details based on student / course stuff.
Return EnrolmentParams.
Hope this makes sense.
Regards,
Chris Will, Dept. of Educ. Training, ITB, Sydney, Australia
-----Original Message-----
From: Peter Sham [mailto:[email protected]]
Sent: Friday, 8 October 1999 9:35
To: [email protected]; [email protected]
Subject: Re: (forte-users) Replicating the PersistenceMgrSO
Hi,
Whenever you make a call to your load-balanced SO, it
would go through the router. That is what I
understand. No matter you make the call from inside
or outside the SO.
Secondly, you can turn on the "fail-over" option of a
router but not load-balanced it. On these routers,
you can check their instruments to see which one is
really running.
Hope this help.
Regards,
Peter Sham.

RE: (forte-users) Hi All....very urgent...Forte doesn'thandle La rge ar

Okay, here's my three cents worth,
Are you using Forte "Keep Alive" settings? If yes, you may simply have a
time-out.
While a partition is waiting for a reply from a database, it blocks and
won't respond
to anything, including pings to check if it's still alive. So, if the query
takes longer to
complete than the time-out period of the communication manager, then you
will
loose the connection to the partition.
-----Original Message-----
From: Aberdour George [SMTP:george.aberdourdet.nsw.edu.au]
Sent: Sunday, February 13, 2000 11:39 AM
To: 'Babu Raj'; kamranaminyahoo.com
Subject: RE: (forte-users) Hi All....very urgent...Forte doesn't
handle La rge array properly
Hi,
This sounds almost identical to a problem we have experienced.
If it is the same problem it is because you have compiled a back-end
load-balanced partition, but NOT the router that manages it.
With such a configuration, attempts to send greater than a few thousand
rows
will fail - and it doesn't seem to matter what you set -fm to.
You don't see the problem running distributed from your workspace because
everything is interpreted.
So just compile the router and try again.
Hope this helps.
George Aberdour
(George.Aberdourdet.nsw.edu.au)
-----Original Message-----
From: Babu Raj [mailto:ibcsmartboyyahoo.com]
Sent: Saturday, 12 February 2000 7:24
To: kamranaminyahoo.com
Subject: (forte-users) Hi All....very urgent...Forte doesn't handle
Large array properly
Hi All,
Have anyone experienced problem of retrieving
more than 1500 records from the database table, into
the object.
I use dynamic SQL statement, and populating Array
object from the DBDataSet. When it runs from my
workspace distributed, it works fine. But, when I make
deployment, and install on the test bed, I face
Network connection failure from the client machine. It
looks like, server read the data from the Database,
and while packaging it, to send it across to the
client, server seems to run out ouf memory or couldn't
maintain the connection with the client. I tried to
set -fm flag on that partition, and separately setting
FORTE_GC_SPECIAL too, but still no luck.
we have increased, the rollback segment size on
Oracle too, but still no luck.
Appreciate, your suggestions, if you can,
Thank you,
Babu
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

Okay, here's my three cents worth,
Are you using Forte "Keep Alive" settings? If yes, you may simply have a
time-out.
While a partition is waiting for a reply from a database, it blocks and
won't respond
to anything, including pings to check if it's still alive. So, if the query
takes longer to
complete than the time-out period of the communication manager, then you
will
loose the connection to the partition.
-----Original Message-----
From: Aberdour George [SMTP:george.aberdourdet.nsw.edu.au]
Sent: Sunday, February 13, 2000 11:39 AM
To: 'Babu Raj'; kamranaminyahoo.com
Subject: RE: (forte-users) Hi All....very urgent...Forte doesn't
handle La rge array properly
Hi,
This sounds almost identical to a problem we have experienced.
If it is the same problem it is because you have compiled a back-end
load-balanced partition, but NOT the router that manages it.
With such a configuration, attempts to send greater than a few thousand
rows
will fail - and it doesn't seem to matter what you set -fm to.
You don't see the problem running distributed from your workspace because
everything is interpreted.
So just compile the router and try again.
Hope this helps.
George Aberdour
(George.Aberdourdet.nsw.edu.au)
-----Original Message-----
From: Babu Raj [mailto:ibcsmartboyyahoo.com]
Sent: Saturday, 12 February 2000 7:24
To: kamranaminyahoo.com
Subject: (forte-users) Hi All....very urgent...Forte doesn't handle
Large array properly
Hi All,
Have anyone experienced problem of retrieving
more than 1500 records from the database table, into
the object.
I use dynamic SQL statement, and populating Array
object from the DBDataSet. When it runs from my
workspace distributed, it works fine. But, when I make
deployment, and install on the test bed, I face
Network connection failure from the client machine. It
looks like, server read the data from the Database,
and while packaging it, to send it across to the
client, server seems to run out ouf memory or couldn't
maintain the connection with the client. I tried to
set -fm flag on that partition, and separately setting
FORTE_GC_SPECIAL too, but still no luck.
we have increased, the rollback segment size on
Oracle too, but still no luck.
Appreciate, your suggestions, if you can,
Thank you,
Babu
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

RE: (forte-users) Optimal number of records to fetch fromForte C ursor

The reason why a single fetch of 20.000 records performs less then
2 fetches of 10.000 might be related to memory behaviour. Do you
keep the first 10.000 records in memory when you fetch the next
10.000? If not, then a single fetch of 20.000 records requires more
memory then 2 fetches of 10.000. You might have some extra over-
head of Forte requesting additional memory from the OS, garbage
collections just before every request for memory and maybe even
the OS swapping some memory pages to disk.
This behaviour can be controlled by modifying the Minimum memory
and Maximum memory of the partition, as well as the memory chunk
size Forte uses to increment its memory.
Upon partition startup, Forte requests the Minimum memory from the
OS. Whithin this area, the actual memory being used grows, until
it hits the ceiling of this space. This is when the garbage collector
kicks in and removes all unreferenced objects. If this does not suffice
to store the additional data, Forte requests 1 additional chunk of a
predefined size. Now, the same behaviour is repeated in this, slightly
larger piece of memory. Actual memory keeps growing until it hits
the ceiling, upon which the garbage collector removes all unrefer-
enced objects. If the garbage collector reduces the amount of
memory being used to below the original Miminum memory, Forte
will NOT return the additional chunk of memory to the OS. If the
garbage collector fails to free enough memory to store the new data,
Forte will request an additional chunk of memory. This process is
repeated untill the Maximum memory is reached. If the garbage
collector fails to free enough memory at this point, the process
terminates gracelessly (which is what happens sooner or later when
you have a memory leak; something most Forte developpers have
seen once or twice).
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: [email protected] [SMTP:[email protected]]
Sent: Monday, November 15, 1999 6:53 PM
To: [email protected]
Subject: (forte-users) Optimal number of records to fetch from Forte
Cursor
Hello everybody:
I 'd like to ask a very important question.
I opened Forte cursor with approx 1.2 million records, and now I am trying
to figure out the number of records per fetch to obtain
the acceptable performance.
To my surprise, fetching 100 records at once gave me approx 15 percent
performance gain only in comparsion
with fetching records each by each.
I haven't found significant difference in performance fetching 100, 500
or
10.000 records at once.In the same time, fetching 20.000
records at once make a performance approx 20% worse( this fact I cannot
explain).
Does anybody have any experience in how to improve performance fetching
from
Forte cursor with big number of rows ?
Thank you in advance
Genady Yoffe
Software Engineer
Descartes Systems Group Inc
Waterloo On
Canada
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 Kieran,
According to your description, you are going to figure out what is the optimal number of records per partition, right? As per my understanding, this number was change by your hardware. The better hardware you have, the more number of records per partition.
The earlier version of the performance guide for SQL Server 2005 Analysis Services Performance Guide stated this:
"In general, the number of records per partition should not exceed 20 million. In addition, the size of a partition should not exceed 250 MB."
Besides, the number of records is not the primary concern here. Rather, the main criterion is manageability and processing performance. Partitions can be processed in parallel, so the more there are the more can be processed at once. However, the more partitions
you have the more things you have to manage. Here is some links which describe the partition optimization
http://blogs.msdn.com/b/sqlcat/archive/2009/03/13/analysis-services-partition-size.aspx
http://www.informit.com/articles/article.aspx?p=1554201&seqNum=2
Regards,
Charlie Liao
TechNet Community Support

RE: (forte-users) Optimal number of records to fetch fromForte Cursor

Guys,
The behavior (1 fetch of 20000 vs 2 fetches of 10000 each) may also be DBMS
related. There is potentially high overhead in opening a cursor and initially
fetching the result table. I know this covers a great deal DBMS technology
territory here but one explanation is that the same physical pages may have to
be read twice when performing the query in 2 fetches as compared to doing it in
one shot. Physical IO is perhaps the most expensive (vis a vis- resources)
part of a query. Just a thought.
"Rottier, Pascal" <[email protected]> on 11/15/99 01:34:22 PM
To: "'Forte Users'" <[email protected]>
cc: (bcc: Charlie Shell/Bsg/MetLife/US)
Subject: RE: (forte-users) Optimal number of records to fetch from Forte C
ursor
The reason why a single fetch of 20.000 records performs less then
2 fetches of 10.000 might be related to memory behaviour. Do you
keep the first 10.000 records in memory when you fetch the next
10.000? If not, then a single fetch of 20.000 records requires more
memory then 2 fetches of 10.000. You might have some extra over-
head of Forte requesting additional memory from the OS, garbage
collections just before every request for memory and maybe even
the OS swapping some memory pages to disk.
This behaviour can be controlled by modifying the Minimum memory
and Maximum memory of the partition, as well as the memory chunk
size Forte uses to increment its memory.
Upon partition startup, Forte requests the Minimum memory from the
OS. Whithin this area, the actual memory being used grows, until
it hits the ceiling of this space. This is when the garbage collector
kicks in and removes all unreferenced objects. If this does not suffice
to store the additional data, Forte requests 1 additional chunk of a
predefined size. Now, the same behaviour is repeated in this, slightly
larger piece of memory. Actual memory keeps growing until it hits
the ceiling, upon which the garbage collector removes all unrefer-
enced objects. If the garbage collector reduces the amount of
memory being used to below the original Miminum memory, Forte
will NOT return the additional chunk of memory to the OS. If the
garbage collector fails to free enough memory to store the new data,
Forte will request an additional chunk of memory. This process is
repeated untill the Maximum memory is reached. If the garbage
collector fails to free enough memory at this point, the process
terminates gracelessly (which is what happens sooner or later when
you have a memory leak; something most Forte developpers have
seen once or twice).
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: [email protected] [SMTP:[email protected]]
Sent: Monday, November 15, 1999 6:53 PM
To: [email protected]
Subject: (forte-users) Optimal number of records to fetch from Forte
Cursor
Hello everybody:
I 'd like to ask a very important question.
I opened Forte cursor with approx 1.2 million records, and now I am trying
to figure out the number of records per fetch to obtain
the acceptable performance.
To my surprise, fetching 100 records at once gave me approx 15 percent
performance gain only in comparsion
with fetching records each by each.
I haven't found significant difference in performance fetching 100, 500
or
10.000 records at once.In the same time, fetching 20.000
records at once make a performance approx 20% worse( this fact I cannot
explain).
Does anybody have any experience in how to improve performance fetching
from
Forte cursor with big number of rows ?
Thank you in advance
Genady Yoffe
Software Engineer
Descartes Systems Group Inc
Waterloo On
Canada
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]

Hi Kieran,
According to your description, you are going to figure out what is the optimal number of records per partition, right? As per my understanding, this number was change by your hardware. The better hardware you have, the more number of records per partition.
The earlier version of the performance guide for SQL Server 2005 Analysis Services Performance Guide stated this:
"In general, the number of records per partition should not exceed 20 million. In addition, the size of a partition should not exceed 250 MB."
Besides, the number of records is not the primary concern here. Rather, the main criterion is manageability and processing performance. Partitions can be processed in parallel, so the more there are the more can be processed at once. However, the more partitions
you have the more things you have to manage. Here is some links which describe the partition optimization
http://blogs.msdn.com/b/sqlcat/archive/2009/03/13/analysis-services-partition-size.aspx
http://www.informit.com/articles/article.aspx?p=1554201&seqNum=2
Regards,
Charlie Liao
TechNet Community Support

RE: (forte-users) Accelerator keys under MS Windows95/98/NT

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BEF001.9C8C0B50
Content-Type: text/plain
Unfortunately, ALT key is not recognized as a validkey modifier on Windows
That isn't entirely true. The ALT key is recognized. I've used it
successfully
under Windows 95 and NT. The only annoying side-effect is that you get the
standard operating system beep when you perform the keypress.
-----Original Message-----
From: "Ajith Kallambella" [SMTP:[email protected]]
Sent: Thursday, August 26, 1999 1:43 PM
To: "[email protected]" [SMTP:[email protected]];
"[email protected]" [SMTP:[email protected]]
Subject: Re: (forte-users) Accelerator keys under MS Windows 95/98/NT
The Window class has a method named SetAsFunctionKey
and an event named FunctionKeyPress. When used
in combination, the former can be used to configure
various accelerator keys for the window widgets
and the latter can be used to trap them.
For more details, take a look at Forte online help.
Unfortunately, ALT key is not recognized as a valid
key modifier on Windows, but is only available on
Unix and VMS - for reasons beyond my comprehension :(
Hope this helps
Ajith Kallambella M.
Forte Systems Consultant.
From: "Burns, Troy" <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: (forte-users) Accelerator keys under MS Windows 95/98/NT
Date: Thu, 26 Aug 1999 13:56:07 -0400
Let's say I have a pushbutton on a window and I've given it
label text of "&Search". In past developer-lives, the ampersand
is what gives the button the ability to respond to ALT-S. This
doesn't appear to be the case in Forte. What do I need to do
to make this work?
Thanks in advance,
Troy Burns
E-mail: [email protected]
Marriott Vacation Club International
941-688-7700 ext. 4408
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: [email protected]
------_=_NextPart_001_01BEF001.9C8C0B50
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<DEFANGED-META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<DEFANGED-META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<DEFANGED-TITLE>RE: (forte-users) Accelerator keys under MS Windows =
95/98/NT</TITLE>
</HEAD>
<BODY>
> Unfortunately, ALT key is not recognized as a =
valid
 key modifier on Windows

That isn't entirely true. The ALT key is recognized. =
I've used it successfully
 under Windows 95 and NT. The only annoying =
side-effect is that you get the
 standard operating system beep when you perform the =
keypress.

-----Original Message-----
 From: "Ajith Kallambella" =
[SMTP:[email protected]] 
 Sent: Thursday, August 26, 1999 1:43 PM
 To: "[email protected]" =
[SMTP:[email protected]];
 "[email protected]" =
[SMTP:[email protected]]
 Subject: Re: (forte-users) Accelerator keys under MS =
Windows 95/98/NT

 
The Window class has a method named =
SetAsFunctionKey
 and an event named FunctionKeyPress. When =
used
 in combination, the former can be used to =
configure
 various accelerator keys for the window =
widgets
 and the latter can be used to trap them.

For more details, take a look at Forte online =
help.

Unfortunately, ALT key is not recognized as a =
valid
 key modifier on Windows, but is only available =
on
 Unix and VMS - for reasons beyond my comprehension =
:(

Hope this helps

Ajith Kallambella M.
 Forte Systems Consultant.

 
>From: "Burns, Troy" =
<[email protected]>
 >To: "'[email protected]'" =
<[email protected]>
 >Subject: (forte-users) Accelerator keys under MS =
Windows 95/98/NT
 >Date: Thu, 26 Aug 1999 13:56:07 -0400
 >
 >Let's say I have a pushbutton on a window and =
I've given it
 >label text of "&Search". In =
past developer-lives, the ampersand
 >is what gives the button the ability to respond =
to ALT-S. This
 >doesn't appear to be the case in Forte. =
What do I need to do
 >to make this work?
 >
 >Thanks in advance,
 >
 >---------------------------------------------
 >Troy Burns
 >E-mail: [email protected]
 >Marriott Vacation Club International
 >941-688-7700 ext. 4408
 >
 >--
 >For the archives, go to: <A =
HREF=3D"<a href=
"http://lists.sageit.com/forte-users">http://lists.sageit.com/forte-users</a>" =
TARGET=3D"_blank">http://lists.sageit.com/forte-users</A> and =
use
 >the login: forte and the password: archive. To =
unsubscribe, send in a new
 >email the word: 'Unsubscribe' to: =
[email protected]
 >

 
_______________________________________________________________=

 Get Free Email and Do More On The Web. Visit <A =
HREF=3D"<a href="http://www.msn.com">http://www.msn.com</a>" =
TARGET=3D"_blank">http://www.msn.com</A>

--
 For the archives, go to: <A =
HREF=3D"<a href=
"http://lists.sageit.com/forte-users">http://lists.sageit.com/forte-users</a>" =
TARGET=3D"_blank">http://lists.sageit.com/forte-users</A> and =
use
 the login: forte and the password: archive. To =
unsubscribe, send in a new
 email the word: 'Unsubscribe' to: =
[email protected]

</BODY>
</HTML>
------_=_NextPart_001_01BEF001.9C8C0B50--

Hi,Beau Leo, I am having problem installing Oracle9i Database Rel.2 on my pc.
I read the suggestion and solution you posted for fixing Oracle 8.1.x installation
probblem, and since my pc also hung at 48% while installing Oracle 9i software,
I wonder if the same problem in the Oracle8 Vs.Pentium4 also exists for Oracle9i.
I have Windows2000,256RAM, Pentium3 1Ghz, and 13.8 free diskspace. But the installation always
hangs at 48%, my computer will just shut down and restart automatically without
even showing an error message. I have tried installing the Enterprise edition for 3
times already but everytime encountered the same problem. I've also tried custom installation
by selecting not to create database, but it also hung.
Before I started each installation, I always made sure that my registry and environment
path are cleared and that all the partially-installed Oracle files are deleted.
I hope that you or anyone who has a solution for this problem could be so kindly to help me out.
Thank you in advance.
ailee

RE: (forte-users) Help on 'The class has been voided andcannot be insta

PB Solved.
The symtom was that my 'windows' plan that I distrubute call
the StartMethod of a class defined higher in the hierarchy,
and I had to specify that plan as direct supplier plan of my
new project for the 'voided' not to happen.
cheers
j-p
-----Message d'origine-----
De: Jean-Paul Gabrielli [mailto:Jean-Paul.Gabriellisema.fr]
Date: mercredi 5 juillet 2000 12:08
À: Klerk, Theo de
Objet: RE: (forte-users) Help on 'The class has been voided and cannot
be instanciated' plz
the issue is as follows:
I distribute a plan A
I want to rename the plan,
and create a plan B that has A as supplier.
Distributing B wor'ks
Running it fails with that issue.
Actually I recreated supplierplans in B as they were defined in A,
and the problem disappeared.
thansk for your time
j-paul
-----Message d'origine-----
De: Klerk, Theo de [mailto:Theo.de.Klerkcompaq.com]
Date: mardi 4 juillet 2000 22:31
À: 'Jean-Paul.Gabriellisema.fr'
Objet: RE: (forte-users) Help on 'The class has been voided and cannot
be instanciated' plz
Jean-Paul,
It would help if you have a bit more description around thesituation when
this error happens.
Could it be you have two service objects that refer to each other
while the
partition is still starting up? (SO's are not supposed to talk to
each other
during partition startup).
Or was the partition up and running?
Has the service object been in existence and used before itbecame voided?
Is the partition compiled or interpreted?
Theo de Klerk
Architecture & Application Integration
Professional Services
Compaq Computer Corp. - the Netherlands
PGP Fingerprint: 5A70 DD56 F3BA FE04 9DCA 1ACE 8581 0A2F F057 FA6E
-----Original Message-----
From: Jean-Paul Gabrielli [mailto:Jean-Paul.Gabriellisema.fr]
Sent: Tuesday, 04 July, 2000 18:17
To: Forte-Users
Subject: (forte-users) Help on 'The class has been voided and
cannot be
instanciated' plz
Hi,
Here's the stack I get:
SYSTEM ERROR: Failed to create service object
BOS.MyServicesMgrSO.
Class: qqsp_ResourceException
Error Time: Tue Jul 4 18:05:07
Exception occurred (locally) on partition "BC_cl0_Part3",
(partitionId =
AF3B67A0-3335-11D4-BE9D-963C5A7FAA77:0x224, taskId =
[AF3B67A0-3335-11D4-BE9D-963C5A7FAA77:0x224.6]) in application
"BC_cl0", pid 10328 on node MyServerin environment
CentralEnv.
SYSTEM ERROR: The class MyServericesMgr has been voided and cannot
be
instantiated in this partition.
Class: qqsp_UsageException with ReasonCode: SP_ER_INVALIDSTATE
Error #: [201, 14]
Detected at: qqlo_VoidedClassException at 1
Error Time: Tue Jul 4 18:05:07
Exception occurred (locally) on partition
"BC_cl0_Part3",
(partitionId =
AF3B67A0-3335-11D4-BE9D-963C5A7FAA77:0x224, taskId
=
[AF3B67A0-3335-11D4-BE9D-963C5A7FAA77:0x224.6]) in
application
"BC_cl0", pid 10328 on node MyServer in
environment
CentralEnv.
aud Tue Jul 4 18:05:07 : Shutting down partition due to
failure of this
partition.
aud Tue Jul 4 18:05:07 : Shutting down partition as requested.
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

Hi Sylvain
Try using window.smallIconImage =
ImageData(<TitleBarIcon>.ImageValue) ;
This should work.
Jairaj Rampershad
System Concultant
--- Sylvain_Porée <Sylvain.Poreesophia.sema.fr>
wrote:
Hi Forte Gurus,
I have tried to set an icon using this statement :
window.SmallIconImage =
aIconFile.<TitleBarIcon>.imagevalue;
where <TitleBarIcon> is a PictureGraphic in my
window workshop.
I have tried 16*16 16 colours as well as many other
arrangements. It does
not work. I use windows NT.
Any ideas ?
Thanks
Sylvain
PS : For info (forte help):
SmallIconImage
Data Type ImageData
Source Class Window
Settable? Yes
The SmallIconImage attribute (ImageData) provides
the small icon to be used
when the window is iconized, for example, in the
task bar. The image size
for a small icon should be 16 by 16 pixels. Although
the image will be
scaled if you provide one of a different size, for
best results, we
recommend that you create your icons in the same
size in which they will be
displayed.
Windows 95/NT only
This feature is available on Windows 95/NT only. On
other platforms, the
attribute is ignored.
For the archives, go to:
http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To
unsubscribe, send in a new
email the word: 'Unsubscribe' to:
forte-users-requestlists.xpedior.com

Re: (forte-users) Question

This is a multi-part message in MIME format.
--------------4E6A4194374DC1BDF50CB1A1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I would set the completion event for the display method of the new window and
register to this event in the main window as you see in the attached .pex file.
With this solution it is possible to handle a failor in the new window in order
to bahave like the normal completion and cause the deletion of the input element
in the main window.
Best Regards,
Tamas Deak
"Zirney, Bobby" wrote:
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BEF4BD.83F24DA6
Content-Type: text/plain;
charset="iso-8859-1"
I have a frame with a button on it that will open up another frame. When I
close the second frame by pressing the X in the top right hand corner, I
want to clear all the data on the first screen. I have been trying all
sorts of things without success. Does anyone have any suggestions as to how
to do this?
------_=_NextPart_001_01BEF4BD.83F24DA6
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<DEFANGED-META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<DEFANGED-META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<DEFANGED-TITLE>Question</TITLE>
</HEAD>
<BODY>
I have a frame with a button on it =
that will open up another frame. When I close the second frame by =
pressing the X in the top right hand corner, I want to clear all the =
data on the first screen. I have been trying all sorts of things =
without success. Does anyone have any suggestions as to how to do =
this?
</BODY>
</HTML>
------_=_NextPart_001_01BEF4BD.83F24DA6--
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]
--------------4E6A4194374DC1BDF50CB1A1
Content-Type: application/x-unknown-content-type-pex_auto_file;
name="Win.pex"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="Win.pex"
YmVnaW4gVE9PTCBUb3NzTWU7DQoNCmluY2x1ZGVzIERpc3BsYXlQcm9qZWN0Ow0KaW5jbHVk
ZXMgRnJhbWV3b3JrOw0KSEFTIFBST1BFUlRZIElzTGlicmFyeSA9IEZBTFNFOw0KDQotLSBT
VEFSVCBGT1JXQVJEIENMQVNTIERFQ0xBUkFUSU9OUw0KZm9yd2FyZCAgTmV3V2luIGlzIG1h
cHBlZDsNCmZvcndhcmQgIFdpbiBpcyBtYXBwZWQ7DQotLSBFTkQgRk9SV0FSRCBDTEFTUyBE
RUNMQVJBVElPTlMNCg0KLS0gU1RBUlQgRk9SV0FSRCBDVVJTT1IgREVDTEFSQVRJT05TDQot
LSBFTkQgRk9SV0FSRCBDVVJTT1IgREVDTEFSQVRJT05TDQoNCi0tIFNUQVJUIENPTlNUQU5U
IERFRklOSVRJT05TDQotLSBFTkQgQ09OU1RBTlQgREVGSU5JVElPTlMNCg0KLS0gU1RBUlQg
QyBEQVRBIFRZUEUgREVGSU5JVElPTlMNCi0tIEVORCBDIERBVEEgVFlQRSBERUZJTklUSU9O
Uw0KDQotLSBTVEFSVCBDTEFTUyBERUZJTklUSU9OUw0KDQpjbGFzcyBOZXdXaW4gaXMgbWFw
cGVkIGluaGVyaXRzIGZyb20gRGlzcGxheVByb2plY3QuVXNlcldpbmRvdw0KDQoNCg0KaGFz
IHB1YmxpYyAgbWV0aG9kIERpc3BsYXkgd2hlcmUgY29tcGxldGlvbiA9IChyZXR1cm4gPSBO
ZXdXaW5kb3dGaW5pc2hlZCwgZXhjZXB0aW9uID0gTmV3V2luZG93RmFpbGVkKTsNCmhhcyBw
dWJsaWMgIG1ldGhvZCBJbml0Ow0KDQpoYXMgcHJvcGVydHkNCglzaGFyZWQ9KGFsbG93PW9u
LCBvdmVycmlkZT1vbiwgZGVmYXVsdD1vZmYpOw0KCXRyYW5zYWN0aW9uYWw9KGFsbG93PW9u
LCBvdmVycmlkZT1vbiwgZGVmYXVsdD1vZmYpOw0KCW1vbml0b3JlZD0oYWxsb3c9b24sIG92
ZXJyaWRlPW9uLCBkZWZhdWx0PW9mZik7DQoJZGlzdHJpYnV0ZWQ9KGFsbG93PW9mZiwgb3Zl
cnJpZGU9b2ZmKTsNCg0KaGFzDQorNTE1MTQ2MzEwMDAwMDFiMTAwMDAwMTcyOWZlMzAxMDEw
MDAwMjEwMTAyMDAwMDAwMDAwMjAyMDYwMDk0MDgwMA0KKzFkMDA5ZmZmMDEwMTA0MjEwZjEw
MTExMjAxMDEwMTE3MDAwMDlmZmYwMDAwMDAwMDBkMDAwMDBiYjgwZmEwMDANCiswMDAwMDAw
MDAwMDAwMDAwMDAwMTAxNjA2MDAwMDAwMDAwMDAwMDAwMDAwMDlkMGJiODlkMGZhMDAwMDAw
MDAwDQorMDAwMDAxMDgwMzAzMDFmZmZkMDAwMDAwMDAwMDAwMDAwMDAyMDEwMDAwMDAwMDBm
MDQwNTAwMDYwMDAwMDIwMQ0KKzAwMDEwMDAwMGMwMDAwMDEwMDBiMDAwMTAwMDAwMDAwMDAw
MzAwMDAyMTAxMDIwMDAwMDAwMDA1MDQwMDAwMWMNCiswMjAwMTAwNTA2MDA3YTA4MDA0ZDAw
OWZmZjAxMDEwMTAxMGYxMDExMTIwMTAxMDExNzAwMDA5ZmZmMDEwMDAwDQorMDAwZDAwMDA1
ZGMwNWRiZjAwMDAwMDAwMDMwMzAzMDMwMDAyMDQwNGEwYTAwMDAwMDAwMDAwMDAwMDAwMDA5
ZA0KKzVkYzA5ZDVkYmYwMDAwMDAwMDAwMDAwMTA4MDY2ODAxMDAwMDAwNWRjMDVkYmYwMDAw
MDAwMjAxMDAwMDAwMDANCiswOTAwMDAwNjAwMDAyMTAxMDIwMDAwMDAwMDA3MDcwNjAwNzgw
ODAyMDEwMjBhMGE0NjYxNjk2YzQyNzU3NDc0DQorNmY2ZTAxMDIwNDIxMjEyMTIxMjEyMTIx
MjExNzAwMDE5ZmZmMGMwMDAwMDAwZDlkMDEyZTlkMDEyNDAwZTUwMQ0KKzQzMDAwMDAwMDAw
MzAzMDMwMzAwMDUwMTAxYTBhMDAwMDAwMDAwMDAwMDAwMDAwMDljZTU5ZDAxNDMwMDAwMDAN
CiswMDAwMDAwMTBiMDQwNDQ2NjE2OTZjMDAwMjAxMDAwMDAwMDAwNzFhOTE5YzljOWNhMzlk
MDEwMzlkMDEwZTlkDQorMDE3MjE2MTkxYTM4NjI2Mzc3OTE5YjljOWM5Y2EwOWNhMzljYzE5
Y2ViOWNlYzlkMDEwMDlkMDEwMzlkMDEwZA0KKzlkMDEwZTlkMDEzNjlkMDE2MzlkMDE2NDlk
MDE3MjAzMDENCi0wMDQ2ODRhMA0KDQoNCmVuZCBjbGFzczsNCg0KY2xhc3MgV2luIGlzIG1h
cHBlZCBpbmhlcml0cyBmcm9tIERpc3BsYXlQcm9qZWN0LlVzZXJXaW5kb3cNCg0KDQpoYXMg
cHVibGljICBtZXRob2QgRGlzcGxheTsNCmhhcyBwdWJsaWMgIG1ldGhvZCBJbml0Ow0KDQpo
YXMgcHVibGljICBldmVudCBoYW5kbGVyIFdpbkNsb3NlSGFuZGxlcihpbnB1dCBwV2luOiBU
b3NzTWUuTmV3V2luKTsNCg0KaGFzIHByb3BlcnR5DQoJc2hhcmVkPShhbGxvdz1vbiwgb3Zl
cnJpZGU9b24sIGRlZmF1bHQ9b2ZmKTsNCgl0cmFuc2FjdGlvbmFsPShhbGxvdz1vbiwgb3Zl
cnJpZGU9b24sIGRlZmF1bHQ9b2ZmKTsNCgltb25pdG9yZWQ9KGFsbG93PW9uLCBvdmVycmlk
ZT1vbiwgZGVmYXVsdD1vZmYpOw0KCWRpc3RyaWJ1dGVkPShhbGxvdz1vZmYsIG92ZXJyaWRl
PW9mZik7DQoNCmhhcw0KKzUxNTE0NjMxMDAwMDAyM2QwMDAwMDFlOTlmZTMwMTAxMDAwMDIx
MDEwMjAwMDAwMDAwMDIwMjA2MDA5NDA4MDANCisxZDAwOWZmZjAxMDEwNDIxMGYxMDExMTIw
MTAxMDExNzAwMDA5ZmZmMDAwMDAwMDAwZDAwMDAwYmI4MGZhMDAwDQorMDAwMDAwMDAwMDAw
MDAwMDAwMDEwMTYwNjAwMDAwMDAwMDAwMDAwMDAwMDA5ZDBiYjg5ZDBmYTAwMDAwMDAwMA0K
KzAwMDAwMTA4MDMwMzAxZmZmZDAwMDAwMDAwMDAwMDAwMDAwMjAxMDAwMDAwMDAwZjA0MDUw
MDA2MDAwMDAyMDENCiswMDAxMDAwMDBkMDAwMDAxMDAwYjAwMDEwMDAwMDAwMDAwMDMwMDAw
MjEwMTAyMDAwMDAwMDAwNTA0MDAwMDFjDQorMDIwMDEwMDUwNjAwN2EwODAwNGQwMDlmZmYw
MTAxMDEwMTBmMTAxMTEyMDEwMTAxMTcwMDAwOWZmZjAxMDAwMA0KKzAwMGQwMDAwNWRjMDVk
YmYwMDAwMDAwMDAzMDMwMzAzMDAwMjA0MDRhMGEwMDAwMDAwMDAwMDAwMDAwMDAwOWQNCis1
ZGMwOWQ1ZGJmMDAwMDAwMDAwMDAwMDEwODA2NjgwMTAwMDAwMDVkYzA1ZGJmMDAwMDAwMDIw
MTAwMDAwMDAwDQorMDkwMDAwMDYwMDAwMjEwMjAyMDAwMDAwMDAwNzA4MDcwNjAwZjYwODIw
ODkwMjA3MDc2NDYxNzQ2MTRmNmU2NQ0KKzAxMDIwYjIxMjEyMTIxMjEwMTAxMDExNzAwMDEw
ODA4NTQ2NTc4NzQ0NDYxNzQ2MTBjMDAwMDAwMGQ5ZDA2MWENCis5ZDA2MjUwMGM2MDUzNTAw
MDAwMDAwMDMwMzAzMDMwMDA1MDEwMjgwYTAwMDAwMDAwMDAwMDAwMDAwMDA5Y2M2DQorOWQw
NTM1MDAwMDAwMDAwMDAwMDEwMzAyMDEwNzAwMTMwMDAwMDlmZjgxMDAwMDllMDA0MDAwMTQw
MzAxMDAwOA0KKzA2MDA3ODA4MDIwMTAyMDcwNzYyNzQ2ZTRmNzA2NTZlMDEwMjA0MjEyMTIx
MjEyMTIxMjEyMTE3MDAwMjlmZmYNCiswZDAwMDAwMDBkOWQwOTEzOWQwOWVlMDBlNTAzOTUw
MDAwMDAwMDAzMDMwMzAzMDAwNTAxMDFhMGEwMDAwMDAwDQorMDAwMDAwMDAwMDAwOWNlNTlk
MDM5NTAwMDAwMDAwMDAwMDAxMGIwZDBkNGY3MDY1NmUyYzIwNTM2NTczNjE2ZA0KKzY1MjEw
MDAyMDEwMDAwMDAwMDA4MWE5MTljOWM5Y2EzOWQwMTAzOWQwMTBmOWQwMTdmOWQwMWU5MWMx
OTFhMzgNCis2MjYzNzc5MTliOWM5YzljYTA5Y2EzOWNjMTljZWI5Y2VjOWQwMTAwOWQwMTAz
OWQwMTBkOWQwMTBmOWQwMTNjDQorOWQwMTY5OWQwMTZhOWQwMTZkOWQwMTcyOWQwMTdmOWQw
MWE0OWQwMWQxOWQwMWQyOWQwMWU5MDMwMQ0KLTAwODg1MDI2DQoNCg0KZW5kIGNsYXNzOw0K
LS0gRU5EIENMQVNTIERFRklOSVRJT05TDQoNCi0tIFNUQVJUIFNFUlZJQ0UgT0JKRUNUIERF
RklOSVRJT05TDQotLSBFTkQgU0VSVklDRSBPQkpFQ1QgREVGSU5JVElPTlMNCg0KLS0gU1RB
UlQgQ1VSU09SIERFRklOSVRJT05TDQotLSBFTkQgQ1VSU09SIERFRklOSVRJT05TDQoNCi0t
IFNUQVJUIFRZUEVERUYgREVGSU5JVElPTlMNCi0tIEVORCBUWVBFREVGIERFRklOSVRJT05T
DQoNCi0tIFNUQVJUIE1FVEhPRCBERUZJTklUSU9OUw0KDQotLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCm1ldGhvZCBOZXdX
aW4uRGlzcGxheQ0KYmVnaW4NCnNlbGYuT3BlbigpOw0KZXZlbnQgbG9vcA0KICAgICAgICB3
aGVuIHRhc2suU2h1dGRvd24gZG8NCiAgICAgICAgICAgICAgICB0YXNrLmxnci5wdXRsaW5l
KCdzaHV0ZG93bicpOw0KICAgICAgICAgICAgICAgIGV4aXQ7DQogICAgICAgIHdoZW4gV2lu
ZG93LkFmdGVyRGVhY3RpdmF0ZSBkbw0KICAgICAgICAgICAgICAgIHRhc2subGdyLnB1dGxp
bmUoJ2RlYWN0Jyk7DQogICAgICAgICAgICAgICAgDQogICAgICAgIHdoZW4gPEZhaWxCdXR0
b24+LkNsaWNrIGRvDQovLwkJCWRvIGFuIGludmFsaWQgb3BlcmF0aW9uLiBsZXRgc2VlIHdo
YXQgaGFwcGVucw0KCQkJdCA6IFRleHREYXRhOw0KCQkJdC5TZXRWYWx1ZSgnTklMIGV4Y2Vw
dGlvbiBzaG91bGQgcmFpc2UgaGVyZScpOw0KCQkJICAgICAgICANCmVuZCBldmVudDsNCnNl
bGYuQ2xvc2UoKTsNCmVuZCBtZXRob2Q7DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KbWV0aG9kIE5ld1dpbi5Jbml0
DQpiZWdpbg0Kc3VwZXIuSW5pdCgpOw0KZW5kIG1ldGhvZDsNCg0KLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQptZXRob2Qg
V2luLkRpc3BsYXkNCmJlZ2luDQpkYXRhT25lLnNldFZhbHVlKCdTdHVmZicpOw0Kc2VsZi5P
cGVuKCk7DQpldmVudCBsb29wDQogICAgICAgIHdoZW4gdGFzay5TaHV0ZG93biBkbw0KICAg
ICAgICAgICAgICAgIGV4aXQ7DQogICAgICAgIHdoZW4gPGJ0bk9wZW4+LkNsaWNrIGRvDQog
ICAgICAgICAgICAgICAgdyA6IE5ld1dpbiA9IG5ldzsNCiAgICAgICAgICAgICAgICBzdGFy
dCB0YXNrIHcuRGlzcGxheSgpIHdoZXJlIGNvbXBsZXRpb249ZXZlbnQ7DQogICAgICAgICAg
ICAgICAgcmVnaXN0ZXIgV2luQ2xvc2VIYW5kbGVyKHcpOw0KZW5kIGV2ZW50Ow0Kc2VsZi5D
bG9zZSgpOw0KZW5kIG1ldGhvZDsNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQptZXRob2QgV2luLkluaXQNCmJlZ2lu
DQpzdXBlci5Jbml0KCk7DQpkYXRhT25lID0gbmV3Ow0KZW5kIG1ldGhvZDsNCg0KLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQpldmVudCBoYW5kbGVyIFdpbi5XaW5DbG9zZUhhbmRsZXIoaW5wdXQgcFdpbjogVG9zc01l
Lk5ld1dpbikNCmJlZ2luDQp3aGVuIHBXaW4uTmV3V2luZG93RmluaXNoZWQgZG8NCglkYXRh
T25lID0gbmV3Ow0KCXRhc2sucGFydC5sb2dtZ3IucHV0bGluZSgnTmV3V2luZG93RmluaXNl
ZCcpOw0KCQ0Kd2hlbiBwV2luLk5ld1dpbmRvd0ZhaWxlZCBkbw0KCWRhdGFPbmUgPSBuZXc7
CQ0KZW5kIGV2ZW50Ow0KLS0gRU5EIE1FVEhPRCBERUZJTklUSU9OUw0KSEFTIFBST1BFUlRZ
DQoJQ29tcGF0aWJpbGl0eUxldmVsID0gMDsNCglQcm9qZWN0VHlwZSA9IEFQUExJQ0FUSU9O
Ow0KCVJlc3RyaWN0ZWQgPSBGQUxTRTsNCglNdWx0aVRocmVhZGVkID0gVFJVRTsNCglJbnRl
cm5hbCA9IEZBTFNFOw0KCUxpYnJhcnlOYW1lID0gJ3Rvc3NtZSc7DQoJU3RhcnRpbmdNZXRo
b2QgPSAoY2xhc3MgPSBXaW4sIG1ldGhvZCA9IERpc3BsYXkpOw0KDQoNCmVuZCBUb3NzTWU7
DQo=
--------------4E6A4194374DC1BDF50CB1A1--

Bobby,
The simplest solution I think would be to use grids and map them to some business class - which I suppose you must be already using. In the event handler of the first window (button.click event) after you call the display method of the second window you can new the business class.
Kapil
From: Zirney, Bobby[SMTP:[email protected]]
Sent: Donnerstag, 2. September 1999 02:33
To: '[email protected]'
Subject: (forte-users) Question
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BEF4BD.83F24DA6
Content-Type: text/plain;
charset="iso-8859-1"
I have a frame with a button on it that will open up another frame. When I
close the second frame by pressing the X in the top right hand corner, I
want to clear all the data on the first screen. I have been trying all
sorts of things without success. Does anyone have any suggestions as to how
to do this?
------_=_NextPart_001_01BEF4BD.83F24DA6
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<DEFANGED-META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<DEFANGED-META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<DEFANGED-TITLE>Question</TITLE>
</HEAD>
<BODY>
I have a frame with a button on it =
that will open up another frame. When I close the second frame by =
pressing the X in the top right hand corner, I want to clear all the =
data on the first screen. I have been trying all sorts of things =
without success. Does anyone have any suggestions as to how to do =
this?
</BODY>
</HTML>
------_=_NextPart_001_01BEF4BD.83F24DA6--
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]

NT User Extensible Policy - what am I missing ?

Hi,
NT4SP6a Workstation, NW Client 4.83
Zen 3.2 on NW6SP3 server.
I have created one simple user.
Then I created a User Policy Package, including a DLU policy and a User
Extensible Policy, in which I disabled "Registry editing tools".
I have assigned my policy to my user :
- the DLU policy works fine, my user is created at login, in the user group
I've chosen
- unfortunately, the user has access to regedit, and the parameters I
modifiy in the common.adm policy does not seem to be applied.
What did I miss ?

I once noticed a strange behaviour you might want to check.
When working in the policy package, I associated the policy package directly
to users.
It failed to apply.
I looked at the user for associated policies and it was empty. I can't
really remember whether or not the new policy association showed up in
effective policies or not. I suspect not.
So I worked from the user screen and associated the policy and it worked.
Maybe that will work for you.
Chris Denby
IT Coordinator
Rainy River District School Board
Fort Frances, Ontario
Canada
<[email protected]> wrote in message
news:CfvHd.655$[email protected]..
> Hi,
>
> NT4SP6a Workstation, NW Client 4.83
> Zen 3.2 on NW6SP3 server.
>
> I have created one simple user.
>
> Then I created a User Policy Package, including a DLU policy and a User
> Extensible Policy, in which I disabled "Registry editing tools".
>
> I have assigned my policy to my user :
>
> - the DLU policy works fine, my user is created at login, in the user
group
> I've chosen
> - unfortunately, the user has access to regedit, and the parameters I
> modifiy in the common.adm policy does not seem to be applied.
>
> What did I miss ?

RE: (forte-users) XMLParser-Node : Serializing parts of aDOM across par

I managed to solve this problem with the help of
Sanjeev Sondur and Girish Nair from Sun.
The Solution suggested is as follows :
Whenever a node is supposed to passed as a parameter
for an inter-partition call. We have marshal and
UN-Marshalling :
- Create a new document.
- Clone the node in the context on the new document
- Append the node to the new document
- Serialize the document into a MemoryStream which is
a attribute of the object (SerializedNode) that
is passed in Lieu of a Node.
- On the other end UnMarshall by DeSeralizing the Document
and then reading the node.
Code Follows :
SerializedNode::SerializeNode(pNode);
NewDoc : document = new();
lNode : node;
if pNode <> nil then
-- This clones the node from an old document and creates it
-- in the context of the new document.
lNode = NewDoc.ImportNodeFromDocument(pNode, deep = true);
-- You can then attach to the any part of DOM (I am using
child of root)
NewDoc.appendchild(lNode);
end if;
-- _mStream is MemoryStream
mStream.Open(Framework.SPAM_WRITE, IsBinary = TRUE);
_mStream.seek(0);
_mStream.WriteSerialized(NewDoc);
_mStream.close();
On the other end I Unmarshall it
SerializedNode::GetNode()
mStream.Open(Framework.SPAM_READ, IsBinary = TRUE);
_mStream.seek(0);
NewDoc : document = (Document)(_mStream.ReadSerialized());
lNode : node = NewDoc.getFirstChild();
if lNode = NIL then
task.lgr.putline(' In GetNode : Node was NIL');
end if;
return lNode;
Note : This can use used for read-only access to parts of the DOM.
across partitions.
Thanks to all who responded.
Vivek Shetty
vivekvi-corp.com vivek.shettyLibertyMutual.com
978-884-9942 (cell) 978-750-3639 x 202 (Liberty Mutual)
-----Original Message-----
From: Shetty, Vivek [mailto:Vivek.ShettyLibertyMutual.com]
Sent: Thursday, December 21, 2000 10:04 AM
To: 'forte-userslists.xpedior.com'
Subject: (forte-users) XMLParser-Node : Serializing parts of a DOM
across partitions
I am modeling an Insurance-Policy as a XML document.
One of my requirement was to pass pieces of this Policy (Node)
to a service object for processing.
I have discovered that the Node cannot be serialized across partitions.
I can serialize the whole document using the exportDocument and send
it across the partition and import it on the other end. This is fine when
large pieces of the document have to be sent over.
When smaller pieces of this information has to sent to a service object,
I was planning to create a new document, extract the required nodes
from the old document create in the new document and send the
new document (which is a subset) across.
I am having problems extracting a node from one document and
creating it another document.
I have tried node.clonenode, document.importnodefromdocument without much
success.
I have a choice of writing a method that creates a structure in the new
document by
recursively navigating the old tree and creating new nodes in the new
document from scratch.
Have any of you faced similar situations and come up with a more elegant
solution.
Please share.
Thanks
Vivek Shetty
vivekvi-corp.com vivek.shettyLibertyMutual.com
978-884-9942 (cell) 978-750-3639 x 202 (Liberty Mutual)
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Re: (forte-users) size policy in TabFolder

Similar Messages

Maybe you are looking for