Asynchronous call Limit In Tuxedo

In our application we use asynchronous services. In load conditions some of these requests are dropped by Tuxedo system i.e. from IPC message queues.
Is there any limit on number of such request per server i.e. per IPC message queue? If YES then what is its value for different versions?
Is it available some where in Tuxedo documentation then what is its location?
Regards
- Ajeet

Ajeet,
Any Tuxedo context can have a total of at most 51 outgoing tpacall()s plus
tpcall()s at any one time. A "context" is a client context created with
tpinit() or a Tuxedo dispatched thread within a Tuxedo server. (Prior to
Tuxedo 7.1, threads were not supported, and there could be at most 51
outstanding tpacall()s or one outstanding tpcall().)
If Tuxedo attempts to send a message to a message queue and the message will
not fit, then Tuxedo attempts to send a shorter message to that same queue
with a pointer to the rest of the message located in a file. If the
TPNOBLOCK flag is specified, then this second msgsnd() can fail if the
message queue is full, which results in a TPEOS error. If neither TPNOBLOCK
nor TPNOTIME is specified, then the msgsnd() can fail due to time out if the
message queue is full, which results in a TPETIME error. If only TPNOBLOCK
is specified, then this msgsnd() can block indefinitely.
Thus, a full server message queue is one reason that Tuxedo requests can be
dropped. This is especially true if the TPNOBLOCK flag is specified. If
the TPNOREPLY flag is also specified, then the caller will not receive any
notification that the message was dropped. In some applications, such
behavior can be desirable, since it is better to drop a request immediately
if it is unlikely that that request can be successfully processed.
Ed
<AJEET TEWARI> wrote in message news:[email protected]..
In our application we use asynchronous services. In load conditions some of
these requests are dropped by Tuxedo system i.e. from IPC message queues.
Is there any limit on number of such request per server i.e. per IPC message
queue? If YES then what is its value for different versions?
Is it available some where in Tuxedo documentation then what is its
location?
Regards
- Ajeet

Similar Messages

Asynchronous calls in BEA CORBA

Hi all,
from what we know it is possible to asychronous calls with CORBA via those methods
- AMI
- Notification Service
- one way request
I dont see in the current version of BEA Tuxedo (8.1) that AMI is supported .
Notification Service is available , but it seems that the channel is one blocking
process. Therefore I have doubts re performance.
Are one way requests blocking or unblocking ? Accorsing to the documentation BEA
is recommending those because of the lack of quality of service and scalability
issues.
What is the best way to do asynchronous calls with BEA Tuxedo CORBA ?
Any hints ?
Thanks,
Iris

What you are proposing makes good sense. The problem with
asynchronous communication is the problem with errors. The
typical send and forget many asynchronous systems use leads to
serious reliability problems. About the only way to guarantee
reliability is to use a transacted queuing mechanism such as
/Q. Using CORBA for external communication and ATMI inside
seems like a reasonable approach. You may run into difficulties
though if you need a single server to be both an ATMI server
and a CORBA server. I'm not certain that is supported. In your
case though it sounds like you'll have a CORBA server that is
an ATMI client and that should work.
Regards,
Todd
"Iris Peters" <[email protected]> wrote:
>
Hi Todd,
the system we are investigating is already using ATMI and /Q. The client
has got
a system which is based on the pipeline principle which is asynchronous.
Our client
would like to know if this system if appropriate for using asynchronous
CORBA
messages inside and not ATMI anymore . There are also ideas to use CORBA
to interface
with external systems.
Our suggestion is to just use CORBA to interface from and to external
and leave
the ATMI stuff as it is amd maybe just provide a CORBA wrapper for the
ATMI calls
to external.
Regards,
Iris
"Todd Little" <[email protected]> wrote:
Tuxedo does not provide AMI. Besides the alternatives you listed,
one can also use the Dynamic Invocation Interface to acheive
deferred synchronous behavior. Can you describe what it is you
are trying to accomplish and how you see asynchronous messaging
helping you?
An alternative might be to use ATMI and use Tuxedo's /Q mechanism.
Regards,
Todd
"Iris Peters" <[email protected]> wrote:
Hi all,
from what we know it is possible to asychronous calls with CORBA via
those methods
- AMI
- Notification Service
- one way request
I dont see in the current version of BEA Tuxedo (8.1) that AMI is supported
Notification Service is available , but it seems that the channel is
one blocking
process. Therefore I have doubts re performance.
Are one way requests blocking or unblocking ? Accorsing to the documentation
BEA
is recommending those because of the lack of quality of service andscalability
issues.
What is the best way to do asynchronous calls with BEA Tuxedo CORBA?
Any hints ?
Thanks,
Iris

