RE: Forte - CICS on NT

It is true that Forte NT clients do not use native NT threads. However,
Forte NT servers do use native threads (as documented in 2.H release
notes on page 71.) I was assuming that you would build a service object
to act as the interface between Forte clients and CICS. You may be
trying to do something entirely different.
Daniel C. Zimmerman
PageNet
(972)985-2452
From: June White[SMTP:[email protected]]
Sent: Thursday, May 01, 1997 2:57 PM
To: Daniel Zimmerman
Cc: '[email protected]'; 'James Urquhart';
'[email protected]'
Subject: RE: Forte - CICS on NT
The tech bulletin states that Native threads will be part of release 3.
OLE example crashed -this is not unique to NT4.0. This problem
is due to the way Forte threads work in Release 2. It is fixed
in Release 3 of Forte which runs multithreaded using native
threads.
Thanks.
At 01:54 PM 5/1/97 -0500, Daniel Zimmerman wrote:
I thought I saw a Forte tech note or release note that said that Forte
uses native NT threads on 2.F.2 and above.
Daniel C. Zimmerman
PageNet
(972)985-2452
From: James Urquhart[SMTP:[email protected]]
Sent: Thursday, May 01, 1997 1:20 PM
To: [email protected]
Cc: [email protected]
Subject: Re: Forte - CICS on NT
Venkat,
The issue with directly calling the CICS for NT API has to do with
threading packages. When using C wrappering, the called functions are
executed in the same process as the Forte code that calls them. In version
2.0, Forte uses its own threading package on NT clients, rather than the
native NT threads. Unfortunately, the threading package used by CICS for
NT conflicts with our package, and random crashes can occur when running
both in the same process.
By using the socket interface, we are able to run CICS for NT in a seperate
process, thus keeping the threading packages uniquely seperate. This, in
turn, avoids any thread conflicts.
In version 3.0 of Forte, it may be possible to reimpliment the CICS code
with the C wrappering mechanism, as Forte NT clients will use native NT
threads in this version.
At 01:06 PM 5/1/97 -0500, you wrote:
I was looking at the Forte - CICS wrapper code for CICS on NT that is part
of Forte Shareware.
The Forte piece communicates via NT Winsock to a C program that starts a
thread to talk to the CICS API on NT.
My question is, can we do this level of communication by Forte directly
calling the CICS for NT API, not spending time on the
socket calls? Has any body done this? What are the implications of doing
it
either way?
Any insight into it will be appreciated.
Venkat Kodumudi
James Urquhart [email protected]
Product Manager phone: (510) 986-3513
Forte Software, Inc. fax: (510) 869-2092

Similar Messages

Forte - CICS on NT

I was looking at the Forte - CICS wrapper code for CICS on NT that is part
of Forte Shareware.
The Forte piece communicates via NT Winsock to a C program that starts a
thread to talk to the CICS API on NT.
My question is, can we do this level of communication by Forte directly
calling the CICS for NT API, not spending time on the
socket calls? Has any body done this? What are the implications of doing it
either way?
Any insight into it will be appreciated.
Venkat Kodumudi

A clarification:
What I meant to say is that Forte version 2.0.anything uses the Forte
thread package on NT client partitions, meaning any client partition
deployed on an NT node will use Forte threads. All server partitions use
NT native threads.
James
At 01:35 PM 5/1/97 -0500, you wrote:
>
>
>
>
James,
We are running Forte 2.0.H.2 on NT4.0, where our only options on thread
packages are Native NT and DCE threads. SO, will we have the
problem that you are describing in that situation?
Thanks
Venkat
[email protected] on 05/01/97 01:20:40 PM
To: Venkat Kodumudi
cc: [email protected]
Subject: Re: Forte - CICS on NT
Venkat,
The issue with directly calling the CICS for NT API has to do with
threading packages. When using C wrappering, the called functions are
executed in the same process as the Forte code that calls them. In version
2.0, Forte uses its own threading package on NT clients, rather than the
native NT threads. Unfortunately, the threading package used by CICS for
NT conflicts with our package, and random crashes can occur when running
both in the same process.
By using the socket interface, we are able to run CICS for NT in a seperate
process, thus keeping the threading packages uniquely seperate. This, in
turn, avoids any thread conflicts.
In version 3.0 of Forte, it may be possible to reimpliment the CICS code
with the C wrappering mechanism, as Forte NT clients will use native NT
threads in this version.
At 01:06 PM 5/1/97 -0500, you wrote:
I was looking at the Forte - CICS wrapper code for CICS on NT that is part
of Forte Shareware.
The Forte piece communicates via NT Winsock to a C program thatstarts a
thread to talk to the CICS API on NT.
My question is, can we do this level of communication by Fortedirectly
calling the CICS for NT API, not spending time on the
socket calls? Has any body done this? What are the implications of doingit >either way?
Any insight into it will be appreciated.
Venkat Kodumudi
James Urquhart [email protected]
Product Manager phone: (510) 986-3513
Forte Software, Inc. fax: (510) 869-2092
James Urquhart [email protected]
Product Manager phone: (510) 986-3513
Forte Software, Inc. fax: (510) 869-2092

