RE: (forte-users) Debugging 'fixes' problem!!!

Duncan
This is often indicative of a race condition, especially when
multi-threading is involved.
What can happen is that task A is using something created or initialized by
task B,
and task B hasn't gotten around to doing its thing before task A asks for
it.
When running in debug mode, you give everything a lot more time to get
things
done while it's waiting for you to click the next button. So, when task A
starts task B,
you click Run on task B, watch it happen, go back to task A and click,
watch, click, etc.,
and by the time you get to the trouble spot, task B has long since done what
it had to do.
HTH.
Ken.
==========================
Ken Gacioch
Senior Consultant
Caro Systems, Inc.
[email protected]
-----Original Message-----
From: Duncan Kinnear [SMTP:[email protected]]
Sent: Sunday, November 21, 1999 11:33 PM
To: [email protected]
Subject: (forte-users) Debugging 'fixes' problem!!!
Hi folks,
I've got a weird one here.
I'm trying to find out why my code to highlight a particular outline field
row does not work.
However, when I run it in debug, it works perfectly! (The correct row is
highlighted). Anybody got any idea how I can get debug to behave
consistently with "The running man"?
I have tried using "<OutlineField>.UpdateFieldFromData()" as well as
using the same method on the specific DisplayNode involved.
I must point out that the outline field is in a window running as a
separate asynchronous task. Would that make any difference when
running in debug? When the second debug window appears for this
task I just click on the "Go" button and there are no breakpoints.
Any help would be greatly appreciated.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email:
[email protected]
PO Box 764, McLean Towers, Phone: +64 6 834 3360
Shakespeare Road, Napier, New Zealand. Fax: +64 6 834
3369

Duncan
This is often indicative of a race condition, especially when
multi-threading is involved.
What can happen is that task A is using something created or initialized by
task B,
and task B hasn't gotten around to doing its thing before task A asks for
it.
When running in debug mode, you give everything a lot more time to get
things
done while it's waiting for you to click the next button. So, when task A
starts task B,
you click Run on task B, watch it happen, go back to task A and click,
watch, click, etc.,
and by the time you get to the trouble spot, task B has long since done what
it had to do.
HTH.
Ken.
==========================
Ken Gacioch
Senior Consultant
Caro Systems, Inc.
[email protected]
-----Original Message-----
From: Duncan Kinnear [SMTP:[email protected]]
Sent: Sunday, November 21, 1999 11:33 PM
To: [email protected]
Subject: (forte-users) Debugging 'fixes' problem!!!
Hi folks,
I've got a weird one here.
I'm trying to find out why my code to highlight a particular outline field
row does not work.
However, when I run it in debug, it works perfectly! (The correct row is
highlighted). Anybody got any idea how I can get debug to behave
consistently with "The running man"?
I have tried using "<OutlineField>.UpdateFieldFromData()" as well as
using the same method on the specific DisplayNode involved.
I must point out that the outline field is in a window running as a
separate asynchronous task. Would that make any difference when
running in debug? When the second debug window appears for this
task I just click on the "Go" button and there are no breakpoints.
Any help would be greatly appreciated.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email:
[email protected]
PO Box 764, McLean Towers, Phone: +64 6 834 3360
Shakespeare Road, Napier, New Zealand. Fax: +64 6 834
3369