Jolt and Asynchronous calls

We are currently using Jolt 1.2 connected to a Tuxedo 6.5 system on Solaris.
We are porting a Windows thick application to browser. We call a Tuxedo
service
with the old system that takes around 10 minutes to complete. We obviously
call this
asynchronously. When we call this same service using Jolt it "times-out".
Which makes
sense since Jolt 1.2 seems to only allow synchronous ( aka
Request-Response ) calls.
I have looked at the documentation for Jolt 1.2, 1.2.1, the Jolt with Tuxedo
7.1 and Tuxedo 8 and
I cannot find an ability to make a Asynchronous call. However, I did find
it in the API documentation
for the Jolt that comes with Weblogic Enterprise 5.1 and above? Are these
APIs available without
Weblogic Enterprise? Is there a special Jolt add-on package?
Thanks for the info,
Carl J. Collin
Walgreen Co.
[email protected]

Thank you very much. That is exactly what our engineers came up with
to get around this. The problem is that we have no ability to be notified
when this async service is finished. In our old application we would lock
the window manually (windows api) and run a loop doing getReplies until
the async returned a buffer. With a browser model, it probably isn't
possible
without having an applet or something. It just rubs me raw that the API I
need
for Jolt isn't supplied when you BUY JOLT, but only if you buy the
SUPER-EXPENSIVE
Weblogic Enterprise. Why have a Jolt product to begin with if you do not
supply the whole
functionality needed to merge Java and Tuxedo, which is the supposedly the
product's goal?
Carl J. Collin
Walgreen Co.
[email protected]
"Manoj SASIDHARAN" <[email protected]> wrote in message
news:[email protected]...
>
Hello Carl J. Collin,
I can suggest a workaround to make things happen.
From the browser call a Tuxedo service (synchronously) using Jolt whichinternally
does the following:
SVC(TPSVINFO...)
SvcName="Name of Service Currently called from Browser..";
ret=tpacall(SvcName,... TPNOREPLY);
tpreturn(...);
HTH
regards
MS
"Carl J. Collin" <[email protected]> wrote:
We are currently using Jolt 1.2 connected to a Tuxedo 6.5 system on
Solaris.
We are porting a Windows thick application to browser. We call a Tuxedo
service
with the old system that takes around 10 minutes to complete. Weobviously
call this
asynchronously. When we call this same service using Jolt it"times-out".
Which makes
sense since Jolt 1.2 seems to only allow synchronous ( aka
Request-Response ) calls.
I have looked at the documentation for Jolt 1.2, 1.2.1, the Jolt with
Tuxedo
7.1 and Tuxedo 8 and
I cannot find an ability to make a Asynchronous call. However, I did
find
it in the API documentation
for the Jolt that comes with Weblogic Enterprise 5.1 and above? Are
these
APIs available without
Weblogic Enterprise? Is there a special Jolt add-on package?
Thanks for the info,
Carl J. Collin
Walgreen Co.
[email protected]

Wait on Asynchronous Call - why so long?