Forte' Shareware: Forte'/CICS integration

(I send again this mail, as I don't know if it has been properly
broadcasted.
So excuse me if you receive this mail twice.)
Hi All,
Recently I have downloaded the "Forte' shareware: Forte'/CICS integration"
solution from the Forte' web site.
Unfortunately I have audited that this solution has been developed for
"CICS for Windows NT Version 2" while we have installed "IBM Transaction
Server for Windows NT, Version 4" containing "CICS for Windows NT, V4" and
"CICS Client for Windows NT, V2.0.1.".
I have understood that in our installation the necessary libraries have
furnished with the CICS Client.
I tried to compile ntlisten.c : here is my make file.
NTLISTEN.MAK
ntlisten.exe: ntlisten.obj
link /nod ntlisten.obj cclwin32.lib libc.lib kernel32.lib user32.lib
gdi32.lib wsock32.lib
ntlisten.obj: ntlisten.c
cl /c /MT /DWIN32 /D_WIN32 /D_X86_=1 /DCICS_W32 ntlisten.c
The problem is that the "_beginthread" function doesn't come resolved.
ERROR LNK2001: Unresolved external symbol _beginthread
I have seen that inside the remarks the author declares that:
" I compiled it with this command:
cl /MT /D_WIN32 ntlisten.c wsock32.lib faacicnt.lib "
Therefore I think that the _beginthread symbol might be defined in the
FAACICNT.LIB library which however I am not able to locate in my
installation of CICS.
Any experiences would be appreciated.
Regards
Giuseppe Sorce
Giuseppe Sorce
CSI Piemonte
C.so Unione Sovietica, 216
10134 TORINO - ITALY
E-mail address: [email protected]
Telephone Number: +39-11-3168847

I have the exact same problem.
Mine's WinNT4SP6a
Same versions of iWS and iAS.
One note is that the Dialog that pops up has wonky paths
D:\Netscape\Server4/bin/https/jar/IWSToolsIntegration.jar
Can anyone help either Vadim or myself?
Vadim Gorbounov wrote:
Hello,
Does anybody succeed in Forte 3.0 Enterprise Edition configuration?
I'm doing Win2000 installation, I have iPlanet WebServer 4.1 SP7 and
iPlanet AppServer 6.0 installed on this box. Forte 3.0 iPlanet plugin asks
me
for web server4 home directory during first start and than complains
about missing <server4>\bin\https\jar\IWSToolsIntegration.jar. I can't
find any IWSToolsIntegration.jar nowhere, neither no references in
iPlanet/Forte documentation.
Can anybody shed some light on this?
Thank you
Vadim Gorbounov
[email protected]
www.simplyengineering.com

Forte, CICS, and MQ

In response to Manuel Granados, it may help to look
at the interfaces I have developed for CICS for NT,
and also for the MQ Series, which are on the Forte
home page, under "Technical Information." Look
under "Shareware" and download what you like. You
need a password, but Technical Support should be
able to provide you with one right away, if you
don't already have one.
Hope this helps!
Geoff

In response to Manuel Granados, it may help to look
at the interfaces I have developed for CICS for NT,
and also for the MQ Series, which are on the Forte
home page, under "Technical Information." Look
under "Shareware" and download what you like. You
need a password, but Technical Support should be
able to provide you with one right away, if you
don't already have one.
Hope this helps!
Geoff

CICS/Adabas connection

Hi :
We are trying to access an Adabas DB (running in an MVS mainframe) from a
Forte application. We have CICS on the mainframe and CICS NT in an Forte
node.
To connect CICS NT with Mainframe we use SNA .(There in no TCP/IP on our
mainframe). Forte interacts with CICS NT using the NTLISTEN program from
Forte shareware.
I have the next questions:
Has somebody tried a similar connection?
What kind of programs have you running on host?
Do you need some FRONTEND program on host?
Do you use APPC? (single or parallel sessions?)(any considerations with
Logmodes?)
What about the throughput?
Thanks in advance.

The only what I know is, there was a gateway access to Adabas:
"Procedural Gateway for APPC provides RPC capability via PL/SQL to execute
CICS, IMS/TM, and IDMS/DC transactions accessing virtually any mainframe data
source including Adabas, CA-IDMS, IMS, VSAM, DB2 and DatacomDB"
But language is PL/SQL, not C.
Werner

How have people done Forte application to Forte applicationcommunicatio

I was wondering what architectures folks have been using to do Forte
application to Forte application integration on the client and at the server
level?
connected environments?
CORBA/IIOP?
Message Oriented Middleware?

