Forte & MSMQ
Does anybody have any experience with Forte and MSMQ integration???
Here are the details:
We are currently deployed on Windows NT and Windows 3.1 for the Client
partition. Our server partitions are deployed on UNIX (AIX). We also
have WEB access built into the system using Forte's WEBsdk.
We must integrate with another (non-Forte) application that resides on
NT server. We want to use MSMQ as a means to communicate to this
application.
My preferred partitioning scheme is as follows:
I plan to create a new partition and move it to the NT Server. The
Service Object on the NT server will be accessible from both the client
partition and the server level (UNIX based) partitions. This is the
first time I am adding another server to the mix.
The new partition on the NT Server will serve as the interface to the
other application (via MSMQ). By the way, MSMQ is the only game in
town, because our vendor does not provide an open API. They rely on
MSMQ for everything...
At this time, I don't necessarily have a preference with regard to how
we link to MSMQ. However, I can say that performance is paramount. I
originally preferred OLE or ActiveX, but I think I can easily be talked
into C/C++ wrappering; especially now that Forte has C++ call-in
capability in version 3.0.
I'd appreciate hearing from anyone who has integrated Forte with MSMQ.
Thanks
James Krzeszowski
Project Manager
Advanta Business Services
[email protected]
The SunWS_Cache directory must have write permission. The cache contains state information that must be locked when a compiler is being run, to avoid trashing the state information if another compilation runs in the same directory at the same time. (Sun C++ supports dmake and gmake for running multiple compilations in parallel.)
A non-writeable template cache is not an available option.
Starting with C++ 5.5 (Sun ONE Studio 8 Compiler Collection), the template cache is no longer required, and by default is not used. If you are having problems involving the cache, you should consider upgrading to this new release.
Similar Messages
-
RE: (forte-users) 3J= 3M new to me error
Hi Thomas,
Thanks for your email but I think it will be interesting for Brenda not me.
It is exactly what I have expected from Forte Support: detailed information
about bugs and workarounds. But what I cannot understand is that #53398 was
released without any information about possible reasons for this problem or
suggested workarounds. My first reaction after reading this bugreport was to
open a new case at CallCenter to get more information about it. Please
release more information with your bug reports !
Regards
Zenon Adamek
Information Services
Senior Programmer Analyst
Tel: 905 712-1084 ext. 3628
Fax: 905 712-6709
E-mail: zadamekpurolator.com
-----Original Message-----
From: Thomas Degen - Sun Germany Forte Tools - Bonn
[SMTP:thomas.degensun.com]
Sent: Wednesday, September 27, 2000 9:49 AM
To: Adamek, Zenon
Cc: 'Brenda Cumming'; Forte-userslists.xpedior.com
Subject: RE: (forte-users) 3J=>3M new to me error
Hi Zenon,
bug #53398 is not a bug which will likely get fixed, it's an informational
bugreport.
You might see an errorstack like Brenda has reported (and described in
informational
bugreport #53398) probably when you are doing something illegal that is
possible
via Forte Tool but Forte is not trapping it for performance reasons. Hence
you will see
the error coming from your illegal operation only at runtime, probably
only
while
running interpreted in the Forte IDE, but in worst case it might be even a
segmentation
violation.
Technotes 12448 'Sudden client partition crashes at runtime' and 11225
'Don't reparent
mapped Widgets between UserWindows at runtime' explain this matter . See
attached.
But maybe Brenda is much more experiencing a problem as described by Forte
Technote 11398 'Read Only Workspace Errors using ListViews or ActiveX
control'
that might get easily resolved via setting of FORTE_YIELD_THROTTLE=0.
Good Luck and Best Regards !
BTW: I've logged bug #53398, so I've felt responsible to explain its real
background.
Thomas
Thomas Degen
Sun Microsystems - Forte Tools
Forte CTE & Sustaining Group
Technical Support Germany
tel.:+49.228/91499-50
MailTo:thomas.degensun.com
Technote 11398 Read Only Workspace Errors using ListViews or ActiveX
control
SCENARIO:
Getting some unusual interpreter errors that result in an error stating
that
the workspace has been set to read only. Please see Enclosures for the
two
most common error stacks that have been encountered. The abbreviated
versions of the errors are:
- Can't read record (record size = -1)
- Id in index does not match id in record header in data file
- Recursive deserialization attempted.
- Unknown Mark type in deserialization
- Could not read record (64,74615) from repository data file.
Header
is corrupt.
These errors can be happening in either the development environment when
running from one of the development workshops, or with the deployed
application.
The bug outlined in this Technote may be the culprit if the errors above
are
seen when running a client on Windows NT or Motif and the user interface
incorporates ActiveX controls or ListView/TreeView widgets.
CAUSE:
Basically what is happening is that in rare circumstances Forte may invoke
a
nested copy of the interpreter while the first interpreter has yielded.
This
is not a problem in and of itself, but in the case where the original
interpreter was in the middle of a repository fetch when it yielded, and
the second interpreter needs to fetch code as well, we will get one of the
errors listed above, depending on the exact timing. The reason for the
errors is that the repository code at this level is thread-safe but not
re-entrant. It is protected by a mutex that is already owned by the
current task. Which, given the scenario outlined here, where the two
interpreters are running inside of the same task, results in the nested
interpreter being allowed to change data out from under the first.
While for every fetch one or more calls to WindowSystem.Yield will be made
(this is there to prevent the semblance of system lock-up on Win 3.1,
where
Yield is the only way other applications can be allowed to run), there is
a parameter which controls how often to actually yield, which by default
is
set to one out of every 100 calls. This is the reason the problem is
intermittent--you need a yield to occur during a repository fetch
which starts another interpreter which also needs to fetch code from
disk.
The reason this has only surfaced recently is that the nested interpreter
scenario can only happen in 2 cases that we know of:
- ActiveX controls which respond to events/Windows messages
- Outline fields/ListViews with column(s) mapped to virtual
attributes
In all other normal cases, the yield can process the message (typically a
paint message) without starting another interpreter, so regardless of
whether
the first interpreter yielded during a repository operation or not, there
is
no conflict.
SOLUTION:
The workaround is to prevent yields altogether by setting the
FORTE_YIELD_THROTTLE environment variable equal to 0 in the client's
environment. This should have no detrimental effects since the yield code
is in place solely for Windows 3.1x clients.
ERROR STACK 1
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to
prevent the application from attempting to write to the repository. The
repository and work you have saved to the repository are safe. If your
workspace
contains unsaved work, you may use the following procedure to save this
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import
the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::GetObjectById
Last TOOL statement: method EFWindowController.EFEventLoop
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
The remainder of the Error Manager stack is:
SYSTEM ERROR: Internal Error attempting to deserialize element (64,67470)
(fetch
bitmask is 0x20). Your workspace is now read-only to prevent the
application
from attempting to write to the repository. The repository and work you
have
saved to the repository are safe. If your workspace contains unsaved work,
you
may use the following procedure to save this work. First, export the
changed
components. Then, shut down and restart this application and reopen this
workspace in read-write mode. Finally, import the changed components and
save
your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Last TOOL statement: method EFTabManagerNew.EFNoteBookHandler
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
SYSTEM ERROR: Unknown Mark type in deserialization.
Class: qqsp_ImplementationException
Error #: [1101, 34]
Detected at: qqrp_DeSerializeObject::ProcessHdr
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
ERROR STACK 2
SYSTEM ERROR: A serious error has occurred in Repository
(c:\PROGRA~1\CSSPTEST\conplu0). Corrective action may be necessary.
Notify
your repository administrator.
Class: qqsp_ImplementationException
Error #: [1101, 198]
Detected at: qqrp_Repository::Fetch
Last TOOL statement: method
SalesDevelopment_NWC.DEVNotifyofTabSetCurrent
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
SYSTEM ERROR: Could not read record (64,74615) from repository data file.
Header is corrupt.
Class: qqsp_ImplementationException
Error #: [1106, 612]
Detected at: qqbt_BtreeAccess::FetchDataFileRecord
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
Technote 11225 Don't reparent mapped Widgets between UserWindows at
runtime
It is sometimes tempting to unparent a widget from one UserWindow and
reparent
it into another at runtime. However, this can cause crashes if the widget
(or
its decendants) are "mapped" to data. Here's why...
Suppose you have two UserWindows, UW1 and UW2. UW1 contains a DataField
(DF1)
which is mapped to a TextData. UW2 contains a RadioList (RL2) which is
mapped to
a scalar Integer. At compile time, every mapped attribute is internally
assigned
a "Map ID" (a small integer) which is used to tie the Widget to its
corresponding attribute. These Map IDs are used by the Widget to look up a
pointer to their data in a "Map" which is maintained by the UserWindow.
Each
UserWindow is assumed be to independent of the others, so there is nothing
wrong
with Widgets in different UserWindows being assigned the same Map IDs.
In
this
case, let's assume that DF1 and RL2 both got assigned the same Map ID of
3. No
problem so far, since each lives in a separate UserWindow with a separate
map.
Now suppose at runtime the application "detaches" or unparents DF1 from
its
UserWindow and reparents it somewhere into UW2. When it comes time for DF1
to
paint itself the Display System it must ask the Runtime System for the
value of
DF1's mapped attribute. To do that it says "give me the value of the
TextData
for DF1. You'll find it in the Map for this UserWindow (UW1), and its Map
ID is
3". When the runtime system goes to do this it expects to find a TextData
in
this "slot" of the map, but instead it picks up the integer which is
mapped to
RL2. At best this leads to bad data being returned; more likely you get a
segfault and a crash.
If DF1 was not a mapped attribute (say, a Rectangle) there would be no
problem
because there is no data mapped to a Rectangle. If instead of moving DF1
you
created a brand new DataField on the fly there would be no problem,
because the
dynamic DataField would not have any Map ID and so couldn't conflict with
any
IDs in UW2.
So how do you solve this problem? This is exactly what Nested Windows are
all
about. While you can't move DF1 into the middle of UW2, you can nest
UW1.
This
works because UW1 brings its map with it, and when you access DF1 it knows
to
look up its value in UW1's map.
UserWindows are intended to be the "unit of compilabilty" that can be
nested
inside other UserWindows. It is dangerous to "transplant" anything from
inside
one UserWindow into another at runtime.
(Note that you can't avoid this problem by cloning DF1 because the MapID
gets
copied along with it, and the clone will fail in the same way.)
Further details explained in related technote 12448 'Sudden client
partition
crashes at runtime.'
Technote 12448 Sudden client partition crashes at runtime
Scenario : You have two UserWindows, A and B. When Window A starts up, it
instantiates an instance of B and reparents some component of B into A's
window
hierarchy.
This is not allowed and almost always leads to an error at best or at
worse a
segmentation fault.
Here's why :
When you compile a UserWindow in Forte, each "mapped attribute" (whether a
form
element or menu element) is assigned an internal ID which represents an
offset into
that UserWindow's table of mapped attributes. This offset is only valid
in the
context of the UserWindow in which it was compiled. If you detach a
FieldWidget or
MenuWidget from one compiled Window ("tmpMenu" for example) and then
parent
into another compiled window ("tmpWindow") the internal ID comes with it.
When Forte tries to make use of that copied widget it uses the ID as an
offset
into tmpWindow's table of mapped attributes. But that copied offset is
meaningless in the context of tmpWindow's table, so you get some kind off
error.
In this case it found that the data type of the variable in the slot
wasn't
what
was expected. But you might even index off the end of the table and get a
segmentation fault.
There is nothing to prevent you from dynamically creating menu items and
adding
them to a window at runtime; that will work fine. Although of course you
can't
access them via mapped attributes, since those can only be created at
compile time.
But you are not allowed to reparent a widget from one compiled UserWindow
into
the hierarchy of another.
More information may be found in technote 11225 'Don't reparent mapped
Widgets
between UserWindows at runtime'.
Possible errorstacks seen at runtime instead of a complete crash or
segmentation
violation while you are illegally reparenting a widget or menuitem between
windows
at runtime:
Map::SetSubjectData: Invalid conversion from map type 0 to subject type 22
SYSTEM ERROR: Bad parameter at location 3 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 3
Error Time: Wed Aug 09 13:03:57
Exception occurred (locally) on partition "testproject_CL0_Client",
(partitionId = D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd,
taskId =
[D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd.68]) in application
"FTLaunch_cl0", pid 672 on node ONEWAY in environment Audi3M2Env.
At 13:14 26.09.00 -0400, Adamek, Zenon wrote:
Hi,
It is the unfixed defect 53398. Please contact Forte support.
Zenon
-----Original Message-----
From: Brenda Cumming [SMTP:brenda_cummingtranscanada.com]
Sent: Tuesday, September 26, 2000 1:15 PM
To: Forte User group
Subject: (forte-users) 3J=>3M new to me error
Hi,
We are in the process of going from 3J1 to 3.0.M.2, and I am getting
this error that I am unfamiliar with on a GUI that works fine in 3J.
It
does not happen all the time, and I have been unable to establish the
pattern that kicks it off. Has anyone seen this before?
PS- this error is not occurring in the deployed (non-compiled) app,but
when I am running locally from my workspace.
SYSTEM ERROR: Bad parameter at location 6 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 6
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2,
taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Can't find scope 20070 for a class.
Class: qqsp_Exception
Error #: [201, 11]
Detected at: qqlo_ClassTableLoadScope at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to prevent the application from attempting to write to the repository.
The repository and work you have saved to the repository are safe. If
your
workspace contains unsaved work, you may use the following procedure
to save this work. First, export the changed components. Then, shut down and
restart this application and reopen this workspace in read-write mode.
Finally, import the changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::IsDistributed
Last TOOL statement: method PPMeasWin.
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Internal Error attempting to deserialize element
(64,120684) (fetch bitmask is 0x20). Your workspace is now read-onlyto
prevent
the application from attempting to write to the repository. The
repository
and work you have saved to the repository are safe. If your workspace
contains unsaved work, you may use the following procedure to savethis
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Recursive Deserialization attempted, Internal Error!
Class: qqsp_UsageException with ReasonCode: SP_ER_INVALIDSTATE
Error #: [301, 231]
Detected at: qqsp_DeSerializeDriver::Run at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in anew
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.comHi Thomas,
Thanks for your email but I think it will be interesting for Brenda not me.
It is exactly what I have expected from Forte Support: detailed information
about bugs and workarounds. But what I cannot understand is that #53398 was
released without any information about possible reasons for this problem or
suggested workarounds. My first reaction after reading this bugreport was to
open a new case at CallCenter to get more information about it. Please
release more information with your bug reports !
Regards
Zenon Adamek
Information Services
Senior Programmer Analyst
Tel: 905 712-1084 ext. 3628
Fax: 905 712-6709
E-mail: zadamekpurolator.com
-----Original Message-----
From: Thomas Degen - Sun Germany Forte Tools - Bonn
[SMTP:thomas.degensun.com]
Sent: Wednesday, September 27, 2000 9:49 AM
To: Adamek, Zenon
Cc: 'Brenda Cumming'; Forte-userslists.xpedior.com
Subject: RE: (forte-users) 3J=>3M new to me error
Hi Zenon,
bug #53398 is not a bug which will likely get fixed, it's an informational
bugreport.
You might see an errorstack like Brenda has reported (and described in
informational
bugreport #53398) probably when you are doing something illegal that is
possible
via Forte Tool but Forte is not trapping it for performance reasons. Hence
you will see
the error coming from your illegal operation only at runtime, probably
only
while
running interpreted in the Forte IDE, but in worst case it might be even a
segmentation
violation.
Technotes 12448 'Sudden client partition crashes at runtime' and 11225
'Don't reparent
mapped Widgets between UserWindows at runtime' explain this matter . See
attached.
But maybe Brenda is much more experiencing a problem as described by Forte
Technote 11398 'Read Only Workspace Errors using ListViews or ActiveX
control'
that might get easily resolved via setting of FORTE_YIELD_THROTTLE=0.
Good Luck and Best Regards !
BTW: I've logged bug #53398, so I've felt responsible to explain its real
background.
Thomas
Thomas Degen
Sun Microsystems - Forte Tools
Forte CTE & Sustaining Group
Technical Support Germany
tel.:+49.228/91499-50
MailTo:thomas.degensun.com
Technote 11398 Read Only Workspace Errors using ListViews or ActiveX
control
SCENARIO:
Getting some unusual interpreter errors that result in an error stating
that
the workspace has been set to read only. Please see Enclosures for the
two
most common error stacks that have been encountered. The abbreviated
versions of the errors are:
- Can't read record (record size = -1)
- Id in index does not match id in record header in data file
- Recursive deserialization attempted.
- Unknown Mark type in deserialization
- Could not read record (64,74615) from repository data file.
Header
is corrupt.
These errors can be happening in either the development environment when
running from one of the development workshops, or with the deployed
application.
The bug outlined in this Technote may be the culprit if the errors above
are
seen when running a client on Windows NT or Motif and the user interface
incorporates ActiveX controls or ListView/TreeView widgets.
CAUSE:
Basically what is happening is that in rare circumstances Forte may invoke
a
nested copy of the interpreter while the first interpreter has yielded.
This
is not a problem in and of itself, but in the case where the original
interpreter was in the middle of a repository fetch when it yielded, and
the second interpreter needs to fetch code as well, we will get one of the
errors listed above, depending on the exact timing. The reason for the
errors is that the repository code at this level is thread-safe but not
re-entrant. It is protected by a mutex that is already owned by the
current task. Which, given the scenario outlined here, where the two
interpreters are running inside of the same task, results in the nested
interpreter being allowed to change data out from under the first.
While for every fetch one or more calls to WindowSystem.Yield will be made
(this is there to prevent the semblance of system lock-up on Win 3.1,
where
Yield is the only way other applications can be allowed to run), there is
a parameter which controls how often to actually yield, which by default
is
set to one out of every 100 calls. This is the reason the problem is
intermittent--you need a yield to occur during a repository fetch
which starts another interpreter which also needs to fetch code from
disk.
The reason this has only surfaced recently is that the nested interpreter
scenario can only happen in 2 cases that we know of:
- ActiveX controls which respond to events/Windows messages
- Outline fields/ListViews with column(s) mapped to virtual
attributes
In all other normal cases, the yield can process the message (typically a
paint message) without starting another interpreter, so regardless of
whether
the first interpreter yielded during a repository operation or not, there
is
no conflict.
SOLUTION:
The workaround is to prevent yields altogether by setting the
FORTE_YIELD_THROTTLE environment variable equal to 0 in the client's
environment. This should have no detrimental effects since the yield code
is in place solely for Windows 3.1x clients.
ERROR STACK 1
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to
prevent the application from attempting to write to the repository. The
repository and work you have saved to the repository are safe. If your
workspace
contains unsaved work, you may use the following procedure to save this
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import
the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::GetObjectById
Last TOOL statement: method EFWindowController.EFEventLoop
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
The remainder of the Error Manager stack is:
SYSTEM ERROR: Internal Error attempting to deserialize element (64,67470)
(fetch
bitmask is 0x20). Your workspace is now read-only to prevent the
application
from attempting to write to the repository. The repository and work you
have
saved to the repository are safe. If your workspace contains unsaved work,
you
may use the following procedure to save this work. First, export the
changed
components. Then, shut down and restart this application and reopen this
workspace in read-write mode. Finally, import the changed components and
save
your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Last TOOL statement: method EFTabManagerNew.EFNoteBookHandler
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
SYSTEM ERROR: Unknown Mark type in deserialization.
Class: qqsp_ImplementationException
Error #: [1101, 34]
Detected at: qqrp_DeSerializeObject::ProcessHdr
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
ERROR STACK 2
SYSTEM ERROR: A serious error has occurred in Repository
(c:\PROGRA~1\CSSPTEST\conplu0). Corrective action may be necessary.
Notify
your repository administrator.
Class: qqsp_ImplementationException
Error #: [1101, 198]
Detected at: qqrp_Repository::Fetch
Last TOOL statement: method
SalesDevelopment_NWC.DEVNotifyofTabSetCurrent
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
SYSTEM ERROR: Could not read record (64,74615) from repository data file.
Header is corrupt.
Class: qqsp_ImplementationException
Error #: [1106, 612]
Detected at: qqbt_BtreeAccess::FetchDataFileRecord
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
Technote 11225 Don't reparent mapped Widgets between UserWindows at
runtime
It is sometimes tempting to unparent a widget from one UserWindow and
reparent
it into another at runtime. However, this can cause crashes if the widget
(or
its decendants) are "mapped" to data. Here's why...
Suppose you have two UserWindows, UW1 and UW2. UW1 contains a DataField
(DF1)
which is mapped to a TextData. UW2 contains a RadioList (RL2) which is
mapped to
a scalar Integer. At compile time, every mapped attribute is internally
assigned
a "Map ID" (a small integer) which is used to tie the Widget to its
corresponding attribute. These Map IDs are used by the Widget to look up a
pointer to their data in a "Map" which is maintained by the UserWindow.
Each
UserWindow is assumed be to independent of the others, so there is nothing
wrong
with Widgets in different UserWindows being assigned the same Map IDs.
In
this
case, let's assume that DF1 and RL2 both got assigned the same Map ID of
3. No
problem so far, since each lives in a separate UserWindow with a separate
map.
Now suppose at runtime the application "detaches" or unparents DF1 from
its
UserWindow and reparents it somewhere into UW2. When it comes time for DF1
to
paint itself the Display System it must ask the Runtime System for the
value of
DF1's mapped attribute. To do that it says "give me the value of the
TextData
for DF1. You'll find it in the Map for this UserWindow (UW1), and its Map
ID is
3". When the runtime system goes to do this it expects to find a TextData
in
this "slot" of the map, but instead it picks up the integer which is
mapped to
RL2. At best this leads to bad data being returned; more likely you get a
segfault and a crash.
If DF1 was not a mapped attribute (say, a Rectangle) there would be no
problem
because there is no data mapped to a Rectangle. If instead of moving DF1
you
created a brand new DataField on the fly there would be no problem,
because the
dynamic DataField would not have any Map ID and so couldn't conflict with
any
IDs in UW2.
So how do you solve this problem? This is exactly what Nested Windows are
all
about. While you can't move DF1 into the middle of UW2, you can nest
UW1.
This
works because UW1 brings its map with it, and when you access DF1 it knows
to
look up its value in UW1's map.
UserWindows are intended to be the "unit of compilabilty" that can be
nested
inside other UserWindows. It is dangerous to "transplant" anything from
inside
one UserWindow into another at runtime.
(Note that you can't avoid this problem by cloning DF1 because the MapID
gets
copied along with it, and the clone will fail in the same way.)
Further details explained in related technote 12448 'Sudden client
partition
crashes at runtime.'
Technote 12448 Sudden client partition crashes at runtime
Scenario : You have two UserWindows, A and B. When Window A starts up, it
instantiates an instance of B and reparents some component of B into A's
window
hierarchy.
This is not allowed and almost always leads to an error at best or at
worse a
segmentation fault.
Here's why :
When you compile a UserWindow in Forte, each "mapped attribute" (whether a
form
element or menu element) is assigned an internal ID which represents an
offset into
that UserWindow's table of mapped attributes. This offset is only valid
in the
context of the UserWindow in which it was compiled. If you detach a
FieldWidget or
MenuWidget from one compiled Window ("tmpMenu" for example) and then
parent
into another compiled window ("tmpWindow") the internal ID comes with it.
When Forte tries to make use of that copied widget it uses the ID as an
offset
into tmpWindow's table of mapped attributes. But that copied offset is
meaningless in the context of tmpWindow's table, so you get some kind off
error.
In this case it found that the data type of the variable in the slot
wasn't
what
was expected. But you might even index off the end of the table and get a
segmentation fault.
There is nothing to prevent you from dynamically creating menu items and
adding
them to a window at runtime; that will work fine. Although of course you
can't
access them via mapped attributes, since those can only be created at
compile time.
But you are not allowed to reparent a widget from one compiled UserWindow
into
the hierarchy of another.
More information may be found in technote 11225 'Don't reparent mapped
Widgets
between UserWindows at runtime'.
Possible errorstacks seen at runtime instead of a complete crash or
segmentation
violation while you are illegally reparenting a widget or menuitem between
windows
at runtime:
Map::SetSubjectData: Invalid conversion from map type 0 to subject type 22
SYSTEM ERROR: Bad parameter at location 3 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 3
Error Time: Wed Aug 09 13:03:57
Exception occurred (locally) on partition "testproject_CL0_Client",
(partitionId = D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd,
taskId =
[D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd.68]) in application
"FTLaunch_cl0", pid 672 on node ONEWAY in environment Audi3M2Env.
At 13:14 26.09.00 -0400, Adamek, Zenon wrote:
Hi,
It is the unfixed defect 53398. Please contact Forte support.
Zenon
-----Original Message-----
From: Brenda Cumming [SMTP:brenda_cummingtranscanada.com]
Sent: Tuesday, September 26, 2000 1:15 PM
To: Forte User group
Subject: (forte-users) 3J=>3M new to me error
Hi,
We are in the process of going from 3J1 to 3.0.M.2, and I am getting
this error that I am unfamiliar with on a GUI that works fine in 3J.
It
does not happen all the time, and I have been unable to establish the
pattern that kicks it off. Has anyone seen this before?
PS- this error is not occurring in the deployed (non-compiled) app,but
when I am running locally from my workspace.
SYSTEM ERROR: Bad parameter at location 6 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 6
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2,
taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Can't find scope 20070 for a class.
Class: qqsp_Exception
Error #: [201, 11]
Detected at: qqlo_ClassTableLoadScope at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to prevent the application from attempting to write to the repository.
The repository and work you have saved to the repository are safe. If
your
workspace contains unsaved work, you may use the following procedure
to save this work. First, export the changed components. Then, shut down and
restart this application and reopen this workspace in read-write mode.
Finally, import the changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::IsDistributed
Last TOOL statement: method PPMeasWin.
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Internal Error attempting to deserialize element
(64,120684) (fetch bitmask is 0x20). Your workspace is now read-onlyto
prevent
the application from attempting to write to the repository. The
repository
and work you have saved to the repository are safe. If your workspace
contains unsaved work, you may use the following procedure to savethis
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Recursive Deserialization attempted, Internal Error!
Class: qqsp_UsageException with ReasonCode: SP_ER_INVALIDSTATE
Error #: [301, 231]
Detected at: qqsp_DeSerializeDriver::Run at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in anew
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com -
Using Forte 3.0 to deploy web app to iPlanet Web Server
Is anyone familiar with using Forte 3.0 to develop/deploy a web application to an iPlanet Server?
All I need is a simple walkthrough to create/deploy a "Hello World" app (it could be just a JSP) or a link to some document that covers this topic.
ThanksFor anyone who cares
First make a web module, then make a web application and add the web module you made. When adding it the Mapping field should contain whatever context of the module is. Then deploy the application. -
Hi All. I live outside of the USA and have an iPhone 4s. I'm going to Fort Lauderdale, FLA and want to data service for my iPhone ( navigation using google or imaps, browsing and voip ing when no wi fi available). I browsed the net but seems almost impossible. When I visited Toronto I was able to get data thru Koodo but I don't think this is offered in the USA. Anyone who has real experience with this please help. This is a situation that is best aided by persons who have experienced it. Thanks
Have a look here:
http://forums.macrumors.com/archive/index.php/t-982315.html -
Forte Transaction Management & 2PC
Forte Transaction Management & 2PC
The main purpose of 2PC in a distributed transaction manager is
to enable recovery from a failure that occurs during the window
of transaction commit processing. The Forte transaction manager was built
with this in mind but only with respect to the "volatile" (or "in memory")
objects that Forte manages. What this implies is that because Forte stores
objects in memory and not persistently on disk, the requirement of recovery
for these objects is significantly reduced (if not eliminated all together).
Forte follows a distributed 2PC model in that tasks and messages carry
along with them transaction identification and, during commit processing,
every distributed participant is polled for its availability to commit
the transaction. Applications saving persistent data to disk during a
distributed Forte transaction need to concern themselves with the potential
for failure during the commit processing window. Forte's prepare phase polls
each site (confirming a communications link with each distributed participant)
but no prepare request goes to the database primarily because (in release 1 and
2 of forte) no database supported a general distributed two-phase commit
(one could take issue with that in the case of Sybase, but rather than debate
this point, suffice it to say that the general direction in the industry for
support of this functionality was through TP monitors -- more on that later).
Once all sites are ready to commit Forte expects that the commit will
complete successfully. If at this moment, for example, a participating
Sybase server terminates (with data not yet committed) while a participating
Oracle server has already committed its unit of work, then the outcome of
the distributed transaction is inconsistent - if no one has yet committed
Forte will still abort the transaction. This "window of inconsistency"
is documented in the Forte TOOL manual.
Mission critical applications that require distributed transactions can
address this window of inconsistency in a number of ways:
* Utilize a TP monitor such as Encina (see below)
* Log distributed updates in an auxiliary database table (much like a
distributed transaction monitor's transaction-state log). This approach has
been the traditional banking application solution prior to the commercial
availability of products like Encina, Tuxedo, TopEnd, etc.
This solution is somewhat complex and is usually not generic enough
so as not to have to change code every time a new table or database
site is introduced into the application's data model.
* Rearrange the data model in order to eliminate the need for distributed
transactions. This is usually only a temporary solution (with smaller
numbers of active clients) and cannot be applied to complex legacy systems.
With the advent of the X/Open distributed transaction architecture (the
XA Interface) more database vendors have found that by complying with the
XA interface they can plug their database-specific implementation of
transaction into a globally managed transaction, with commit and abort
processing being conducted by a central coordinator. Of course, the
overall transaction manager coordinating the global transaction must
itself, persistently record the state of the different distributed
branches participating in the transaction. A significant portion of
the functionality provided by products such as Encina, Tuxedo, TopEnd and
OpenTP1 is to provide exactly this global transaction management.
Rather than extend the Forte distributed transaction manager with the
functionality necessary to manage and recover distributed transactions
that modify data on disk, Forte has chosen to integrate with the emerging
set of commercial transaction monitors and managers. This decision was
built into the original design of the Forte transaction model (using XA and
early Tuxedo white-papers as guidelines):
* In Forte release 2 an integration with Encina was delivered.
* In January 1997 a press release announced an integration of
OpenTP1 with Forte for release 3.
* The Forte engineering staff is currently investing integration
with other transaction management products as well.
Neil Goodman,
Forte Development.You don't. ("manage" a transaction)
There is nothing really to "manage".
A transaction is automatically started when you make any changes to data (e.g. fire off a DML statement).
You simply needs to issue a COMMIT or ROLLBACK when needed. A COMMIT at the end of the business transaction and not before (i.e. no committing every n number of rows). A ROLLBACK when hitting an exception or business logic error that requires the uncommitted changes to be undone.
That in a nutshell is it. It is that simple.
Oracle also supports creating savepoints and rolling back only some changes made thus far in the transaction.
The only other thing to keep in mind that a DDL in Oracle issues an implicit commit. Firing off a DDL with cause any exiting uncommitted transaction to be committed.
Transaction "logic/management" should not be made more complex than this. -
Automated Testing of Forte Applications
Dear Jim,
This is a technical and education Forum and I want to make sure everyone is
"educated" to your options out there. Our company specific purposes is
delivering testing solutions for Forte Developed applications. (Primary
responsibility is to help developers and qa staff) I have tried to answer
you questions as follows and to educate fellow Forte people on solutions
available to them. If you need more discussion about our tools, please
contact me directly.
To anyone interested in testing Forte Applications:
1) What product are developers using to automate the process of testing
Forte applications?
IQTest- Unit Level Testing Tool that tests specific Forte methods and
saves them for automatic regression testing.
IQTrace: Unit Level Pathway Testing. Tests specific method level and
functional threads and saves them for automatic regression testing.
2) If there is a tool, how long does it take to create a typical test?
- Class I.Q. automatically generate the test classes and instantiates the
object under test. A typical setup for a developer is about 30 minutes
which is done once. The actual process of testing methods or traces takes
seconds. All tests are saved to any Forte database for automatic
regression testings.
3) Can the test include the testing of persistance to a database?
Yes, Our products are written to test persistance in a database and all
fully supported to test service objects which is currently a major issue
that most development teams are running into problems with.
4) What type of testing can be performed: black box testing, white box
testing, integration testing, UI testing, etc.?
Class I.Q. is considered a "White Box" approach to testing. It is
exercising the source code and creating an output for each method call.
The test cases then are dynamically linked into a trace.
Some of the features of Class I.Q. Products:
- Automatic Test Class Generation
- Saving of Test Cases and Test Traces
- Groups A queue for Different Testing Responsibilities
- Linking to Any Forte Supported Test Configuration Product
Thank you,
Any additional questions please call or email me directly.
Joe Burns
Class I.Q.
610-254-5151
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>We have used JMETER from Apache foundation. This is more a stress test tool, but you can also use it for unit testing, as it allows you to record a serie of HTTP requests.
Since your question is not related to JHeadstart, you better post this question on the JDeveloper forum.
Steven DAvelaar,
JHeadstart team. -
Re: Forte and Dialup PPP connections
Subject: Forte and Dialup PPP connections
Priority: normal
Reply-to: "Dexel Durban" <[email protected]>
We want to run Win 95 on our client forte machines. Currently we're
using Forte v2.0E and MS TCP/IP.
Everything works fine in the LAN enviroment, however these client
machines have to run at remote sites, and therefore will need to use
modems with dialup PPP links.
The catch with the dialup procedure is that they will dial into a box
which verifies their username/password and then dials them back (for
security reasons) and sets up the PPP conection.
The only software that seems capable of setting up a PPP connection
after someone dialing your machines, is a product called Fastlink which
we're using.
After we've set up the PPP connection and run forte it works 100%,
however if we come out and run forte again - it can't establish the
connection to the host.
What we've deduced from this is that possibly :
1) MS TCP/IP isn't cleaning up after itself after the first
connection
2) The problem lies with Fastlinks ODI driver.
My questions are :
1) Has anyone managed to get forte running over a modem using PPP,
with the call-back verification procedure outlined above ?
2) In the Forte doc's it says that Forte is only compatible with Win
95 and MS TP/IP no other TCP/IP stack - is this true, or has someone
managed to get another stack working ?
Any help would be greatly appreciated !
- Carl
I have some similiar problems that basically were solved by a fix to one of the
ip executables. For this particular situations I was using Lan Workplace for DOS
Version 5 and just visited their web site and looked for a description similiar
to the problem I was having to determine the right patch. It sounds like when
you let go of your connection that the com port is probably still being held and
not beig released. I could be wrong but.... are you getting any other type of message?Thank you for your answer, David.
We are considering the splitting of one VMS partition into several ones to
streamline some functionality. Currently the communication between the
implied components is handled within the existing partition. By splitting it
we are expecting some performance loss due to interpartition communication
overhead and, since the number of messages expected will be high, we were
wondering if they will be needlessly going through the whole network stack
or transferred directly via socket IPC, as can be done in the Unix boxes.
The answer would help us tune-up the system by focusing at the right
parameters during testing of the new setup.
Alberto Lamas
Datamed SA -
We have no problem using JDK 1.1.5. However, we are using Orbixweb. If
you are accessing the applet and the IOR file from the same host (exact
host name), then one other possibility is the JVM compatibility for your
browser. Using Javasoft's Activator or appletviewer should resolve
that.
-----Original Message-----
From: Kamran Amin [SMTP:[email protected]]
Sent: Tuesday, March 10, 1998 7:48 AM
To: '[email protected]'; '[email protected]'
Subject: RE: Java and Forte
Dan,
We had the same problem as you are having regarding question
one. Make
sure you are
using JDK 1.1.3 or 1.1.4. It did not work for me when I was using JDK
1.1.5. Also you have to
use the gatekeeper to make the applet work. Hope this help.
Kamran Amin
Forte Technical Leader, Software Engineering
[email protected]
203-459-7362
Oxford Health Plans
48 Monroe Turnpike
CT, Trumbull 06611
http://www.oxhp.com/
From: [email protected][SMTP:[email protected]]
Sent: Monday, March 09, 1998 7:49 PM
To: [email protected]
Subject: Re: Java and Forte
1. I have been able to make my Java client appllication call-in to a
Forte service object with success. However the tricky part beginswhen
I try to do the same with a Java applet. I get an exception returned
which is an AppletSecurityException. I understand that running a Java
applet in a browser has two limitations, one being the Java applet
sandbox and the firewall restriction. As I am only running my Java
applet and the Forte service object on the same node, this rules out
the latter.
I have tried running the Gatekeeper from the same directory as myJava
client application, which includes all the client stub files
(including stub files which are generated from Forte supplier plans
such as those in the Framework folder). However, I still receive the
AppletSecurityException.
How can I go about making this operation successful?
**AppletSecurityExceptions can be caused by many problems--trying toaccess
machines other than the class download machine, or trying to accessserver
side classes outside the defined directory structure in the webserver. I'd
look closely at the classes that are being brought into memory (forexample,
Visibroker's ORB shows you each file as it is loaded) and make sureyour web
server is defined correctly. If you follow the Forte technotesclosely, it
usually solves this problem.
2. Has anyone tried implementing a 'fat' client, one that combines a
Forte web application, JavaScript, and a Java applet client toperform
operations such as validation and a tiny bit of data processing allon
the client side, relieveing the application server from such
operations? If yes, how do I implement the solution, and are thereany
tech notes from Forte that specifically tell me how to do this?
**We have created a Java framework that follows many of the designpatterns
and naming conventions as our Forte framework. The Java classes canbe
extended to marshal and unmarshal scalar data structs passed acrossthe ORB
boundary to instantiate 'thick' functional objects on the client, andas much
processing and as many business rules as wanted can be developed inthe
client
Java objects.If you look at the exception information in the iiop manual it
discusses exteneded propties DefaultThrowsClause, ThrowsClause and
IsThrowable.
If you mark your exception class with IsThrowable it will show up in the
IDL as an exception. If you use either DefaultThrowsClause(project) or
ThrowsClause(method) you will get the appropriate raises in the idl.
This will cause the idl2java to produce code which will allow you to catch
the exception.
Tom.
At 09:41 AM 1/29/99 +0100, Giuseppe Sorce wrote:
>
Hi all,
I am currently working to an architecture to establish a communication
between a Forte' server and a Java client, using Visigenic's Visibroker and
IDL mode.
I have problems when I try to raise a Forte' exception from a method
invoked by the Java client; I would like the exception class
(ProductException) not to inherit from the class GenericException, because
the IDL I want to generate must have this structure:
exception ProductException {
string message;
Using this solution, the client application gets blocked waiting forever.
I am currently working with:
- Forte' 3.0.G.2 plus WebEnterprise 1.0.B
- JDK 1.1.5
- Visibroker 3.1
My question is: is it possible to raise an exception from the Forte' side
that is
compliant to the IDL mentioned above?
Of course it should be caught from the Java side.
Thank you in advance
Giuseppe Sorce
CSI Piemonte - C.so Unione Sovietica 216 - 10134 Torino - ITALY
tel. +39-011-3168736
fax +39-011-3168212
e-mail [email protected]
url http://www.csi.it
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
RE: how can two Forte installtion communicate
Hi,
I have similar arrangement here but for "user acceptence test". However,
may I remind you that when some objects/codes got checked out --> overwrite
with new import --> integrate --> check out again. Some funny things ( I
would say corruption ) may happen. I have one time that a normal old piece
of code got compilation error and no one can find out why. The last resort
is that I deleted everything and start from scratch again. Then everything
works.
Thus, I would suggest that from time to time, you should start out with a
new repository instead of using it over and over again in this fashion.
Maybe you can archive the old one as a version backup.
Regards,
Peter Sham.
-----Original Message-----
From: Kalidindi, Ravi CWT-MSP [SMTP:[email protected]]
Sent: Tuesday, February 16, 1999 1:10 AM
To: 'Nick Delany'; 'Jim Rice'
Cc: [email protected]
Subject: RE: how can two Forte installtion communicate
Nick...
We have a similar situation here. We have about seven teams,
each
with their own repositories with interdependent code.
Let me give you a simple scenario to explain how you can
make it
work:
Problem
--Team A is responsible for projects 1,2,3 and use repository RepA
--Team B is responsible for projects 4,5,6 adn use repository RepB.
--Project 2 is a supplier plan to project 5 and project 3 is a
supplier plan
to project 6.
Solution
--each repository is reponsible for some projects and these projects
can be
changed only in that repository.
--each repository also has a workspace called "SlaveProjects"
--This workspace has all the projects that are needed but are not
developed
by this team.
--These projects are checked out so that no one else can change them
-- so, RepB's slaveProjects workspace will have projects 2 and 3
(and other
projects they need).
-- You can also password protect the slaveProjects workspace.
-- When team A thinks they have a new working(or atleast compilable)
"version" of projects 2 and 3, they can trigger of an fscript which
will
export the projects 1 and 2, possibly save it in version control.
-- team B can then trigger another fscript which will pull the code
from
version control, import the projects 1 and 2 into RepB's
slaveProjects
workspace, integrate it and recheck everything out.
Options
-- you can get fancy with the scripts
-- you can add the two scripts together to do the whole thing in one
shot.
However existense of many such repositories can cause integrate
failures and
you might not know where exactly it stopped. You need to log the
output to
keep track.
-- you should probably make the second script actually create a
temporary
workspace, and import projects there and integrate. This is in case
you had
many other projects in the slaveprojects workspace that need not be
integrated and rechecked out each time.
-- you could create an application in forte or VB etc.. to make this
process
more sophisticated.
Hope that gives you a start. Different locations definetly
adds more
complexity to this, but the concept should be the same. If you have
more
questions or need more help, I suggest you call Len Lopez at
612-594-2539
who has played around with this stuff a lot. He put in place a VB
app that
does most of the stuff for us and will probably make a presentation
at the
Forte Forum this year on the same topic.
Good Luck!
-Ravi Kalidindi
Born Info Svcs Group.
> -----Original Message-----
> From: Nick Delany [SMTP:[email protected]]
> Sent: Monday, February 15, 1999 10:27 AM
> To: 'Jim Rice'
> Cc: [email protected]
> Subject: RE: how can two Forte installtion communicate
>
>
> Jim,
>
> Rajiv may not be referring to scenario 1, but I'm involved in
something
> like
> that.
> We're a bi-located team, and while we are trying to split up the
work to
> minimise the geographical dependancies, I'd be interested in
anything you
> might have to say about the best way to share code/repositories.
>
> Nick
>
> -----Original Message-----
> From: Jim Rice [mailto:[email protected]]
> Sent: 08 February 1999 22:38
> To: Rajiv Srivastava
> Cc: [email protected]
> Subject: Re: how can two Forte installtion communicate
>
>
> Rajiv,
>
> Can you elaborate ? I can see your questions leading toward at
least the 3
> following scenarios....
>
> 1. Are you asking about 2 different independent developer groups
which
> have
> only the internet as a possible connection pipe between them,
> or
> 2. Are you asking about 2 deployed applications which are the same
> application but deployed to environment production1 and redeployed
to
> environment production2
> or
> 3. Are you asking about 2 deployed applications whic are different
> applications and each is deployed to either
> 3a. a common deployment environment using the same
"Forte_NS_ADDRESS"
> 3b. two seperate deployment environements using the different
> "Forte_NS_ADDRESS" and therefore may even be on sepearte LAN/WAN's
>
> -Jim
>
> At 11:33 AM 2/8/99 , Rajiv Srivastava wrote:
> >Can somebody tell me that what r the possible way where two
different
> >independent Forte Installation can communicate to each other.
> >and share certain the information.
> >
> >thanking you in anticipation.
> >
> >Rajeev
> >
> >-
> >To unsubscribe, email '[email protected]' with
> >'unsubscribe forte-users' as the body of the message.
> >Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
> >
> Jim Rice mailto:[email protected]
> Partner ConCall @ Feb 17
> http://www.forte.com/events/frameset_partners.html
> Forte Usr Mtg @ May9-12 http://forum99.forte.com
> Partner Tech Specialist Work#: 301-721-1910
>
> -
> To unsubscribe, email '[email protected]' with
> 'unsubscribe forte-users' as the body of the message.
> Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
> -
> To unsubscribe, email '[email protected]' with
> 'unsubscribe forte-users' as the body of the message.
> Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Hi,
I have similar arrangement here but for "user acceptence test". However,
may I remind you that when some objects/codes got checked out --> overwrite
with new import --> integrate --> check out again. Some funny things ( I
would say corruption ) may happen. I have one time that a normal old piece
of code got compilation error and no one can find out why. The last resort
is that I deleted everything and start from scratch again. Then everything
works.
Thus, I would suggest that from time to time, you should start out with a
new repository instead of using it over and over again in this fashion.
Maybe you can archive the old one as a version backup.
Regards,
Peter Sham.
-----Original Message-----
From: Kalidindi, Ravi CWT-MSP [SMTP:[email protected]]
Sent: Tuesday, February 16, 1999 1:10 AM
To: 'Nick Delany'; 'Jim Rice'
Cc: [email protected]
Subject: RE: how can two Forte installtion communicate
Nick...
We have a similar situation here. We have about seven teams,
each
with their own repositories with interdependent code.
Let me give you a simple scenario to explain how you can
make it
work:
Problem
--Team A is responsible for projects 1,2,3 and use repository RepA
--Team B is responsible for projects 4,5,6 adn use repository RepB.
--Project 2 is a supplier plan to project 5 and project 3 is a
supplier plan
to project 6.
Solution
--each repository is reponsible for some projects and these projects
can be
changed only in that repository.
--each repository also has a workspace called "SlaveProjects"
--This workspace has all the projects that are needed but are not
developed
by this team.
--These projects are checked out so that no one else can change them
-- so, RepB's slaveProjects workspace will have projects 2 and 3
(and other
projects they need).
-- You can also password protect the slaveProjects workspace.
-- When team A thinks they have a new working(or atleast compilable)
"version" of projects 2 and 3, they can trigger of an fscript which
will
export the projects 1 and 2, possibly save it in version control.
-- team B can then trigger another fscript which will pull the code
from
version control, import the projects 1 and 2 into RepB's
slaveProjects
workspace, integrate it and recheck everything out.
Options
-- you can get fancy with the scripts
-- you can add the two scripts together to do the whole thing in one
shot.
However existense of many such repositories can cause integrate
failures and
you might not know where exactly it stopped. You need to log the
output to
keep track.
-- you should probably make the second script actually create a
temporary
workspace, and import projects there and integrate. This is in case
you had
many other projects in the slaveprojects workspace that need not be
integrated and rechecked out each time.
-- you could create an application in forte or VB etc.. to make this
process
more sophisticated.
Hope that gives you a start. Different locations definetly
adds more
complexity to this, but the concept should be the same. If you have
more
questions or need more help, I suggest you call Len Lopez at
612-594-2539
who has played around with this stuff a lot. He put in place a VB
app that
does most of the stuff for us and will probably make a presentation
at the
Forte Forum this year on the same topic.
Good Luck!
-Ravi Kalidindi
Born Info Svcs Group.
> -----Original Message-----
> From: Nick Delany [SMTP:[email protected]]
> Sent: Monday, February 15, 1999 10:27 AM
> To: 'Jim Rice'
> Cc: [email protected]
> Subject: RE: how can two Forte installtion communicate
>
>
> Jim,
>
> Rajiv may not be referring to scenario 1, but I'm involved in
something
> like
> that.
> We're a bi-located team, and while we are trying to split up the
work to
> minimise the geographical dependancies, I'd be interested in
anything you
> might have to say about the best way to share code/repositories.
>
> Nick
>
> -----Original Message-----
> From: Jim Rice [mailto:[email protected]]
> Sent: 08 February 1999 22:38
> To: Rajiv Srivastava
> Cc: [email protected]
> Subject: Re: how can two Forte installtion communicate
>
>
> Rajiv,
>
> Can you elaborate ? I can see your questions leading toward at
least the 3
> following scenarios....
>
> 1. Are you asking about 2 different independent developer groups
which
> have
> only the internet as a possible connection pipe between them,
> or
> 2. Are you asking about 2 deployed applications which are the same
> application but deployed to environment production1 and redeployed
to
> environment production2
> or
> 3. Are you asking about 2 deployed applications whic are different
> applications and each is deployed to either
> 3a. a common deployment environment using the same
"Forte_NS_ADDRESS"
> 3b. two seperate deployment environements using the different
> "Forte_NS_ADDRESS" and therefore may even be on sepearte LAN/WAN's
>
> -Jim
>
> At 11:33 AM 2/8/99 , Rajiv Srivastava wrote:
> >Can somebody tell me that what r the possible way where two
different
> >independent Forte Installation can communicate to each other.
> >and share certain the information.
> >
> >thanking you in anticipation.
> >
> >Rajeev
> >
> >-
> >To unsubscribe, email '[email protected]' with
> >'unsubscribe forte-users' as the body of the message.
> >Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
> >
> Jim Rice mailto:[email protected]
> Partner ConCall @ Feb 17
> http://www.forte.com/events/frameset_partners.html
> Forte Usr Mtg @ May9-12 http://forum99.forte.com
> Partner Tech Specialist Work#: 301-721-1910
>
> -
> To unsubscribe, email '[email protected]' with
> 'unsubscribe forte-users' as the body of the message.
> Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
> -
> To unsubscribe, email '[email protected]' with
> 'unsubscribe forte-users' as the body of the message.
> Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
Re: Running the same (Forte) application multiple times -for different
Hi
We had the same problem - how to deploy a number of identical applications, using each their own db.
(for training).
The solution we used is to wrap the entire application into different applications by using a very small
module called KURSUS01, KURSUS02 etc, that did nothing but call the start procedure of the main app.
Then in the dbsession connect, we made a call appname to get the application name, and appended the
first 8 chars to the dbname. Thus our dbnames now points to logicals name: rdbdataKURSUS01, rdbdataKURSUS02 etc.
All this allows us to deploy the identical apps in the same env, or change one version, and run both the old
and new program on the same pc and server at the same time (eg. KURSUS01 and KURSUS02).
I also think this is a kludge - but it works nicely!
Jens Chr
KAD/Denmark
-----Original Message-----
From: Haben, Dirk <[email protected]>
To: 'Soapbox Forte Users' <[email protected]>
Date: 15. januar 1999 09:41
Subject: Running the same (Forte) application multiple times - for different business clients.
Hi All
We have a number of different business clients all willing to use our
application.
The (forte) application is to run on our machines etc for these (business)
clients.
All (business) clients will have their data kept in separate Oracle DBs
(instance).
The problem now is that the entire (forte) application is written using
DBSessions.
Now, depending on what business client needs to be serviced (so to speak) we
need to attach to the right DB - or use the "right" SO.
The two options we can think of are:
Option1:
Programatic change to somehow "know" what (business) client (DB) I'm talking
about and then use the right DB.
Pro:
Only one forte environment to maintain
Can run multiple (business) clients on same PC at the same time
Con:
Requires many program changes
bending O-O rules(?)
can't dynamically name SOs so can it be done at all? (ResourceMGRs maybe?)
Option2:
Use separate environments! One for each business client.
Pro:
More defined separation of app and data,
SLA-easy
Con:
Maintain "n" number of environments
Can only run the application for one environment (business client) at a time
on one PC - Big Negative here!
Not knowing any feasible solution to option 1 (without much code changes and
developer moaning) I would go for option two; as I have already worked on
multi-environment setups on VMS back at the Hydro (hi guys).
I would appreciate any comments from anyone who has solved this problem.
How, Why Pro Con etc.
TIA,
Dirk Haben
Perth, WA
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Hi
We had the same problem - how to deploy a number of identical applications, using each their own db.
(for training).
The solution we used is to wrap the entire application into different applications by using a very small
module called KURSUS01, KURSUS02 etc, that did nothing but call the start procedure of the main app.
Then in the dbsession connect, we made a call appname to get the application name, and appended the
first 8 chars to the dbname. Thus our dbnames now points to logicals name: rdbdataKURSUS01, rdbdataKURSUS02 etc.
All this allows us to deploy the identical apps in the same env, or change one version, and run both the old
and new program on the same pc and server at the same time (eg. KURSUS01 and KURSUS02).
I also think this is a kludge - but it works nicely!
Jens Chr
KAD/Denmark
-----Original Message-----
From: Haben, Dirk <[email protected]>
To: 'Soapbox Forte Users' <[email protected]>
Date: 15. januar 1999 09:41
Subject: Running the same (Forte) application multiple times - for different business clients.
Hi All
We have a number of different business clients all willing to use our
application.
The (forte) application is to run on our machines etc for these (business)
clients.
All (business) clients will have their data kept in separate Oracle DBs
(instance).
The problem now is that the entire (forte) application is written using
DBSessions.
Now, depending on what business client needs to be serviced (so to speak) we
need to attach to the right DB - or use the "right" SO.
The two options we can think of are:
Option1:
Programatic change to somehow "know" what (business) client (DB) I'm talking
about and then use the right DB.
Pro:
Only one forte environment to maintain
Can run multiple (business) clients on same PC at the same time
Con:
Requires many program changes
bending O-O rules(?)
can't dynamically name SOs so can it be done at all? (ResourceMGRs maybe?)
Option2:
Use separate environments! One for each business client.
Pro:
More defined separation of app and data,
SLA-easy
Con:
Maintain "n" number of environments
Can only run the application for one environment (business client) at a time
on one PC - Big Negative here!
Not knowing any feasible solution to option 1 (without much code changes and
developer moaning) I would go for option two; as I have already worked on
multi-environment setups on VMS back at the Hydro (hi guys).
I would appreciate any comments from anyone who has solved this problem.
How, Why Pro Con etc.
TIA,
Dirk Haben
Perth, WA
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
How can two Forte installtion communicate - exactrequirement giv en at
To me, this clearly looks like a design issue. Here are two options that I
can think of:
1) You can achieve this through sql i.e. the sql service on location 1 can
allow you to query the database on location 2. Your service object uses the
user's criteria to decide which database to get to. This however is
inefficient since the dbsession is not on the same machine as the database.
2) Create a new layer ( umbrella ) which maintians a list of services that
register with it. This could be a seperate application and can be in a
seperate environment too. Your "database" service objects should also be
seperate applications. They register themselves to this layer. The remaining
part of your app should now be a seperate application which uses the "layer"
to get to the appropriate database. These different applications can talk to
each other using reference partitions accross connected environments.
Location 1 Location 2
app 1 app2
| |
(query the layer) (query the
layer)
| |
---------------------------------service
layer--------------------------------------------
|
(register self)
(register self)
|
database services 1 database services 2
I am sure there are more solutions to this problem. Others??
Ravi Kalidindi
Born Info Svcs Group
-----Original Message-----
From: Rajiv Srivastava [SMTP:[email protected]]
Sent: Tuesday, February 09, 1999 11:45 AM
To: 'Kalidindi, Ravi CWT-MSP'
Subject: RE: [email protected]
Thnaks to yr reply:
Actual requirment is :
an Forte application running at Location 1 on Local Prodution data.
same application is running at Location2 with its own local data.
(both has their own separate resources) there is Network connectivity
available.
Now i wana to fire a query that can be done either way to retive some
information.
i.e. i should be able to retrive some data based on some criteria, from
location one while sitting at location 2. and vis-versa.
i think its clearly says what i want.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>To me, this clearly looks like a design issue. Here are two options that I
can think of:
1) You can achieve this through sql i.e. the sql service on location 1 can
allow you to query the database on location 2. Your service object uses the
user's criteria to decide which database to get to. This however is
inefficient since the dbsession is not on the same machine as the database.
2) Create a new layer ( umbrella ) which maintians a list of services that
register with it. This could be a seperate application and can be in a
seperate environment too. Your "database" service objects should also be
seperate applications. They register themselves to this layer. The remaining
part of your app should now be a seperate application which uses the "layer"
to get to the appropriate database. These different applications can talk to
each other using reference partitions accross connected environments.
Location 1 Location 2
app 1 app2
| |
(query the layer) (query the
layer)
| |
---------------------------------service
layer--------------------------------------------
|
(register self)
(register self)
|
database services 1 database services 2
I am sure there are more solutions to this problem. Others??
Ravi Kalidindi
Born Info Svcs Group
-----Original Message-----
From: Rajiv Srivastava [SMTP:[email protected]]
Sent: Tuesday, February 09, 1999 11:45 AM
To: 'Kalidindi, Ravi CWT-MSP'
Subject: RE: [email protected]
Thnaks to yr reply:
Actual requirment is :
an Forte application running at Location 1 on Local Prodution data.
same application is running at Location2 with its own local data.
(both has their own separate resources) there is Network connectivity
available.
Now i wana to fire a query that can be done either way to retive some
information.
i.e. i should be able to retrive some data based on some criteria, from
location one while sitting at location 2. and vis-versa.
i think its clearly says what i want.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
Question about creating libraries in Forte'
I'm looking into creating compiled libraries in Forte' to create a
"plug-and-play" interface among different implementation products. This
would allow us the ability to remove one library and upgrade it with
another assuming that the interfaces were the same. I'm using the
AddProjToLib to create a "super library" and am setting all of the
components as compiled. I am able to make the application distribution
with no problem. The problems that I am having are two-fold:
1) First auto-compile services cannot handle this "super project"
correctly. Don't get me wrong I HATE autocompile services but I decided to
give it a shot and see what happened. With that avenue gone, I went to
fcompile the individual libraries...these have to be done by supplier plan
order which is no big deal. The problem I ran into was that Forte' lower
cases all of the directory names, but the linker expected in some cases
that the directories would have some uppercase letters. The general rule
of thumb I found was that the directory name has to match the library name
generated. Forte' generated the library name with the proper letters
uppercase, but failed to do this to the directory structure. Obviously
this makes automating library creation a little more painful. This really
isn't a show stopper just a point I'd like to bring up in case and Forte'
people actually read these threads.
2) The major road block I ran into is the fact the Forte' statically
stores the full path of the libraries it is using during link/compilation
in the generated shared library. Forte's solution of just creating
symlinks (solution I found from their Technical Notes) is appalling at best
and does not support having multiple versions of libraries built from a
single installation running on the same machine (Unless you do simulated
environments to create a pseudo-new area...but I don't want to get into
that). Currently we are doing something extremely hoaky to solve this
problem with the few libraries that we have, but if we move to a more large
scale library solution this will not work.
I would love to hear any comments or suggestions about any of this. It is
sad that Forte' does not implement such a basic concept as SHLIB_PATH in
their shared libraries. By not doing this, it makes compiled libraries a
major hassle and potentially a waste of time.
Thanks for any comments that you might have in advance,
Scott Francis
Security First Technologies
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>I'm looking into creating compiled libraries in Forte' to create a
"plug-and-play" interface among different implementation products. This
would allow us the ability to remove one library and upgrade it with
another assuming that the interfaces were the same. I'm using the
AddProjToLib to create a "super library" and am setting all of the
components as compiled. I am able to make the application distribution
with no problem. The problems that I am having are two-fold:
1) First auto-compile services cannot handle this "super project"
correctly. Don't get me wrong I HATE autocompile services but I decided to
give it a shot and see what happened. With that avenue gone, I went to
fcompile the individual libraries...these have to be done by supplier plan
order which is no big deal. The problem I ran into was that Forte' lower
cases all of the directory names, but the linker expected in some cases
that the directories would have some uppercase letters. The general rule
of thumb I found was that the directory name has to match the library name
generated. Forte' generated the library name with the proper letters
uppercase, but failed to do this to the directory structure. Obviously
this makes automating library creation a little more painful. This really
isn't a show stopper just a point I'd like to bring up in case and Forte'
people actually read these threads.
2) The major road block I ran into is the fact the Forte' statically
stores the full path of the libraries it is using during link/compilation
in the generated shared library. Forte's solution of just creating
symlinks (solution I found from their Technical Notes) is appalling at best
and does not support having multiple versions of libraries built from a
single installation running on the same machine (Unless you do simulated
environments to create a pseudo-new area...but I don't want to get into
that). Currently we are doing something extremely hoaky to solve this
problem with the few libraries that we have, but if we move to a more large
scale library solution this will not work.
I would love to hear any comments or suggestions about any of this. It is
sad that Forte' does not implement such a basic concept as SHLIB_PATH in
their shared libraries. By not doing this, it makes compiled libraries a
major hassle and potentially a waste of time.
Thanks for any comments that you might have in advance,
Scott Francis
Security First Technologies
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
How can i run a program outside of Forte? (Forte and java/class files)
im making a program with forte... and i have a bunch of class files, i form file and a java file... how can i put these in one file so poeple without forte can run it...
thanksjmburns wrote:
I am trying to do a silent install of a program I built using LabVIEW 8.5. I also need to call an exe after the installation, so I am using the "run executable after installation" option on the Advanced tab of the installer. I then pass the following command lines to the setup.exe:
/qb /acceptlicenses yes /r
This installs the LabVIEW program successfully, but does not then run the additional exe afterward. If I run the setup.exe normally (with no command line parameters), the additional exe gets run.
Thanks,
Jason
This problem is fixed in a future release of LabVIEW. Here's the CAR ID 67549 for tracking purposes.
Message Edited by Bob P on 07-10-2008 09:10 AM -
Creating Forte FieldWidgets Dynamically at Runtime
Hi Everyone,
Could someone please help me with the following problem I have when
creating Forte fieldwidgets dynamically at run-time. I am using Forte
ver. 3.0.G.2.
(-1-) I have a window class with an empty gridfield, <grfMain>, inside a
viewport. The idea is to populate the gridfield with DataField
fieldwidgets dynamically at runtime. Depending on some input criteria,
sometimes some of the DataFields need to map to IntegerNullables, some
to DoubleNullables and some to DateTimeNullables. (Please note that I
cannot use the Forte window workshop to create these fieldwidgets,
because different types of fieldwidgets will be needed at different
times, in different numbers, at run-time. ) Here is a sample of how I am
currently trying to achieve this:
dfDate : DataField = new;
dfDate.MaskType = MK_Template;
dfDate.DateTemplate = new( value='dd/mm/yyyy' );
dfDate.Row = 1;
dfDate.Column = 2;
dfDate.Parent = <grfMain>;
dfInt : DataField = new;
dfInt.MaskType = MK_INTEGER;
dfInt.Row = 2;
dfInt.Column = 2;
dfInt.Parent = <grfMain>;
dfReal : DataField = new;
dfReal.MaskType = MK_FLOAT;
dfReal.Row = 3;
dfReal.Column = 2;
dfReal.Parent = <grfMain>;
The code above is called after the window has been opened with the
Open() statement.
Looking at the code above, one obvious omission is that the "Mapped
Type" of the Datafields are not set up. In the Forte window workshop, an
interface is provided to set up the "Mapped Type" of the Datafield
widgets, but I'm not sure how to do that dynamically, and that is
basically my biggest problem here.
(-2-) If I now run the window class, the Datafield widgets get created,
and they all have the correct input maks, but no validation gets done
when one tabs away from the field. For example, Datafields with
MaskType=MK_INTEGER will gladly accept '--1--0++7', while Datafields
created in the window workshop (mapping to IntegerNullables) will do a
validation, and not allow one to tab out of the field before the extra
minus and plus signs are not removed.
I have the same problem with the Datafields which have
MaskType=MK_Template and DateTemplate='dd/mm/yyyy'. For the date, one
can enter something like '2*\**\****', and leave the field, while the
same type of datafield created in the window workshop (mapped to a
DateTimeNullable), will not allow you to leave the field before a valid
date has not been entered. To summarise, the input masks of my
dynamically created Datafields work fine, but no validation gets done
when the field looses the focus.
(-3-) As a test, I used the Forte debugger ("view"-"local variables") to
look at the differences between Datafields created dynamically, and
those created in the Forte window workshop. One very obvious difference
was that Datafield attribute "MapTypeName" was filled in for the window
workshop Datafields, but not for my dynamically created Datafields. The
problem is that Forte does not allow me to set this attribute
dynamically in my code. How else can I setup the Mapped Type
dynamically?
(-4-) In order to have a consistent look-and-feel throughout our Forte
project, we are making use of Domain classes for DATE and DECIMAL data
entry fields. My questions are:
(4.1) How must I go about creating Datafields dynamically that make use
of these Domain classes?
(4.2) Is it also a matter of setting up the "MapTypeName" attribute,
which I cannot seem to do?
(4.3) Is the mapping done differently for Domain classes?
(-5-) Another interesting thing to note for Datafields created in the
Forte Window Workshop, is that if the mapped type is IntegerNullable
with Input Mask = Integer, or DoubleNullable with Input Mask = Float,
then the Object that the Datafield widget maps to, must first be
instantiated before the Loose-Focus validations will start to work. For
example, if a Datafield widget called "dfTestInt" was created in the
Forte window workshop, which maps to an IntegerNullable, and Input Mask
= Integer, then the following line is needed before the window is
displayed: dfTestInt = new;
Without this line, one can enter something like '2---3+++7', and leave
the field.
This is not true for Datafields where the mapped type is
DateTimeNullable with say Input Mask Template='dd\mm\yyyy'. In this case
validations are done even thought the object being mapped to, has not
been instantiated yet. In other words you will never be able to enter
'2*/**/****', and leave the field for datafield created in the window
workshop. Maybe in this case the validation is being done by the
template itself?
Thanks in advance
Riaan
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>what I mean is rendering JSF components on the fly, becuase some time you don't know things at design time. Lets say I am designing a page in creator that shows the total number of dependants that belongs to a primary inusrance member in text boxes. Of course we don't know in advance how many dependants we have for a specific member unless we go to databse and fetch all the data at runtime. Desiging some thing dynamic like that is very easy in CGI or ASP/JSP but JSF model seems very static due to it's design time feature.
So is it possible with JSF or not? -
BSOD when starting MSMQ service as domain user Windows server 2012
Hi
We have a problem with a server getting BSOD when we start a service related to MSMQ. We get the attempted execute of noexecute memory BSOD whenever we start the service as a User on the domain. When we start the service as a system local it starts without
problem. I got the crashdump here:
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Microsoft (R) Windows Debugger Version 6.3.9600.17298 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\170\120314-11828-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 8 Kernel Version 9200 MP (4 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Built by: 9200.16912.amd64fre.win8_gdr.140502-1507
Machine Name:
Kernel base = 0xfffff800`48476000 PsLoadedModuleList = 0xfffff800`48742aa0
Debug session time: Wed Dec 3 14:41:01.892 2014 (UTC + 1:00)
System Uptime: 0 days 0:04:09.904
Loading Kernel Symbols
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
Loading User Symbols
Loading unloaded module list
* Bugcheck Analysis *
Use !analyze -v to get detailed debugging information.
BugCheck FC, {7f982e340e0, 791000010fdb1025, fffff8800485a5e0, 80000005}
Probably caused by : mqac.sys ( mqac!ACCreateQueue+a77 )
Followup: MachineOwner
1: kd> !analyze -v
* Bugcheck Analysis *
ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY (fc)
An attempt was made to execute non-executable memory. The guilty driver
is on the stack trace (and is typically the current instruction pointer).
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: 000007f982e340e0, Virtual address for the attempted execute.
Arg2: 791000010fdb1025, PTE contents.
Arg3: fffff8800485a5e0, (reserved)
Arg4: 0000000080000005, (reserved)
Debugging Details:
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT_SERVER
BUGCHECK_STR: 0xFC
PROCESS_NAME: mqsvc.exe
CURRENT_IRQL: 0
ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) amd64fre
TRAP_FRAME: fffff8800485a5e0 -- (.trap 0xfffff8800485a5e0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=000007f982e0c950 rbx=0000000000000000 rcx=0000005dff1fecd0
rdx=0000005dff34e988 rsi=0000000000000000 rdi=0000000000000000
rip=000007f982e340e0 rsp=fffff8800485a778 rbp=fffff8800485ab80
r8=fffffa800e623980 r9=0000000000000521 r10=fffffa800ec547a0
r11=0000000000000006 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
000007f9`82e340e0 ?? ???
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80048661ef1 to fffff800484d0540
STACK_TEXT:
fffff880`0485a408 fffff800`48661ef1 : 00000000`000000fc 000007f9`82e340e0 79100001`0fdb1025 fffff880`0485a5e0 : nt!KeBugCheckEx
fffff880`0485a410 fffff800`48588980 : fffff880`0485a5e0 ffffd8e9`9e6056e2 fffffa80`0ec547a0 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x33f2d
fffff880`0485a450 fffff800`4850aabd : fffff880`0485a500 00000000`c0000016 fffffa80`0e603b00 fffffa80`0e623980 : nt! ?? ::FNODOBFM::`string'+0x33e85
fffff880`0485a4a0 fffff800`484cdfee : 00000000`00000008 00000000`00000000 00000000`00000000 fffff880`0485a5e0 : nt!MmAccessFault+0x3ed
fffff880`0485a5e0 000007f9`82e340e0 : fffff880`00dc5297 fffffa80`0ec54770 00000000`00000000 fffff8a0`011ce7c0 : nt!KiPageFault+0x16e
fffff880`0485a778 fffff880`00dc5297 : fffffa80`0ec54770 00000000`00000000 fffff8a0`011ce7c0 fffff980`00000000 : 0x000007f9`82e340e0
fffff880`0485a780 fffff880`00dc60d7 : 00000000`00000000 0000005d`ff34e988 00000000`00000000 00000000`00000000 : mqac!ACCreateQueue+0xa77
fffff880`0485a7f0 fffff800`488ab127 : fffffa80`0e5ed520 fffffa80`0d50ecf0 00000000`00000521 00000000`00000000 : mqac!ACDeviceControl+0x62b
fffff880`0485a890 fffff800`488c02f6 : 00000000`00000000 fffff8a0`00000080 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x7e5
fffff880`0485aa20 fffff800`484cf553 : 00000000`00000000 00000000`0000000c fffff6fb`7dbed078 fffff6fb`7da0ff30 : nt!NtDeviceIoControlFile+0x56
fffff880`0485aa90 000007f9`8a702c1a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
0000005d`ff34e928 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x000007f9`8a702c1a
STACK_COMMAND: kb
FOLLOWUP_IP:
mqac!ACCreateQueue+a77
fffff880`00dc5297 85c0 test eax,eax
SYMBOL_STACK_INDEX: 6
SYMBOL_NAME: mqac!ACCreateQueue+a77
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: mqac
IMAGE_NAME: mqac.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 5010abc2
IMAGE_VERSION: 6.2.9200.16384
BUCKET_ID_FUNC_OFFSET: a77
FAILURE_BUCKET_ID: 0xFC_mqac!ACCreateQueue
BUCKET_ID: 0xFC_mqac!ACCreateQueue
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:0xfc_mqac!accreatequeue
FAILURE_ID_HASH: {d1daca31-6256-358c-65b5-69af54392880}
Followup: MachineOwnerHi,
For BugCheck FC, it indicates that an attempt was made to execute non-executable memory. For more details,
please refer to following article.
Bug Check 0xFC: ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY
à
whenever we start the service as a User on the domain
. When we start the service as a system local it starts without problem
Did you mean that just use a standard domain user account to start the service, then encounter the issue? If
configure Log on as Local System account, will no BSOD issue occurred? Just a confirmation, thanks for your understanding.
Please check if you install all necessary Windows Updates on the server.
In addition, as you know, troubleshoot this kind of kernel crash issue, we need to analyze the crash dump file to narrow down the root cause of the issue. However, it is
not effective for us to debug the crash dump file here in the forum. If this issues is a state of emergency for you. Please contact Microsoft Customer Service and Support (CSS) via telephone so that a dedicated Support Professional can assist with your request.
To obtain the phone numbers for specific technology request, please refer to the web site listed below:
http://support.microsoft.com/default.aspx?scid=fh;EN-US;OfferProPhone#faq607
Hope this helps.
Best regards,
Justin Gu
Maybe you are looking for
-
Mon Mac Mini n'affiche Pas La Barre De Menus
Bonjour Mon Mac Mini n'affiche Pas la barre de menus depuis que je L'ai donc depuis hier et j'ai essayé sur plusieurs écran mais rien ne fonctionnent Sil vous plait aider moi
-
Lose Mouse click after resuming local session (from RDP)
After posting this thread, I was told to post here. https://answers.microsoft.com/en-us/windows/forum/windows8_1-tms/lose-mouse-click-on-session-resume/e4ca4acf-4f96-4a1f-9e76-4c3665d1253e?auth=1 This gist of the problem is that when I resume a local
-
Further musings...Notes for a Logic developer regarding practical usage of
It does seem like the control section of Logic was designed specifically for the Logic control, using their own dialog and terms. I have been struggling with Logic since I switched to it, simply because I make dance music, and I rely super heavily on
-
Fall back to DNS if node in HOSTS file doesn't respond
I have a server farm in which the servers talk to each other on a private backbone (via hosts files), but the clients talk to the servers on a second NIC via AD/DNS. Is there a way to have the servers fail over to DNS if entries in the hosts files do
-
Is it possible to mass change desktop wall paper for all users using WGM?
is it possible to mass change desktop wall paper for all users using WGM?