Forte timer
I am trying to start a process overnight at a certain time in a forte
application, and I am wondering if anyone has any hints on using the timer
class in forte. I was thinking of having a service object on the server
waiting until a specific time and then posting a message to another service
object, which contains the methods that will perform the process.
Jim Field
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
Jim,
There are a few ways to do this.
1. Use a WaitUntil method on a Timer object to post a message
at a specified time. This way you don't have to trap Timer ticks
in an event loop. However, I remember having heard( in this
list ) cries about a WaitUntil bug which often posted Tick
event several minutes( or hours?? ) after the specified time.
2. Have a service object running on the server with
an attribute of type Timer and make it post events.
You should know that in the Forte Framework,
Timer is not set to shared or distributed. So you
will first need to wrap the Timer( preferably as a private
attribute ) in a class, make the wrapper class
shared, and make the wrapper class an attribute of your
SO.
3. For applications that need certain processes to be
run by a Service object periodically,
create a local Timer object, set its TickInterval
as per your requirements the Init() method .
Also have an event loop in the Init method which
traps the Timer's Tick event and performs the
required process. This is a very simple solution.
Happy Holidays!
Ajith Kallambella. M
Forte Systems Engineer,
International Business Corporation.
-----Original Message-----
From: Field, Jim [mailto:[email protected]]
Sent: Monday, December 28, 1998 7:01 PM
To: forte users group
Subject: Forte timer
I am trying to start a process overnight at a certain time in a forte
application, and I am wondering if anyone has any hints on using the timer
class in forte. I was thinking of having a service object on the server
waiting until a specific time and then posting a message to another service
object, which contains the methods that will perform the process.
Jim Field
(916) 861-1869
[email protected]
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
Similar Messages
-
From: "GAUR, Anurag" <[email protected]>
Date: Mon, 17 May 1999 14:03:39 -0400
Subject: Forte Timer Class
Hi,
I'm using Forte's Timer class in developing a Scheduler for our project.
I have noticed the tick event generated by the Timer class is always late.
For a timer of 30 minutes duration, the event generated is late by 36
seconds, for a timer
of 6 hours duration, its late by 7 minutes and 12 seconds. And for a timer
of 24 hours
duration its late by 28 minutes and 49 seconds.
Any idea why Timer class is behaving like this. Is Timer class notsupposed
to be
used for long duration of time ?
Thanks,
Anurag GaurAnurag,
What you have described is consistent with a case I opened last October.
The case # is 48702- You may want to look it up. Essentially there is a
defect in the Forte runtime which we observed on Solaris 2.6. Forte on
Solaris uses the Forte thread package, and the correction for this will go
very deep. Forte has acknowledged the bug but its probably not going to be
fixed on version 3. On platforms such as NT native threads are used and
the problem does not appear. It also doesn't appear on Digital Unix. Our
workaround is to do time polling in an event loop which works but it's not
pretty as compared to the Timer.WaitUntil method.
Good Luck ....
Charlie Shell
Information Services, Bell Atlantic Mobile
2000 Corporate Drive, Orangeburg NY 10962
E-Mail: [email protected]
Tel: (914) 365-7927 Cell: (908) 770 -0096
Pager: 1-800-SKY-8888 pin 6300432
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 h/w and s/w are you using?
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
There definitely seems to be a bug in the Forte timer class.
I believe that Forte will "'fess up" to this if you ask, although it seems
to have existed for some time.
We have the exact same problem here where a timer that we schedule for hours
in advance will often be late on the order of 30 minutes. The delay seems
to be somewhat proportional as well. For instance, if we schedule something
only ten minutes into the future, it may be off by only 30-45secs.
We have been asking tech support about this, but they only will say there is
a know timer problem (without explaining what it is). This seems sufficient
to them as a means to explain away any and all timer related bugs.
Sam Yates
Email: [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/>On Mon, 30 Nov 1998 16:37:42 -0700, Chris Lee wrote:
We are using "WaitUntil" method on Forte Timer to run daily process in
our applciation.
WaitUntil is set to tick at 3:00 AM everyday. However, it generally does
not fire until some mins later (upto 20 mins).
Has anyone experienced similar situations with Forte Time? Or, Does
anyone have any suggestions as to what might inhibit timer?Only 20 minutes late? You are lucky! When we tried using WaitUntil to
schedule a process to wake up at 5:30 AM, it typically wouldn't wake up
until after 6:30, and sometimes not until after 8 AM! Needless to say,
we abandoned using Forte's Timer class for this purpose.
================================================
Dale V. Georg
Senior Systems Analyst
Indus Consultancy Services
[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/> -
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/> -
7 Hours left :(! I hate Java Forte SO MUCH. Please help! Not much time
7 Hours left :(! I hate Java Forte SO MUCH. Please help! Not much time
Ok I first Installed Java Forte cause I had to a Course and the teacher gave us an Exe which was 62 MB on a Disc and i ran it and put Java Forte On My Computer. I also put a JDK program on my computer through a Java book(Got a CD with it).I could do my Java at home but there was a massive problem. I am using Windows XP and if i used java, My Computer would never shut down cause java would always be running. So this got frustrating and i decided to uninstall it.(Also the Java Plug in decided to stop my java Yahoo chat on IE).When i uninstalled it, I am not sure if i deleted the folder, Did it through control panel(Add/Remove), Or use the uninstaller, I didnt think there was an uninstaller.
Anyway there was still some jc.java and java Web Start folders and J2SDK folder on my HDD.
A while later I get a big Java Assignment to do, I decide to install the Java again on my Computer, I go ahead and click the exe, It takes me to an intall place, I wait, Wait impatiently for 1 hour, It just froze on the install screen. I also tryed it on my old PC which had java, It froze But before it frose it said i already had it installed (Which it wasnt anymore). So i though maybe its the CD or something. So my friend gives me his CD and i try, Yet again it stayed like that for 2 hours. I was so frustrated. I ended up Going to control panel and removed the java Web Start and deleted the J2sdk FOlder and deleted the java Plug in from where it locates it.
I then decide to install Java again but this time it takes me to the uninstaller? Why did it try to install from this exe but after i deleted stuff both CD's Mine and my Friends take to to the uninstaller? Well anyway i decided to Uninstall it like it said"Java Forte 3 and Some other little thing" Then i waited and it said Uninstall Complete. I double click the exe on the CD again and it takes me to the uninstaller again? I was like WTF? How do i install Java? Its just the biggest pain? Why is it taking me there instead of the actuall installer?
Also I dislike other java programs as 1, You cant Execute the code cause its only HTML compatible and or you need the JDK files accosiated with the JCreator which i cant Understand.
Also i got Jreal and it actually worked, But there is no uninstaller for it and it has no Removeal in the Control panel? Whats up with that? Also its good how it works. But for some reason it doesnt accept the code properly as the buttons and labels just appear everywhere and stay there even if i change forms and are messed up compared to when i run it on Java Forte at School.
Also i have a Major Problem with Jreal as it states everytime i run an Applet "Start Applet is not Initialized?" And it shows a Blank applet? Whats up with this? I got no Errors and i think it said Exit Statement:1. But It worked before then i tryed it and it does this all the time for all my Java Program Applets. So I have no idea. It really frustrates me as it was working and i did no changes to the code and it wont let me test any more :(! Why is this happenning to me?
Please help me in the best way you can, I dont have much time, 7 Hours to be Precise to do it in!
Please if you can help me with any problems about installing or evening trying to be able to run Jcreator(Dont understand How to link it with JDK) or any good Java Programs to download that are easy to use(I dont have enough time to read). I couldnt understand CoffeeCup as it was HTML only? and only could run as a Web Page! But any help on Any of these problems that i suffer including Jreal How to Uninstall? Plus Mainly trying to get Java Forte Runnign as that was the only one that was properly showed the correct format of my Coding Applet.Awww :(
-
Hello everybody,
I have a generic question regarding the Forte compilation performance. We
have a large application in Forte 3.0.G. We compile this application to
generate an executable. We notice two problems:
1. Each time we change a class, Forte generates the entire application
again, even though we changed only one class (out of 100 classes). Is
there any way to be able to compile only a part of the application. It
takes an enormous time to make a compiled distribution and to actually
compile it. BTW, we use FCompile and not the AutoCompile feature of Forte.
2. The time taken to make a compiled distribution and to fcompile
generated .pgf file is huge (currently it takes more than 4 hours for the
entire process and we have 3 such applications, so the total time is a big
12 hours!). Is there any flag that we can set either in Forte or in
FCompile to speed up the process?
Also have anybody used the Autocompile feature? Does it work faster?
I would be grateful if somebody can help us out.
Thanks,
Anand.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Anand,
Autocompile will be slower that using fcompile. Autocompile is a sequential
process. It starts one compile after the other finishes.
But since you control fcompile, you can start multiple at the same time.
Have you tried the Make Partial Distribution facility. I am not sure if it
will work in your situation, but it is worth a try.
Hope this helps.
Venkat J Kodumudi
PriceWaterhouseCoopers LLP
Internet: [email protected]
Internet2: [email protected]
-----Original Message-----
From: [email protected]
[SMTP:[email protected]]
Sent: Monday, January 18, 1999 11:21 AM
To: Venkat Kodumudi
Subject: Forte Compilation Time
To: [email protected]
cc: (bcc: Venkat Kodumudi/MCS/Price Waterhouse)
From: [email protected] @ INTL
Date: 01/18/99 03:49:22 PM GMT
Subject: Forte Compilation Time
Hello everybody,
I have a generic question regarding the Forte compilation performance. We
have a large application in Forte 3.0.G. We compile this application to
generate an executable. We notice two problems:
1. Each time we change a class, Forte generates the entire application
again, even though we changed only one class (out of 100 classes). Is
there any way to be able to compile only a part of the application. It
takes an enormous time to make a compiled distribution and to actually
compile it. BTW, we use FCompile and not the AutoCompile feature of
Forte.
2. The time taken to make a compiled distribution and to fcompile
generated .pgf file is huge (currently it takes more than 4 hours for the
entire process and we have 3 such applications, so the total time is a big
12 hours!). Is there any flag that we can set either in Forte or in
FCompile to speed up the process?
Also have anybody used the Autocompile feature? Does it work faster?
I would be grateful if somebody can help us out.
Thanks,
Anand.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received
this in error, please contact the sender and delete the material from any
computer.
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
Re: (forte-users) DateTimeData and time zones, I need amagictrick !
You might try externalizing as textdata whenever its passed between partitions.
kelsey.petrychynsasktel.sk.ca on 04/26/2000 03:45:28 PM
To: "Guylain Rochon" <GRochonInfluatec.ca>
cc: kamranaminyahoo.com (bcc: Charlie Shell/Bsg/MetLife/US)
Subject: Re: (forte-users) DateTimeData and time zones, I need a magic trick !
I haven't done a lot of work with time zones, but I have some ideas that just
may work. If it is important for this object to pass in and out of time-zones
untouched by the destination try passing it by reference. The idea is that the
actual object will remain in one time zone. You may need to "anchor it down"
somehow where it resides (Make it private, READ_ONLY or ??).
Another thing to try is: If it is passed via a method set the mechanism as
"input". I believe this will stop the destination from changing it. (i.e. It
will receive it as input only).
Just some ideas. Good luck.
Kelsey PetrychynSaskTel Technical Analyst
ITM - Technology Solutions - Distributed Computing
Tel (306) 777 - 4906, Fax (306) 359 - 0857
Internet:kelsey.petrychynSasktel.sk.ca
Quality is not job 1. It is the only job!
Guylain Rochon <GRochonInfluatec.ca> on 04/26/2000 01:15:47 PM
To: "\[FORTE\] Maling list" <kamranaminyahoo.com>
cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
Subject: (forte-users) DateTimeData and time zones, I need a magic trick !
Help, I'm drowning and FortI haven't done a lot of work with time zones, but I have some ideas that just
may work. If it is important for this object to pass in and out of time-zones
untouched by the destination try passing it by reference. The idea is that the
actual object will remain in one time zone. You may need to "anchor it down"
somehow where it resides (Make it private, READ_ONLY or ??).
Another thing to try is: If it is passed via a method set the mechanism as
"input". I believe this will stop the destination from changing it. (i.e. It
will receive it as input only).
Just some ideas. Good luck.
Kelsey PetrychynSaskTel Technical Analyst
ITM - Technology Solutions - Distributed Computing
Tel (306) 777 - 4906, Fax (306) 359 - 0857
Internet:kelsey.petrychynSasktel.sk.ca
Quality is not job 1. It is the only job!
Guylain Rochon <GRochonInfluatec.ca> on 04/26/2000 01:15:47 PM
To: "\[FORTE\] Maling list" <kamranaminyahoo.com>
cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
Subject: (forte-users) DateTimeData and time zones, I need a magic trick !
Help, I'm drowning and Fort -
Error msg when running Forte the first time
The first time I ran Forte after installing it, I got an error message. Does anyone know what this means? I got this message on Win 98 and 2000. Here is the error message:
"Some of the set of previously installed modules did not satisfy their dependencies
and will be treated as disabled.
For Tools Debugger ("org.netbeans.modules.debugger.debug/1") failed:
This module depends on Java package sun.tools.debug which is not loaded
(or registered according to theVersioning Specification)."The same error message appeared when I installed Forte on a Linux platform. I wondered if it might have something to do with the fact that I set JDK_HOME to the location of J2SE and not J2EE, which I thought perhaps might have org.netbeans stuff in it, maybe also the remote debugging stuff in sun.tools.debug. But I'm not sure if I should set JDK_HOME of J2EE and reinstall Forte to find out.
-
RE: Forte Compilation Time -Reply
J.KODUMUDI 01/18/99 11:30am >>>
Anand,
Autocompile will be slower that using fcompile. Autocompile is a
sequential process. It starts one compile after the other finishes.
But since you control fcompile, you can start multiple at the same time.
Have you tried the Make Partial Distribution facility. I am not sure if it will
work in your situation, but it is worth a try.
Hope this helps.
Venkat J KodumudiOur Forte server is an RS/6000 running AIX. Our app has around 5-7
partitions (depending on how we set things up). We had 2 fcompile
scripts. One would fcompile each partition in order (ie. one at a time), the
other script was actually a script for each partition. The time to run the
one large one was about the same as it took to launch the 5-7 single
scripts at the same time.
Apparently, there is only so much CPU to go around. Anyone else
experience this?
Steven
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>J.KODUMUDI 01/18/99 11:30am >>>
Anand,
Autocompile will be slower that using fcompile. Autocompile is a
sequential process. It starts one compile after the other finishes.
But since you control fcompile, you can start multiple at the same time.
Have you tried the Make Partial Distribution facility. I am not sure if it will
work in your situation, but it is worth a try.
Hope this helps.
Venkat J KodumudiOur Forte server is an RS/6000 running AIX. Our app has around 5-7
partitions (depending on how we set things up). We had 2 fcompile
scripts. One would fcompile each partition in order (ie. one at a time), the
other script was actually a script for each partition. The time to run the
one large one was about the same as it took to launch the 5-7 single
scripts at the same time.
Apparently, there is only so much CPU to go around. Anyone else
experience this?
Steven
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'm afraid it is a strange question, but : is it
possible to read FORTE(1) code text of a method at run time ?
(1) in V 2.F.2
Regards,
Jean-Baptiste BRIAUD
SEMA GROUP
16 rue Barbes
92126 Montrouge
FranceHi,
see your other post http://forums.ni.com/ni/board/message?board.id=330&message.id=13914
Also, you can, specify to display the front panel of your VI when you specify your VI in your sequence file.
There are examples, for dialog panel using LabVIEW, in the examples folder of TestStand and on the NI Web Site.
Regards
Ray Farmer
Regards
Ray Farmer -
from Mr. Mohee Jarada
Lufthansa Systems - Forté Consultant
Email(s):
[email protected]
[email protected]
Hamburg - Germany
Hi,
If any one facing problems witfrom Mr. Mohee Jarada
Lufthansa Systems - Forté Consultant
Email(s):
[email protected]
[email protected]
Hamburg - Germany
Hi,
If any one facing problems wit -
Dear users,
I run the forte 4 IDE on the 1.4.0 runtime. Often forte hangs with a gray screen and the application does not respond to anything.
Does anybody know what the cause of this problem is?
Greats,
JeffreyHi ,
I too had occasionally faced such problems when using forte 4.Try using Sun Java studio 5.
Its much faster and has lots of new features.
You might also try posting your query in the forte forum at http://swforum.sun.com/jive/forum.jspa?forumID=78
-Amol -
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 -
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. -
Can we share our photos in the family on different mac´s with Time Capsule?
Can we share our photos in the family on different mac´s with Time Capsule?
It depends on the size and number of photos you are sharing around.
Nothing wrong with putting a copy of the photos on the TC if that works for you. Each person can access the photo just fine like that.
I am not saying don't.. just beware of the risks so do it prudently..
But if the library is too large, you will steal space on the TC that should be used for backups.. if all the computers in the network are backing up to it, don't use too much of the spare space.
Better to buy a firewire drive (or USB but firewire 800 are much faster) and connect it to a computer that is regularly turned on. Share that drive to the network. It will then also be backed up correctly to the TC although again be careful of the amount of files, and still keep a straight copy backup somewhere else.
I am recent convert so workflow on the Mac is not my forte.. so perhaps some of the wiser heads can also drop in and post a reply.
Maybe you are looking for
-
CR VS2005 ActiveX Printing Mode print the report larger
Hi, I have a problem with CR VS2005 for ActiveX printing mode. It will print the report larger than usual so when I print it to the printer, some parts will cut off. But the report will print okay if I export it to pdf and print from the acrobat read
-
I just bought a Iphone 5 -- my Iphone 4 and my ipad used to automatically sinc calendars via the Icloud whenever I entered anything on either device -- I can not get the new phone to do this.I have check the settings on both devices and they seem to
-
Hi, Given a MacPro with a X1900 card - what would be good choice of LCD for running Aperture? I am torn between the ACD23" and a cheaper DeLL24" Ultrasharp 2407WFP. Being on a student budget I would like to have money for more equipment and currently
-
I am trying to debug a third party package which fails in the debugger but runs OK. There are two issues. 1 It includes the following code in the package body (ie as package initialisation). gv_audit_dir := TRIM(pk_dbgen.GET_SYSTEM_PARAMETER(pmi_
-
I recently rented a movie, it downloaded successfully, and it will not play. When I call up the movie, there is no play button, just what appears to be a stop button. How do I access this movie, or get a refund?