LV 2013, Win7
I have a window which comes and goes, during program operation.
This window has 72 subPanels, each containing a reentrant copy of the same VI for a "block". I insert the VI in the subpanel, and then run the VI with a CALL and FORGET call.
When the user closes the window, all the block VIs terminate, and the window closes. I don't care if the closing behind the scenes still goes on after the window disappears.
But when the user QUITs the program, with this window up, I need to make sure that all the block VIs have terminated before I shut down other things (close files, etc).
To that end, I changed the CALL and FORGET to a CALL and COLLECT operation, and installed a WAIT ON ASYNCHRONOUS CALL for each instance at the end of the big window code. This is after the blocks have been commanded to die (via an event).
I see from the debugging file (a portion is pictured) that it takes over 1000 mSec to wait for all the instances to die.
The thing is, if I change that "0" to "1000", then what I would expect is that the actual waiting time would drop to < 100 mSec.
My thinking is that during that timed wait, the blocks would be dying anyway, so it would take less time to actually wait on them.
But when I do that, nothing really changes. The listed time is still over 1000 mSec.
If I limit the number of blocks to 12, the time is 97 mSec, for 24 it is 185, for 36 it is 576, and so on - it's proportional to the number of blocks.
So, what is really happening? If it's just waiting on things to die, why doesn't the timed wait affect the numbers?
I originally (when I used CALL and FORGET) kept track of how many were opened and how many were closed and waited until that became zero, but this is a cleaner way of doing it, at least in theory.
Am I missing something?
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks
Solved!
Go to Solution.

Have you checked how long the first loop of the For loop takes, versus all of the others?
So I tried that, several times - the pattern is the same as shown here. The first few lines are from the blocks themselves, it's the last thing they do.
Looks like there's ONE case where there's a bigger delay than expected, All told, this takes about 600 mSec.
Maybe the debugging process affects that (* waves to Mr. Heisenberg * )
The 300-400 mSec is back to where I first saw this delay. Apparently the unreleased refs clog up the system enough to drive it up to 1000 (or 2000 mSec as I saw in one case).
Still, I don't understand why a timed delay ahead of the WAITS doesn't affect the WAIT time.
But I guess that's not important. It must be actually doing more work than simply asking "is it dead yet?"
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

Is there a way to process multiple asynchronous calls individually (instead of all at once)?

