Re: (forte-users) Hi - Query on XML Import document -Hang

Double check that your XML is valid. I've seen
importDocument hang when I'm missing an end tag.
I don't think it's a validating parser.
Of course, there's no documentation, so.... :)
Chris
--- "Saravanan, Lakshmi N." <lnarayanoxhp.com> wrote:
Hi guys,
I am trying to import an XML document from a
Memory stream object. I
got the example
from this group ( It was very helpful ).
Sample Code :
l_MemStr : MemoryStream = new;
l_MemStr.Open( SP_AM_READ_WRITE );
l_MemStr.WriteText( source = l_XMLData );
l_MemStr.Seek( position=0 );
-- Create a Document object from the memory stream
myDoc : Document = new;
myDoc.importdocument( l_MemStr );
After this line nothing seems to happen.. the
partition just hangs... keeps
the CPU busy.
If i deploy the same in a NT or on a IBM box it
works fine. The problem is
with the Sequent box..( i guess ).
Did any of you guys face a problem like this...
Please let us know..
I would really appreciate it.
Thanks
Laks
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/

Well, Forte have agreed to release a patch for the XML bug on DG Unix with
Forte Version 3.0.M.2. I've attached a related mail with this.
- Charu.
-----Original Message-----
From: Epari, Madhusudhan [mailto:meparioxhp.com]
Sent: Friday, September 01, 2000 7:59 AM
To: 'Amin, Kamran'
Cc: 'forte-userslists.xpedior.com'
Subject: RE: (forte-users) Hi - Query on XML Import document - Hang
I did check the xml by opening it in IE 5.0 for it's well-formedness. Still
it's failing on sequent box.
-----Original Message-----
From: Amin, Kamran [mailto:kamran.aminlendware.com]
Sent: Friday, September 01, 2000 10:55 AM
To: 'Epari, Madhusudhan'
Subject: RE: (forte-users) Hi - Query on XML Import document - Hang
Well not really. One way to check if the xml is valid is to open it in IE
5.0. If its well formed then it will show up otherwise it will give you an
error. Also the document object is not the best code that came out of Forte
and has errors, so this might be a bug you will have to report. And they
are not giving any new patches until 3.5 comes out in 2 months.
ka
-----Original Message-----
From: Epari, Madhusudhan [mailto:meparioxhp.com]
Sent: Friday, September 01, 2000 10:52 AM
To: 'Christopher Fury'
Cc: 'forte-userslists.xpedior.com'
Subject: RE: (forte-users) Hi - Query on XML Import document - Hang
If the XML is invalid it should fail on all boxes. This should be a sequent
specific problem.
Madhu
-----Original Message-----
From: Christopher Fury [mailto:cfuryyahoo.com]
Sent: Friday, September 01, 2000 9:37 AM
To: 'forte-userslists.xpedior.com'
Subject: Re: (forte-users) Hi - Query on XML Import document - Hang
Double check that your XML is valid. I've seen
importDocument hang when I'm missing an end tag.
I don't think it's a validating parser.
Of course, there's no documentation, so.... :)
Chris
--- "Saravanan, Lakshmi N." <lnarayanoxhp.com> wrote:
Hi guys,
I am trying to import an XML document from a
Memory stream object. I
got the example
from this group ( It was very helpful ).
Sample Code :
l_MemStr : MemoryStream = new;
l_MemStr.Open( SP_AM_READ_WRITE );
l_MemStr.WriteText( source = l_XMLData );
l_MemStr.Seek( position=0 );
-- Create a Document object from the memory stream
myDoc : Document = new;
myDoc.importdocument( l_MemStr );
After this line nothing seems to happen.. the
partition just hangs... keeps
the CPU busy.
If i deploy the same in a NT or on a IBM box it
works fine. The problem is
with the Sequent box..( i guess ).
Did any of you guys face a problem like this...
Please let us know..
I would really appreciate it.
Thanks
Laks
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. 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
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Similar Messages

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

    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) XML Parser - Reading an XML document intothe Document

    Hi Laks
    Here is an example of converting a XML doc to a DOM object.
    The method is ParseXML(pXMLString:TextData, pListType:CSAListInterface).
    Hope this helps.
    Argyris Simakis
    Corporate Services Applications ITB
    Sydney AUSTRALIA
    -----Original Message-----
    From: Narayanan, Lakshmi [mailto:lnarayanoxhp.com]
    Sent: Thursday, April 06, 2000 8:31 AM
    To: 'kamranaminyahoo.com'
    Subject: (forte-users) XML Parser - Reading an XML document into the
    Document Object
    Importance: High
    Hi guys,
    I have been trying to read an XML file and feed it into the XMLParser.
    I have read about the DOM API, and i can work with the DOM API in java
    scripts. How
    will i play with it in TOOL implementation of DOM API. Can anyone guide me
    in this
    process.
    Thanks for your help.
    Laks
    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 Laks
    Here is an example of converting a XML doc to a DOM object.
    The method is ParseXML(pXMLString:TextData, pListType:CSAListInterface).
    Hope this helps.
    Argyris Simakis
    Corporate Services Applications ITB
    Sydney AUSTRALIA
    -----Original Message-----
    From: Narayanan, Lakshmi [mailto:lnarayanoxhp.com]
    Sent: Thursday, April 06, 2000 8:31 AM
    To: 'kamranaminyahoo.com'
    Subject: (forte-users) XML Parser - Reading an XML document into the
    Document Object
    Importance: High
    Hi guys,
    I have been trying to read an XML file and feed it into the XMLParser.
    I have read about the DOM API, and i can work with the DOM API in java
    scripts. How
    will i play with it in TOOL implementation of DOM API. Can anyone guide me
    in this
    process.
    Thanks for your help.
    Laks
    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) XML Parser - Reading an XML document intothe D ocumen

    Hi Simakis,
    Your attachments explained the exact start i was looking for.
    Thanks a lot for sharing.
    Thanks
    Laks
    -----Original Message-----
    From: Simakis, Argyris [mailto:Argyris.Simakisdet.nsw.edu.au]
    Sent: Thursday, April 06, 2000 12:35 AM
    To: 'Narayanan, Lakshmi'
    Cc: 'kamranaminyahoo.com'
    Subject: RE: (forte-users) XML Parser - Reading an XML document into the
    D ocument Object
    Hi Laks
    Here is an example of converting a XML doc to a DOM object.
    The method is ParseXML(pXMLString:TextData, pListType:CSAListInterface).
    Hope this helps.
    Argyris Simakis
    Corporate Services Applications ITB
    Sydney AUSTRALIA
    -----Original Message-----
    From: Narayanan, Lakshmi [mailto:lnarayanoxhp.com]
    Sent: Thursday, April 06, 2000 8:31 AM
    To: 'kamranaminyahoo.com'
    Subject: (forte-users) XML Parser - Reading an XML document into the
    Document Object
    Importance: High
    Hi guys,
    I have been trying to read an XML file and feed it into the XMLParser.
    I have read about the DOM API, and i can work with the DOM API in java
    scripts. How
    will i play with it in TOOL implementation of DOM API. Can anyone guide me
    in this
    process.
    Thanks for your help.
    Laks
    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 Simakis,
    Your attachments explained the exact start i was looking for.
    Thanks a lot for sharing.
    Thanks
    Laks
    -----Original Message-----
    From: Simakis, Argyris [mailto:Argyris.Simakisdet.nsw.edu.au]
    Sent: Thursday, April 06, 2000 12:35 AM
    To: 'Narayanan, Lakshmi'
    Cc: 'kamranaminyahoo.com'
    Subject: RE: (forte-users) XML Parser - Reading an XML document into the
    D ocument Object
    Hi Laks
    Here is an example of converting a XML doc to a DOM object.
    The method is ParseXML(pXMLString:TextData, pListType:CSAListInterface).
    Hope this helps.
    Argyris Simakis
    Corporate Services Applications ITB
    Sydney AUSTRALIA
    -----Original Message-----
    From: Narayanan, Lakshmi [mailto:lnarayanoxhp.com]
    Sent: Thursday, April 06, 2000 8:31 AM
    To: 'kamranaminyahoo.com'
    Subject: (forte-users) XML Parser - Reading an XML document into the
    Document Object
    Importance: High
    Hi guys,
    I have been trying to read an XML file and feed it into the XMLParser.
    I have read about the DOM API, and i can work with the DOM API in java
    scripts. How
    will i play with it in TOOL implementation of DOM API. Can anyone guide me
    in this
    process.
    Thanks for your help.
    Laks
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

  • I have 100 groups in planning for those 100 groups i want to build roles like interactive,view user,planner etc.for those how to change in export -import folder .xml file  in that edit  how  to change user roles in that xml it will generate automatic id.h

    I have 100 groups in planning for those 100 groups i want to build roles like interactive,view user,planner etc.for those how to change in export -import folder .xml file  in that edit  how  to change user roles in that xml it will generate automatic id.how to do that in xml file ?

    Thanks john for you are reply.
    I had tried what you sad.I open shared service in that foundation project i had export shared service.after that in import-export file.In that role.csv,user.csv,group.csv.Like this file have.When i open user file added some users after i trying save in excel it shown messgse
    I click yes and save the .csv file and import from share servie. i got error like this
    am i doing right way john.or explain clearly

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

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

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

  • RE: (forte-users) XML and XSL in Forte

     

    We too (at Viking Freight) would also be very interested to see if anybody
    has produced such a useful series of classes...
    Frank Lees, Developer
    -----Original Message-----
    From: Amin, Kamran [mailto:kamran.aminframeworkinc.com]
    Sent: Wednesday, January 19, 2000 12:11 PM
    To: 'Forte User'
    Subject: (forte-users) XML and XSL in Forte
    Has anybody integrated an XSL parser with Forte. I know Forte provides us
    with an XML parser but that does not help with parsing XSL. There a lot of
    parsers written in JAVA but that will not integrate well with Forte. We
    need something that will be easy to integrate with Forte. This parser will
    take our XML and XSL to give us a result set. If anybody can comment on the
    subject or share some information I would appreciate it.
    thanks in advance.
    ka
    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: forte-users-requestlists.sageit.com

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

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

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

  • New user, XML Import

    Hi
    This question is about how to view contents of XML files I import into InDesign and whether that might help preserve features of original documents created in other programs (like OpenOffice or  Microsoft Word).
    When I place rtf copies of text / tables / graphics files which I created other programs (like Microsoft Word or Open Office)  into InDesign, I am losing important features.  For example, with the Table of Contents, fonts, tables, etc depart significantly from the original document.
    I am wondering if I can do better by saving the original doc as an XML and using File > Import XML to bring it into InDesign.  So far when I have tried it the "import" appears to run to completion, but the InDesign document appears empty.   Do you know how to display what was imported?  I have the feeling there is a simple solution, like I need to creat a text frame or something to view it.
    Thanks,
    -las_123456

    las_123456 wrote:
    Thank you for your posts.  2 of them requested more information about the features I am losing by saving an OpenOffice document in rtf or doc format and placing that into an InDesign document.  With this approach th
    First I need to point out that the OpenOffice document I want to convert to InDesign is more than 400 pages and consists of multiple chapters each with mostly text, tables, and a few figures.  The whole thing has a table of contents and an index.  Do you think I should be working with an InDesign "book" rather than a "document"?
    Most of things that are not going into InDesign as they appear (function) in Open Office have to do with hierarchies and referencing:
    (a)    Outline /bullet hierarchies
    (b)    Tables (columns / rows may change shape)
    (c)    Table of Contents and Indexing
    I am wondering if XML import will help preserve functions related to the Table of Contents, Figure captions, Table numbers, etc.
    Thank you for your help.
    -Leigh (las_123456) 
    Jim Maivald's book has been praised on these InDesign forums:
    A Designer's Guide to Adobe Indesign and XML: Harness the Power of XML to Automate Your Print and Web Workflows (ISBN: 0321503554)
    Look it up at your local public library, read the description and reviews at Amazon.com, compare prices at allbookstores.com.
    HTH
    Regards,
    Peter
    Peter Gold
    KnowHow ProServices

  • 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

  • Using XML Import/Export in Transport Connection

    Hi, I was investigating the feasibility of copying a query definition from one BW system to another using the XML Import/Export functionality in Transport Connection.  This is not to replace our current transport process across the landscape (Dev -> QA -> Prod), but merely just looking at possibilities for end users who develop queries in QA & then recreate them in Prod.
    My question is: has anyone worked with the XML Export/Import for types Queries & Query Elements?  I was trying this out between a Dev and Sandbox system and only had limited success.  I was able to take a small query and perform the Export to a local .xml file without much difficulty.  But when I try to do the Import, my query never shows up.  The Import function shows a green light, but I get a couple of error messages on the Import such as the following:
    ==========================================================
    SAP object 3WROG4HZ3NKP1PIYHCR1H24CQ () cannot be imported
    Diagnosis
    You attempted to import SAP object 3WROG4HZ3NKP1PIYHCR1H24CQ of type into the system via the XMI interface. However, you are not allowed to import SAP objects.
    System response
    The object was ignored during the import.
    Note: It can be that the import is incomplete when the required SAP objects are still not active in the system.
    Procedure
    Install the specified objects from Business Content. Only import the metadata afterwards.
    =========================================================
    The portion returned for Saving and Activating returns green lights.  The two sample objects mentioned appear to just be custom InfoObjects used in my query & don't look to be any different than others that work OK. 
    Just curious if anyone else has worked with this and could help advise. 
    Thanks...  Jody

    This is an old subject, but I think XML import only works for datamodeling objects like InfoObjects, InfoCubes, and ODS objects. If you try to export a query, and open the XML file in a text editor, there is not enough information (in my opinion) to build the query. As an example you don't see how key figures are to be displayed, filter or free characteristics.
    However, when an InfoObject is collected, you get all the attributes, texts in all languages.
    If anyone has more insight, please enlighten us.
    -John

  • 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) Optimal number of records to fetch fromForte Cursor

    Guys,
    The behavior (1 fetch of 20000 vs 2 fetches of 10000 each) may also be DBMS
    related. There is potentially high overhead in opening a cursor and initially
    fetching the result table. I know this covers a great deal DBMS technology
    territory here but one explanation is that the same physical pages may have to
    be read twice when performing the query in 2 fetches as compared to doing it in
    one shot. Physical IO is perhaps the most expensive (vis a vis- resources)
    part of a query. Just a thought.
    "Rottier, Pascal" <[email protected]> on 11/15/99 01:34:22 PM
    To: "'Forte Users'" <[email protected]>
    cc: (bcc: Charlie Shell/Bsg/MetLife/US)
    Subject: RE: (forte-users) Optimal number of records to fetch from Forte C
    ursor
    The reason why a single fetch of 20.000 records performs less then
    2 fetches of 10.000 might be related to memory behaviour. Do you
    keep the first 10.000 records in memory when you fetch the next
    10.000? If not, then a single fetch of 20.000 records requires more
    memory then 2 fetches of 10.000. You might have some extra over-
    head of Forte requesting additional memory from the OS, garbage
    collections just before every request for memory and maybe even
    the OS swapping some memory pages to disk.
    This behaviour can be controlled by modifying the Minimum memory
    and Maximum memory of the partition, as well as the memory chunk
    size Forte uses to increment its memory.
    Upon partition startup, Forte requests the Minimum memory from the
    OS. Whithin this area, the actual memory being used grows, until
    it hits the ceiling of this space. This is when the garbage collector
    kicks in and removes all unreferenced objects. If this does not suffice
    to store the additional data, Forte requests 1 additional chunk of a
    predefined size. Now, the same behaviour is repeated in this, slightly
    larger piece of memory. Actual memory keeps growing until it hits
    the ceiling, upon which the garbage collector removes all unrefer-
    enced objects. If the garbage collector reduces the amount of
    memory being used to below the original Miminum memory, Forte
    will NOT return the additional chunk of memory to the OS. If the
    garbage collector fails to free enough memory to store the new data,
    Forte will request an additional chunk of memory. This process is
    repeated untill the Maximum memory is reached. If the garbage
    collector fails to free enough memory at this point, the process
    terminates gracelessly (which is what happens sooner or later when
    you have a memory leak; something most Forte developpers have
    seen once or twice).
    Pascal Rottier
    STP - MSS Support & Coordination Group
    Philip Morris Europe
    e-mail: [email protected]
    Phone: +49 (0)89-72472530
    +++++++++++++++++++++++++++++++++++
    Origin IT-services
    Desktop Business Solutions Rotterdam
    e-mail: [email protected]
    Phone: +31 (0)10-2428100
    +++++++++++++++++++++++++++++++++++
    /* All generalizations are false! */
    -----Original Message-----
    From: [email protected] [SMTP:[email protected]]
    Sent: Monday, November 15, 1999 6:53 PM
    To: [email protected]
    Subject: (forte-users) Optimal number of records to fetch from Forte
    Cursor
    Hello everybody:
    I 'd like to ask a very important question.
    I opened Forte cursor with approx 1.2 million records, and now I am trying
    to figure out the number of records per fetch to obtain
    the acceptable performance.
    To my surprise, fetching 100 records at once gave me approx 15 percent
    performance gain only in comparsion
    with fetching records each by each.
    I haven't found significant difference in performance fetching 100, 500
    or
    10.000 records at once.In the same time, fetching 20.000
    records at once make a performance approx 20% worse( this fact I cannot
    explain).
    Does anybody have any experience in how to improve performance fetching
    from
    Forte cursor with big number of rows ?
    Thank you in advance
    Genady Yoffe
    Software Engineer
    Descartes Systems Group Inc
    Waterloo On
    Canada
    For the archives, go to: http://lists.sageit.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: [email protected]
    For the archives, go to: http://lists.sageit.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: [email protected]

    Hi Kieran,
    According to your description, you are going to figure out what is the optimal number of records per partition, right? As per my understanding, this number was change by your hardware. The better hardware you have, the more number of records per partition.
    The earlier version of the performance guide for SQL Server 2005 Analysis Services Performance Guide stated this:
    "In general, the number of records per partition should not exceed 20 million. In addition, the size of a partition should not exceed 250 MB."
    Besides, the number of records is not the primary concern here. Rather, the main criterion is manageability and processing performance. Partitions can be processed in parallel, so the more there are the more can be processed at once. However, the more partitions
    you have the more things you have to manage. Here is some links which describe the partition optimization
    http://blogs.msdn.com/b/sqlcat/archive/2009/03/13/analysis-services-partition-size.aspx
    http://www.informit.com/articles/article.aspx?p=1554201&seqNum=2
    Regards,
    Charlie Liao
    TechNet Community Support

  • 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) XMLParser-Node : Serializing parts of aDOM across par

    I managed to solve this problem with the help of
    Sanjeev Sondur and Girish Nair from Sun.
    The Solution suggested is as follows :
    Whenever a node is supposed to passed as a parameter
    for an inter-partition call. We have marshal and
    UN-Marshalling :
    - Create a new document.
    - Clone the node in the context on the new document
    - Append the node to the new document
    - Serialize the document into a MemoryStream which is
    a attribute of the object (SerializedNode) that
    is passed in Lieu of a Node.
    - On the other end UnMarshall by DeSeralizing the Document
    and then reading the node.
    Code Follows :
    SerializedNode::SerializeNode(pNode);
    NewDoc : document = new();
    lNode : node;
    if pNode <> nil then
    -- This clones the node from an old document and creates it
    -- in the context of the new document.
    lNode = NewDoc.ImportNodeFromDocument(pNode, deep = true);
    -- You can then attach to the any part of DOM (I am using
    child of root)
    NewDoc.appendchild(lNode);
    end if;
    -- _mStream is MemoryStream
    mStream.Open(Framework.SPAM_WRITE, IsBinary = TRUE);
    _mStream.seek(0);
    _mStream.WriteSerialized(NewDoc);
    _mStream.close();
    On the other end I Unmarshall it
    SerializedNode::GetNode()
    mStream.Open(Framework.SPAM_READ, IsBinary = TRUE);
    _mStream.seek(0);
    NewDoc : document = (Document)(_mStream.ReadSerialized());
    lNode : node = NewDoc.getFirstChild();
    if lNode = NIL then
    task.lgr.putline(' In GetNode : Node was NIL');
    end if;
    return lNode;
    Note : This can use used for read-only access to parts of the DOM.
    across partitions.
    Thanks to all who responded.
    Vivek Shetty
    vivekvi-corp.com vivek.shettyLibertyMutual.com
    978-884-9942 (cell) 978-750-3639 x 202 (Liberty Mutual)
    -----Original Message-----
    From: Shetty, Vivek [mailto:Vivek.ShettyLibertyMutual.com]
    Sent: Thursday, December 21, 2000 10:04 AM
    To: 'forte-userslists.xpedior.com'
    Subject: (forte-users) XMLParser-Node : Serializing parts of a DOM
    across partitions
    I am modeling an Insurance-Policy as a XML document.
    One of my requirement was to pass pieces of this Policy (Node)
    to a service object for processing.
    I have discovered that the Node cannot be serialized across partitions.
    I can serialize the whole document using the exportDocument and send
    it across the partition and import it on the other end. This is fine when
    large pieces of the document have to be sent over.
    When smaller pieces of this information has to sent to a service object,
    I was planning to create a new document, extract the required nodes
    from the old document create in the new document and send the
    new document (which is a subset) across.
    I am having problems extracting a node from one document and
    creating it another document.
    I have tried node.clonenode, document.importnodefromdocument without much
    success.
    I have a choice of writing a method that creates a structure in the new
    document by
    recursively navigating the old tree and creating new nodes in the new
    document from scratch.
    Have any of you faced similar situations and come up with a more elegant
    solution.
    Please share.
    Thanks
    Vivek Shetty
    vivekvi-corp.com vivek.shettyLibertyMutual.com
    978-884-9942 (cell) 978-750-3639 x 202 (Liberty Mutual)
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Maybe you are looking for