Similar Messages

  • Oggetto: Re: (forte-users) XML - ExportDocumentproblem

    Ok, I'll detail the question.
    The application I'm talking about is a Fort&egrave; server and a Java client (or other
    client platform).
    I have to send via HTTP a XML message to and from the two.
    I'm developing the Forte side (but think will have the same problems in Java).
    Since there could be lots of client sides developed by others teams (or given
    out to external suppliers) my concern is to send the message containing the DTD
    information to enforce the validation on the various application.
    Maybe you are right and I'm overcautious, but the messages are to be built
    following the various DTDs (and this is impossible aside starting from a xml
    template, since I cannot create a DTD runtime or insert a declaration <!DOCUMENT
    ...> ... I'll example:)
    doc : document = new();
    xml : processistruction = doc.createprocessistruction('xml version="1.0"');
    root : element = doc.createelement('root');
    dtd : ????? = doc.create??????(???);
    doc.addchild(xml);
    doc.appendchild(dtd);
    doc.addchild(root);
    All would be nice if I only know how to fill the ???
    This is needed because I want to use the parser to make the work for me and
    check the doc while I build it.
    Also since the DTD should be put on a url it could change and I need to send
    this info along with the message to inform the client (since I'm the server
    [suffering of multiple personality problem] I think is my duty).
    If I recall well DTD are meant to force the parser to create defaults and things
    like that.
    As I said I'm new of the problem and probabli I may use DTD in a wrong way, but
    Luca
    Matthew Middleton <mathew.middletonlawpoint.com.au> il 09/08/2000 01.03.16
    Per: forte-userslists.xpedior.com
    cc: (ccr: Luca Gioppo/CSI/IT)
    Oggetto: Re: (forte-users) XML - ExportDocument problem

    I went through the same process some time back. I
    submitted a call to Forte and was informed that there
    are hooks but they were intentionally undocumented
    because Forte had plans to provide a interface to
    Source Control Managers in future releases. If you
    submit a call, they will send you a ZIP file
    containing instructions on how to use the hooks. The
    hooks have proven very useful.
    --- Luca Gioppo <Luca.Gioppocsi.it> wrote:
    >
    >
    I think that the topic is still open and alive.
    In my case I have the need to integrate with PVCS
    dimension.
    The problem for me is that we develop both with java
    and tool, and is
    frustrating seeing java people smiling as tha
    various tools give the chance to
    integrate to various extends with source control
    products.
    I'm interested too in the problem, looking for a
    solution since a bit, but no
    satifactory solutions.
    So count 2 on the problem.
    Luca
    "David Potts" <david.pottss1.com> il 23/11/2000
    17.12.47
    Per: forte-userslists.xpedior.com
    cc: (ccr: Luca Gioppo/CSI/IT)
    Oggetto: (forte-users) Source Control
    Hello,
    I'm looking how to do version control for forte
    development, and have
    done a search on the list archive. There are lots
    of messages asking
    how to do source control, but the answers all seem
    to be "roll your
    own". My questions are:
    (1) Most of the postings seem to come from some
    years ago. What is the
    current state of play with source control for forte
    4GL?
    (2) There was some mention of "hooks". What are
    these hooks?
    (3) With Sun appearing on the scene, anyone got any
    idea where source
    control is going in future versions?
    I'm very new to Forte, so sorry if this topic has
    been closed.
    Cheers,
    Dave.
    ATTACHMENT part 2 application/octet-streamname=david.potts.vcf
    http://shopping.yahoo.com/

  • Re: (forte-users) Display Problem

    Judging by the title bar of the window, it looks like the application is
    not running on the Boston user's PC, but is being driven by some sort of
    PCAnywhere-style program. Maybe that's the problem?
    At 14:44 28/02/00 -0800, Holm, Steve wrote:
    <<good.doc>>
    We have an application running in production that has been working just
    fine. The screen layout is in the attached good.doc document. We brought
    up our Boston division on this application and one user there has a problem
    with the tabs at the bottom. The bottom section is scrunched together so
    that not all the data is visible. I have attached a screen shot of the
    application on her pc (bad.doc). Does anyone have any idea what might be
    causing this?
    <<bad.doc>>Stephen Szalla
    Senior Technical Specialist
    Sun Microsystems Australia - Forte Tools Group
    Voice: +61 3 9699 7754
    Fax: +61 3 9699 7781
    Mobile: +61 419 392 867
    mailto:Stephen.Szallaaus.sun.com
    http://www.forte.com

    My guess is, your third service object is not referenced.
    -----Original Message-----
    From: Forte App [mailto:forteapphotmail.com]
    Sent: Wednesday, May 17, 2000 3:08 PM
    To: kamranaminyahoo.com
    Subject: (forte-users) Partition problem
    Hello Everyone,
    I have three (3) service objects in my project and when i went into
    partition workshop i can only see two service objects instead of three and
    all the three service objects properties settings are same
    iam using Forte 3.0L2.
    Thanks in Advance
    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

  • Re: (forte-users) access violation caught in debugmode

    Eric,
    There has been a problem with Forte debug mode for sometime now when the app
    is silent. If you attempt to inspect the variables when the app is in the
    'silent' mode, i.e., waiting on an event loop for a user input or a system
    event, then you get the "Access violation caught ..." exception message and
    the workspace including the launch server crashes.
    If you are getting this problem in the 'step-through' mode, you should look
    at the lauch server immediately after you get the exception before
    everything disappears. There could be a stack backtrace due to some illegal
    reference. We have faced a similar situation before but the error appeared
    both in the 'debug' and 'run' modes.
    Hope this helps.
    Braja K Chattaraj.
    From: Eric Decossaux <[email protected]>
    To: forte mailing <[email protected]>
    Subject: (forte-users) access violation caught in debug mode
    Date: Thu, 23 Sep 1999 17:31:39 +0200
    Hello,
    I have a problem using Forte in debug mode. If I run my program on my NT
    machine from the partition workshop (distributed run), the program works
    fine except that some object does not display what I'm expecting. So I
    want to use the debug mode to inspect the objets of this window. When I
    choose the "local variables" option to see the content of my window, I
    have a "access violation caught" and forte disappears. If I just let my
    program run without choosing this option, everything is the same than
    with the distributed run.
    Does somebody have an idea what to look for ? I really want to look the
    inside the attributes of this window.
    We recently upgraded from release 30G2 to release 30L2. Could it be the
    problem ?
    Eric Decossaux
    Cliniques Universitaires St Luc
    Informatique des Laboratoires
    av Hippocrate 10 / 1730
    1200 Bruxelles
    +32+2+764 17 53
    For the archives, go to: http://lists.sageit.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: [email protected]

    Eric,
    Another possibility has to do with the repository. You said you recently
    migrated 30G2 to release 30L2.
    Many strange problems have been traced to release migrations with old
    repositories. If the repository was properly migrated another thing you can try
    is to export the project(s) to PEX files, delete them from the repository, and
    then re-import. I know this can be time consuming but I have solved more than
    one unexplained problem in the IDE by doing it.
    ---------------------- Forwarded by Charlie Shell/Bsg/MetLife/US on 09/23/99
    01:19 PM ---------------------------
    "Ajith Kallambella" <[email protected]> on 09/23/99 12:08:54 PM
    To: [email protected], [email protected]
    cc: (bcc: Charlie Shell/Bsg/MetLife/US)
    Subject: Re: (forte-users) access violation caught in debug mode
    Eric,
    Sometimes( 90% ) you can solve this problem by
    checking out the class that is causing the crash
    and force-compiling it.
    If it doesn't help, run through this checklist.
    1. Do you have enough memory resources.?
    2. Is the object you are inspecting held in a lock ?
    ( mutex, transaction lock etc )
    3. Does it work when you wait for sometime at the
    breakpoint before inspecting the values? I mean
    are you interrupting some process thread?
    4. Does it work if you log the attributes using logmgr?
    5. Are you using any call-outs/call-ins? Any external
    systems integration? Sometimes( for reasons beyond
    my comprehension ) the objects allocated outside
    Forte gets corrupted when its passed back and forth.
    6. ...finally...Santa Clause, help me!
    Ajith Kallambella M.
    Forte Systems Consultant.
    From: Eric Decossaux <[email protected]>
    To: forte mailing <[email protected]>
    Subject: (forte-users) access violation caught in debug mode
    Date: Thu, 23 Sep 1999 17:31:39 +0200
    Hello,
    I have a problem using Forte in debug mode. If I run my program on my NT
    machine from the partition workshop (distributed run), the program works
    fine except that some object does not display what I'm expecting. So I
    want to use the debug mode to inspect the objets of this window. When I
    choose the "local variables" option to see the content of my window, I
    have a "access violation caught" and forte disappears. If I just let my
    program run without choosing this option, everything is the same than
    with the distributed run.
    Does somebody have an idea what to look for ? I really want to look the
    inside the attributes of this window.
    We recently upgraded from release 30G2 to release 30L2. Could it be the
    problem ?
    Eric Decossaux
    Cliniques Universitaires St Luc
    Informatique des Laboratoires
    av Hippocrate 10 / 1730
    1200 Bruxelles
    +32+2+764 17 53
    For the archives, go to: http://lists.sageit.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: [email protected]
    For the archives, go to: http://lists.sageit.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: [email protected]

  • Re: (forte-users) XML/HTTP clients

    Hi,
    As much as I know, DS Data Systems has done a Java client using http with Web
    Enterprise (from Web Designer). They have called it JDesigner (it was showed at
    the Forte Forum of San Francisco in May). I have myself experienced the use of
    External connections to make performance testings on Web Enterprise last
    summer. I used a Forte Client http to make an injector on port 80. It worked
    very well.
    For DHTML, I'm actually testing some solutions for "Outline field" and "menus".
    It works... It costs 8-10 ko for each script. But, it is really not easy to
    debug, to maintain, and you need different codes for each brower! Netscape is
    really unstable also. This may not be applicable with release 3 of IE and NS.
    You can find some good code samples on http://www.webreference.com/dhtml/
    But, it may be a good solution for Intranet and it should be possible to
    generate menus and outline from the HttpScanner as it is for DropLists for
    instance.
    Hope this helps,
    Daniel Nguyen
    Freelance Forte Consultant
    http://perso.club-internet.fr/dnguyen/
    Thomas Mercer-Hursh, Ph.D. a &eacute;crit:
    Does anyone out there have any experience, experimental or production, with
    using XML over HTTP instead of IIOP to communicate with non-Forte clients
    from R3 server components? If so, any pointers? Performance issues?
    Special problems? Recommendations?
    How about with using DHTML for the client compared to say Java?
    TIA
    =========================================================================
    Thomas Mercer-Hursh, Ph.D email: [email protected]
    Computing Integrity, Inc. sales: 510-233-9329
    550 Casey Drive - Cypress Point support: 510-233-9327
    Point Richmond, CA 94801-3751 fax: 510-233-6950
    For the archives, go to: http://lists.sageit.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: [email protected]

    You can also use the HTTP-DC project.... You don't
    need Web Enterprise for this. From what I can tell,
    this is available in L.x on....
    There is api documentation in M.2 (with scant
    examples.)
    There's a special process to put the project in your
    repository (it isn't installed in the repository in
    the standard install,) the documentation in M.2
    (probably in M.0 too, AFAIK) that tells you how to do
    this (look for HTTP-DC in the online help.)
    I haven't done much with it yet, I've just installed
    it. If anybody out there has examples, that'd be
    great. I'll try to contribute more the moment I get a
    chance to explore it....
    Christopher Fury
    BellSouth Communications Systems
    --- Daniel Nguyen <dnguyenclub-internet.fr> wrote:
    Hi,
    If you have Web Enterprise, you can user
    HttpAccess.SendRequest().
    Hope this helps,
    Daniel Nguyen
    Freelance Forte Consultant
    Amin, Kamran a &eacute;crit:
    Is there any way to make a HTTP request from TOOLto another HTTP Service?
    thanks in advance.
    For the archives, go to:
    http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. Tounsubscribe, send in a new
    email the word: 'Unsubscribe' to:forte-users-requestlists.xpedior.com
    For the archives, go to:
    http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To
    unsubscribe, send in a new
    email the word: 'Unsubscribe' to:
    forte-users-requestlists.xpedior.com
    Kick off your party with Yahoo! Invites.
    http://invites.yahoo.com/

  • RE: (forte-users) Forte not letting go of Oracle connections+ RE: (fort

    The bug was just reported yesterday so they might not have it available to
    the public for a while. I am guessing this bug has been around since 3.M.?
    and its very easy to verify it if its happening in your environment. Also I
    have been talking to other user that are not using Oracle (Sybase instead)
    who are also seen the same problem. I think this is a problem across all
    database because there is some fundamental event or process that is not
    taking place to close database connections. But just to be safe verify it
    in your test environment before moving to 3.5. To verify if its happening
    in your Forte version just create a small application that connects to the
    database and run it in debug mode. Log into the database and then stop the
    debug session. The connection will still be open. This will also occur
    when you use the running man or in a deployed application.
    ka
    -----Original Message-----
    From: Labeaux Schiek [mailto:DHSV017dhs.state.il.us]
    Sent: Thursday, March 01, 2001 7:21 AM
    To: kamran.aminlendware.com; Forte-userslists.xpedior.com
    Subject: RE: (forte-users) Forte not letting go of Oracle connections +
    RE: (forte-users) SQL Server Maximum DB Processes already allocated.
    Hi Kamran,
    I just looked up bug # 54610 in Cyber Support and it is not there yet, so a
    question.
    In your opinion, does this effect all databases? We are using DB2 and
    considering going to 3.5 . Are we going to see the same problems you have
    had with Oracle?
    -thanks
    -labeaux
    "Amin, Kamran" <kamran.aminlendware.com> 02/28/01 05:28PM >>>Update on my problem. Well now its everybody's problem. Forte has
    conformed the bug. Bug number 54610 for your reference.
    thanks to everybody for the help..
    ka
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

    The bug was just reported yesterday so they might not have it available to
    the public for a while. I am guessing this bug has been around since 3.M.?
    and its very easy to verify it if its happening in your environment. Also I
    have been talking to other user that are not using Oracle (Sybase instead)
    who are also seen the same problem. I think this is a problem across all
    database because there is some fundamental event or process that is not
    taking place to close database connections. But just to be safe verify it
    in your test environment before moving to 3.5. To verify if its happening
    in your Forte version just create a small application that connects to the
    database and run it in debug mode. Log into the database and then stop the
    debug session. The connection will still be open. This will also occur
    when you use the running man or in a deployed application.
    ka
    -----Original Message-----
    From: Labeaux Schiek [mailto:DHSV017dhs.state.il.us]
    Sent: Thursday, March 01, 2001 7:21 AM
    To: kamran.aminlendware.com; Forte-userslists.xpedior.com
    Subject: RE: (forte-users) Forte not letting go of Oracle connections +
    RE: (forte-users) SQL Server Maximum DB Processes already allocated.
    Hi Kamran,
    I just looked up bug # 54610 in Cyber Support and it is not there yet, so a
    question.
    In your opinion, does this effect all databases? We are using DB2 and
    considering going to 3.5 . Are we going to see the same problems you have
    had with Oracle?
    -thanks
    -labeaux
    "Amin, Kamran" <kamran.aminlendware.com> 02/28/01 05:28PM >>>Update on my problem. Well now its everybody's problem. Forte has
    conformed the bug. Bug number 54610 for your reference.
    thanks to everybody for the help..
    ka
    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) Events in Interface

    I know, I've implemented similar structures in other locations as well,
    always without problems. I've even recreated the whole interface, building
    it completely from dragging and dropping methods and events from the class
    to the interface. Then I did a force compile of the whole workspace. It
    still doesn't solve the problem. There must be some combination of things
    that were different in the other circumstances, but I don't seem to be able
    to find it. It's definately not an error in the code. There something wrong
    in Forte internally, but I don't know which combination of factors causes
    it.
    Pascal Rottier
    Atos Origin Nederland (BAS/West End User Computing)
    Tel. +31 (0)10-2661223
    Fax. +31 (0)10-2661199
    E-mail: Pascal.Rottiernl.origin-it.com
    ++++++++++++++++++++++++++++
    Philip Morris (Afd. MIS)
    Tel. +31 (0)164-295149
    Fax. +31 (0)164-294444
    E-mail: Rottier.Pascalpmintl.ch
    -----Original Message-----
    From: Moris_Mihaildis/AUST/CSCcsc.com
    [mailto:Moris_Mihaildis/AUST/CSCcsc.com]
    Sent: Tuesday, April 03, 2001 5:00 AM
    To: Rottier, Pascal
    Cc: forte-userslists.xpedior.com
    Subject: Re: (forte-users) Events in Interface
    FYI. We are using Forte 3.0.J.4 and NT4.0 SP6, and have had no problems
    implementing your pattern.
    There should be no need for a fix (cast). There is something wrong with
    your interface.
    Regards,
    Moris Mihailidis
    Consulting
    CSC
    Level 4, 570 St. Kilda Road, Melbourne VIC 3004
    Ph: 61-3-95364675 Fax: 61-3-95364633 Email: mmihailicsc.com.au
    "Rottier, Pascal" <Rottier.Pascalpmintl.ch> on 04/02/2001 09:52:46 PM
    To: "'Forte Users'" <forte-userslists.xpedior.com>
    cc:
    Subject: (forte-users) Events in Interface
    We have the following scenario:
    There is a Service Object that acts as a Facade (Facade pattern) for 3
    manager classes that implement some business functions. Each of these three
    managers are stored as private attributes on this Service Object.
    For the sake of flexibility, these three private attributes are defined by
    their Interface, not their class. When the Service Object opens an Event
    Loop and registers for the events of one of these interfaces, the whole
    partition crashes. Even when using the running man in the development
    workshop, the whole partition crashes. The only way to fix that is to cast
    the Interface to a class that implements the interface before registering
    for the event.
    I know it's possible to register for events using an Interface that
    contains
    these events, rather then a class that implements the events. Of course, at
    runtime you do need a real instance of a class that implements the
    interface, otherwise you get a NIL-exception.
    Does anyone have any experience registering for events from Interfaces? Are
    there unexpected circumstances where it should work semantically, but still
    causes Forte to crash. We're using Forte 3.j.1 on NT 4.0 SP 6.
    Any help is appreciated.
    Pascal Rottier
    Atos Origin Nederland (BAS/West End User Computing)
    Tel. +31 (0)10-2661223
    Fax. +31 (0)10-2661199
    E-mail: Pascal.Rottiernl.origin-it.com
    ++++++++++++++++++++++++++++
    Philip Morris (Afd. MIS)
    Tel. +31 (0)164-295149
    Fax. +31 (0)164-294444
    E-mail: Rottier.Pascalpmintl.ch
    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

    I know, I've implemented similar structures in other locations as well,
    always without problems. I've even recreated the whole interface, building
    it completely from dragging and dropping methods and events from the class
    to the interface. Then I did a force compile of the whole workspace. It
    still doesn't solve the problem. There must be some combination of things
    that were different in the other circumstances, but I don't seem to be able
    to find it. It's definately not an error in the code. There something wrong
    in Forte internally, but I don't know which combination of factors causes
    it.
    Pascal Rottier
    Atos Origin Nederland (BAS/West End User Computing)
    Tel. +31 (0)10-2661223
    Fax. +31 (0)10-2661199
    E-mail: Pascal.Rottiernl.origin-it.com
    ++++++++++++++++++++++++++++
    Philip Morris (Afd. MIS)
    Tel. +31 (0)164-295149
    Fax. +31 (0)164-294444
    E-mail: Rottier.Pascalpmintl.ch
    -----Original Message-----
    From: Moris_Mihaildis/AUST/CSCcsc.com
    [mailto:Moris_Mihaildis/AUST/CSCcsc.com]
    Sent: Tuesday, April 03, 2001 5:00 AM
    To: Rottier, Pascal
    Cc: forte-userslists.xpedior.com
    Subject: Re: (forte-users) Events in Interface
    FYI. We are using Forte 3.0.J.4 and NT4.0 SP6, and have had no problems
    implementing your pattern.
    There should be no need for a fix (cast). There is something wrong with
    your interface.
    Regards,
    Moris Mihailidis
    Consulting
    CSC
    Level 4, 570 St. Kilda Road, Melbourne VIC 3004
    Ph: 61-3-95364675 Fax: 61-3-95364633 Email: mmihailicsc.com.au
    "Rottier, Pascal" <Rottier.Pascalpmintl.ch> on 04/02/2001 09:52:46 PM
    To: "'Forte Users'" <forte-userslists.xpedior.com>
    cc:
    Subject: (forte-users) Events in Interface
    We have the following scenario:
    There is a Service Object that acts as a Facade (Facade pattern) for 3
    manager classes that implement some business functions. Each of these three
    managers are stored as private attributes on this Service Object.
    For the sake of flexibility, these three private attributes are defined by
    their Interface, not their class. When the Service Object opens an Event
    Loop and registers for the events of one of these interfaces, the whole
    partition crashes. Even when using the running man in the development
    workshop, the whole partition crashes. The only way to fix that is to cast
    the Interface to a class that implements the interface before registering
    for the event.
    I know it's possible to register for events using an Interface that
    contains
    these events, rather then a class that implements the events. Of course, at
    runtime you do need a real instance of a class that implements the
    interface, otherwise you get a NIL-exception.
    Does anyone have any experience registering for events from Interfaces? Are
    there unexpected circumstances where it should work semantically, but still
    causes Forte to crash. We're using Forte 3.j.1 on NT 4.0 SP 6.
    Any help is appreciated.
    Pascal Rottier
    Atos Origin Nederland (BAS/West End User Computing)
    Tel. +31 (0)10-2661223
    Fax. +31 (0)10-2661199
    E-mail: Pascal.Rottiernl.origin-it.com
    ++++++++++++++++++++++++++++
    Philip Morris (Afd. MIS)
    Tel. +31 (0)164-295149
    Fax. +31 (0)164-294444
    E-mail: Rottier.Pascalpmintl.ch
    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) Accelerator keys under MS Windows95/98/NT

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

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

  • RE: (forte-users) Phantom Nodes

    Yes both the client and server have to have the same setting and it does not
    work all the time.
    -----Original Message-----
    From: Samer Kanjo [mailto:[email protected]]
    Sent: Thursday, May 10, 2001 11:33 PM
    To: Amin, Kamran; Forte Users
    Subject: RE: (forte-users) Phantom Nodes
    Kamran,
    Just so I am clear on the use of keep alive settings,
    the settings are required on both the server and the
    client, correct? If so then should the settings on
    both client and server nodes be equal?
    Again to be clear, are you saying that the keep alive
    settings alone will prevent phantom nodes?
    Kelsey & Pascal, do you still have the problem even
    though you are using keep alive settings?
    Samer Kanjo
    --- "Amin, Kamran" <[email protected]> wrote:
    The socket time is an OS level setting and is
    different on each OS. I had
    open up a ticket with Forte 2 years ago and the only
    quick solution was to
    change the name of the client computer which faked
    Forte into thinking its a
    different node. This way the client was able to get
    back into their
    application quickly. The only problem was that the
    clients had to reboot
    their computer. The other way to prevent this was
    to use the keep alive
    settings to force a clean up on the Forte central
    environment side.
    ka
    -----Original Message-----
    From: Samer Kanjo [mailto:[email protected]]
    Sent: Thursday, May 10, 2001 6:26 PM
    To: [email protected]; Forte Users
    Subject: RE: (forte-users) Phantom Nodes
    Kelsey,
    We use model nodes exclusively. Occasionally, a
    client
    node would crash and would be inaccessbile for two
    hours but would still appear active under the model
    node. After two hours the client could access the
    environment again. My only option thus far has been
    to
    bounce the environment but that can only be done
    after
    work hours, which may not be convenient for the
    affected user.
    Kamran Amin just wrote me to say that the two hour
    delay is the result of the default socket timeout
    setting on UNIX boxes. Perhaps reducing the socket
    timeout from two hours to something more reasonable
    would fix the problem without manipulating the
    environment configuration.
    I am not sure how I would determine a good socket
    timeout setting for my application. Does anyone have
    any ideas? Is my assumption about reducing the
    socket
    timeout to avoid manipulating the environment
    configuration to remove the phantom nodes in a more
    timely fashion correct?
    Samer Kanjo
    --- [email protected] wrote:
    "... have you reported this to Forte as a bug or
    looked through the defect
    reports?..."
    No and No. I just kind of "stumbled" upon this
    solution this week. I just
    opened the properties windows when it just all ofa
    suddened dawned on me:
    "Maybe, if none of the boxes are checked then the
    node effectively serves
    no usefull purpose in the environment. Therefore,
    maybe Forte will be more
    apt to release it - like the garbage collectordoes
    with an object that is
    not referenced".
    " ... Have you tried this technique when usingmodel
    nodes? ..."
    No I haven't. So far our model nodes have beenwell
    behaved. If a member
    was online the node was online, otherwise, if "no
    one was home" then it was
    off-line. Model nodes aren't real nodes; I viewthem
    as a sort of virtual
    node. Only real nodes have ocassionally behaved
    goofy. I think what happens
    is either the user's machine is improperlyshutdown
    or they just all of
    sudden loose connection to the network. Exception
    handling was never Forte
    ADE's forte.
    Kelsey Petrychyn, P. Eng. SaskTel TechnicalAnalyst
    ITM - Technology Solutions - Distributed Computing
    Tel (306) 777 - 4906, Fax (306) 359 - 0857
    Internet:[email protected]
    Quality is not job 1. It is the only job!
    Samer Kanjo
    <skanjo@yahoo To:
    "Forte Users" <[email protected]>
    .com> cc:
    Subject:
    RE: (forte-users) Phantom Nodes
    05/10/2001
    01:57 PM
    Pascal,
    This is very inetresting. I have experienced the
    same
    problem and have noted the mysterious two hourdelay
    in getting the client node back up and running. I
    thought it may have had something to do with the
    keepalive settings, which seem to work otherwise.
    Kelsey, have you reported this to Forte as a bugor
    looked through the defect reports? Have you tried
    this
    technique when using model nodes? I will give your
    fix
    of reconfiguring the node a try the next time I
    encounter the problem. However, I use model nodesso
    perhaps it may not have the same effect.
    Samer Kanjo
    --- "Rottier, Pascal" <[email protected]>
    wrote:
    I've seen this problem many times myself and the
    cause was always the same.
    The nodemanager of the phantom node was notproperly
    shutdown. Usually,
    because this node was running on NT and somebody
    simply shutdown the
    machine. A "kill -9" on unix will also have thesame
    effect.
    Part of the shutdown process of a node, which
    you
    should always invoke from
    e-console or e-script, is to inform theenvironment
    that it's going away.
    Then Forte will mark it as offline, rather then
    online. However, it the
    nodemgr suddenly dies, there is no such signal.
    === message truncated ===

    Therefore, how to remotely start a node manager ? :-p
    j-p
    -----Message d'origine-----
    De: John Parks [mailto:jparkss1.com]
    Date: vendredi 15 septembre 2000 20:07
    &Agrave;: Jean-Paul.Gabriellisema.fr
    Cc: 'Forte Users'
    Objet: Re: (forte-users) [Model Nodes] What prevents Server Parts to be
    assigned there ?!:?
    Jean-Paul,
    The ModelNode is a client node by definiton, no matter what properties you
    change. I've previously asked for an enhancement to allow a
    model node to be a
    server node, but I don't expect much to happen. To install
    server applications
    to several nodes, you have to make sure that the node manager on
    each node is
    active. There really is no built-in support for distributing
    applications in
    mass to servers like there is for clients (using the model node feature).
    Regards,
    John Parks
    S1 Corporation
    Jean-Paul Gabrielli wrote:
    Hi,
    I want to have a separate node to provide a dedicated service,
    and therefore when I start my environment server and declared that
    node as ModelNode, with 'client' disabled, i still can't assign to it
    my server partition.
    And if I declare it as regular node, the installation of the application
    failed if the node is not online.
    What choice do I have ?
    What prevents that ModelNode, client disabled, to host serverpartition ?!,
    j-paul gabrielli
    sema dts
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe,send in a new
    email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com--
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

  • RE: (forte-users) RE: Forte' vs J2EE

    Hi Alexandra,
    1) Forte 4GL and FJEE (Forte for Jave Enterprise Edition) are tools.
    2) TOOL and Java are languages.
    3) TOOL is proprietary and Java is public.
    4) J2EE is a proposed, Java-based achitecture. Not a tool, not a language,
    not a standard.
    5) J2EE looks a lot like the architecture already supported by Forte 4GL,
    however J2EE is explicetaly based on Java, EJB, JSP, JDBC and Servlets.
    There are 3 versions of Forte for Java. The "Consumer Edition (CE)", the
    "Internet Edition (IE)" and the "Enterprise Edition (EE)". CE is really a
    remake of "NetBeans" and can be downloaded for free. IE and EE do not exist
    yet. However, EE should be a remake of SynerJ, Forte's first Java tool.
    You quoted someone who was very negative about Forte. I don't think that's
    deserved. He's probably someone who simply didn't manage to understand the
    tool. However, he is right in complaining about the support of Forte 4GL.
    And it's true that the version people are currently using is at least more
    than 2 years old and outdated. Since this period, there have been some
    bugfixes, but hardly any real improvements.
    From the description of your application, I would really advise to use Forte4GL. However, the lack of improvements, new releases, press releases, etc.
    has me worried about the future of that product.
    One of the real disadvantages of Java is performance. Java is very slow and
    requires very heavy hardware to perform acceptably. Swing is a GUI framework
    based on Java, which is notoriously slow even by Java standards. FJCE
    development GUI is based on Swing. Download this product, install it and run
    it and you'll see what I mean.
    Forte applications can run in 2 modes. Interpreted or compiled. If they're
    compiled, they're turned into platform dependent executables, which perform
    really well. If they're interpreted, they're running inside a Forte Virtual
    Machine, which performs less well, but still very acceptable. Java
    applications run only in Java Virtual Machines and perform far less.
    I would use Forte server side and Forte client side. For the browsers, I
    would simply use any available tool to build webpages and use CGI to
    interface with Forte. I would not try to use a different client side tool
    that should communicate to a Forte server side.
    Express is a good tool for developing CRUD (Create Read Update Delete)
    applications based on an existing, and relatively static, database model. I
    don't know about Rapport. However, don't be fooled into believing that
    Express makes it easier for unexperienced developers to build Forte
    applications. If anything, it makes it harder. A common look and feel can
    easily be achieved by agreeing on the look and feel of windows during the
    design-phase, and have all developers conform to this standard. It really
    isn't that hard. Just don't create very large window class trees. That
    causes strange behaviour.
    Pascal Rottier
    Atos Origin Nederland (BAS/West End User Computing)
    Tel. +31 (0)10-2661223
    Fax. +31 (0)10-2661199
    E-mail: Pascal.Rottiernl.origin-it.com
    ++++++++++++++++++++++++++++
    Philip Morris (Afd. MIS)
    Tel. +31 (0)164-295149
    Fax. +31 (0)164-294444
    E-mail: Rottier.Pascalpmintl.ch
    -----Original Message-----
    From: Alexandra Macedo [mailto:ammeasysoft.pt]
    Sent: Tuesday, December 05, 2000 3:55 PM
    To: forte-users
    Subject: (forte-users) RE: Forte' vs J2EE
    Alexandra I presume.
    Excuse me for asking but isn't J2EE just a STANDARD? And Forte aprogramming
    language that may or may not adhere to that standard?
    Now to the question, if the C++ experience is good - what's wrong withusing
    C++?
    Do you need to build component based distributed systems? Then hire saytwo
    experienced architects - to design a practical model (UML perhaps).
    Are there already good systems around you could tailor for your needs?
    Just a few questions that need to be addressed to make an informeddecision.
    What business are you in (your team/company)? If it's not IT then ask
    yourself why do it inhouse?
    Regards,
    Dirk
    PS: What country and from where is the Forte support? You mean peoplecode
    in a language other than English?----------------------------------------------------------------------
    Well, Fort&eacute; is certainly not a programming language, TOOL is the
    language for the Fort&eacute; 4GL environment.
    J2EE is a standard, and there are already some Application servers
    that
    implement it (as I was told, webSphere, Iplanet and weblogic,
    sorry if I am missing someone).
    I really do not know the standard, and I am not sure it says it will
    have to be implemented in Java, but all these 3 application servers
    do it in Java...
    The C++ experience is only from part of the team, and is not from
    Database applications, the type of application we are doing is not
    well suited to do in C++, we all agree, C++ is out of the question.
    I have received many answers (not posted in this mailling list
    unfortunatly) telling me that Java is best, others told me Fort&eacute; is
    good Java is just a promise, but they really did not know Java
    very well, someone even said:
    Forte 4GL sucks terribly. It is not supported well by what
    is left of 'Forte the company'.
    The tools for this proprietary environment suck.
    No distributed debugging or profiling!
    There is really no adequate profiling support at all
    Avoid Forte like the plague that it is.
    Any way, a Fort&eacute; person told us that Fort&eacute; is good, precisely, for
    our kind of application, and as some people made more questions about
    it, I am explaining better our application:
    - We are doing this application because we are an IT company, our
    job is to make and sell back-office applications for the finance
    sector (accounting, third-party, bank management, credit
    management), now we want to make one application with all of these.
    In simple terms we can define it as an ERP for Credit Operations.
    - The users will be in-house except for a small set of
    functionalitty, which will be available through browsers.
    The front-end should run in an ordinary PC running WINDOWS (we
    were told that Java is too heavy and PC's should have at least 256Mb
    RAM, which, I believe, is to much for all our clients)
    If this is true, it puts Java clients (with Swing) or Java applets out,
    HTML, we believe is not powerfull enough for all the interface.
    The server, will have to work well with about 300 simultaneous
    internal users, plus some Web ones (do not know how many)
    The application must be multi-lingual, that is, it should be easy to
    put it in any language.
    The application is based on a big database, with more than 500
    tables, some with about 100 columns, some with millions of records.
    - We want to be sure that the application will have the same layout
    (look and feel) in every screen, so it will be nice something to
    generate code or to create similar functionality (table screens,
    for instance) in an automatic way ( that is why we are considering
    Express for it). Of course this will help also the maintenance of
    the sources.
    Our questions are:
    FORT&Eacute; or JAVA for the server-side.
    Which tool for the client-side?
    Which framework to use?
    -Express or Rapport from albion if using Fort&eacute;?
    -Are there any good frameworks for Java ?
    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

    Gabriel,
    I disagree with you on one very important point. You say it's nearly
    impossible to predict anything about the future in ICT-world, so it's better
    to not predict at all and only look at the here and now. Here and now, Forte
    is better than Java. So, the best choice would be Forte.
    But you also mention that Forte is best suited for big projects. Big
    applications usually have a long lifetime. Many of the current Forte
    applications are the legacy systems of tomorrow. While all the VB, Access,
    ASP and Java crap that's being produced will be replaced within 6 to 18
    months, Forte applications will live for years.
    Migrating such large applications to a new environment, even if this
    environment is using a similar technology, requires very high investments.
    Companies will want to avoid this as much as possible. So, they'll want to
    invest in technology that can evolve with the rest of the world. As
    operatingsystems change, databases change, middleware architectures become
    obsolete (DCE) and new ones are created (EJB), end user interfaces evolve
    (from text to GUI to Web), requirements change (data-oriented,
    process-oriented, eCommerce), etc.
    Of course, flexibility is not only achieved through technology. A good
    design is probably more important.
    Managers, not developers, will have to make the strategic decisions about
    where to spend their millions. So, they have to look at the future, no
    matter how hard that is. At the moment, Forte is still superior, even though
    it hasn't been truly improved for over 2 years and that's pretty impressive.
    Java is still very "hyped" and no one knows what's going to happen to it.
    But the future of Java looks much brighter than the future of Forte. If
    Forte doesn't put some serious effort in product development and marketing,
    like now, the future of this product suite looks very bleak indeed. And I
    wouldn't want to spend my millions knowing I have to do it all over again 2
    years from now.
    Keeping an eye on the future, where the only certainty is change, I would
    not focus on platform independance. I would focus on language independance.
    CORBA seemed like a very good idea 2 years ago, but it turned out to be too
    complex, technical and inflexible. I would definately go for a CBD
    architecture, using XML as backbone. XML can be exchanged between components
    using HTTP, CORBA, DCOM, FTP, file copy, DCE, C/C++ call in/out, RMI, IIOP,
    E-mail, MQSeries, etc. etc. Or any mixture of these systems.
    The role of the data architect will become much more important than the role
    of the application architect. The choice for a language or tool is reduced
    to "the best choice here and now" as long as you design your large
    application as loosly coupled components. It's OK if all of these components
    are Forte and they're all communicating using Forte native RMI's. As long as
    the design is sound, it's not going to be very difficult to exchange
    individual components by others, built in Java, VB, Perl, Cobol++, Fortran
    for Windows, or what other monsters the future might bring. The only thing
    that binds them, is the datamodel (NB: datamodel is not the same as
    databasemodel)
    I do worry about the trend to use very large, omni-present, closed,
    non-component architectures, like the current ERP applications. This locks
    organisations into a single, expensive and hard to maintain technology.
    However, it is an opportunity for us, OO - C/S - CBD developers, to build
    bridges, adapters, wrappers and gateways to hook these systems into the rest
    of the organisation.
    Pascal Rottier
    Atos Origin Nederland (BAS/West End User Computing)
    Tel. +31 (0)10-2661223
    Fax. +31 (0)10-2661199
    E-mail: Pascal.Rottiernl.origin-it.com
    ++++++++++++++++++++++++++++
    Philip Morris (Afd. MIS)
    Tel. +31 (0)164-295149
    Fax. +31 (0)164-294444
    E-mail: Rottier.Pascalpmintl.ch
    -----Original Message-----
    From: Gabriel, C200/Fa. GFT, DA [mailto:A.Gabriel3deutschepost.de]
    Sent: Wednesday, December 06, 2000 5:44 PM
    To: 'forte-userslists.xpedior.com'
    Subject: Re: (forte-users) RE: Forte' vs J2EE
    If I were you, I would also consider this very important issue ( I think
    it's the same for all 4GL users ), WILL THERE BE FORTE 4GL 5.0?I wonder every time I see that... Why is this that important?
    (my mail is long.. if you don't like long mails, delete it now :) )
    Let's see from the business' point of view:
    If you would like to have an application implemented now,
    use now, then you choose an environment existing now.
    Now Forte 4GL seems to be a better alternative than Java,
    because of the issues mentioned by others already.
    I seem to be short-sighted, but could anybody tell me
    with 100% accuracy, what will happen to Java in two years?
    I doubt...
    Forte did not changed too much in the last two years, and
    still rocks, at least compared to other existing enterprise
    level alternatives. So, nothing has changed that dramatically.
    If you look behind the marketing-hype, you will probably agree.
    I think, for the next two years Forte will be good enough for us too.
    And what then? We will find out then, not now. Anybody, who tries to
    explain you what will be in two years in the IT, almost certainly lies :)
    Of course, using a "two years old technology" is not that cool from the
    marketing point of view, but you use a solid technology, most likely
    bug-free,
    or at least having only known bugs. That is technically important!
    If you ask about investment protection ... ?
    Forte is very good in this subject too. If you look at it, you will see, it
    is
    sold as an integration solution (Fusion, Conductor, etc...)
    If something is sold as an integration tool, it should be not that difficult
    to
    integrate :) Forte supports the most important standards, existing now.
    If your future system supports it (it should), it will be easy to upgrade to
    it,
    using the existing product,know-how, etc... Probably without noticeable
    downtime.
    Scalability issues: Forte scales well from big to very-big to ultra-big.
    What is big, you have to decide :)
    For example, one million mails per day is not big. :)
    For small businesses Forte isn't good. Java is. And a lot of other
    environments
    are, for example Perl, Python, etc...
    My personal opinion is that our future will be heavily influenced by free
    software.
    They are very good already, and will be only better.
    As Forte evolves, one important step would be to port it to free (and thus
    independent)
    OS's and DB's like Linux or FreeBSD and Postgres or Mysql. Even without
    warranty!
    I can't see what Sun's goal is with Forte, maybe they wouldn't
    like this idea at all, since that may be the market segment what their Java
    is thought for.
    But that would be the perfect investment production as the company grows,
    they don't have
    to do anything to the software, just buy machines, and play around in
    Environment Console :)
    From the personal point of view:Although I don't work with Forte in the moment, I did this till last year,
    and I will do
    that in the next year too :)
    If you would like to protect your "investment" and/or "market value" then
    try to learn
    platform and language independent things. I think, knowing Forte is 25%
    platform dependent
    knowledge (so useless anywhere else) and 75% platform independent. Using,
    analysing, designing,
    programming, and living OO is absolutely platform independent.
    Project (and self-) management, presentation techniques, design and
    documentation practices, version
    and revision management, and so on, they are all platform independent.
    Furthermore if you quit the Forte world, and have to program f.e. Java, you
    will learn it in weeks.
    JFC, Swing, et. al. are nothing, if you know OO. You just need a book or
    an online manual, and you
    can write programs in the first week. You will have much more problems with
    the working environment,
    and you will wonder, how the others can use that crap... after the smart
    Forte IDE :)
    Back to business a bit:
    One big advantage of Forte, that came to my mind right now is that you can't
    (ok, you can, but it is
    difficult) to write bad OO programs (and designs). In Java, it is too
    easy... believe me, I saw some examples ... :)
    Sorry for the bad english and the long mail...
    Best regards,
    Akos Gabriel
    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) Is there a later version than Forte v30L2?What 's th

    Hi,
    We have recently upgraded to 30L4, and Forte say that this fixes a
    corruption problem with the repository to do with large projects.
    This patch also fixes the problem with AfterValueChange event on
    FillInFields.
    Upgrading was simple for us as we don't use Express.
    R4 is still next year some time as far as I know.
    Regards,
    Jace.
    Jason de Cean
    Genisys Team
    Lumley Technology Ltd.
    Lvl. 8, 55 Sussex St
    Sydney, NSW 2000 Australia
    Ph: 02 9248 1321
    -----Original Message-----
    From: Haben, Dirk [mailto:[email protected]]
    Sent: Wednesday, 20 October, 1999 3:06
    To: 'Soapbox Forte Users'
    Subject: (forte-users) Is there a later version than Forte v30L2? What's
    the news on R4?
    G'day
    Someone posted a while back about Forte v30L2 having a minor problem
    with
    the repository. What's the latest on v30L2 and is there a later release
    worth going/waiting for - from v30G2?
    What's the release plan for R4 - and what's in it?
    Is SynerJ vastly different to Forte - complement, supplement? Any
    management
    issues to know/learn about?
    When will we see integration of selected projects to baseline only
    rather
    than whole workspace?
    Thanks,
    Dirk
    For the archives, go to: http://lists.sageit.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a
    new
    email the word: 'Unsubscribe' to: [email protected]

    I know system management for SynerJ is more complicated. I just got the
    1.4.1 version of SynerJ and it has completely changed on how partitioning
    work regarding the EJBs. Just more to learn to do the same thing we did in
    Forte.
    ka
    Kamran Amin
    [email protected]
    (203)-459-7362 or 8-204-7362 - Trumbull
    From: Peter Sham[SMTP:[email protected]]
    Sent: Wednesday, October 20, 1999 9:55 AM
    To: Haben, Dirk; 'Soapbox Forte Users'
    Subject: Re: (forte-users) Is there a later version than Forte v30L2?
    What's the news on R4?
    Hi,
    I guess many people is interested in finding out how different it is
    between SynerJ and TOOL.
    Here is something to share. 
    1. Forte is posting all manuels ( SynerJ, Fusion, Conductor ) on the Web. 
    You just need a customer login in.  Here is a good start.
    2. java.sun.com now has a beta document J2EE APM which explain the
    architectual of J2EE.  The document how and when you will use JSP,
    Servlet, EJB & Java Bean etc.  You will find it along with the J2EE beta
    free download.
    My feeling is: on system management level, SynerJ is more or less similiar
    with what we have now ( maybe they jus rewriting everything in Java ). 
    However, on development and design level, there is quite a large
    difference.  Nevertheless, it's exciting.
    Regards,
    Peter Sham.
    "Haben, Dirk" <[email protected]> wrote:
    G'day
    Someone posted a while back about Forte v30L2 having a minor problem
    with
    the repository. What's the latest on v30L2 and is there a later
    release
    worth going/waiting for - from v30G2?
    What's the release plan for R4 - and what's in it?
    Is SynerJ vastly different to Forte - complement, supplement? Any
    management
    issues to know/learn about?
    When will we see integration of selected projects to baseline only
    rather
    than whole workspace?
    Thanks,
    Dirk
    For the archives, go to: http://lists.sageit.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in
    a new
    email the word: 'Unsubscribe' to:
    [email protected]

  • Re: (forte-users) systemexception

    Hi There
    Segmentation violations can be caused by different
    situations. Force compiling works well in clearing
    most SV's. It is advisable to first clear all
    breakpoints, force-compile your plans and run your
    application. If you still get the SV then run in debug
    mode to identify the problem area.
    Hope this helps.
    Jairaj Rampershad
    System Consultant
    --- Forte App <[email protected]> wrote:
    Hi,
    iam getting system segmentation/access violation
    Fatal Error: system segmentation/access violation
    caught.
    Class: qqos_SystemException
    Error: [101, 321]
    Detected: qqos_MainSingHd1 on part5,
    Error: TMgr
    RunThread:task10.SAsync.AppServerInterfaceMgr
    Error:qq10_LomTaskInitiator
    what cause this type of error
    Thanks in advance
    For the archives, go to:
    http://lists.sageit.com/forte-users and use
    the login: forte and the password: archive. To
    unsubscribe, send in a new
    email the word: 'Unsubscribe' to:
    [email protected]

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

  • Re: (forte-users) (UPDATE) Forte not letting go of Oracleconnections

    All,
    I have been communicating with Forte regarding this
    issue. I was informed that a fix for this bug will be
    released in SP2 tentatively due at the end of May.
    Forte also confirmed that the bug was introduced in
    3.5 and exists in 3.5.1.
    Samer Kanjo
    --- Joseph Mirwald <jomirweb.de> wrote:
    Hello all,
    some time ago we talked about the problem, that some
    DBSession-connects hang
    if the partition where the DBSessionSO is used goes
    down.
    Ok, there may be some problems with forte or the
    Database (TWO_TASK, and so
    on).
    Does anybody implement a DBSession.Disconnect() when
    partition goes down?
    I mean the partition exits by a kill or by escript
    or econsole, not by a
    Forte-Method call
    of somewhere else.
    I thought the solution must be a loop which
    registers for the
    task.Shutdown-event, but at
    the init-method I couldn't stay in a loop and wait,
    because i has to call
    the service-objects
    methods. Another solution may be a 'start task
    LoopMethod()' which are
    registers the
    event, but i don't try it now, because i don't know
    the side-effects
    because the thread calls
    a method of the 'mother-process' which goes down
    also.
    What is your solution or idea?
    Joseph Mirwald
    GERMANY
    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

    All,
    I have been communicating with Forte regarding this
    issue. I was informed that a fix for this bug will be
    released in SP2 tentatively due at the end of May.
    Forte also confirmed that the bug was introduced in
    3.5 and exists in 3.5.1.
    Samer Kanjo
    --- Joseph Mirwald <jomirweb.de> wrote:
    Hello all,
    some time ago we talked about the problem, that some
    DBSession-connects hang
    if the partition where the DBSessionSO is used goes
    down.
    Ok, there may be some problems with forte or the
    Database (TWO_TASK, and so
    on).
    Does anybody implement a DBSession.Disconnect() when
    partition goes down?
    I mean the partition exits by a kill or by escript
    or econsole, not by a
    Forte-Method call
    of somewhere else.
    I thought the solution must be a loop which
    registers for the
    task.Shutdown-event, but at
    the init-method I couldn't stay in a loop and wait,
    because i has to call
    the service-objects
    methods. Another solution may be a 'start task
    LoopMethod()' which are
    registers the
    event, but i don't try it now, because i don't know
    the side-effects
    because the thread calls
    a method of the 'mother-process' which goes down
    also.
    What is your solution or idea?
    Joseph Mirwald
    GERMANY
    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) FW: (forte-users) Overflow Exception thatIcan't catch

    Dave
    If you use #,##0.00 template, forte won't allow you to enter more than 28 numbers.
    Nat
    "Campbell, Dave" <DCampbellpurolator.com> 01/28 10:49 AM >>>Thanks Zenon,
    You mean... that without the aftervaluechange event, I could catch this?
    Because by no means is my exception block anchored to that event.
    I am looking for advice of where I could put this exception block...if there
    is another possible place at all.
    Thanks.
    Dave
    Regards,
    Dave Campbell
    Consultant,
    Caro Systems Inc.
    Mailto:Dave.CampbellCaroSys.com
    -----Original Message-----
    Hi Dave,
    You have no chance to catch this exception in aftervaluechange block.
    This event is triggered if the value in DataField is OK.
    You get only Arithmetic exception without the aftervaluechange event if the
    length of the decimal is greater as 28.
    Regards
    Zenon Adamek
    Forte Developer
    Purolator Courier Ltd.
    ZAdamekpurolator.com
    -----Original Message-----
    From: Campbell, Dave [SMTP:DCampbellpurolator.com]
    Sent: Friday, January 28, 2000 8:19 AM
    To: 'kamranaminyahoo.com'
    Subject: (forte-users) Overflow Exception that I can't
    catch...
    The problem is:
    I have a DataField, mapped type :DecimalNullable
    the input mask is set to Template ( #,##0;;;;)
    Because it is Template I can't validate on keystroke and
    I can't set the max characters in the properties sheet.
    This works great until, Someone enters over 28 characters into the
    field.
    It then displays the errors:
    USER ERROR: Operation caused arithmetic overflow
    Class: qqsp_ArithmeticException
    Error #: [301, 7]
    Deteced at: DecimalData.SetScale at 1
    ErrorTime: Thu Jan 27 15:50:48
    Exception occurred (locally) on partition
    "PurolatorApplications_CL0_Client" ,(partitionId =
    DEB96B60-AA27-11D1-82A8-23E82A0FAA77:0X6f98:0x7, TASKiD =
    [DEB96B60-AA27-11D1-82A8-23E82A0FAA77:0X6f98:0x7.492] in
    application
    "FTLaunch_c10",pid 279 on node W5300109 in environment centrale
    This is the first bit of code that executes when I leave the field
    and the
    value has changed:
    when <est_daily_rev_amt>.aftervaluechange do
    Begin
    sys_upd_usr_nam = aUserProfileBO.user_nam;
    aCPVDetailItem.SetState(base_detailItem.CHANGED_STATE);
    Exception
    when ex:ArithmeticException Do
    Task.ErrMgr.Clear();
    Window.MessageDialog(
    messageText='Revenue amount can not exceed
    100,000,000',
    MessageType=MT_WARNING);
    Self.Window.PurgeEvents();
    End;
    This is what I do:
    I put a debugging stop on the "when line" and the "Exception line"
    I also set the debugger to stop on all exceptions and posts.
    It never reaches the above code!?
    Is this a forte bug?
    I need the template and I need it to be a decimalnullable.
    Is there any suggestions for where else I may catch this
    Exception???
    Thanks in advance
    Regards,
    Dave Campbell
    Consultant,
    Caro Systems Inc.
    Mailto:Dave.CampbellCaroSys.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

    Dave
    If you use #,##0.00 template, forte won't allow you to enter more than 28 numbers.
    Nat
    "Campbell, Dave" <DCampbellpurolator.com> 01/28 10:49 AM >>>Thanks Zenon,
    You mean... that without the aftervaluechange event, I could catch this?
    Because by no means is my exception block anchored to that event.
    I am looking for advice of where I could put this exception block...if there
    is another possible place at all.
    Thanks.
    Dave
    Regards,
    Dave Campbell
    Consultant,
    Caro Systems Inc.
    Mailto:Dave.CampbellCaroSys.com
    -----Original Message-----
    Hi Dave,
    You have no chance to catch this exception in aftervaluechange block.
    This event is triggered if the value in DataField is OK.
    You get only Arithmetic exception without the aftervaluechange event if the
    length of the decimal is greater as 28.
    Regards
    Zenon Adamek
    Forte Developer
    Purolator Courier Ltd.
    ZAdamekpurolator.com
    -----Original Message-----
    From: Campbell, Dave [SMTP:DCampbellpurolator.com]
    Sent: Friday, January 28, 2000 8:19 AM
    To: 'kamranaminyahoo.com'
    Subject: (forte-users) Overflow Exception that I can't
    catch...
    The problem is:
    I have a DataField, mapped type :DecimalNullable
    the input mask is set to Template ( #,##0;;;;)
    Because it is Template I can't validate on keystroke and
    I can't set the max characters in the properties sheet.
    This works great until, Someone enters over 28 characters into the
    field.
    It then displays the errors:
    USER ERROR: Operation caused arithmetic overflow
    Class: qqsp_ArithmeticException
    Error #: [301, 7]
    Deteced at: DecimalData.SetScale at 1
    ErrorTime: Thu Jan 27 15:50:48
    Exception occurred (locally) on partition
    "PurolatorApplications_CL0_Client" ,(partitionId =
    DEB96B60-AA27-11D1-82A8-23E82A0FAA77:0X6f98:0x7, TASKiD =
    [DEB96B60-AA27-11D1-82A8-23E82A0FAA77:0X6f98:0x7.492] in
    application
    "FTLaunch_c10",pid 279 on node W5300109 in environment centrale
    This is the first bit of code that executes when I leave the field
    and the
    value has changed:
    when <est_daily_rev_amt>.aftervaluechange do
    Begin
    sys_upd_usr_nam = aUserProfileBO.user_nam;
    aCPVDetailItem.SetState(base_detailItem.CHANGED_STATE);
    Exception
    when ex:ArithmeticException Do
    Task.ErrMgr.Clear();
    Window.MessageDialog(
    messageText='Revenue amount can not exceed
    100,000,000',
    MessageType=MT_WARNING);
    Self.Window.PurgeEvents();
    End;
    This is what I do:
    I put a debugging stop on the "when line" and the "Exception line"
    I also set the debugger to stop on all exceptions and posts.
    It never reaches the above code!?
    Is this a forte bug?
    I need the template and I need it to be a decimalnullable.
    Is there any suggestions for where else I may catch this
    Exception???
    Thanks in advance
    Regards,
    Dave Campbell
    Consultant,
    Caro Systems Inc.
    Mailto:Dave.CampbellCaroSys.com
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Maybe you are looking for