Hello,
I have a function that saves a record using a RPC call (asyncToken with a new responder). When I save an individual record (pressing "s" key), it works fine. However, when I attempt to save multiple records simultaneously (bound to "v" key) (I have a for loop running through the selectedItems in the datagrid), it performs strangely.
For anyone who hasn't experienced this, the successive calls seem to get stacked (literally - i.e. using a stack) and processed at the end of all operations in that block of code (I had trace functions before and after the call that were executed before I saw the result confirming this).
What I would like to do is to simulate multiple AsyncToken usages with a single click, but still have them all occur individually since right now, the function saves the last item in the stack 8 times instead of saving each of the 8 items separately.
OR
Is there another means of RPC using something like "interruptToken" as opposed to asyncToken? (In most other areas I've seen, asynchronous calls are performed as interrupts and dealt with immediately, thats why this procedure confused me for a bit)
Thanks in advance,

The second paragraph you posted is definitely worthwhile - still figuring out some of the inner workings of Flex calls (not just RPC stuff) that I use as I am pretty new to flex.
I don't have the code with me at the moment, but I think I have to use separate calls to the save function. My situation is this (and I plan on updating with code on Monday if necessary):
I have a datagrid that is populated using a single RPC (which is loaded into an arrayCollection first then the datagrid). Changes are made to the datagrid through a copy/paste function that I made, but these changes are only reflected on the datagrid (i.e. not in the dataprovider). When the user hits "save", the selected line (selectedItem actually - i.e. not an index but the object itself) is passed to another class which contains a modified version of my "modify data" function (brings up a dialog after choosing a given line allowing editting/validation of certain fields regarding the selectedItem). This changed version of "modify data" is then called and immediately closed effectively saving this record (without allowing the user to alter fields - so they don't have to hit save twice).
With the copy/paste function, I make all of these changes en masse and then have a loop that goes something like
for each (_object:Object in myDatagrid.selectedItems)
callSaveFunction(this, _object);
which ideally loops through the data and saves each item that has been changed. If there is a way to save all of the data in the datagrid simultaneously, I would appreciate a bit of help there (perhaps dealing with the bindings - right now I have the object I save as the destination and the source is myDatagrid.selectedIndex.[field name]).
Good to know about the other stuff, though - my understanding was a little bit lacking before

How can we tell if a VI is already running before calling Start Asynchronous Call?

The new Start Asynchronous Call node is awesome for spawning multiple instances of reentrant VIs. However, I've stumbled a bit in using it for non-reentrant VIs. The old practice of using the "Run VI" method would allow us to check the Execution.State of the VI before invoking the method to run it. That way if the State was Running or Run Top Level, we could skip the invoke node and just use a property node to open its front panel. WIth the Start Asynchronous Call node, it looks like we have to use a strictly typed static VI reference, and when we open the VI reference, the VI gets reserved and its Execution.State = Running. So, how can I tell if it is not just reserved by the thread but actually executing before making a redundant Start call?
By the way, the redundant Start has interesting behavior. It will actually cause the targeted VI to be executed again after it stops. Even if you hit the Abort button on the target VI, it will immediately execute again and again equal to the number of times the Start Asynchronous Call node was run. There's nothing wrong with that, and I suppose the simple answer is to just go back to using the old "Run VI" method. It's just that the ability to wire up those inputs directly to the connector pane is so nice. Perhaps I am missing something obvious. Oh, I am referring to the Call and Forget mode (0x80).
Thanks,
Dan
Solved!
Go to Solution.

Just throwing it out there, I know I'm a year.5 late on this but if it's a psuedo-modal dialog or some other window that you only want a single instance visible at one time, you can check the FP.State property on the strictly typed vi reference. If it's loaded and visible to the user it will be "Standard", if it was closed or not opened prior then the state will be "Closed".
I think the standard behavior of serializing execution on another thread would be great for doing a pre-set number of iterations with a sub vi in a non-blocking sort of way but for sub vi's meant for UI interaction checking FP.State works.
Philip
CLD

Notify an application user that an asynchronous call of a bi publisher report has been completed

Hi experts,
We have an ADF application (11g) from where we call BI Publisher (11g) reports by using bi publisher web services.
I have the following 2 requirements:
Run the reports asynchronously
Notify each user that the report which has been asynchronously called has been completed.
My thought was to use the scheduleReport web service which is asynchronous by default.
My problem is how to notify only the specific user using "http notification" that the report is ready.
http://docs.oracle.com/cd/E28280_01/bi.1111/e22259/reporttriggers.htm#BIPDV008
Can you please help me on this?
Regards,
Dimitris

I've converted the Blob to a Clob but still can't get it to appear in the BI Report. It shows up in the XML file as a bunch of text character, but in the report if I use the fo: instructions it remains blank, and if I don't, it shows the same text data that is in the XML file.
Perhaps BI Reports aren't meant to show database images? Is there another tool I can use instead (data is in APEX 4.0) 11g.?

Asynchronous call in OSB

Hi, I was trying to call a business service in an asynchronous way. I used publish action but I can´t get the response of the service. It seems it just work with one-way services like a file adapter. Any help please.

When you say you are making an asynchronous call, then you would not care about the response.
If you are looking for a response from the service then you should use a service callout instead.
Let me know if my understanding is incorrect.
Thanks,
Patrick

SOAP Receiver Adapter (Asynchronous Call)

Hi All,
Scenario is Proxy to Webservice asynchronous call.
Scenario configuration is done as follows.
1) Imported the WSDL and using as a asynchronous inbound interface.
2) SOAP receiver channel is configured with the target URL & soapAction as given in the WSDL as (soap address & soap Action).
3) Configured the proxy server details as required.
SOAP channel is successfully sending the message to the application as DLVD.
But the issue is target application not receiving the data. What could be the reason ? I am wondering , i have tried with the external tool like Altova XML Spy & SOAP UI sending data to the webservice & it's working fine.
Please suggest me if anything which can help to resolve this issue.
Thanks
Ashwin

In this case you can do the following:
1. start your tcpmon or TCPGateway, add there a listener e.g. on port 9090
2. configure the target URL in TCPGateway for this listener
3. configure the target URL in your XI SOAP Receiver Adapter to http://<ip of TCPGateway>:9090
4. now execute the scenario again in XI
(make sure XI can reach your TCP Gateway, e.g. check Proxy)
I have used this method successfully for error tracking. In some cases it is necessary to add 2 listeners in TCPGateway and route e.g. 9090 to 9191 and from there to the end (I did not analyse why).
Then you will be able to see what XI is really sending and you will see the full response from the partner side. You can then compare the XI request data with those which are sent via soapUI. This should give a clue about the problem.
CSY

How to move files in background (asynchronous call)?

