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é 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

Similar Messages

  • 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) 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) 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) 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) 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

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

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

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

  • RE: (forte-users) 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

  • Communication problem between NetBeans and Tomcat

    hi!
    i got a quite mysterious problem. here is what happens:
    - i start NetBeans 5.5.1 (the first time)
    - i want to debug my JSF-Project, the Debugger starts
    - After a few seconds the debugger waits for tomcat (it sais: "Waiting for Tomcat...") and tomcat starts
    - Again after a few seconds the tomcat-debugger-output sais "Tomcat startet in 3333 ms".
    okay.
    when i enter http://localhost:8084/ in my browser i get the tomcat homepage, so the server has definitely started! But nothing happens in NetBeans and nothing happens with my project....
    In the lower-right corner i see this blue working-bar that sais "deploying project" but nothing happens. The Project-Debugger-Output still sais "Waiting for Tomcat..." but nothing happens...
    And after something around 3 minutes (i guess it's a timeout) i get the error "Starting of Tomcat failed." But is HAS started, i can login to the Administration-Area in my browser!
    so i guess there is a communication problem between netbeans an tomcat. Netbeans waits for a message from tomcat but tomcat doesn't send it..or netbeans doesn't understand it.
    But the story goes on:
    When i press the debug-button a second time it takes only a few seconds till i get the message: "Tomcat server port 8084 already in use". OF COURSE! Because Tomcat has already startet and can't be stoped by NetBeans.
    i'm trying to solve this problem for 4 days now, so i would be very happy if anyone has an idea where to start/continue the search...
    thanks,
    flo.
    some system-info:
    - windows vista business 32-bit
    - no firewall is running
    - AntiVir Personal Edition IS running
    - Yahoo Widgets Engine IS running
    - no other software is running
    and finally the tomcat-log:
    Using CATALINA_BASE: C:\Users\Administrator\.netbeans\5.5.1\apache-tomcat-5.5.17_base
    Using CATALINA_HOME: C:\Program Files\NetBeans\enterprise3\apache-tomcat-5.5.17
    Using CATALINA_TMPDIR: C:\Users\Administrator\.netbeans\5.5.1\apache-tomcat-5.5.17_base\temp
    Using JRE_HOME: C:\Program Files\Java\jdk1.5.0_12
    Listening for transport dt_shmem at address: tomcat_shared_memory_id
    21.09.2007 18:27:50 org.apache.catalina.core.AprLifecycleListener lifecycleEvent
    INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:\Program Files\Java\jdk1.5.0_12\bin;.;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\ThinkPad\ConnectUtilities;C:\Program Files\Common Files\Teleca Shared;C:\Program Files\Common Files\Adobe\AGL;C:\Program Files\MySQL\MySQL Server 5.0\bin;C:\Program Files\cvsnt;
    21.09.2007 18:27:50 org.apache.coyote.http11.Http11BaseProtocol init
    INFO: Initializing Coyote HTTP/1.1 on http-8084
    21.09.2007 18:27:50 org.apache.catalina.startup.Catalina load
    INFO: Initialization processed in 1862 ms
    21.09.2007 18:27:50 org.apache.catalina.core.StandardService start
    INFO: Starting service Catalina
    21.09.2007 18:27:50 org.apache.catalina.core.StandardEngine start
    INFO: Starting Servlet Engine: Apache Tomcat/5.5.17
    21.09.2007 18:27:50 org.apache.catalina.core.StandardHost start
    INFO: XML validation disabled
    21.09.2007 18:27:53 org.apache.coyote.http11.Http11BaseProtocol start
    INFO: Starting Coyote HTTP/1.1 on http-8084
    21.09.2007 18:27:54 org.apache.jk.common.ChannelSocket init
    INFO: JK: ajp13 listening on /0.0.0.0:8009
    21.09.2007 18:27:54 org.apache.jk.server.JkMain start
    INFO: Jk running ID=0 time=0/31 config=null
    21.09.2007 18:27:54 org.apache.catalina.storeconfig.StoreLoader load
    INFO: Find registry server-registry.xml at classpath resource
    21.09.2007 18:27:54 org.apache.catalina.startup.Catalina start
    INFO: Server startup in 3626 ms

    As i wrote before, the same problem occured for me. I have found a solution which is : Go to tools menu and then select options . In the proxy info, select No Proxy.
    I hope this help you

  • 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) 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) Forte ADE

    In addition to this confusion, I'd like to see some statement by Forte to
    indicate
    WHEN the next Forte R4 is scheduled (before the Sun era is was said to be
    Summer 2000) and
    WHAT exactly it will contain (major headings will do).
    With the cancellation of the Forte Forum event doubt and uncertainty are
    spreading in the
    Forte communities that I talk with and no one seems to counterbalance these
    doubts with an
    official statement. How serious does Sun take TOOL Forte for the coming few
    years? Release
    of Fusion V2 seems to say "serious". The deafning silence with regard to R4
    indicates the
    opposite. And the users are divided (as always).
    Theo de Klerk
    Architecture & Application Integration
    Professional Services
    Compaq Computer Corp. - the Netherlands
    -----Original Message-----
    From: Rottier, Pascal [mailto:Rottier.Pascalpmintl.ch]
    Sent: Tuesday, 18 April, 2000 17:49
    To: 'kamranaminyahoo.com'
    Subject: (forte-users) Forte ADE
    A long, long time ago
    In a galaxy far away....
    I saw a demonstration of Forte's new Application Development
    Environment,
    which was more userfriendly than the current one. It also looked more
    similar to the interface of the other development tools out
    there, with a
    tree structure and capabilities to browse through the
    inheritance tree, and
    not opening a new window for every project, class and method that is
    accessed.
    This new interface was supposed to be included in Forte 4, which would
    combine TOOL and Java and would be released soon.
    Since then, we've seen SynerJ and now FJEE, but Forte 4 is still not
    released. And when it will be released, it still won't
    support TOOL and Java
    simultaneously. That's OK. I understand that.
    But now I've heard that this improved ADE won't even be
    included in Forte 4.
    Is this true? And if so, why?
    Pascal
    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

    You may be interested in the following which comes from a statement of direction
    recently issued by Sun.
    Product Context
    + Fort&eacute; 4GL is an award-winning, proven product with many unique advantages for
    building
    enterprise business systems that are distributed, that involve the integration
    of existing
    business systems as well as new functionality, and that target heterogeneous
    runtime
    environments.
    + Fort&eacute; 4GL is recognized by Gartner Group as the most successful Enterprise
    Application
    Development Tool.
    + Forte 4GL has a substantial customer base that has been successful with the
    product and that
    looks forward to using Fort&eacute; 4GL for new applications.
    + The Sun Microsystems, Inc. (SMI) development tools group (formerly Fort&eacute;
    Software, Inc.)
    has a strong internal commitment to Fort&eacute; 4GL. Fort&eacute; Fusion is written with, and
    is currently
    being enhanced with Fort&eacute; 4GL.
    + SMI has retained the Fort&eacute; field sales organization as an independent unit
    whose primary
    product offerings are Fort&eacute; 4GL and Fort&eacute; Fusion. Continued volume sales of
    Fort&eacute; 4GL
    remain the foundation of our business plan.
    Product Future
    + We intend to actively enhance and promote Fort&eacute; 4GL for the indefinite
    future.
    + We believe Fort&eacute; 4GL will flourish in the long term, especially if we are
    able to harness the
    considerable selling power of the entire SMI field sales organization. To make
    the product
    more attractive and easier to sell, we will continue to make the product more
    modular and
    easier to integrate with heterogeneous software environments.
    + We believe that the best opportunity for attracting new customers is to
    leverage the ability of
    Fort&eacute; 4GL to easily build powerful shared business services (server components)
    that can be
    accessed by non-Fort&eacute; clients (e.g., browsers, Java clients) and that can easily
    integrate with
    new and existing business systems.
    + We believe that Fort&eacute; 4GL?s continued success is enhanced by continuing to
    issue small and
    frequent product releases. Our target is two such releases per year.
    + There is a great potential for our three product lines (Fort&eacute; 4GL, Fort&eacute;
    Fusion, and Fort&eacute; for
    Java) to complement and reinforce each other. Interoperability among the three
    product lines
    is seen as a critical success factor for Fort&eacute; 4GL.
    Forte 4GL Statement of Direction Page 2
    Sun Microsystems, Inc Proprietary and Confidential
    Product Priorities
    1. Interoperability with third party software components
    + External (non-4GL) client support (e.g., browsers, Java clients)
    + External server integration (e.g., messaging, component support, data
    exchange)
    2. Enhanced productivity
    + Increased automation (i.e., less coding)
    + Support for platform updates (e.g., new versions of OS, DBMS)
    3. TOOL code to Java code migration
    4. Unified developer look and feel with other Forte development products
    5. Common repository
    Short Term Product Plans
    Mid-year release
    + New features available as ?preview? per the standard Forte maintenance
    release procedures
    + Tentatively labeled ?release 3.5? and distributed as a free product
    enhancement for
    customers under maintenance
    + Scheduled for Summer 2000
    + Defining features
    + Introspection (reflection) ? the ability for an object to describe itself at
    runtime
    + Improved integration with applications developed using Fort&eacute;-for-Java
    Community
    Edition
    + Platform support improvements to track important operating system and
    database
    vendor activity
    + Target features
    + Display system enhancements (e.g., Motif 2 support, line arrowheads, window
    refresh control, editable outline fields)
    + Dynamic library loading
    + Improved CORBA/IIOP support
    + Improved XML and XSLT class support
    + JMQ support
    New year release
    + New features available as ?preview? per the standard Forte maintenance
    release procedures
    + Tentatively labeled ?release 3.6? and distributed as a free product
    enhancement for
    customers under maintenance
    + Scheduled for year end 2000
    + Defining features
    + Any Release 3.5 target features that were not included in 3.5
    + Generation of EJB interfaces for R3 service objects
    + Platform support improvements to track important operating system and
    database
    vendor activity
    + Target features
    + COBOL record handling as part of the OS390 transaction adaptor
    + Improved runtime security
    + Interface classes for access to Netscape Server 4.0 and possibly other web
    servers
    Long Term Product Plans
    + To be determined by customer and market feedback.
    + A major criterion for new functionality will be enhancing the revenue
    generating ability of
    the product, thereby fostering its long-term health in the marketplace.
    + Substantial emphasis will be placed on creating new capabilities that enhance
    the
    attractiveness of the product for new users.
    + The contents of Release 3.7 (or whatever it will be called) will be
    solidified just after release
    3.5 ships. Subsequent planning visibility will be two forward releases.
    "Klerk, Theo de" <Theo.de.Klerkcompaq.com> on 04/18/2000 12:27:36 PM
    To: "'Rottier, Pascal'" <Rottier.Pascalpmintl.ch>,
    "'kamranaminyahoo.com'" <kamranaminyahoo.com>
    cc: (bcc: Charlie Shell/Bsg/MetLife/US)
    Subject: RE: (forte-users) Forte ADE

  • Re: (forte-users) HTTP request through proxy server

    Daniel -
    No, it does not. ;)
    How do you say to HTTPRequest to go through proxy?
    Thanks,
    Taras
    Daniel Nguyen wrote:
    >
    Hi,
    It works very well. I have experienced this model for a distant Forte client
    calling a Forte Server service Object for instance without any environment
    and without TCP access (passing through firewall for instance).
    It has also worked very well to make an injectot to improve Web Enterprise
    and IIS using the SendRequest from HTTPAccess.
    Hope this helps,
    Daniel Nguyen
    Freelance Forte Consultant
    http://perso.club-internet.fr/dnguyen/
    Taras Katkov a &eacute;crit:
    HTTP request through proxy server using forte HTTP library?
    Any experience?
    Thanks,
    Taras
    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

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

  • RE: (forte-users) memory management

    Brenda,
    When a partition starts, it reserves the MinimumAllocation. Within this
    memory space, objects are created and more and more of this memory is
    actually used. When objects are no longer referenced, they remain in memory
    and the space they occupy remains unusable.
    When the amount of free memory drops below a certain point, the garbage
    collector kicks in, which will free the space occopied by all objects that
    are no longer referenced.
    If garbage collecting can't free enough memory to hold the additional data
    loaded into memory, then the partition will request another block of memory,
    equal to the IncrementAllocation size. The partition will try to stay within
    this new boundary by garbage collecting everytime the available part of this
    memory drops below a certain point. If the partition can't free enough
    memory, it will again request another block of memory.
    This process repeats itself until the partition reaches MaximumAllocation.
    If that amount of memory still isn't enough, then the partition crashes.
    Instrument ActivePages shows the memory reserved by the partition.
    AllocatedPages shows the part of that memory actually used.
    AvailablePages shows the part ot that memory which is free.
    Note that once memory is requested from the operating system, it's never
    released again. Within this memory owned by the partition, the part actually
    used will always be smaller. But this part will increase steadily, until the
    garbage collecter is started and a part of it is freed again.
    There are some settings that determine when the garbage collector is
    started, but I'm not sure which ones they are.
    The garbage collector can be started from TOOL using
    "task.Part.OperatingSystem.RecoverMemory()", but I'm not sure if that will
    always actually start the garbage collector.
    If you track AllocatedPages of a partition, it's always growing, even if the
    partition isn't doing anything. I don't know why.
    If you add AllocatedPages and AvailablePages, you shoud get the value of
    ActivePages, but you won't. You always get a lower number and sometimes even
    considerably lower. I don't know why.
    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: Brenda Cumming [mailto:brenda_cummingtranscanada.com]
    Sent: Tuesday, January 23, 2001 6:40 PM
    To: Forte User group
    Subject: (forte-users) memory management
    I have been reading up on memory management and the
    OperatingSystemAgent, and could use some clarification...
    When a partition is brought online, is the ActivePages value set to the
    MinimumAllocation value, and expanded as required?
    And what is the difference between the ExpandAtPercent and
    ContractAtPercent functions?
    Thanks in advance,
    Brenda
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

    The Forte runtime is millions of lines of compiled C++ code, packaged into
    shared libraries (DLL's) which are a number of megabytes in size. The
    space is taken by the application binary, plus the loaded DLL's, plus
    whatever the current size of garbage collected memory is.
    Forte allocates a garbage-collected heap that must be bigger than the size
    of the allocated objects. So if you start with an 8MB heap, you will always
    have at least 8MB allocated, no matter what objects you actually
    instantiate. See "Memory Issues" in the Forte System Management Guide.
    -tdc
    Tom Childers
    iPlanet Integration Server Engineering
    At 10:37 PM 6/11/01 +0200, [email protected] wrote:
    Hi all,
    I was wondering if anyone had any experience in deploying clients on NT
    concerning
    the memory use of these client apps.
    What is the influence of the various compiler options (optimum
    performance, memory use etc)?
    We seem to see a lot of the memory is taken by the Forte client apps (seen
    in the Task Manager
    of NT) in respect to the other native Window apps. For example an
    executable of approx 4Mb takes up to
    15Mb of memory. When I look at the objects retained in memory after
    garbage collection, these are about
    2Mb. Where do the other Mb's come from?

Maybe you are looking for

  • How can I check for a Virus?

    Hello, I tried to use my internet banking the other day on my MacBook Pro but for some reason my password wasn't working. I phoned my bank and they informed me that it had been blocked due to a security threat they'd picked up. They suspect there is

  • Should have thought of this before I bought new mac!!

    Have just taken delivery of a beautiful new mac but hadn't given any thought to the fact that all my music is on itunes on the old mac. How do I get my library,purchases ,playlists etc transferred across ? Thanks for any help

  • Ship to party name  in Sales Order

    Hello all. I created a sales order. I saw the technical information of a Ship-party in a sales order. It is a structure KUAGV. Field is TXTPA. I want to know  the real database table this information came from. Your help will be appreciated. Shirish

  • Ports won't open after forwarding

    I'm trying to set up my AEBS so I can access my network remotely. However, even after forwarding the ports, none of them are showing as open. So far, I've Mapped the ports (3389 for Windows RDP, 21 for FTP) Reverted my Firmware from 7.6.3 to 7.6.1 Al

  • What is the error for sw1 sw2=6f 00

    Hello there, I got a sw1 sw2 = 6f 00 What is the likely error i got. i got this error when i am trying to select my applet Thanx.