Hi,
I have used MQSeries and CICS Client. They worked well, except that CICS Client
is for little applications... Tuxedo has also good reputation.
You should also consider a lower protocol like TCP/IP. I use it in synchrone and
asynchrone to support an application protocol with external connections. It
works very well. For instance, It can be an alternative to connected
environments, even for Forte Partitions (for example : you need to connect
several thousands of Forte clients without having to maintain your central
environment).
For asynchrone communcation, and low cost and equipment (external clients, B to
B, etc...) you can also use SMTP with external connections. If you use MIME base
64, you can also transfer serialized objects for instance. Then you can use SMTP
like VMS Mailbox (in old times). Be aware, of course, that you will not have any
delivery warranty on your messages, so you should take care about this on your
protocol.
Hope this helps,
Daniel Nguyen
Freelance Forte Consultant
Edward.CarmodyLibertyMutual.com a écrit:
I was wondering what architectures folks have been using to do Forte
application to Forte application integration on the client and at the server
level?
connected environments?
CORBA/IIOP?
Message Oriented Middleware?
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

RE: (forte-users) 3J= 3M new to me error

Hi Thomas,
Thanks for your email but I think it will be interesting for Brenda not me.
It is exactly what I have expected from Forte Support: detailed information
about bugs and workarounds. But what I cannot understand is that #53398 was
released without any information about possible reasons for this problem or
suggested workarounds. My first reaction after reading this bugreport was to
open a new case at CallCenter to get more information about it. Please
release more information with your bug reports !
Regards
Zenon Adamek
Information Services
Senior Programmer Analyst
Tel: 905 712-1084 ext. 3628
Fax: 905 712-6709
E-mail: zadamekpurolator.com
-----Original Message-----
From: Thomas Degen - Sun Germany Forte Tools - Bonn
[SMTP:thomas.degensun.com]
Sent: Wednesday, September 27, 2000 9:49 AM
To: Adamek, Zenon
Cc: 'Brenda Cumming'; Forte-userslists.xpedior.com
Subject: RE: (forte-users) 3J=>3M new to me error
Hi Zenon,
bug #53398 is not a bug which will likely get fixed, it's an informational
bugreport.
You might see an errorstack like Brenda has reported (and described in
informational
bugreport #53398) probably when you are doing something illegal that is
possible
via Forte Tool but Forte is not trapping it for performance reasons. Hence
you will see
the error coming from your illegal operation only at runtime, probably
only
while
running interpreted in the Forte IDE, but in worst case it might be even a
segmentation
violation.
Technotes 12448 'Sudden client partition crashes at runtime' and 11225
'Don't reparent
mapped Widgets between UserWindows at runtime' explain this matter . See
attached.
But maybe Brenda is much more experiencing a problem as described by Forte
Technote 11398 'Read Only Workspace Errors using ListViews or ActiveX
control'
that might get easily resolved via setting of FORTE_YIELD_THROTTLE=0.
Good Luck and Best Regards !
BTW: I've logged bug #53398, so I've felt responsible to explain its real
background.
Thomas
Thomas Degen
Sun Microsystems - Forte Tools
Forte CTE & Sustaining Group
Technical Support Germany
tel.:+49.228/91499-50
MailTo:thomas.degensun.com
Technote 11398 Read Only Workspace Errors using ListViews or ActiveX
control
SCENARIO:
Getting some unusual interpreter errors that result in an error stating
that
the workspace has been set to read only. Please see Enclosures for the
two
most common error stacks that have been encountered. The abbreviated
versions of the errors are:
- Can't read record (record size = -1)
- Id in index does not match id in record header in data file
- Recursive deserialization attempted.
- Unknown Mark type in deserialization
- Could not read record (64,74615) from repository data file.
Header
is corrupt.
These errors can be happening in either the development environment when
running from one of the development workshops, or with the deployed
application.
The bug outlined in this Technote may be the culprit if the errors above
are
seen when running a client on Windows NT or Motif and the user interface
incorporates ActiveX controls or ListView/TreeView widgets.
CAUSE:
Basically what is happening is that in rare circumstances Forte may invoke
a
nested copy of the interpreter while the first interpreter has yielded.
This
is not a problem in and of itself, but in the case where the original
interpreter was in the middle of a repository fetch when it yielded, and
the second interpreter needs to fetch code as well, we will get one of the
errors listed above, depending on the exact timing. The reason for the
errors is that the repository code at this level is thread-safe but not
re-entrant. It is protected by a mutex that is already owned by the
current task. Which, given the scenario outlined here, where the two
interpreters are running inside of the same task, results in the nested
interpreter being allowed to change data out from under the first.
While for every fetch one or more calls to WindowSystem.Yield will be made
(this is there to prevent the semblance of system lock-up on Win 3.1,
where
Yield is the only way other applications can be allowed to run), there is
a parameter which controls how often to actually yield, which by default
is
set to one out of every 100 calls. This is the reason the problem is
intermittent--you need a yield to occur during a repository fetch
which starts another interpreter which also needs to fetch code from
disk.
The reason this has only surfaced recently is that the nested interpreter
scenario can only happen in 2 cases that we know of:
- ActiveX controls which respond to events/Windows messages
- Outline fields/ListViews with column(s) mapped to virtual
attributes
In all other normal cases, the yield can process the message (typically a
paint message) without starting another interpreter, so regardless of
whether
the first interpreter yielded during a repository operation or not, there
is
no conflict.
SOLUTION:
The workaround is to prevent yields altogether by setting the
FORTE_YIELD_THROTTLE environment variable equal to 0 in the client's
environment. This should have no detrimental effects since the yield code
is in place solely for Windows 3.1x clients.
ERROR STACK 1
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to
prevent the application from attempting to write to the repository. The
repository and work you have saved to the repository are safe. If your
workspace
contains unsaved work, you may use the following procedure to save this
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import
the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::GetObjectById
Last TOOL statement: method EFWindowController.EFEventLoop
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
The remainder of the Error Manager stack is:
SYSTEM ERROR: Internal Error attempting to deserialize element (64,67470)
(fetch
bitmask is 0x20). Your workspace is now read-only to prevent the
application
from attempting to write to the repository. The repository and work you
have
saved to the repository are safe. If your workspace contains unsaved work,
you
may use the following procedure to save this work. First, export the
changed
components. Then, shut down and restart this application and reopen this
workspace in read-write mode. Finally, import the changed components and
save
your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Last TOOL statement: method EFTabManagerNew.EFNoteBookHandler
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
SYSTEM ERROR: Unknown Mark type in deserialization.
Class: qqsp_ImplementationException
Error #: [1101, 34]
Detected at: qqrp_DeSerializeObject::ProcessHdr
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
ERROR STACK 2
SYSTEM ERROR: A serious error has occurred in Repository
(c:\PROGRA~1\CSSPTEST\conplu0). Corrective action may be necessary.
Notify
your repository administrator.
Class: qqsp_ImplementationException
Error #: [1101, 198]
Detected at: qqrp_Repository::Fetch
Last TOOL statement: method
SalesDevelopment_NWC.DEVNotifyofTabSetCurrent
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
SYSTEM ERROR: Could not read record (64,74615) from repository data file.
Header is corrupt.
Class: qqsp_ImplementationException
Error #: [1106, 612]
Detected at: qqbt_BtreeAccess::FetchDataFileRecord
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
Technote 11225 Don't reparent mapped Widgets between UserWindows at
runtime
It is sometimes tempting to unparent a widget from one UserWindow and
reparent
it into another at runtime. However, this can cause crashes if the widget
(or
its decendants) are "mapped" to data. Here's why...
Suppose you have two UserWindows, UW1 and UW2. UW1 contains a DataField
(DF1)
which is mapped to a TextData. UW2 contains a RadioList (RL2) which is
mapped to
a scalar Integer. At compile time, every mapped attribute is internally
assigned
a "Map ID" (a small integer) which is used to tie the Widget to its
corresponding attribute. These Map IDs are used by the Widget to look up a
pointer to their data in a "Map" which is maintained by the UserWindow.
Each
UserWindow is assumed be to independent of the others, so there is nothing
wrong
with Widgets in different UserWindows being assigned the same Map IDs.
In
this
case, let's assume that DF1 and RL2 both got assigned the same Map ID of
3. No
problem so far, since each lives in a separate UserWindow with a separate
map.
Now suppose at runtime the application "detaches" or unparents DF1 from
its
UserWindow and reparents it somewhere into UW2. When it comes time for DF1
to
paint itself the Display System it must ask the Runtime System for the
value of
DF1's mapped attribute. To do that it says "give me the value of the
TextData
for DF1. You'll find it in the Map for this UserWindow (UW1), and its Map
ID is
3". When the runtime system goes to do this it expects to find a TextData
in
this "slot" of the map, but instead it picks up the integer which is
mapped to
RL2. At best this leads to bad data being returned; more likely you get a
segfault and a crash.
If DF1 was not a mapped attribute (say, a Rectangle) there would be no
problem
because there is no data mapped to a Rectangle. If instead of moving DF1
you
created a brand new DataField on the fly there would be no problem,
because the
dynamic DataField would not have any Map ID and so couldn't conflict with
any
IDs in UW2.
So how do you solve this problem? This is exactly what Nested Windows are
all
about. While you can't move DF1 into the middle of UW2, you can nest
UW1.
This
works because UW1 brings its map with it, and when you access DF1 it knows
to
look up its value in UW1's map.
UserWindows are intended to be the "unit of compilabilty" that can be
nested
inside other UserWindows. It is dangerous to "transplant" anything from
inside
one UserWindow into another at runtime.
(Note that you can't avoid this problem by cloning DF1 because the MapID
gets
copied along with it, and the clone will fail in the same way.)
Further details explained in related technote 12448 'Sudden client
partition
crashes at runtime.'
Technote 12448 Sudden client partition crashes at runtime
Scenario : You have two UserWindows, A and B. When Window A starts up, it
instantiates an instance of B and reparents some component of B into A's
window
hierarchy.
This is not allowed and almost always leads to an error at best or at
worse a
segmentation fault.
Here's why :
When you compile a UserWindow in Forte, each "mapped attribute" (whether a
form
element or menu element) is assigned an internal ID which represents an
offset into
that UserWindow's table of mapped attributes. This offset is only valid
in the
context of the UserWindow in which it was compiled. If you detach a
FieldWidget or
MenuWidget from one compiled Window ("tmpMenu" for example) and then
parent
into another compiled window ("tmpWindow") the internal ID comes with it.
When Forte tries to make use of that copied widget it uses the ID as an
offset
into tmpWindow's table of mapped attributes. But that copied offset is
meaningless in the context of tmpWindow's table, so you get some kind off
error.
In this case it found that the data type of the variable in the slot
wasn't
what
was expected. But you might even index off the end of the table and get a
segmentation fault.
There is nothing to prevent you from dynamically creating menu items and
adding
them to a window at runtime; that will work fine. Although of course you
can't
access them via mapped attributes, since those can only be created at
compile time.
But you are not allowed to reparent a widget from one compiled UserWindow
into
the hierarchy of another.
More information may be found in technote 11225 'Don't reparent mapped
Widgets
between UserWindows at runtime'.
Possible errorstacks seen at runtime instead of a complete crash or
segmentation
violation while you are illegally reparenting a widget or menuitem between
windows
at runtime:
Map::SetSubjectData: Invalid conversion from map type 0 to subject type 22
SYSTEM ERROR: Bad parameter at location 3 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 3
Error Time: Wed Aug 09 13:03:57
Exception occurred (locally) on partition "testproject_CL0_Client",
(partitionId = D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd,
taskId =
[D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd.68]) in application
"FTLaunch_cl0", pid 672 on node ONEWAY in environment Audi3M2Env.
At 13:14 26.09.00 -0400, Adamek, Zenon wrote:
Hi,
It is the unfixed defect 53398. Please contact Forte support.
Zenon
-----Original Message-----
From: Brenda Cumming [SMTP:brenda_cummingtranscanada.com]
Sent: Tuesday, September 26, 2000 1:15 PM
To: Forte User group
Subject: (forte-users) 3J=>3M new to me error
Hi,
We are in the process of going from 3J1 to 3.0.M.2, and I am getting
this error that I am unfamiliar with on a GUI that works fine in 3J.
It
does not happen all the time, and I have been unable to establish the
pattern that kicks it off. Has anyone seen this before?
PS- this error is not occurring in the deployed (non-compiled) app,but
when I am running locally from my workspace.
SYSTEM ERROR: Bad parameter at location 6 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 6
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2,
taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Can't find scope 20070 for a class.
Class: qqsp_Exception
Error #: [201, 11]
Detected at: qqlo_ClassTableLoadScope at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to prevent the application from attempting to write to the repository.
The repository and work you have saved to the repository are safe. If
your
workspace contains unsaved work, you may use the following procedure
to save this work. First, export the changed components. Then, shut down and
restart this application and reopen this workspace in read-write mode.
Finally, import the changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::IsDistributed
Last TOOL statement: method PPMeasWin.
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Internal Error attempting to deserialize element
(64,120684) (fetch bitmask is 0x20). Your workspace is now read-onlyto
prevent
the application from attempting to write to the repository. The
repository
and work you have saved to the repository are safe. If your workspace
contains unsaved work, you may use the following procedure to savethis
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Recursive Deserialization attempted, Internal Error!
Class: qqsp_UsageException with ReasonCode: SP_ER_INVALIDSTATE
Error #: [301, 231]
Detected at: qqsp_DeSerializeDriver::Run at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in anew
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Hi Thomas,
Thanks for your email but I think it will be interesting for Brenda not me.
It is exactly what I have expected from Forte Support: detailed information
about bugs and workarounds. But what I cannot understand is that #53398 was
released without any information about possible reasons for this problem or
suggested workarounds. My first reaction after reading this bugreport was to
open a new case at CallCenter to get more information about it. Please
release more information with your bug reports !
Regards
Zenon Adamek
Information Services
Senior Programmer Analyst
Tel: 905 712-1084 ext. 3628
Fax: 905 712-6709
E-mail: zadamekpurolator.com
-----Original Message-----
From: Thomas Degen - Sun Germany Forte Tools - Bonn
[SMTP:thomas.degensun.com]
Sent: Wednesday, September 27, 2000 9:49 AM
To: Adamek, Zenon
Cc: 'Brenda Cumming'; Forte-userslists.xpedior.com
Subject: RE: (forte-users) 3J=>3M new to me error
Hi Zenon,
bug #53398 is not a bug which will likely get fixed, it's an informational
bugreport.
You might see an errorstack like Brenda has reported (and described in
informational
bugreport #53398) probably when you are doing something illegal that is
possible
via Forte Tool but Forte is not trapping it for performance reasons. Hence
you will see
the error coming from your illegal operation only at runtime, probably
only
while
running interpreted in the Forte IDE, but in worst case it might be even a
segmentation
violation.
Technotes 12448 'Sudden client partition crashes at runtime' and 11225
'Don't reparent
mapped Widgets between UserWindows at runtime' explain this matter . See
attached.
But maybe Brenda is much more experiencing a problem as described by Forte
Technote 11398 'Read Only Workspace Errors using ListViews or ActiveX
control'
that might get easily resolved via setting of FORTE_YIELD_THROTTLE=0.
Good Luck and Best Regards !
BTW: I've logged bug #53398, so I've felt responsible to explain its real
background.
Thomas
Thomas Degen
Sun Microsystems - Forte Tools
Forte CTE & Sustaining Group
Technical Support Germany
tel.:+49.228/91499-50
MailTo:thomas.degensun.com
Technote 11398 Read Only Workspace Errors using ListViews or ActiveX
control
SCENARIO:
Getting some unusual interpreter errors that result in an error stating
that
the workspace has been set to read only. Please see Enclosures for the
two
most common error stacks that have been encountered. The abbreviated
versions of the errors are:
- Can't read record (record size = -1)
- Id in index does not match id in record header in data file
- Recursive deserialization attempted.
- Unknown Mark type in deserialization
- Could not read record (64,74615) from repository data file.
Header
is corrupt.
These errors can be happening in either the development environment when
running from one of the development workshops, or with the deployed
application.
The bug outlined in this Technote may be the culprit if the errors above
are
seen when running a client on Windows NT or Motif and the user interface
incorporates ActiveX controls or ListView/TreeView widgets.
CAUSE:
Basically what is happening is that in rare circumstances Forte may invoke
a
nested copy of the interpreter while the first interpreter has yielded.
This
is not a problem in and of itself, but in the case where the original
interpreter was in the middle of a repository fetch when it yielded, and
the second interpreter needs to fetch code as well, we will get one of the
errors listed above, depending on the exact timing. The reason for the
errors is that the repository code at this level is thread-safe but not
re-entrant. It is protected by a mutex that is already owned by the
current task. Which, given the scenario outlined here, where the two
interpreters are running inside of the same task, results in the nested
interpreter being allowed to change data out from under the first.
While for every fetch one or more calls to WindowSystem.Yield will be made
(this is there to prevent the semblance of system lock-up on Win 3.1,
where
Yield is the only way other applications can be allowed to run), there is
a parameter which controls how often to actually yield, which by default
is
set to one out of every 100 calls. This is the reason the problem is
intermittent--you need a yield to occur during a repository fetch
which starts another interpreter which also needs to fetch code from
disk.
The reason this has only surfaced recently is that the nested interpreter
scenario can only happen in 2 cases that we know of:
- ActiveX controls which respond to events/Windows messages
- Outline fields/ListViews with column(s) mapped to virtual
attributes
In all other normal cases, the yield can process the message (typically a
paint message) without starting another interpreter, so regardless of
whether
the first interpreter yielded during a repository operation or not, there
is
no conflict.
SOLUTION:
The workaround is to prevent yields altogether by setting the
FORTE_YIELD_THROTTLE environment variable equal to 0 in the client's
environment. This should have no detrimental effects since the yield code
is in place solely for Windows 3.1x clients.
ERROR STACK 1
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to
prevent the application from attempting to write to the repository. The
repository and work you have saved to the repository are safe. If your
workspace
contains unsaved work, you may use the following procedure to save this
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import
the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::GetObjectById
Last TOOL statement: method EFWindowController.EFEventLoop
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
The remainder of the Error Manager stack is:
SYSTEM ERROR: Internal Error attempting to deserialize element (64,67470)
(fetch
bitmask is 0x20). Your workspace is now read-only to prevent the
application
from attempting to write to the repository. The repository and work you
have
saved to the repository are safe. If your workspace contains unsaved work,
you
may use the following procedure to save this work. First, export the
changed
components. Then, shut down and restart this application and reopen this
workspace in read-write mode. Finally, import the changed components and
save
your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Last TOOL statement: method EFTabManagerNew.EFNoteBookHandler
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
SYSTEM ERROR: Unknown Mark type in deserialization.
Class: qqsp_ImplementationException
Error #: [1101, 34]
Detected at: qqrp_DeSerializeObject::ProcessHdr
Error Time: Tue Nov 18 15:58:47
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1,
taskId =
[7EFAE060-4AFA-11D1-A1C1-1FDC8A99AA77:0x446:0x1.23]) in application
"ConPlus_GUI_cl0", pid 147 on node ISD060 in environment EdgeTest.
ERROR STACK 2
SYSTEM ERROR: A serious error has occurred in Repository
(c:\PROGRA~1\CSSPTEST\conplu0). Corrective action may be necessary.
Notify
your repository administrator.
Class: qqsp_ImplementationException
Error #: [1101, 198]
Detected at: qqrp_Repository::Fetch
Last TOOL statement: method
SalesDevelopment_NWC.DEVNotifyofTabSetCurrent
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
SYSTEM ERROR: Could not read record (64,74615) from repository data file.
Header is corrupt.
Class: qqsp_ImplementationException
Error #: [1106, 612]
Detected at: qqbt_BtreeAccess::FetchDataFileRecord
Error Time: Wed Dec 03 10:27:22
Exception occurred (locally) on partition "ConPlus_GUI_cl0_Client",
(partitionId = 769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1,
taskId =
[769D4310-6B88-11D1-84FD-65BF87C8AA77:0x121:0x1.22]) in application
"ConPlus_GUI_cl0", pid 172 on node ISD42 in environment Edge.
Technote 11225 Don't reparent mapped Widgets between UserWindows at
runtime
It is sometimes tempting to unparent a widget from one UserWindow and
reparent
it into another at runtime. However, this can cause crashes if the widget
(or
its decendants) are "mapped" to data. Here's why...
Suppose you have two UserWindows, UW1 and UW2. UW1 contains a DataField
(DF1)
which is mapped to a TextData. UW2 contains a RadioList (RL2) which is
mapped to
a scalar Integer. At compile time, every mapped attribute is internally
assigned
a "Map ID" (a small integer) which is used to tie the Widget to its
corresponding attribute. These Map IDs are used by the Widget to look up a
pointer to their data in a "Map" which is maintained by the UserWindow.
Each
UserWindow is assumed be to independent of the others, so there is nothing
wrong
with Widgets in different UserWindows being assigned the same Map IDs.
In
this
case, let's assume that DF1 and RL2 both got assigned the same Map ID of
3. No
problem so far, since each lives in a separate UserWindow with a separate
map.
Now suppose at runtime the application "detaches" or unparents DF1 from
its
UserWindow and reparents it somewhere into UW2. When it comes time for DF1
to
paint itself the Display System it must ask the Runtime System for the
value of
DF1's mapped attribute. To do that it says "give me the value of the
TextData
for DF1. You'll find it in the Map for this UserWindow (UW1), and its Map
ID is
3". When the runtime system goes to do this it expects to find a TextData
in
this "slot" of the map, but instead it picks up the integer which is
mapped to
RL2. At best this leads to bad data being returned; more likely you get a
segfault and a crash.
If DF1 was not a mapped attribute (say, a Rectangle) there would be no
problem
because there is no data mapped to a Rectangle. If instead of moving DF1
you
created a brand new DataField on the fly there would be no problem,
because the
dynamic DataField would not have any Map ID and so couldn't conflict with
any
IDs in UW2.
So how do you solve this problem? This is exactly what Nested Windows are
all
about. While you can't move DF1 into the middle of UW2, you can nest
UW1.
This
works because UW1 brings its map with it, and when you access DF1 it knows
to
look up its value in UW1's map.
UserWindows are intended to be the "unit of compilabilty" that can be
nested
inside other UserWindows. It is dangerous to "transplant" anything from
inside
one UserWindow into another at runtime.
(Note that you can't avoid this problem by cloning DF1 because the MapID
gets
copied along with it, and the clone will fail in the same way.)
Further details explained in related technote 12448 'Sudden client
partition
crashes at runtime.'
Technote 12448 Sudden client partition crashes at runtime
Scenario : You have two UserWindows, A and B. When Window A starts up, it
instantiates an instance of B and reparents some component of B into A's
window
hierarchy.
This is not allowed and almost always leads to an error at best or at
worse a
segmentation fault.
Here's why :
When you compile a UserWindow in Forte, each "mapped attribute" (whether a
form
element or menu element) is assigned an internal ID which represents an
offset into
that UserWindow's table of mapped attributes. This offset is only valid
in the
context of the UserWindow in which it was compiled. If you detach a
FieldWidget or
MenuWidget from one compiled Window ("tmpMenu" for example) and then
parent
into another compiled window ("tmpWindow") the internal ID comes with it.
When Forte tries to make use of that copied widget it uses the ID as an
offset
into tmpWindow's table of mapped attributes. But that copied offset is
meaningless in the context of tmpWindow's table, so you get some kind off
error.
In this case it found that the data type of the variable in the slot
wasn't
what
was expected. But you might even index off the end of the table and get a
segmentation fault.
There is nothing to prevent you from dynamically creating menu items and
adding
them to a window at runtime; that will work fine. Although of course you
can't
access them via mapped attributes, since those can only be created at
compile time.
But you are not allowed to reparent a widget from one compiled UserWindow
into
the hierarchy of another.
More information may be found in technote 11225 'Don't reparent mapped
Widgets
between UserWindows at runtime'.
Possible errorstacks seen at runtime instead of a complete crash or
segmentation
violation while you are illegally reparenting a widget or menuitem between
windows
at runtime:
Map::SetSubjectData: Invalid conversion from map type 0 to subject type 22
SYSTEM ERROR: Bad parameter at location 3 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 3
Error Time: Wed Aug 09 13:03:57
Exception occurred (locally) on partition "testproject_CL0_Client",
(partitionId = D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd,
taskId =
[D4914A10-36C1-11D4-91B3-419AA33BAA77:0x208:0xd.68]) in application
"FTLaunch_cl0", pid 672 on node ONEWAY in environment Audi3M2Env.
At 13:14 26.09.00 -0400, Adamek, Zenon wrote:
Hi,
It is the unfixed defect 53398. Please contact Forte support.
Zenon
-----Original Message-----
From: Brenda Cumming [SMTP:brenda_cummingtranscanada.com]
Sent: Tuesday, September 26, 2000 1:15 PM
To: Forte User group
Subject: (forte-users) 3J=>3M new to me error
Hi,
We are in the process of going from 3J1 to 3.0.M.2, and I am getting
this error that I am unfamiliar with on a GUI that works fine in 3J.
It
does not happen all the time, and I have been unable to establish the
pattern that kicks it off. Has anyone seen this before?
PS- this error is not occurring in the deployed (non-compiled) app,but
when I am running locally from my workspace.
SYSTEM ERROR: Bad parameter at location 6 in method
qqrt_MapClassAccess::ProcessSubjectData.
Class: qqsp_Exception
Error #: [1001, 381]
Detected at: qqrt_MapClassAccess::ProcessSubjectData at 6
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2,
taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Can't find scope 20070 for a class.
Class: qqsp_Exception
Error #: [201, 11]
Detected at: qqlo_ClassTableLoadScope at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Because of a prior error, your workspace was set to
read-only to prevent the application from attempting to write to the repository.
The repository and work you have saved to the repository are safe. If
your
workspace contains unsaved work, you may use the following procedure
to save this work. First, export the changed components. Then, shut down and
restart this application and reopen this workspace in read-write mode.
Finally, import the changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 695]
Detected at: qqrp_Session::IsDistributed
Last TOOL statement: method PPMeasWin.
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Internal Error attempting to deserialize element
(64,120684) (fetch bitmask is 0x20). Your workspace is now read-onlyto
prevent
the application from attempting to write to the repository. The
repository
and work you have saved to the repository are safe. If your workspace
contains unsaved work, you may use the following procedure to savethis
work.
First, export the changed components. Then, shut down and restart this
application and reopen this workspace in read-write mode. Finally, import the
changed components and save your workspace.
Class: qqrp_RepResourceException
Error #: [1101, 61]
Detected at: qqrp_LogicalSession::MaterializeObject
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition
"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
SYSTEM ERROR: Recursive Deserialization attempted, Internal Error!
Class: qqsp_UsageException with ReasonCode: SP_ER_INVALIDSTATE
Error #: [301, 231]
Detected at: qqsp_DeSerializeDriver::Run at 1
Error Time: Wed Sep 20 14:32:54
Exception occurred (locally) on partition"ABSDevtStartUp_CL0_Client",
(partitionId = 36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2, taskId =
[36172000-5DA8-11D4-B1F0-14015EDAAA77:0x2da:0x2.25]) in
application
"Forte_cl0", pid 93 on node T5621 in environment AbisDMEnv.
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in anew
email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

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

For 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 have a factory unlocked iphone 4s. I'm from Belize but i'm going to visit Fort Lauderdale, FLA. How can I get data for my phone? I checked the web and only got 'not sure to don't know' answers. Whoever has done this please help me

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.

Making the BP Fact Sheet as the default page in CIC

Hi All,
How to make the BP Fact Sheet as the default page in the CIC WinClient. What is the config (IMG) path/ transaction code to do this change? Please let me know.
Thanks in advance.
--R D

Hi R D,
the transaction code is CRMC_CIC_WSP3 -
'Define Profile for Automatically Created Workspaces'
Best regards,
Gerhard

Unable to view Service notification in CIC fact sheet

In the Customer Interaction Center for Utilities(CIC0), I'm unable to view a certain service notification under a custom fact sheet. However, if I try to view it by accessing CIC from ECC, it is visible there. What could be the possible issue?

It is working fine now. Actually I had some DML configuration data in the old DS and it got replicated in the new DS instance. So whenever I click on the ServiceConfiguration tab it tries get some config details about that service and ultimately fails to get so. When I deleted the entry in LDAP, I can see all the services available.
--lakshmi

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

RE: Java and Forte

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: Forte - CICS on NT

Similar Messages

Maybe you are looking for