Hello
I would like to make an an Asynchronous call to the Move.vi for moving files as a background process.
I am having the following problems:
- The static VI Reference as input to the Open VI Reference function asks for a path to the VI to be called, but I can't find it. Where exactly is Move.vi located?
- The Type Specifier VI Refnum node accepts VIs via drag and drop, but only from an explorer window, not from the LabView VI palette. Again, I need to know where to find Move.vi. Or is there another way to specify the connector pattern?
It all works, if I call Move.vi from within a wrapper VI (because I know where to find that), but for the sake of simplicity I would like to avoid that step.
I'd appreciate any suggestions, also alternative approaches for moving files in the background.
Sebastian

Move is not a VI, but a primitive, so you can't call it like that. As you've seen, the wrapper method works.
Try to take over the world!

Unexpected loop behaviour with asynchronous call

I am having trouble with loop behaviour when using an asynchronous call.
I am building an application to record simultaneously temperature (NI USB-TC01 thermocouple), displacement (DC voltage, read from an Agilent 34401a) and resistivity (using a Keithley 2400 sourcemeter).
I am using a voltage sweep function on the Keithley 2400 to alternate current direction in a sample and measure the voltage drop - this is a common technique for eliminating thermal emf from resistance measurements. But what you need to know is that I set the number of current cycles I want and then wait for the instrument to measure and return the meausurements - up to 50 samples, which takes nearly 30 seconds. With the other two measurements, I have to programmatically call a measurement vi for each sample I want.
I have set up my application to asynchronously program the resistivity measurement and then wait for the response, and I want to in parallel measure temperature and position until the resistivity is done. I then want to record the mean and standard deviation for each signal. I used an event structure to interrupt the temperature and position measurements when done.
The problem I am running into is that after the first resistivity measurement is completed and I go to do the second one, the loop that measures temperature and displacement only runs twice, so I only get two samples, regardless of how many resistivity samples I want to collect. For example, if I want 50 resistivity samples at a time, the first iteration will measure rougly 40 samples of temperature and displacement, but any subsequent iterations will only measure twice.
I know this is probably overwhelming to understand the operation, but can anyone help? I have attached my code ('Delatometer') as well as a test vi I built that uses the same structure but has no interactions with instruments ('asynchronousCall').
The
Attachments:
Delatometer.zip ‏221 KB
asynchronousCall.zip ‏29 KB

I forgot to mention...the test vi that I uploaded executes as expected, so I am thinking that maybe its an issue with the instrument calls? I also found that if I run the Delatometer program in 'highligh execution mode' it runs properly, and it is my understanding that in 'highlight execution mode' there is no multi-threading.

Problem about asynchronous call: subVI front panel doesn't pop up when called.

Dear All,
I'm new to LabVIEW, and this is the first time I try to use the asynchronous call.
I'm using LabVIEW 2011.
I want to build a directory for several VIs, and it should allow users to open more than one of the VIs at the same time by pushing the buttons. Before building this directory, I simply tried to use asynchronous call to call a VI form another VI, but found a big problem.
I followed the steps in the help file, created a strictly typed reference, set the option to x80 because I don't need the return. When I run it for the first time, it worked fine: the subVI popped up and run. Then I closed the subVI. But for the sencond time and on, when I run the caller VI, the subVI didn't pop up, instead it seemed to run silently on background because when I manually opened it from the file I found it running. Besides, I didn't find any option like "show front panel when called" of the asynchronous call.
The caller VI and subVI are attached. The address of subVI in caller VI should be changed accordingly.
What should I do to make it work properly? Thanks very much for any idea!
Solved!
Go to Solution.
Attachments:
asynchronous_call.vi ‏8 KB
boolean.vi ‏7 KB

Jeff·Þ·Bohrer wrote:
A better approach is to set the vi properties programaticly like this:
Jeff, you will be happy to know that I used this tactic in full force on a project recently (lots of dialogs in this program). Not sure how many LabVIEW reboots it has saved me from. Reuse VIs made it even easier to do.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

ORA-02393 Exceeded Call Limit on CPU Usage

