RE: (forte-users) Serialisation

Singh,
Any message sent across partition boundaries is serialized. This includes
method invokations, events and exceptions. The signature of the message
itself is serialized, as well as the values of all parameters/attributes.
Serializing a scalar value requires less overhead then serialising an
object, however, the difference isn't as big as you might think. Objects
have more attributes then just the value you're interested in and these
attributes are serialised as well. Each object is an instance of a class and
each class has a UUID, which is added to the serialized stream as well.
However, methods are NOT serialised. What happens is this. Forte serializes
an object into a stream containing only the values of the attributes
(including nested attributes). This stream is given a header which sais of
which class this object is an instance (the UUID is used for that). The
receiving partition reads the serialized stream, finds the definition of the
class (defined by UUID) in its own code, creates an instance of this class
and fills the data out of the serialized stream into this new object.
You can imagine what might happen if there is a mismatch between the
class-definitions in both partitions. You either get
serialization-deserialization errors, or the receiving partition complains
that it doesn't even know the UUID of the received streamed object, or you
get no errors at all and just have an object that displays different
behaviour, depending what partition it's in.
If there are no problems, then the main issue is the
serializing-deserializing overhead. Note that the receiving partition has to
instantiate a new object for every serialized object it receives and will
therefore execute all code in the Init() method. This overhead is not
required for scalar types, for which Forte only needs to reserve a small
amount of memory space on the stack.
Any call to a database is also a message sent across partitions and is
therefore serialized. However, one partition is a Forte partition and the
other one isn't. Therefore, Forte's internal serialization mechanism isn't
used. Forte serializes the SQL-query into a format understood by the
database (which is different for every vendor). Forte then receives a stream
back which has a different format for every different database type. This
stream is deserialized and written to attributes that Forte has reserved to
contain the data. Whether these are scalar, datavalues or domains only
impacts performance inside the Forte partition. It has no effect on the
communication with the database.
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: Singh [mailto:fortelistyahoo.com]
Sent: Thursday, February 22, 2001 3:30 AM
To: forte-userslists.xpedior.com
Subject: (forte-users) Serialisation
Hello All
I have a question that has been bugging me for some
time.
We all know that it is better to use scalar data
types, as opposed to objects, when passing data across
a network.
The reason, if I understand correctly, is that when
you send an object across a network, the whole object
(properties, attributes and methods) is deserialised
into zero's and one's before being sent across and
then serialised back into the object when it gets to
the other side. This would take longer for an object
since for a scalar value, just the value is
deserialised and serialised.
But when you are writing to a database from the tier
before the database to the database, does it matter
what type you use. The reason for saying this is that
the values are serialised before they go across and
then deserialised when they get to the base, in other
words, they are sent as zero's and one's. For a scalar
- just the value is sent across but for an object -
does just the value go across or the complete object.
If just the value of the object goes across, then it
doesn't really matter whether a scalar or object is
sent across.
Am I correct in this assumption.
Thanks in advance for your help.
Regards,
Singh
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,
I cannot get hold of Tech Note 10398..... can anyone email me a copy?
Tx
Etienne
-----Original Message-----
From: Klerk, Theo de [SMTP:Theo.de.Klerkcompaq.com]
Sent: Wednesday, February 09, 2000 4:26 PM
To: 'Jason de Cean'; 'Forte Users'
Subject: RE: (forte-users) Serialisation
There are a number of flags that will show you some of the required
information in a log file (not within the application itself). Technote
10398 has many more flags listed for a variety of obscure, useful, not so
useful and exotic information:
trc:cm:*:4 and *:8 - show packet serialisation, open, closes between
partition communication
trc:do:*:2 - proxy creation/deletion, exception events
trc:do:*:5 - individual message tracing between proxies
trc:do:*:8 - serialisation information
Theo
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Similar Messages

  • Re: (forte-users) FW: (forte-users) Serialisation

    Here is a Word formatted copy of the Tech Note
    "Slabbert, Etienne" <etiennemds.co.za> 02/17/00 04:10AM >>>Hi,
    I cannot get hold of Tech Note 10398..... can anyone email me a copy?
    Tx
    Etienne
    -----Original Message-----
    From: Klerk, Theo de [SMTP:Theo.de.Klerkcompaq.com]
    Sent: Wednesday, February 09, 2000 4:26 PM
    To: 'Jason de Cean'; 'Forte Users'
    Subject: RE: (forte-users) Serialisation
    There are a number of flags that will show you some of the required
    information in a log file (not within the application itself). Technote
    10398 has many more flags listed for a variety of obscure, useful, not so
    useful and exotic information:
    trc:cm:*:4 and *:8 - show packet serialisation, open, closes between
    partition communication
    trc:do:*:2 - proxy creation/deletion, exception events
    trc:do:*:5 - individual message tracing between proxies
    trc:do:*:8 - serialisation information
    Theo
    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

    Here is a Word formatted copy of the Tech Note
    "Slabbert, Etienne" <etiennemds.co.za> 02/17/00 04:10AM >>>Hi,
    I cannot get hold of Tech Note 10398..... can anyone email me a copy?
    Tx
    Etienne
    -----Original Message-----
    From: Klerk, Theo de [SMTP:Theo.de.Klerkcompaq.com]
    Sent: Wednesday, February 09, 2000 4:26 PM
    To: 'Jason de Cean'; 'Forte Users'
    Subject: RE: (forte-users) Serialisation
    There are a number of flags that will show you some of the required
    information in a log file (not within the application itself). Technote
    10398 has many more flags listed for a variety of obscure, useful, not so
    useful and exotic information:
    trc:cm:*:4 and *:8 - show packet serialisation, open, closes between
    partition communication
    trc:do:*:2 - proxy creation/deletion, exception events
    trc:do:*:5 - individual message tracing between proxies
    trc:do:*:8 - serialisation information
    Theo
    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) Copy Input parameter

    Peter,
    Just a quick response before I prepare a code sample for you.
    Unfortunately, we pay for our sins as a true cloning operation has to take
    into account the (potentially) recursive nature of an object graph and
    effectively has to do the equivalent of serialising an object graph (as in
    parameter passing to remote methods) without going into an infinite loop
    when the object graph recurses back into itself.
    The Forte runtime does this quite nicely but if you wish to change its
    default behaviour, it's a bit of hard work but it's achievable.
    So you need to decide. Is it worth it?
    Mario Emmi
    British Aerospace Australia
    -----Original Message-----
    From: Peter Sham [SMTP:[email protected]]
    Sent: Thursday, 28 October 1999 07:20
    To: EMMI, Mario
    Cc: '[email protected]'
    Subject: RE: (forte-users) Copy Input parameter
    Hi,
    Interesting solution!
    Just to clarify further. How exactly would you
    over-write the clone method. New the object and then
    clone all the attributes of the existing object to the
    new object, excluding whatever attribute you think is
    appropriate?
    Regards,
    Peter Sham.
    --- "EMMI, Mario" <[email protected]> wrote:
    Peter,
    That is the behaviour that I have experienced also,
    so I do not have such
    (anchored service object) attributes in my classes
    anymore but instead add
    that service object attribute as an input parameter
    to all methods in that
    class that require access via that service object
    attribute.
    Alternatively, if access to that anchored service
    object is only required in
    the partition that it was created then overriding
    the Clone method of the
    class to return a NIL value in the service object
    attribute should work for
    you.
    Mario Emmi
    British Aerospace Australia
    -----Original Message-----
    From: Peter Sham [SMTP:[email protected]]
    Sent: Thursday, 28 October 1999 05:33
    To: Forte User Group
    Subject: (forte-users) Copy Input parameter
    Hi folks,
    I have this problem where a "copy input" seems tocopy
    the service object too.
    The case is that I have a service object, say
    batchmgrso, for batch processing and an object,say
    batchproc, as the process. The batchproc has an
    attribute for referencing the batchmgrso as itwill
    create some other process and submit it to the
    batchmgrso.
    The problem is whenever a batchproc fails and the
    batchmgrso tries to re-submit the object from the
    queue, and I use a copy input as the mechanism for
    passing in the batchproc to the service object, Ican
    find that not only does the batchproc get cloned,but
    also the batchmgrso. It caused a lot of problemand
    bombed the method.
    When I changes the mechanism to just input in the
    method signature, everything works fine.
    So is it a forte feature/bug that a copy inputwould
    clone something so "deeply" that even a SO orarchored
    object would get clone too. Is there any way toavoid
    it?
    Regards,
    Peter Sham.
    =====
    For the archives, go to:
    http://lists.sageit.com/forte-users and use
    the login: forte and the password: archive. Tounsubscribe, send in a new
    email the word: 'Unsubscribe' to:
    [email protected]
    =====
    Do You Yahoo!?
    Bid and sell for free at http://auctions.yahoo.com

    Mario,
    Well. There're 2 ways that I can do it. Avoid copy
    input as much as possible ( in fact, I hate copy input
    ) or code my own clone method.
    Coding my own clone method should be a better
    solution. So if you have time, please please descibe
    it.
    Thanks for all the troubles. Regards,
    Peter Sham.
    --- "EMMI, Mario" <[email protected]> wrote:
    Peter,
    Just a quick response before I prepare a code sample
    for you.
    Unfortunately, we pay for our sins as a true cloning
    operation has to take
    into account the (potentially) recursive nature of
    an object graph and
    effectively has to do the equivalent of serialising
    an object graph (as in
    parameter passing to remote methods) without going
    into an infinite loop
    when the object graph recurses back into itself.
    The Forte runtime does this quite nicely but if you
    wish to change its
    default behaviour, it's a bit of hard work but it's
    achievable.
    So you need to decide. Is it worth it?
    Mario Emmi
    British Aerospace Australia
    -----Original Message-----
    From: Peter Sham [SMTP:[email protected]]
    Sent: Thursday, 28 October 1999 07:20
    To: EMMI, Mario
    Cc: '[email protected]'
    Subject: RE: (forte-users) Copy Input parameter
    Hi,
    Interesting solution!
    Just to clarify further. How exactly would you
    over-write the clone method. New the object andthen
    clone all the attributes of the existing object tothe
    new object, excluding whatever attribute you thinkis
    appropriate?
    Regards,
    Peter Sham.
    --- "EMMI, Mario" <[email protected]> wrote:
    Peter,
    That is the behaviour that I have experienced
    also,
    so I do not have such
    (anchored service object) attributes in myclasses
    anymore but instead add
    that service object attribute as an inputparameter
    to all methods in that
    class that require access via that serviceobject
    attribute.
    Alternatively, if access to that anchoredservice
    object is only required in
    the partition that it was created thenoverriding
    the Clone method of the
    class to return a NIL value in the serviceobject
    attribute should work for
    you.
    Mario Emmi
    British Aerospace Australia
    -----Original Message-----
    From: Peter Sham [SMTP:[email protected]]
    Sent: Thursday, 28 October 1999 05:33
    To: Forte User Group
    Subject: (forte-users) Copy Input parameter
    Hi folks,
    I have this problem where a "copy input" seems
    to
    copy
    the service object too.
    The case is that I have a service object, say
    batchmgrso, for batch processing and an
    object,
    say
    batchproc, as the process. The batchproc has
    an
    attribute for referencing the batchmgrso as itwill
    create some other process and submit it to the
    batchmgrso.
    The problem is whenever a batchproc fails and
    the
    batchmgrso tries to re-submit the object fromthe
    queue, and I use a copy input as the mechanismfor
    passing in the batchproc to the serviceobject, I
    can
    find that not only does the batchproc get
    cloned,
    but
    also the batchmgrso. It caused a lot of
    problem
    and
    bombed the method.
    When I changes the mechanism to just input in
    the
    method signature, everything works fine.
    So is it a forte feature/bug that a copy inputwould
    clone something so "deeply" that even a SO orarchored
    object would get clone too. Is there any way
    to
    avoid
    it?
    Regards,
    Peter Sham.
    =====
    For the archives, go to:
    http://lists.sageit.com/forte-users and use
    the login: forte and the password: archive. Tounsubscribe, send in a new
    email the word: 'Unsubscribe' to:
    [email protected]
    =====
    =====

  • RE: (forte-users) Class compatibility

    Pascal,
    Basically the way to work with objects as parameters is to ensure that
    sending and receiving parties have the same knowledge of the underlying
    classes of these objects.
    o Partitions in one application, generated at distribution time always are
    "in sync" with one another as they use the same class definitions specified
    through the supplier plan relationships of the main project
    o Applications distributed independently that exchanging objects only
    understand the common set of class definitions.
    For example, a Forte Conductor engine object is built using the standard
    Forte Framework classes. Its API specifies things like "DataValue" objects.
    Sending it a TextData is fine, sending it MyOwnTextData is not - the other
    application has no clue what that (sub)class is supposed to be as it did not
    know at the time it was built.
    This is also true in cases where applications use libraries and these are
    given objects of (sub)classes it knows nothing about.
    All of these generate serialisation errors of some sort since the flattened
    object that is sent across the wire cannot be reconstructed at the receiving
    end by lack of a blueprint (class definition) on how to create such an
    object.
    Theo de Klerk
    Architecture & Application Integration
    Professional Services
    Compaq Computer Corp. - the Netherlands
    PGP Fingerprint: 5A70 DD56 F3BA FE04 9DCA 1ACE 8581 0A2F F057 FA6E

    Theo,
    I understand all of that. Of course we make sure that all components use the
    same blueprints for all classes. However, in case we managed to get these
    blueprints out of sync, we don't want the application to simply crash. We
    want to trap this exception and print a message that says: "There seems to
    be a compatability problem between components. Please make sure the latest
    version of all application components have been installed."
    Of course we can trap all exceptions (GenericException) and ignore all of
    them after displaying them, but that seems like a blunt-axe-approach. I'm
    looking for the scalpel.
    Pascal Rottier
    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: Klerk, Theo de [mailto:Theo.de.Klerkcompaq.com]
    Sent: Wednesday, October 18, 2000 5:15 PM
    To: Rottier, Pascal; 'Forte Users'
    Subject: RE: (forte-users) Class compatibility
    Pascal,
    Basically the way to work with objects as parameters is to ensure that
    sending and receiving parties have the same knowledge of the underlying
    classes of these objects.
    o Partitions in one application, generated at distribution time always are
    "in sync" with one another as they use the same class definitions specified
    through the supplier plan relationships of the main project
    o Applications distributed independently that exchanging objects only
    understand the common set of class definitions.
    For example, a Forte Conductor engine object is built using the standard
    Forte Framework classes. Its API specifies things like "DataValue" objects.
    Sending it a TextData is fine, sending it MyOwnTextData is not - the other
    application has no clue what that (sub)class is supposed to be as it did not
    know at the time it was built.
    This is also true in cases where applications use libraries and these are
    given objects of (sub)classes it knows nothing about.
    All of these generate serialisation errors of some sort since the flattened
    object that is sent across the wire cannot be reconstructed at the receiving
    end by lack of a blueprint (class definition) on how to create such an
    object.
    Theo de Klerk
    Architecture & Application Integration
    Professional Services
    Compaq Computer Corp. - the Netherlands
    PGP Fingerprint: 5A70 DD56 F3BA FE04 9DCA 1ACE 8581 0A2F F057 FA6E
    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) Communication Pbs between a NT client& a HP 11 load-b

     

    Hi,
    I think you misunderstand the anatomy of an Array object. The size of an
    Array containing 63 elements can never be 1638 bytes when each element
    contains a 100 byte string.
    If you use the sizeof function, you'll only get the combined size of all
    attributes of the object. But if an object contains attributes that are
    objects themselves (e.g. TextData), then only the size of the pointer to
    this object is counted. Not the object itself.
    Array and LargeArray offer the same functionality but use different
    algorithms. LargeArray is better suited for large lists and Array is better
    suited for small lists. Array is faster, but requirs more memory. LargeArray
    is slower, but requires less memory.
    Array reserves a piece of memory that holds 63 pointers to objects. Within
    these 63 positions, you can read and write randomly. When you add a 64th
    object, Array locates a new piece of memory that holds 127 pointers. The
    first 63 pointers are copied to this new location and the original location
    is free for garbage collection. When you add a 128th object, Array locates a
    new piece of memory that holds 255 pointers. etc.
    Check if you're network communication time is closer to what you expect when
    you have 127 elements in your list. And then check if performance drops
    again when you have 128 elements.
    Also, take into account that Forte is not capable of measuring time in very
    small units. 80 ms and 150 ms might really just be 3 ms apart. Also, garbage
    collection might kick in at any moment, slowing down performance. If you
    have a multi-user OS, it might suddenly start doing maintenance tasks, that
    reduce the amount of processor time available for your partition, either the
    partition that sends the array, or the partition that receives it.
    Sending an object requires the object to be serialised, send and
    deserialised. The partition that invoked the Send() method blocks during
    this whole process. If deserialising at the other end takes longer, then the
    process simply waits longer.
    -----Original Message-----
    From: Olivier Brousseau [SMTP:Olivier.Brousseausema.fr]
    Sent: Thursday, April 06, 2000 7:05 PM
    To: kamranaminyahoo.com
    Cc: Eric ABECASSIS; Giulio CALIENDO
    Subject: (forte-users) Communication Pbs between a NT client & a HP
    11 load-balanced server : 100ms to transfer 1600 bytes on a 10Mbits link.
    Hi,
    we have done a very small application to instrument & verify the
    communication capabilities of our soft & network :
    1. a win NT client that generates an array of object ( nb of object is a
    parameter ), and that send it to a server.
    2. a HP11 server, that contains a load-balanced SO ( with only one
    replicate ). The prototype of the SO entry point, which does nothing, is
    as
    follows :
    void send( input GenericArray of Element );
    And Element is a class that contain a DataValue attribute with a 100 bytes
    string.
    Between the client & server, we have a 10 Mbits link ( it has been
    verified
    using FTP ). From 1 object sent, to 63 objects, ( size of the array with
    63
    objects = 1638 bytes ), everything is OK. The elapsed time is 10
    milliseconds.
    With 64 objects ( size of the array = 1666 bytes ), the elapsed time is
    100
    milliseconds ( in fact for one iteration, it's 80 msec, for the next one,
    150 msec, and then it's 80 msec, etc... ).
    All the results with more objects than 63 are awfull.
    Has anyone enccountered such a problem ?
    Can anyone advise ?
    Thanks,
    olivier
    Nota. Both server & client are built from Fort&eacute; 3.0.M
    O. Brousseau
    Architecture & Performance Team
    Sema Group France ( 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

  • 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) Fusion for the VAR

    Hi,
    It is a good idea. In fact, I think that how Forte is
    going to integrate her own suite of app. too. ( I
    kind of recall that there is a speech on this topic in
    Forum ).
    However, as Forte will most likely goes toward Java, I
    would suggest that you take into account the
    abstraction on Conductor ( which is frankly an event
    broker ) and Fusion ( which handles the XML mapping )
    too. In doing so, you can save guard your investment
    on the design without binding tightly with FORTE and I
    bet there will be tons of event broker or XML parser
    in the future market.
    On the other hand, this integration by Fusion would be
    perfect for a perfect world. But, in this imperfect
    world, it would be hard to do cross-checking between
    apps in Fusion.
    In the old days, we repulicate data or do file
    transfer to integrate apps. In doing so, we also
    build-in all the cross-checking procedure / reports.
    In the case of Fusion, is there such a safety net to
    save guard data integrity. Can I identify a lost
    event and trace back to find out whether it is a app.
    problem or Conductor problem?
    I think the customer would surely like to know.
    Regards,
    Peter Sham.
    --- "Thomas Mercer-Hursh, Ph.D."
    <[email protected]> wrote:
    Fusion has been positioned as an EAI tool, something
    at which it appears to
    be very, very good, but in recent months I have been
    thinking about its
    possible role as an architectural tool for those of
    us who build large,
    multi-application suites of applications. Having
    been tossing some of
    these ideas around the halls at Harrison Street, I
    thought I would try some
    of them on this audience as well to see what
    reaction I got.
    This concept is based on the context that one has
    multiple interacting
    applications which are loosely coupled, or at least
    which should be. E.g.,
    an order processing application may need credit
    status information from an
    accounts receivable application and may generate
    invoices which then need
    to be tracked for payment by that application, but
    the connections between
    these applications are specific, limited, and
    readily enumerable. Mind
    you, people don't always build their applications so
    cleanly modularized,
    but I think we all agree these days that they should
    be.
    The idea is to provide each application with a
    specific API, which it may
    currently have only indirectly. I.e., today one
    might simply have calls
    directly from one application to another, but one
    would gather all these
    links together and define an API, probably in XML
    which covered all of the
    necessary communciations between applications.
    These would then be used to
    build a Fusion Proxy and one would build the
    necessary Conductor processes
    to handle the communications which previously might
    have been made directly
    between applications. There is probably some
    performance loss in this
    process, but many of these interfaces are not
    performance intensive and my
    bet is that if the whole Fusion concept has adequate
    performance for the
    purposes for which it is being primarily marketed,
    then it has the
    performance for this sort of usage.
    One would get several advantages from this
    structure:
    1) Interapplication communications would be handled
    by a Conductor process
    and thus be much more readily configurable than any
    hard-coded link.
    2) One would gain the ability to unplug one's own
    application and plug in a
    customer's application when the customer insisted on
    using something else.
    3) The discipline of working in this structure would
    insure clean boundries
    between applications, which is not only sound
    design, but promotes the
    flexibility of the overall suite.
    4) Those with untransitioned legacy applications
    would have a framework
    that would allow a mixture of new and old
    applications to co-exist, thus
    providing them with a transition strategy until the
    full product line was
    converted.
    Note that I am assuming that one would want to build
    the individual
    applications so that they also used Conductor for
    managing their business
    process logic, but that seems to me to be an
    independent decision from this
    one.
    So, comments?
    Any downsides?
    Any added benefits I haven't covered here?
    Are there many out there that would benefit from
    this approach or just a few?
    Is anyone doing anything like this?
    Note that the one downside I have found so far is
    that Fusion licensing,
    independent of the Conductor aspect, is based on the
    number of proxies and
    so someone like CI who has 15 or more applications
    in a typical site is
    going to have 15 or more proxies. My bet is that
    this can be handled once
    it is clear that use of Fusion by a VAR for
    integrating own applications is
    not the same use as by an end-user integrating
    arbitrary multiple applications.
    =========================================================================
    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]
    =====

    Yes, they do & one page is 1KB page. We use the same instrument to check
    memory usage & to send alerts in our production system.
    Thanks.
    Suraj
    -----Original Message-----
    From: Epari, Madhusudhan [mailto:[email protected]]
    Sent: Monday, May 14, 2001 2:37 PM
    To: 'Saraf, Suraj'; 'Forte User Forum'
    Subject: RE: (forte-users) Instrument for memory used in the partition
    Thanks all for the response. I observed "Allocated Pages" instrument doesn't
    change as and when memory usage by the partition changes. I was trying to
    find a way to measure the actual memory (specifically in bytes or KBs).
    Thanks,
    Madhu
    -----Original Message-----
    From: Saraf, Suraj [mailto:[email protected]]
    Sent: Thursday, May 10, 2001 12:46 PM
    To: 'Epari, Madhusudhan'; 'Forte User Forum'
    Subject: RE: (forte-users) Instrument for memory used in the partition
    Hello,
    I think you can use 'OperatingSystem' service agent & check 'AllocatedPages'
    instrument to see how many memory pages are used. You can compare that with
    your maximum allocation & send alerts depending on that. Thanks.
    Suraj
    -----Original Message-----
    From: Epari, Madhusudhan [mailto:[email protected]]
    Sent: Thursday, May 10, 2001 11:15 AM
    To: 'Forte User Forum'
    Subject: (forte-users) Instrument for memory used in the partition
    Hello Everyone,
    Is there an instrument to track the memory used in the partition at a given
    point of time. I have a requirement where an alert has to be generated in
    the environment when partition uses all its available memory.
    Thanks in advance,
    Madhu
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: [email protected]

  • RE: (forte-users) Reporting tools/components for ForteApplications?

    Hi Robert,
    A good place to start when it comes to reporting is Forte Consulting. They
    have developed a tool called ReportKit, which is ActiveX integration with
    Seagate Software's Crystal Reports tool. Crystal is not really a three-tier
    tool (although, your Forte Consultant can probably set it up to mimic a
    three-tier tool), but it is a quick, easy way to get quality reports from
    your existing Forte applications. If you're interested, give your Forte
    Sales Rep (or, better still, your Forte Regional Consulting Director) a
    call. They can discuss pricing and scheduling. I've done several
    integration projects with Crystal, and I highly recommend ReportKit for
    small- to medium-sized reporting requirements. As for costs, I don't recall
    how much CrystalReports runs, but I think there are developer licenses and
    runtime licenses.
    FYI, the actual integration of ReportKit is pretty quick. The more
    time-consuming piece of any report tool integration is the design and
    implementation of the reports to be used.
    I hope this helps.
    -Katie
    Katie Tierney
    Quality Management Analyst
    Akili Systems Group
    601 Jefferson, Suite 3975
    Houston, Texas 77002
    Office: (713) 655-1400
    Cell: (409) 255-1643
    "The bitterness of poor quality remains long after the sweetness of low
    price is forgotten" --Larry Anderson
    -----Original Message-----
    From: Robert Brooke-N502365 [mailto:Robert.Brookeca.michelin.com]
    Sent: Monday, February 14, 2000 8:17 AM
    To: kamranaminyahoo.com
    Subject: (forte-users) Reporting tools/components for Forte
    Applications?
    Hi all,
    We are looking for what is currently in the marketplace to enhance the
    reporting
    capabilities of Forte. Ideally, we are looking for component libraries that
    we
    could import into our repository. Do these exist?
    Currently, I have found six reporting tools that are out there. The
    tools
    are Actuate, Crystal Reports, Report Workshop from Indus Consultancy
    Services, Brio Technologies (SQR) VisualBRIO, Visual CyberQuery from
    Cyberscience Corp., and Beacon from Brahma Software Solutions FORTify
    Components. Are there any others for Forte?
    If anyone is currently using one of these Reporting Tools for Forte or
    any
    others, could you give me any indications as to the costs, training, type
    of
    application using the Reporting tool, would you recommend using the
    product
    again, does it use wrappering or API, or is it a component based tool, and
    any
    other relevant information on the product?
    Thanks,
    Robert Brooke
    Application Developer
    Michelin North America (Canada) Inc. CA0/CA1
    PO Box 399
    New Glasgow, Nova Scotia
    B2H-3E6
    Phone: (902) 753-1977
    Fax: (902) 396-2180
    Note: We are currently developing in Forte 3.0.L.2. However, we would
    like
    to select a reporting tool/component within the next month. We are in the
    initial phases of our next project, an application to be developed
    in-house.
    Probably will have two databases, one for real-time data and another one
    for
    archived data. Probably will need reporting functionality and capabilities
    for
    both real-time data and archived data.
    This email and any files transmitted with it are confidential and
    intended solely for the use of the individual or entity to whom they
    are addressed. If you have received this email in error please notify
    the system manager.
    This footnote also confirms that this email message has been swept by
    MIMEsweeper for the presence of computer viruses.
    The E-Mail System is to be used for business purposes only.
    www.mimesweeper.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

    At 09:33 AM 4/20/01, Rottier, Pascal wrote:
    Forte 4GL is:
    1) A language, TOOL (Compare to Java)
    2) An IDE (Compare to e.g. JBuilder or FJCE)
    3) A collaborative development environment, with central repository (Compare
    to ????)
    4) A distributed application server / object request broker (Compare to J2EE
    servers and/or CORBA)Let's not forget WebEnterprise, Express, and especially Fusion.
    I think, SUN is not al all interested in TOOL.If TOOL were just a language and had no market yet, you are probably
    right. But, not only is TOOL the key to the Forte environment, but it has
    an existing and profitable market. Sun still sells FORTRAN, after all, and
    continues to put money into ADE development for all its language
    products. The real kicker, though, is that I think iPlanet is very clear
    that Fusion, now iIS, is a very key product for them. There may be those
    who wish it were written in Java and who might lobby for doing a Java
    version, but it was clear at the conference that the iPlanet management
    recognize that Java just isn't up to the task at this point. It isn't as
    if all the iPlanet tools are actually written in Java, after all.
    They will only support them for as long as they need.Or, more likely, for as long as they make money.
    Now, in response to Microsofts .NET stratagy. We have yet to see how
    succesfull this will be, but I expect Microsoft to push this down the
    throats of developers and companies quite succesfully.Like they did DCOM?
    =========================================================================
    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

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

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

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

  • Re: (forte-users) Accessing Technote 10398

    Ketie,
    let's see, I have been using FORTE since November of
    1994. since the beginning those flags have been common
    knowledge within the FORTE community and widely
    disseminated.
    the FORTE flags have been invaluable to me and HAVE
    NEVER caused any downtime. sure, there are a few
    wildcards in there that can cause trouble, but to
    throw out the baby with the bathwater is ridiculous.
    what would life be without trc:lo:25? to trace
    exceptions.
    or trc:os:1:1 and trc:os:5:5 to tune memory
    consumption?
    Should i have to call a consultant or FORTE tech
    support to do the deep dive on exceptions or tune my
    applications? I think not.
    Overreaction? No.
    Mark.
    --- Katie Tierney <katiethetierneys.com> wrote:
    I think y'all are overreacting. There are log flags
    that are detailed in
    Technote 10398 that can cause serious implications
    if used improperly. I
    think Forte/Sun just wants to make sure that people
    don't make mistakes that
    cost them valuable time.
    As a Forte Consultant for many years, I have seen a
    good number of people
    misuse information that was not completely
    understood. In some cases, this
    caused excessive downtime for production
    applications. The only time I ever
    saw Technote 10398 being provided to a customer was
    when they were utilizing
    Forte Consulting, or when a Technical Support
    Engineer was heavily involved.
    I was extremely surprised to learn that it was
    available to non-employees via
    the website - that sounds as if someone may have
    inadvertantly marked it as
    customer-viewable (incorrectly, obviously) in Sun's
    internal systems.
    Again, I think you're overreacting. I am sure that
    this isn't a case of Sun
    thinking anyone is "stupid." It's a matter of
    providing the support that
    people need to properly utilize the tools available.
    -Katie
    mark joyce wrote:
    read: Sometimes, the technotes are markedunviewable
    to customers because they might need further
    explanation. Let me know if you need to log acase.
    in other words, you are TOO STUPID to use FORTElogger
    flags, although they have been widely distributedand
    used for years by FORTE users.
    i can't believe it either. i don't know what iwould
    have done for the last 5 years without using theFORTE
    flags. such a wealth of good output!
    what an excuse! "they might need furtherexplanation"
    .. if i had to log every problem with FORTE,instead
    of resolving them myself through the information
    obtained by using flags, i would have lost my joba
    long time ago.
    mark.
    --- Jeff Bennett <jeff_bennettsehamerica.com>wrote:
    I thought it might be prudent to share with youthe
    response I received from Sun
    regarding the inability to access technote 10398
    (Fort&eacute; logger flags). I was
    able to access it 3+ weeks ago, and fortunatelykept
    a hard-copy. But, how are
    we supposed to do our job effectively and
    expediently if we do not have
    (complete) access to this resource?
    I thought the technotes were completely open tothe
    Fort&eacute; development
    community.... wrong.
    -jeff
    ---------------------- Forwarded by JeffBennett/SEH
    on 09/11/2000 09:02 AM
    Forte Support <supportforte.com> on 09/08/2000
    10:05:17 AM
    To: Jeff Bennett/SEHsehamerica.com
    cc:
    Subject: Re: Accessing Technote 10398
    Fax to:
    Hello Jeff,
    Were you at one point able to access thistechnote?
    You know why -- it's
    because this technote is marked for employeeviewing
    only and not available
    for customer viewing. If you need further
    assistance or need to look at
    this technote, what you would need to do is loga
    call with us and then a
    tech support specialist will give you a callback.
    Sometimes, the
    technotes are marked unviewable to customersbecause
    they might need
    further explanation. Let me know if you need tolog
    a case.
    Thanks!
    At 09:57 AM 9/8/00 -0700, you wrote:
    I am no longer able to access technote 10398
    (forte
    logger flags)... why?
    -jeff~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
    Sun&reg; microsystems
    Jeannie Lee
    Phone: (510) 451-5400
    Fax (510) 869-2010
    Email: jeannie.leesun.com
    Forte Tools Response Coordinator
    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
    http://mail.yahoo.com/
    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
    http://mail.yahoo.com/

    Ketie,
    let's see, I have been using FORTE since November of
    1994. since the beginning those flags have been common
    knowledge within the FORTE community and widely
    disseminated.
    the FORTE flags have been invaluable to me and HAVE
    NEVER caused any downtime. sure, there are a few
    wildcards in there that can cause trouble, but to
    throw out the baby with the bathwater is ridiculous.
    what would life be without trc:lo:25? to trace
    exceptions.
    or trc:os:1:1 and trc:os:5:5 to tune memory
    consumption?
    Should i have to call a consultant or FORTE tech
    support to do the deep dive on exceptions or tune my
    applications? I think not.
    Overreaction? No.
    Mark.
    --- Katie Tierney <katiethetierneys.com> wrote:
    I think y'all are overreacting. There are log flags
    that are detailed in
    Technote 10398 that can cause serious implications
    if used improperly. I
    think Forte/Sun just wants to make sure that people
    don't make mistakes that
    cost them valuable time.
    As a Forte Consultant for many years, I have seen a
    good number of people
    misuse information that was not completely
    understood. In some cases, this
    caused excessive downtime for production
    applications. The only time I ever
    saw Technote 10398 being provided to a customer was
    when they were utilizing
    Forte Consulting, or when a Technical Support
    Engineer was heavily involved.
    I was extremely surprised to learn that it was
    available to non-employees via
    the website - that sounds as if someone may have
    inadvertantly marked it as
    customer-viewable (incorrectly, obviously) in Sun's
    internal systems.
    Again, I think you're overreacting. I am sure that
    this isn't a case of Sun
    thinking anyone is "stupid." It's a matter of
    providing the support that
    people need to properly utilize the tools available.
    -Katie
    mark joyce wrote:
    read: Sometimes, the technotes are markedunviewable
    to customers because they might need further
    explanation. Let me know if you need to log acase.
    in other words, you are TOO STUPID to use FORTElogger
    flags, although they have been widely distributedand
    used for years by FORTE users.
    i can't believe it either. i don't know what iwould
    have done for the last 5 years without using theFORTE
    flags. such a wealth of good output!
    what an excuse! "they might need furtherexplanation"
    .. if i had to log every problem with FORTE,instead
    of resolving them myself through the information
    obtained by using flags, i would have lost my joba
    long time ago.
    mark.
    --- Jeff Bennett <jeff_bennettsehamerica.com>wrote:
    I thought it might be prudent to share with youthe
    response I received from Sun
    regarding the inability to access technote 10398
    (Fort&eacute; logger flags). I was
    able to access it 3+ weeks ago, and fortunatelykept
    a hard-copy. But, how are
    we supposed to do our job effectively and
    expediently if we do not have
    (complete) access to this resource?
    I thought the technotes were completely open tothe
    Fort&eacute; development
    community.... wrong.
    -jeff
    ---------------------- Forwarded by JeffBennett/SEH
    on 09/11/2000 09:02 AM
    Forte Support <supportforte.com> on 09/08/2000
    10:05:17 AM
    To: Jeff Bennett/SEHsehamerica.com
    cc:
    Subject: Re: Accessing Technote 10398
    Fax to:
    Hello Jeff,
    Were you at one point able to access thistechnote?
    You know why -- it's
    because this technote is marked for employeeviewing
    only and not available
    for customer viewing. If you need further
    assistance or need to look at
    this technote, what you would need to do is loga
    call with us and then a
    tech support specialist will give you a callback.
    Sometimes, the
    technotes are marked unviewable to customersbecause
    they might need
    further explanation. Let me know if you need tolog
    a case.
    Thanks!
    At 09:57 AM 9/8/00 -0700, you wrote:
    I am no longer able to access technote 10398
    (forte
    logger flags)... why?
    -jeff~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
    Sun&reg; microsystems
    Jeannie Lee
    Phone: (510) 451-5400
    Fax (510) 869-2010
    Email: jeannie.leesun.com
    Forte Tools Response Coordinator
    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
    http://mail.yahoo.com/
    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
    http://mail.yahoo.com/

  • RE: (forte-users) user name

    Troy Burns wrote:
    It would definitely be of interest to me, since this is an item on my
    "to-do" list. If you can release the code, let me know.Here 'tiz.
    The files you're getting are:
    SFVosC.pex - "C" wrapper.
    Vos.C - The "C" callout.
    Vos.H - A header file for Vos.C, used by ...
    VosCLI.C - A command-line-driven mainline to test Vos.C
    VosObj.CEX - An object that provides a "nice" interface to the "C" wrapper.
    We use this in two ways: instantiated as a local object to get the username
    under VMS or NT, or as a service object partitioned to an NT server to do
    username/password authentication on behalf of clients on other operating
    systems.
    The following changes have been made throughout the files in an attempt to
    keep various people in DuPont happy:
    "our_application_root" replaces the actual name of the root directory of
    the application.
    "our_vms_server" replaces the actual name of the system in question.
    "our_nt_server" replaces the actual name of the system in question.
    "our_application_name" replaces the actual name of the application.
    A copyright notice, the usual disclaimer, and a "fair use" statement (which
    is just a reference to the Perl Artistic License) have been inserted.
    Except for the "ExternalObjectFiles" declaration in SFVosC.pex, all the
    changes appear to have been in comments. But the files come with the usual
    freeware warranty (i.e. "use at your own risk".)
    Have fun with these!
    Tom Wyant
    (See attached file: SFvosC.pex)(See attached file: Vos.c)(See attached
    file: Vos.h)(See attached file: Voscli.c)(See attached file: VosObj.cex)

    I would try going to the "lowest common denominator" between WindowsNT and
    Windows95 - DOS. Both windowing OS's sort of have their roots in DOS, or at
    least both are capable of opening a DOS session.
    Therefore, from a DOS prompt type "set" to view the environment variables for
    both OS types. Look for a common variable between the two that stores the
    userID. If you can find one of these your application will be that much more
    portable between these two Windows mutations.
    I used "set" on my NT and found my userID assigned to a few variables. I haven't
    done this on a Windows95 machine in quite some time, but if the machine is on
    the network it should have at least one environment variable with the userID.
    I'm just guessing that DOS has a variable to store the userID that will be
    common to both machines.
    Good luck....
    Kelsey PetrychynSaskTel Technical Analyst
    ITM - Technology Solutions - Distributed Computing
    Tel (306) 777 - 4906, Fax (306) 359 - 0857
    Internet:kelsey.petrychynSasktel.sk.ca
    Quality is not job 1. It is the only job!
    "Olivier Andrieux" <oandrieuxaxialog.fr> on 07/19/2000 09:12:41 AM
    To: forte-userslists.xpedior.com
    cc: (bcc: Kelsey Petrychyn/SaskTel/CA)
    Subject: (forte-users) user name
    Hi
    I use this command to catch the username:
    task.part.operatingsystem.getenv('username')
    with NT, there is no problem
    but with windows95 or 98 the command doesn't find the username.
    Thanks in advance.
    Olivier Andrieux
    Axialog
    Lille
    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) Minimal Fusion

    Thomas,
    A response which may contain no answers...and may lead to more questions...
    As a novice fusion user, one of the largest obstacles to using Fusion is the lack of XML API's in an application, be it a customer's in-house or vendor's software product. Corresponding to this is simply the lack of any API's in the application. As Forte (abet Sun, now iPlanet) says in their training manual 'A nontrivial task is to build new adapters for your programs if you wish to enable them to interact using XML documents over HTTP'. This is probably an understatement.
    The question that come to mind is:
    Does the warehouse have published API's their product?
    If not, then, IMHO, you have steep hill to climb, not the least being communication, cooperation, and coordination from the warehouse vendor (another one of those 'nontrivial tasks') in trying to create the required API's
    if so, then it is a matter of building an adapter, in a language that is compatible with the warehouse's API (hopefully C or some derivation of) , that contains (1) a DOM (Document Object Module) to API Translator, (2) an XML Parser (converts XML to DOM and visa-versa) , and (3) a HTTP server (again, another one of those 'nontrivial tasks').
    Forte (abet Sun, now iPlanet) suggests, and I would concur (with reservations), that if you haven't done this before you should probably hire their services from the Forte Integration Services group. Their costs (admittible high) should be offset be the time it would take to develop one on your own. A side benefit is working with them, you learn the process for making other adapters in the future. If Fusion is a marketing success, then the benefits should out weigh the costs.
    The Forte Integration Services group markets, or will market, a Fusion Adapter Designer, some sort of a SDK, which assists in the creation of Adapters. I do not know the availability of that product at this time.
    As to your question "Is it reasonable to consider doing this project under Fusion as a
    getting-feet-wet experience?" If you (or your customer) can afford the costs, and the warehouse has published API's, I would say that you gotta get-your-feet-wet somehow. If the warehouse doesn't have published API's and are not willing to put forth the effort and resources to do so, I would say your chances of success are considerably less.
    In any case, IMHO, it will be a 'non trivial' undertaking.
    -later
    -labeaux
    "Thomas Mercer-Hursh, Ph.D." <thomascintegrity.com> 10/31/00 04:49PM >>>This may be one of those questions which has no answer, but ...
    Our long term plan is to develop XML APIs to each of the modules in our
    suite of non-Forte applications and to integrate these under Fusion, thus
    gaining Conductor management of the inter-module work flows and a cleaner
    loose coupling of the applications along with other benefits such as the
    ease of integration with other packages, a clean way to migrate to Forte
    modules, and an ease of interconnecting "mini-applications" to address
    specific customer needs.
    I have an existing customer who has made a decision to migrate to a third
    party warehouse from an in-house warehouse. I.e., were this transition to
    the new structure complete, this would correspond to unhooking some of our
    modules and replacing these with an adapter to the corresponding modules in
    the third party warehouse.
    In fact, as it looks now, I will need to build the logical equivalent of
    these APIs anyway -- might as well do it in XML, right? And these APIs
    will communicate with a daemon responsible for the message traffic to and
    from. I tried to get this traffic to be XML and to use MQSeries or JMS as
    the transport, but the folks at the warehouse end don't seem to be able to
    handle such things, so I am stuck doing something fairly stupid for the
    actual communication.
    So, the question for those out there who have already paid their Fusion
    dues, is it reasonable to consider doing this project under Fusion as a
    getting-feet-wet experience. There are only half a dozen APIs to do and I
    have to do those anyway and am inclined to make them XML regardless. There
    will be one communication daemon to which all these connect and the
    business processes originally implemented in Conductor will basically be
    just point to point connects, except for routing traffic from the daemon to
    the right API based on message type. That's really all I need it to do,
    i.e., far too simple to actually need Fusion, but a possible opportunity
    to get started and then to expand to other uses.
    Crazy?
    =========================================================================
    Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
    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.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

    At 07:55 AM 11/1/00, Labeaux Schiek wrote:
    As a novice fusion user, one of the largest obstacles to using Fusion is
    the lack of XML API's in an application, be it a customer's in-house or
    vendor's software product.In this case, the good news is that one of the applications in question is
    our own, so whipping up an XML API to suit each required transaction on
    that side is no more, probably less, work than importing or exporting a
    flat file or whatever. Moreover, my current expectation of how this
    interaction will work is something like this:
    </pre>
    ---Fusion------
    | |
    WACS<-->WACS_Daemon<----VPN socket
    connection---->IS_Daemon I/S
    </pre>
    I.e., I/S, our application, and the IS_Daemon which handles the connection
    traffic across the internet link are both mine. For I/S, I will create XML
    APIs to suit. For the IS_daemon, I might use the transform facilities to
    convert this XML to the pipe-delimited format they are expected at the
    other end and make the daemon a simple manager of the connection or, the
    daemon could do the conversion, but the former seems like the more
    appropriate approach. The API between the two daemons is something we are
    defining now (unfortunately I lost the argument to make that XML).
    Corresponding to this is simply the lack of any API's in the
    application. As Forte (abet Sun, now iPlanet) says in their training
    manual 'A nontrivial task is to build new adapters for your programs if
    you wish to enable them to interact using XML documents over HTTP'.My neophyte understanding is that, since I am defining the API to I/S in
    the diagram above and I can make this XML, then the adapter issue
    disappears there. I might have to create an adapter for the daemon, but if
    necessary, I could make that the same XML on a pass through and do the
    translation in the daemon.
    If not, then, IMHO, you have steep hill to climb, not the least being
    communication, cooperation, and coordination from the warehouse vendor
    (another one of those 'nontrivial tasks') in trying to create the required
    API'sWe are well through this process anyway. ... which is not to say that it
    has been or will be easy, but it must be done whether I use Fusion or
    not. Given that the vote has gone in favor of simple messages of
    pipe-delimited records, i.e., basically flat file, the technical issues
    there are minimal.
    if so, then it is a matter of building an adapter, in a language that is
    compatible with the warehouse's API (hopefully C or some derivation of) ,
    that contains (1) a DOM (Document Object Module) to API Translator, (2)
    an XML Parser (converts XML to DOM and visa-versa) , and (3) a HTTP server
    (again, another one of those 'nontrivial tasks').I'm not sure I quite understand what you are saying here. The HTTP part
    won't be there since we will apparently be connecting via a VPN sockets
    connection. But, how are you distinguishing DOM and XML since DOM is a
    particular form of XML? The XML API I build for I/S will be DOM compliant.
    Forte (abet Sun, now iPlanet) suggests, and I would concur (with
    reservations), that if you haven't done this before you should probably
    hire their services from the Forte Integration Services group. Their
    costs (admittible high) should be offset be the time it would take to
    develop one on your own. A side benefit is working with them, you learn
    the process for making other adapters in the future. If Fusion is a
    marketing success, then the benefits should out weigh the costs.I am familiar with the "party" line. If I were building a complete
    interface to another major product (I/S is roughly equivalent to JDEC in
    coverage) in the context of an EAI project, I would happily invite them in
    and hope to pick up pointers. Here, though, there are only 8 or 9 total
    transaction types and either all of the interfaces are XML, i.e., no
    adapter required as I understand it, or only the daemon will need an
    adapter and that will be a choice I can make depending on how things
    go. One does wish it were possible to sample a small piece of that
    knowledge store without having to buy the whole thing, though.
    The Forte Integration Services group markets, or will market, a Fusion
    Adapter Designer, some sort of a SDK, which assists in the creation of
    Adapters. I do not know the availability of that product at this time.Last I checked, one couldn't get this without the consulting ... hence the
    last sentence above.
    Thanks for your input.
    =========================================================================
    Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
    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

  • RE: (forte-users) FW: (forte-users)

    Hi there
    Thanks very much for the solution - just wanted to let you know . We
    implemented the design that technote 11378 suggested .
    It worked .
    Thanks very much
    Cheers
    Jen
    -----Original Message-----
    From: Adamek, Zenon [mailto:ZAdamekpurolator.com]
    Sent: Tuesday, 20 March, 2001 9:21 PM
    To: 'forte-userslists.xpedior.com'
    Subject: (forte-users) FW: (forte-users)
    Hi David,
    The problem is that the SO uses an attribute of its class ACBAccount as
    the ObjectReference pointer. SO is not a stateless object. The possible
    scenario before crash can be that client A and B calls SO at the same
    time. A's thread creates ACBAccount gets the ObjectReference. At this
    point B's thread is activated, does the same as A creates new
    ObjectReference. Probably the next switch between A and B will be in the
    Connect() (B should wait for OLE server). If A is reactivated it doesn't
    get the original own reference but the B's reference. It can cause the
    crash and means that a thread can use reference created in some other
    thread.
    Regards,
    Zenon
    -----Original Message-----
    From: David McPaul [SMTP:dmcpaullumley.com.au]
    Sent: Monday, March 19, 2001 11:52 PM
    To: 'forte-userslists.xpedior.com'
    Subject: RE: (forte-users)
    Jenni,
    As Zenon has pointed out, technote 11378 talks about problems that
    can occur if the calls made to an OLE object are not from within the same
    thread the OLE object was created in. It goes on to show a design to
    avoid
    this.
    However, the code you have given DOES communicate to the OLE object
    in the same thread as it was created. So the problem as I see it is more
    likely to be that the OLE object is not being garbage collected. Although
    you do explicitly NIL out the ACBAccount object there is a technote 12453
    that deals with the need to set the ObjectReference of CDispatch objects
    to
    NIL to allow the OLE object to be completely reclaimed by the garbage
    collector. Failure to do so when using code that creates a new OLE object
    every time you ask for an account validation will eventually run the
    partition out of memory.
    As pointed out in a previous post you can also increase
    FORTE_STACK_SIZE but this will delay the problem not correct it.
    Rather than create the connection each time you may want to think
    about redesigning the method as shown in tech note 11378.
    Cheers
    David
    -----Original Message-----
    From: Adamek, Zenon [mailto:ZAdamekpurolator.com]
    Sent: Tuesday, March 20, 2001 5:05 AM
    To: 'Els, Jenni'
    Cc: 'forte-userslists.xpedior.com'
    Subject: RE: (forte-users)
    Hi Jenni,
    The most important issue by designing an OLE connection between a Forte
    server partition and an OLE component is taking into account that an OLE
    object can be referenced from the NT thread in Forte partition that it was
    created in. It is the reason that you have no problems with your mini-app
    in
    single-threaded version.
    This problem is discussed in the Technote 11378. You can find a workaround
    for your problem there, too.
    Regards,
    Zenon
    -----Original Message-----
    From: Els, Jenni [SMTP:JElsnbs.co.za]
    Sent: Monday, March 19, 2001 2:28 AM
    To: 'forte-userslists.xpedior.com'
    Subject: (forte-users)
    Hi there
    We have this situation
    We are calling a Service Object (in the server partition) from ourclient
    partition.This service object calls a method which calls a DLLregistered
    on our server (VB code) . This VB code access a database on anotherserver
    .(DSN set up on our server ).The database is sql server .
    We are having the problem where for about 3 hours in the morning , the
    system works perfectly. We then get a segmentation violation on this
    partition . When we run interpreted we can see that this is an OLEinvoked
    exception. The partition does not always show as offline in econsole
    and
    because it does not , we cannot 'online' another . We cannot take the
    entire app down as everything hangs . Eventually our technical depthas
    to
    down the server
    We set up a mini-app looping through and calling the DLL to simulate
    the
    problem . It worked fine. When we put another asynchronous task in the
    method to call the service object , it erred quite soon. We thencreate
    an
    attribute of type mutex and locked using that. The mini-app worked.
    However our app in development eventually hanged (without the
    partition
    coming though) .
    The service Object is an environment visible service object in asingle
    (non-replicated partition) . It has a dialog duration = session .
    In the project is
    ACB : ACBObject
    ACBObject : CDispatch (shared = disallowed , distributed =
    disallowed, transactional = disallowed, monitored = allowed)
    ACBValidator : Object (shared = allowed , distributed =allowed,
    transactional = disallowed, monitored = disallowed)
    ACBVaidatorSO : ACBValidator
    In this method we have this code to call the DLL
    self.ACBAccount = new;
    self.ACBAccount.CreateUsingCLSID(classID='{2EFD3084-7B05-11D3-857F-00105A4
    8CEA0}');
    pErrorMessage = new;
    acbaccount.BankCode = pBankCode.value;
    acbaccount.BranchCode = pBranchCode.value;
    at : VariantI2 = new;
    at.Value = pAccountType.Value;
    acbaccount.AccountType = at.Value;
    acbaccount.AccountNo = pAccountNo.value;
    begin
    acbaccount.Connect();
    exception
    when e : GenericException do
    ex : GenericException = new;
    ex.SetWithParams(severity = SP_ER_ERROR,
    message = 'There was an error connecting to the database');
    raise ex;
    end;
    begin
    err : i2 = acbaccount.ValidateAccount();
    if err != 0 then
    pErrorMessage.SetValue(acbaccount.ErrDescriptionStr(iErrorCode= err));
    acbaccount.Disconnect();
    return false;
    else
    pErrorMessage.SetValue('The account is
    valid!!');
    acbaccount.Disconnect();
    self.ACBAccount = NIL ;
    return true;
    end if;
    exception
    when e : GenericException do
    acbaccount.Disconnect();
    ex : GenericException = new;
    ex.SetWithParams(severity = SP_ER_ERROR,
    message = 'There was an error Validating the account');
    Task.ErrorMgr.AddError(ex);
    task.errormgr.ShowErrors();
    raise e;
    end;
    exception
    when e : GenericException do
    acbaccount.Disconnect();
    Task.ErrorMgr.ShowErrors();
    raise e;
    If anybody has any suggestions , they would be most welcome
    Thanks very much
    Cheers
    Jenni Els************************************************************************Th
    is e-mail is intended for the use of the individual or entity named above
    and may contain information that is confidential and privileged. If you
    are not the intended recipient, you are hereby notified that any
    dissemination, distribution or copying of this e-mail is strictly
    prohibited. If you have received this e-mail in error, please notify us
    immediately at helpdesklumley.com.au and destroy the original message.
    While this mail and any attachments have been scanned for common computer
    viruses and found to be virus free, we recommend you also perform your own
    virus checking processes before opening any attachments.
    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
    WARNING:
    Any unauthorised use or interception of this email is illegal. If this email
    is not intended for you, you may not copy, distribute nor disclose the
    contents to anyone. Save for bona fide company matters, the BoE Group does
    not accept any responsibility for the opinions expressed in this email.
    For further details please see: http://www.nbs.co.za/emaildisclaim.htm

    Hi there
    Thanks very much for the solution - just wanted to let you know . We
    implemented the design that technote 11378 suggested .
    It worked .
    Thanks very much
    Cheers
    Jen
    -----Original Message-----
    From: Adamek, Zenon [mailto:ZAdamekpurolator.com]
    Sent: Tuesday, 20 March, 2001 9:21 PM
    To: 'forte-userslists.xpedior.com'
    Subject: (forte-users) FW: (forte-users)
    Hi David,
    The problem is that the SO uses an attribute of its class ACBAccount as
    the ObjectReference pointer. SO is not a stateless object. The possible
    scenario before crash can be that client A and B calls SO at the same
    time. A's thread creates ACBAccount gets the ObjectReference. At this
    point B's thread is activated, does the same as A creates new
    ObjectReference. Probably the next switch between A and B will be in the
    Connect() (B should wait for OLE server). If A is reactivated it doesn't
    get the original own reference but the B's reference. It can cause the
    crash and means that a thread can use reference created in some other
    thread.
    Regards,
    Zenon
    -----Original Message-----
    From: David McPaul [SMTP:dmcpaullumley.com.au]
    Sent: Monday, March 19, 2001 11:52 PM
    To: 'forte-userslists.xpedior.com'
    Subject: RE: (forte-users)
    Jenni,
    As Zenon has pointed out, technote 11378 talks about problems that
    can occur if the calls made to an OLE object are not from within the same
    thread the OLE object was created in. It goes on to show a design to
    avoid
    this.
    However, the code you have given DOES communicate to the OLE object
    in the same thread as it was created. So the problem as I see it is more
    likely to be that the OLE object is not being garbage collected. Although
    you do explicitly NIL out the ACBAccount object there is a technote 12453
    that deals with the need to set the ObjectReference of CDispatch objects
    to
    NIL to allow the OLE object to be completely reclaimed by the garbage
    collector. Failure to do so when using code that creates a new OLE object
    every time you ask for an account validation will eventually run the
    partition out of memory.
    As pointed out in a previous post you can also increase
    FORTE_STACK_SIZE but this will delay the problem not correct it.
    Rather than create the connection each time you may want to think
    about redesigning the method as shown in tech note 11378.
    Cheers
    David
    -----Original Message-----
    From: Adamek, Zenon [mailto:ZAdamekpurolator.com]
    Sent: Tuesday, March 20, 2001 5:05 AM
    To: 'Els, Jenni'
    Cc: 'forte-userslists.xpedior.com'
    Subject: RE: (forte-users)
    Hi Jenni,
    The most important issue by designing an OLE connection between a Forte
    server partition and an OLE component is taking into account that an OLE
    object can be referenced from the NT thread in Forte partition that it was
    created in. It is the reason that you have no problems with your mini-app
    in
    single-threaded version.
    This problem is discussed in the Technote 11378. You can find a workaround
    for your problem there, too.
    Regards,
    Zenon
    -----Original Message-----
    From: Els, Jenni [SMTP:JElsnbs.co.za]
    Sent: Monday, March 19, 2001 2:28 AM
    To: 'forte-userslists.xpedior.com'
    Subject: (forte-users)
    Hi there
    We have this situation
    We are calling a Service Object (in the server partition) from ourclient
    partition.This service object calls a method which calls a DLLregistered
    on our server (VB code) . This VB code access a database on anotherserver
    .(DSN set up on our server ).The database is sql server .
    We are having the problem where for about 3 hours in the morning , the
    system works perfectly. We then get a segmentation violation on this
    partition . When we run interpreted we can see that this is an OLEinvoked
    exception. The partition does not always show as offline in econsole
    and
    because it does not , we cannot 'online' another . We cannot take the
    entire app down as everything hangs . Eventually our technical depthas
    to
    down the server
    We set up a mini-app looping through and calling the DLL to simulate
    the
    problem . It worked fine. When we put another asynchronous task in the
    method to call the service object , it erred quite soon. We thencreate
    an
    attribute of type mutex and locked using that. The mini-app worked.
    However our app in development eventually hanged (without the
    partition
    coming though) .
    The service Object is an environment visible service object in asingle
    (non-replicated partition) . It has a dialog duration = session .
    In the project is
    ACB : ACBObject
    ACBObject : CDispatch (shared = disallowed , distributed =
    disallowed, transactional = disallowed, monitored = allowed)
    ACBValidator : Object (shared = allowed , distributed =allowed,
    transactional = disallowed, monitored = disallowed)
    ACBVaidatorSO : ACBValidator
    In this method we have this code to call the DLL
    self.ACBAccount = new;
    self.ACBAccount.CreateUsingCLSID(classID='{2EFD3084-7B05-11D3-857F-00105A4
    8CEA0}');
    pErrorMessage = new;
    acbaccount.BankCode = pBankCode.value;
    acbaccount.BranchCode = pBranchCode.value;
    at : VariantI2 = new;
    at.Value = pAccountType.Value;
    acbaccount.AccountType = at.Value;
    acbaccount.AccountNo = pAccountNo.value;
    begin
    acbaccount.Connect();
    exception
    when e : GenericException do
    ex : GenericException = new;
    ex.SetWithParams(severity = SP_ER_ERROR,
    message = 'There was an error connecting to the database');
    raise ex;
    end;
    begin
    err : i2 = acbaccount.ValidateAccount();
    if err != 0 then
    pErrorMessage.SetValue(acbaccount.ErrDescriptionStr(iErrorCode= err));
    acbaccount.Disconnect();
    return false;
    else
    pErrorMessage.SetValue('The account is
    valid!!');
    acbaccount.Disconnect();
    self.ACBAccount = NIL ;
    return true;
    end if;
    exception
    when e : GenericException do
    acbaccount.Disconnect();
    ex : GenericException = new;
    ex.SetWithParams(severity = SP_ER_ERROR,
    message = 'There was an error Validating the account');
    Task.ErrorMgr.AddError(ex);
    task.errormgr.ShowErrors();
    raise e;
    end;
    exception
    when e : GenericException do
    acbaccount.Disconnect();
    Task.ErrorMgr.ShowErrors();
    raise e;
    If anybody has any suggestions , they would be most welcome
    Thanks very much
    Cheers
    Jenni Els************************************************************************Th
    is e-mail is intended for the use of the individual or entity named above
    and may contain information that is confidential and privileged. If you
    are not the intended recipient, you are hereby notified that any
    dissemination, distribution or copying of this e-mail is strictly
    prohibited. If you have received this e-mail in error, please notify us
    immediately at helpdesklumley.com.au and destroy the original message.
    While this mail and any attachments have been scanned for common computer
    viruses and found to be virus free, we recommend you also perform your own
    virus checking processes before opening any attachments.
    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
    WARNING:
    Any unauthorised use or interception of this email is illegal. If this email
    is not intended for you, you may not copy, distribute nor disclose the
    contents to anyone. Save for bona fide company matters, the BoE Group does
    not accept any responsibility for the opinions expressed in this email.
    For further details please see: http://www.nbs.co.za/emaildisclaim.htm

  • RE: (forte-users) appdist copy from VMS to NT question...

    Well, there are some graphic FTP clients for windows that allow
    you to get files from FTP-servers using simple drag and drop.
    Most of them even support the option of selecting a directory
    and dragging it, with all its subdirectories, to your local drive
    with a single mouse action.
    The only problem might be with binary vs. text files. The appdist
    directory has both filetypes. Getting text files as if they were
    binary files may cause problems. Getting binary files as if they
    were text certainly will cause problems. So, either get the
    whole tree binary and hope for the best. Or get each file indi-
    vidually and set the correct bin or asc setting. Or use a tool
    that is smart enough to see if a file is binary or text and hope
    it doesn't make any mistakes.
    Pascal Rottier
    STP - MSS Support & Coordination Group
    Philip Morris Europe
    e-mail: [email protected]
    Phone: +49 (0)89-72472530
    +++++++++++++++++++++++++++++++++++
    Origin IT-services
    Desktop Business Solutions Rotterdam
    e-mail: [email protected]
    Phone: +31 (0)10-2428100
    +++++++++++++++++++++++++++++++++++
    Don't meddle in the affairs of dragons
    'cause you're crunchy and taste good with ketchup
    -----Original Message-----
    From: Haben, Dirk [SMTP:[email protected]]
    Sent: Wednesday, December 08, 1999 6:32 AM
    To: 'Soapbox Forte Users'
    Subject: (forte-users) appdist copy from VMS to NT question ...
    G'day Folxs
    Does anyone here have a simple way to copy a whole appdist tree for myapp1
    say from VMS to NT? I have created a new environment on a NT box and want
    to
    copy down all our application distributions.
    eg:
    On OpenVMS machine vmsbox1 the directory tree and files
    vmsbox1::forte_root:[appdist.aenv_myapp_cl3...]*.*;
    should go to NT machine ntbox1
    [ntbox1] d:\temp\myapp\cl3\...
    Even just to d:\temp\aenv_myapp_cl3\... will do.
    ftp doesn't seem to do the trick here. Of cause I could write some routine
    to put/get file by file - but before I do all that I thought I ask around
    if
    it's already been done.
    Thanks,
    Dirk
    PS: Needless to say we still develop and makedist on VMS - for now (see
    Bulletin 388)!
    PPS: No I haven't forgotten about [appdist.aenv.myapp1]*.ace
    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]

    Well, there are some graphic FTP clients for windows that allow
    you to get files from FTP-servers using simple drag and drop.
    Most of them even support the option of selecting a directory
    and dragging it, with all its subdirectories, to your local drive
    with a single mouse action.
    The only problem might be with binary vs. text files. The appdist
    directory has both filetypes. Getting text files as if they were
    binary files may cause problems. Getting binary files as if they
    were text certainly will cause problems. So, either get the
    whole tree binary and hope for the best. Or get each file indi-
    vidually and set the correct bin or asc setting. Or use a tool
    that is smart enough to see if a file is binary or text and hope
    it doesn't make any mistakes.
    Pascal Rottier
    STP - MSS Support & Coordination Group
    Philip Morris Europe
    e-mail: [email protected]
    Phone: +49 (0)89-72472530
    +++++++++++++++++++++++++++++++++++
    Origin IT-services
    Desktop Business Solutions Rotterdam
    e-mail: [email protected]
    Phone: +31 (0)10-2428100
    +++++++++++++++++++++++++++++++++++
    Don't meddle in the affairs of dragons
    'cause you're crunchy and taste good with ketchup
    -----Original Message-----
    From: Haben, Dirk [SMTP:[email protected]]
    Sent: Wednesday, December 08, 1999 6:32 AM
    To: 'Soapbox Forte Users'
    Subject: (forte-users) appdist copy from VMS to NT question ...
    G'day Folxs
    Does anyone here have a simple way to copy a whole appdist tree for myapp1
    say from VMS to NT? I have created a new environment on a NT box and want
    to
    copy down all our application distributions.
    eg:
    On OpenVMS machine vmsbox1 the directory tree and files
    vmsbox1::forte_root:[appdist.aenv_myapp_cl3...]*.*;
    should go to NT machine ntbox1
    [ntbox1] d:\temp\myapp\cl3\...
    Even just to d:\temp\aenv_myapp_cl3\... will do.
    ftp doesn't seem to do the trick here. Of cause I could write some routine
    to put/get file by file - but before I do all that I thought I ask around
    if
    it's already been done.
    Thanks,
    Dirk
    PS: Needless to say we still develop and makedist on VMS - for now (see
    Bulletin 388)!
    PPS: No I haven't forgotten about [appdist.aenv.myapp1]*.ace
    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) Named Anchored Obj-EnvironmentFailover

    I did some playing around with this stuff as well. I can tell you a few
    things.
    1) The search path option of connected environments only works for SO's, not
    for named anchors.
    2) When EnvA creates a directory "/glob", which contains object "obj1", then
    EnvA owns directory "/glob". Even after restarting environments. If EnvB
    tries to add a subdirectory to "/glob" or inserts its own objects into this
    path, then the situation becomes unstable. It doesn't immediately produce an
    error, but things go wrong anyway. Is this a bug or expected behaviour? I
    don't know. I just learned not to do this. Every environment must place it's
    named anchors in it's own tree. Directories can't be shared.
    3) I think the relative name "glob/obj1" should work, but only if you set
    the ObjectLocationMgr to start looking at the root. Default, it will start
    looking in it's own environment basepath. But I don't have any experience
    with this.
    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: Master Programmer [mailto:masterprghotmail.com]
    Sent: Monday, January 08, 2001 11:13 PM
    To: forte-userslists.xpedior.com
    Subject: (forte-users) Named Anchored Obj-Environment Failover
    Hi to all,
    We connect from EnvA to EnvB giving the user directory parameter as / and
    set the Environment Search Path
    as EnvA:EnvB. From both environments we start and register
    '/glob/obj1' named anchored objects with the same name.
    From a client we connect to EnvA and bind to'/glob/obj1' when we shutdown EnvA partition it fails-over to
    EnvB. And then we restart EnvA partition. We restart/rebind the client and
    try to use object. We see that it is using the EnvB object.
    Although we started the primary environment object again.
    It is not using the search path. Once we shutdown secondary environment
    it starts using primary environment object.
    When we try to use relative path when we are binding the object
    First parameter ('glob/obj1') No first slash. Trying 3rd parameter
    for bind function or just using environment search path, Is is not able to
    find the object. From nsls command I figured out that
    under the root directory
    /forte/UUID of ENVA/node
    /site
    /UUID of ENVB
    /glob/obj1
    names are available. When we use relative path (without slash)
    is it trying to find /glob/obj1 under the /forte/UUID of ENVA
    but we are registering the name under the root.
    What is the reason of this odd behaviour or is this a bug?
    Any answer will be appreciated,
    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 did some playing around with this stuff as well. I can tell you a few
    things.
    1) The search path option of connected environments only works for SO's, not
    for named anchors.
    2) When EnvA creates a directory "/glob", which contains object "obj1", then
    EnvA owns directory "/glob". Even after restarting environments. If EnvB
    tries to add a subdirectory to "/glob" or inserts its own objects into this
    path, then the situation becomes unstable. It doesn't immediately produce an
    error, but things go wrong anyway. Is this a bug or expected behaviour? I
    don't know. I just learned not to do this. Every environment must place it's
    named anchors in it's own tree. Directories can't be shared.
    3) I think the relative name "glob/obj1" should work, but only if you set
    the ObjectLocationMgr to start looking at the root. Default, it will start
    looking in it's own environment basepath. But I don't have any experience
    with this.
    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: Master Programmer [mailto:masterprghotmail.com]
    Sent: Monday, January 08, 2001 11:13 PM
    To: forte-userslists.xpedior.com
    Subject: (forte-users) Named Anchored Obj-Environment Failover
    Hi to all,
    We connect from EnvA to EnvB giving the user directory parameter as / and
    set the Environment Search Path
    as EnvA:EnvB. From both environments we start and register
    '/glob/obj1' named anchored objects with the same name.
    From a client we connect to EnvA and bind to'/glob/obj1' when we shutdown EnvA partition it fails-over to
    EnvB. And then we restart EnvA partition. We restart/rebind the client and
    try to use object. We see that it is using the EnvB object.
    Although we started the primary environment object again.
    It is not using the search path. Once we shutdown secondary environment
    it starts using primary environment object.
    When we try to use relative path when we are binding the object
    First parameter ('glob/obj1') No first slash. Trying 3rd parameter
    for bind function or just using environment search path, Is is not able to
    find the object. From nsls command I figured out that
    under the root directory
    /forte/UUID of ENVA/node
    /site
    /UUID of ENVB
    /glob/obj1
    names are available. When we use relative path (without slash)
    is it trying to find /glob/obj1 under the /forte/UUID of ENVA
    but we are registering the name under the root.
    What is the reason of this odd behaviour or is this a bug?
    Any answer will be appreciated,
    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