I have created a Profile and attached it to a user, in this example:
Create Profile percall
Limit
CPU_PER_CALL 10
IDLE_TIME 5;
I have attached it to one user - USER1
When USER1 runs a SQL Statement -
SELECT COUNT(*) FROM TABLE1 A WHERE A.EFFDT = (SELECT MAX(B.EFFDT) WHERE B.EMPLID = A.EMPLID AND B.EFFDT <= SYSDATE);
I get an error (Which I want to receive) ORA-02393 Exceeded Call Limit on CPU Usage.
The SQL statement shows in the table DBA_COMMON_AUDIT_TRAIL, but shows a success even though the user received an error ORA-02393.
What I want is a way for a DBA to be able to report on those ORA-02393 errors. I don't see any entries in the Log files, and don't notice any errors in the Oracle Tables.
I would like to be able to show the user (after a week when they bring up the issue) what the SQL statement was and why it Exceeded the CPU Usage. If the error could place the SQL statement in a table or just display it in an error log with the Statement to verify that THIS is the statement which exceeded the CPU Usage.
Thank you
Aaron

can you modify the procedure in which the SELECT resides.
If so, trap & log the error.

Asynchronous call to web servie using pl/sql

1) How do I make an aynschronous call uisng pl/sql. I am currently using utl_http.
But it is expecting me to get repsonse using utl_http.get_response.
Is there anyway I can make asynchronous call to web service? Please give me examples if any.

Web services are NOT asynchronous as the HTTP application protocol is not asynchronous. A web service cannot (as an sync callback event) initiate a call to the web browser (client app) - as the web browser does not have a tcp listening endpoint. The web service must respond using the EXISTING tcp session established via a connect() call from the browser.
PL/SQL code executes in a dedicated or shared server process. Execution is serialised. So asynchronous calls are not supported and non-existent. Again, async processing requires some from of notification (callback event, message handler or signal interrupt handler) to inform the main process (while it is executing code), that the async call has completed.
And this does not exist in PL/SQL processing for very good reasons. (Oracle would have been one of the most unstable products on the market if it did support async PL/SQL processing, as 99% of developers would not understand how to use it correctly, and would have severely violated the fundamental concurrency and MVCC principles)
What can be done via PL/SQL (and SQL) is parallel processing - not to be confused with async processing. The API in PL/SQL to use for that is DBMS_PARALLEL_EXECUTE. You can also self roll this using DBMS_JOB or DBMS_SCHEDULER.
No default IPC exists for inter process communication between parallel processes. If IPC is needed, it needs to be manually coded using a standard SQL table (where row locking provides for mutexes and semaphores), or something like DBMS_PIPE.

Error handling / logging with asynchronous calls

Hi,
I want to log every error my app might throw. I thought it would be sufficient to surround either the launch method or the start method with a try...catch. But it doesn't work as excepted.
If an error occurs in an asynchronous call, e.g. in a button click, the exception is never caught.
Do you have an idea, how to solve this?
Example:
import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;
public class TestApp4 extends Application {
    public static void main(String[] args) {
        launch(args);
    public void start(final Stage stage) throws Exception {
        try {
            final VBox root = new VBox();
            Button button = new Button("Click");
            button.setOnAction(new EventHandler<ActionEvent>() {
                @Override
                public void handle(ActionEvent actionEvent) {
                    int i = 0;
                    int a = 5 / i;
            root.getChildren().add(button);
            Scene scene = new Scene(root);
            stage.setScene(scene);
            stage.show();
        } catch (Exception e) {
            // do logging here
            e.printStackTrace();
}

I'm not 100% sure how it works, but what I am pretty sure is that these Exceptions in EventHandlers are caught by JavaFX itself inside the JavaFX thread. They have to, because if they let the exception bubble up to the top, the FX thread would end (and with it, all response in the UI). It is probably caught at the level where Events are triggered somewhere (my guess is inside the QuantumToolKit).
Anyway, these exceptions are printed to System.err -- if you can redirect that stream to a log file or whatever you can have them all in one place. The error stream can be set in your application simply by calling System.setErr().
Note also that exceptions occuring in a Task are stored in the exception property -- sometimes these can be hard to find as they are put there silently -- you'll need to check your Tasks for exceptions and print them.

Asynchronous call Limit In Tuxedo

Similar Messages

Maybe you are looking for