Queue Probelm in SMQ2

Folks,
I have deleted the queues as I was not able to restart, Now the inbound side of XI is not receiving anything, Please tell me what is the issue .
Manish

Hi manish,
If there is no entry in the SMQ2, then it is good, so that message will be processing. ANd there is no message is in Queue.
But in your case, there may be some other problem.
Can you check this SAP link-
http://help.sap.com/saphelp_nw2004s/helpdata/en/b0/df5f3c8dde1c67e10000000a114084/frameset.htm
http://help.sap.com/saphelp_nw2004s/helpdata/en/96/8412417301ee6fe10000000a1550b0/frameset.htm
/people/prasadbabu.nemalikanti3/blog/2006/02/13/configuration-of-a-central-integration-server
Hope this may give some hints.
Regards,
Moorthy

Similar Messages

Error"XI Error CLIENT_RECEIVE_FAILED.INTERNAL: Queue sto" in SMQ2

Hi,
When i am trying to test my JDBC to ABAP Server proxy i am getting the error(XI Error CLIENT_RECEIVE_FAILED.INTERNAL: Queue sto) in SMQ2 please advice me what could be the problem?
Regards,
Bhoj

Hello better you apply LUW on each and every message in SMQ, queues. Else activate and inactivate the messages in the queue by sxmb_adm -> managequeues -> deregisterqueues -> registerqueues -> activate queue.
And also do if any messages are failed follow the blog to resend the failed messages,
XI : How to Re-Process failed XI Messages Automatically

SXMB_MONI message fail causing Queue struck at SMQ2

Hi All,
If mapping error occured in SXMB_MONI, corresponding entry will be struck up in SMQ2 and saying that SYSFAIL.
When i drill down this into further, it is saying that Mapping error.
Because of this all messages coming later also getting strucked in this queue.
Why is this happening and what to do for not to get struck further messages
Regards

Hi Hetal,
>>Create a job which will restart message after some time if it is stuck because of connection problem or something, then queue will be clear.
It's because of Mapping problem, even though we schedule a job to restart, it won't resolve. again it comes into same error.
@Prateej:
>>Could you check the QoS for the following entry in SXMB_MONI? Is it EOIO ?
QOS is Exactly Once
@Madu:
>>This is the standard behavior of PI. When some message will fail in Integration Engine(either because of Receiver not found or mapping error),some of remaining message(not all messages) which will come in the same queue of failed message will stuck.
You can not predict which messages will stuck and which messages will not stuck.
YES, you are right.
>>If you are having some important interface, which you want to divert the messages in other queue. You apply exactly once in order in sender channel for other interfaces so that these messages will not stuck in SMQ2.
For me all are Important Interfaces only. I can't prioritize
I think the better solution is Monitor failed messages in MONI every day and if it is failed because of Mapping error means, we can delete that entry from SMQ2.because for mapping related errors we don't require that message to restart again.
so that nothing will be queued after wards.
Regards

Queue Status in SMQ2 = RUNNING, but Stuck.

I have a queue that sometimes gets stuck in SMQ2 in status RUNNING (for no apparent reason).
If I activating the queue manually (as suggested in
http://help.sap.com/saphelp_nw04/helpdata/en/d9/b9f2407b937e7fe10000000a1550b0/frameset.htm)
usually solves the problem.
Therefore, this queue processes messages 24x7 and cannot get stuck for more than 5 minutes.
Question n1)Is there a way I can do this automatically (scheduling a JOB) (itu2019s a specific queue, that is only used for this single process)?
Question n2) Sometimes, after activating the queue again, the message continues in status RUNNING, and the only solution is to delete the message and activating the queue manually (when I do this, after processing every message in the queue, when new messages begin to arrive, the queue goes to status READY for a LONG time.) Does anyone knows whats going on?
obs.: The message is ALWAYS processed successfully, and there is no problem to process it 2 times. The only thing that cannot happen is STOP the process.
Thank you.
At.,
Bernardo Tavares Braga

1) I already registered all the queue through sxmb_adm - didn't change anything.
2) This queue is on SAP PI/XI, but the message goes to SAP ECC.
Since the process is executed, what I think happens is that the message updates SAP ECC, but somehow it doesn't give a return to SAP PI/XI.
So SAP PI/XI thinks its still executing.
Pinangshuk, the MONITOR QRFC_RESTART_ALLOWED is set to value 1(in the Integration Engine configuration - sxmb_admin)
Also, this enables the restart of stuck queues manually. Is there a way to do this automatically?

In Bound queue status in SMQ2

Hi All,
i've created a customer in CRM and saved it.
i've filled all the mandatory fields and it should replicate to ECC.
i've checked in SMW01, BUPA_MAIN BDoc is in intermediate state ,then i went to SMQ2 in CRM to check the queue status it is in READY status then upon unlocking the queue and refreshing it moved to RUNNING status and cleared from the inbound queue.....then upon refreshing the SMW01 ,BDoc BUPA_MAIN moved from intermediate state to send to receiver status and customer replicated to ECC.
My query is whenever i create any CUSTOMER/LEAD the queue in SMQ2 should go to RUNNING status and get processed automatically, every time i'm clearing the queue in SMQ2 and refreshing the SMW01 to reliacate the customer to ECC.
Please suggest me if any configuration change i've to do for the automatic queue clearence.
i've cleared all the queues in SMQ2 , there are no queues in wait/failed Status.
Thanks,
Syam

Hi Rohit Sharma,
Thanks for the help it solved my query.
I have one more query ,
Now the customer replicated to ECC without manual clearence of the queue.
even though the customer replicated to ECC i have the BDoc state of the BUPA_MAIN BDoc type as 'Sent to receivers (not all have confirmed)' with yellow light.
BDoc state should change to 'Confirmed (fully processed)' upon successful replication to ECC like BUS_TRANS_MSG for Lead.
Please suggest on any configuration change has to be done for the above query.
Thanks
Syam

My queue not in SMQ2

HI,
I am creating one new queue with this weblog
/people/sap.user72/blog/2005/01/28/setting-up-inbound-qrfc-queues-for-serializing-idocs-using-the-idoc-adapter
I created new table entry in IDXQUEUE table. But in SMQ2 my that queue is not displaying.why?
regards,
Ansar.

hi,
did you post any IDOCs via it?
you can find config info for this IDXQUEUE in my book:
<a href="/people/michal.krawczyk2/blog/2006/10/11/xi-new-book-mastering-idoc-business-scenarios-with-sap-xi"><b>Mastering IDoc Business Scenarios with SAP XI</b></a>
Regards,
michal
<a href="/people/michal.krawczyk2/blog/2005/06/28/xipi-faq-frequently-asked-questions"><b>XI / PI FAQ - Frequently Asked Questions</b></a>

Queues deleted from smq2

Hi
I have mistakenly deleted some important queues from SMQ2, now i want to retrive those quesues. could you please provide me the solution..
Thanks
SK

Hi SK,
I have mistakenly deleted some important queues from SMQ2, now i want to retrive those quesues.
that's no problem provided that we are dealing with ExactlyOnce queues. When deleting the SMQ2 queue you do not delete the message, but it's registration for asynchronous execution.
I suppose you already have identified the messages. Simply select them in SXMB_MONI and press the 'Restart' button. This way a new queue entry is generated and pipeline processing of these messages will continue.
Please note: This procedure also applies to ExactlyOnceInOrder (EOIO) queues, however, by deleting the queues the system has lost all information on the order. Consequently the Integration Server can not re-create the initial order of messages. It is up to you to restart EOIO messages in correct order.
Best regards,
Harald Keimer
XI Development Support
SAP AG, Walldorf

** How to stop a particular queue completely in SMQ2 tcodes

Hi,
I have nearly 6000 messages in various queues in SMQ2 tcode (Inbound queues). For example,
XBTO1_0001    1875
XBTO1_0002    2335
XBTO1_0002    1770
Messages are processed slowly. When we tried to stop a queue, only one message is stopped in the queue. Instead we want to stop complete 1 queue. Then, we feel that remaining queues will work fase. So, how to do this ...?
Kind Regards,
Jeg P.

Hi,
1) Why the queue XBTZ is not displayed in SMQR tcode ? (But, it is* displayed in SMQ2)
--->are you sure that the queue XBTZ* is active. Because in SMQr you could see the queues which are active and are already registered.
Re register the queues and make it active.
Try to make the ragistration of queue "XBTZ*" in SMQR.
Press directly Registration tab and rgister the queue then deactivate it.
http://help.sap.com/saphelp_nw04/helpdata/en/59/d9fa40ee14f26fe10000000a1550b0/frameset.htm
Go to SMQR and check the Scheduler Status i.e first line of the Screen. If it is Wait or any other status, then make sure that all Queues are registered.
Also.
/people/sap.user72/blog/2005/11/29/xi-how-to-re-process-failed-xi-messages-automatically
2) If we 'Deregister' the queue, any effect will come for the new messages ?
If we Deregister the queue then the queue is no longer processed.
http://help.sap.com/saphelp_nw04/helpdata/en/29/595f3ca0dd9770e10000000a114084/frameset.htm
thanks
Swarup

Inbound Stuck Queue in the SMQ2

Hi,
One of the Q got stuck in the Inbound of the CRM system.
It is showing the system status as "Running".IT has been in this staus for the past 2 days.
When I try to activate it is giving Message"The queue is registered and therefore cannot be activated"
The Q is giving Dump Error "Exception condition DELETE_ERROR raised
When I chekced the Bdoc SMW01 the BDOC is in "Yellow Status".
How can i process this queue.

Implement SAP note 758677 for this. This exactly deals with your issue.
This Basically speaks about scheduling 'RSQIWKEX' for inbound and 'RSQOWKEX' for outbound queues.
Also, you need to set the parameter 'QRFC_Restart_ALLOWED' to '1' in the transaction 'SXMB_ADM' -> Integration engine. Its in the runtime dropdown menu.
Note : without this parameter being set this will not work.
Thanks,
Karthik
Edited by: Karthik Rangaraju on Oct 1, 2008 2:13 PM

Queue Block (SMQ2) and no GATP invoking for Sales Order

Hi,
I am encountering two issues:
- Every time I activate any integration model for customer, materials etc. it queues up in SMQ2 in ECC and on processing there it goes to the APO
- When I create sales order it does not invoke the GATP screen. However, if I click onto the 'Item availability' button it takes me to the APO screen with a different check mode (different from the one maintained in product master)
- On saving the sales order and then clicking 'Item availability' button again, I get the message 'Order do not exist'. Next, if I check SMQ1 in ECC I find the queue. If I try to re-process, I get the message "LUWs in status NOSEND must be picked up by the application.
Well, we have maintained X0 for the MRP materials, did CIF manually, and have udated the product master ATP view with new check mode. We have also maintained the distribution, RFC destination, change transfer settings etc.
Can someone please tell me as to what is it that controls the queue communication between ECC & APO or if anything else that is controlling this.
Regards,
Avijit

Hi Santosh,
We maintained this settings in /SAPAPO/C4 in APO.
Also, we maintained Debug = 'R', Logging = 'D' (Detailed) and RFC Mode = 'Q' (Queued RFC) in CFC2 of ECC.
Even on changing the Debugging off in APO system to "Debugging on" / "Debugging on, Recording of t/qRFCs (NOSENDS)". I get the queue in SMQ2 of APO with status 'NOEXEC' i.e. no automatic execution.
Another info:
The queues are CF* and for that we maintained like this:
In ECC (T-code: SMQS): Host id of ECC system is appearing at the 'Schedular Information' section and against the Destination of SCM system we maintained Host id of ECC system once again
In ECC (T-code: SMQR): Host id of ECC system is appearing at the 'Schedular Information' section and against CF* queue Destination with Logon data is blank
In SCM (T-code: SMQS): Host id of SCM system is appearing at the 'Schedular Information' section and against the Destination of ECC system Host id is kept blank
In SCM (T-code: SMQR): Host id of SCM system is appearing at the 'Schedular Information' section and against CF* queue Destination with Logon data is blank
In the light of these, is there something , that I am missing. Please let me know.
Regards,
Avijit

Stuck Messages in Queue in SMQ2

Hi,
I have messages that are stuck in a specific queue seen in SMQ2. when I checked the status of the queue, it is RUNNING and the first message in the queue has a statusText 'Transaction Executing'.
We have deregister - register, activate, unlock, lock the queues already but nothing happened.
there are NO ERROR seen inside the queue.
Already referred to these links:
RECORDED FOR OUTBOUND PROCESS in SXMB_MONI
Recorded for outbound processing
Restarting "Recorded for outbound processing"
Problem Recorded for Outbound Processing...
XI : How to Re-Process failed XI Messages Automatically
thank you.

Hi,
did you check other Tcodes...like SLDCHECK,SXI_CACHE and ST22 whether everthing is working fine.
else as suggested by Rudra, please to ABAP Stack restart.
Regards,
Mastan vali

SMQ2 - Found a queue with name "*" and all other queues stuck in STOP state

Hi all,
We have a problem on the ECC side, on outbound asynchronous proxies. Sometimes a new queue appears on SMQ2 there with name "", and with status "STOP". At this time, all other queues stuck with STOP status... the only way of resetting all those queues to RUNNING state again is to delete the queue named as ""...
Some of you has any idea how this queue "*" appears there and stop all other queues?
thanks
roberti

Hi Ravi,
Is not only about one queue stopped... the problem is this queue named ""... with status STOP, all other queues stops too with it. The only way to make things work again is to delete the queue named as ""... the problem is to discover what or who is creating this stupid "*" queue. I think that this is a procedural error on datacenter, but they are saying is not the case... I'm investigating, but if someone else has any idea about I would appreciate
thanks!
roberti

Error while activating Queue XBTR* in Manage Queues in TCODE sxmb_adm

Hello Experts,
SAP PI is sending the data to ECC through inbound proxy in PI SXMB_MONI it is showing Black colur flag as it is through but in R3 SXMB_MONI messages are in green colur flag showing it is in scheduled state.Data is in quues in SMQ2.
While i try to activate queues in SXMB_ADM it throwing as Error while activating Queue XBTR*
XBTR Queue is in SMQ2.
Regards
Naresh

Hello Naresh,
Check if the queue XBTR* is already registered in your SAP R3 server.
You have to do it first, if not already done.
Regards,
Subhajit

Messages stuck in Queue in production Enviorment

HI ALL,
My messages is been stuck in queue in production envoirment. I have checked in SMQ2 Inbound queue .there in status it is showing SYSFAIL.When i am dbclick on stauts it is showing XI error due JCO communication failure.Mapping Queue..
I am trying to restart thoose messages but are not getting started . what I need to do. Shall I deleted those queues in in SMQ2 or unlock and then restart them.
Note : this is Production Enviorment ...........is right to delete the queue there while they are showing SYSFAIL status.
Please suggest.
Regards

Hi gangadhar kh
just few checks
1) inside the queue check if any message got stuck due to some error . if QOS for that message is EOIO then it will not allow other messages to process until this is not processed
process that and rest message will get processed
2) ask you basis team to update java kernel so that on production system this queue stuck problem should not happen frequently
3) to restart java stack
run tcode SMICM go to menu bar click on AS Java menu ->send soft shut down->with restart
after some time java services will up
then manually reastrat aal the message
Regards
sandeep

Queues indound blocked

I wanted to ask what can I check on my XI, because I often block queues indound, blocking the process of my interfaces.
thanks
umberto

Hi,
check in RWB and Message Monitoring for specific interface.
or
check in TCode SMQ2 for Inbound Queue monitoring
http://help.sap.com/saphelp_nw70/helpdata/EN/76/e12041c877f623e10000000a155106/frameset.htm
Queue Status in SMQ1 and Table ARFCRSTATE
Use
Depending on the way a Logical Unit of Work (LUW) is processed, an inbound queue, outbound queue or table ARFCRSTATE (status table of the LUWs in the tRFC/qRFC target system) can have different statuses.
Outbound Queue
The following statuses may be displayed in transaction SMQ1:
READY
·        The queue is ready for transmission. This status should only be a temporary status. However, in the following case this status can also be permanent: A queue has been locked manually via transaction SMQ1 or via a program, and then unlocked without being activated at the same time. This queue must be activated explicitly.
RUNNING
·        The first LUW of this queue is currently being processed. If a queue in this status hangs for more than 30 minutes, this may mean that the work process responsible for sending this LUW has been terminated. In this case you can activate this queue again.
Note that activating a queue in status RUNNING may cause a LUW to be executed several times if this LUW is still being processed in the target system at that time. We therefore recommend a waiting time of at least 30 minutes before you reactivate the queue.
EXECUTED
·        The first LUW of this queue has been processed. The system waits for a qRFC-internal confirmation from the target system before processing further LUWs. If a queue in this status hangs for more than 30 minutes, this may mean that the work process responsible for sending this LUW has been terminated. In contrast to status RUNNING, this current LUW has definitely been executed successfully. You can reactivate this queue without any problems. The qRFC Manager will automatically delete the LUW already executed and send the next LUW.
SYSFAIL
·        A serious error occurred in the target system while the first LUW of this queue was executed. The execution was interrupted. When you double-click on this status, the system displays an error text. For more information on this error, see the corresponding short dump in the target system (ST22). No background job is scheduled for a retry and the queue is no longer processed. To solve the problem, information from the affected application is required. See note 335162 for the special error text "connection closed".
CPICERR
·        During transmission or processing of the first LUW in the target system, a network or communication error occurred. When you double-click on this status, the system displays an error text. For more information on this error, see the syslog (SM21), the trace files dev_rd or dev_rfc*. Depending on the definition in transaction SM59 for the destination used, a batch job is scheduled for subsequent sending. Status CPICERR may also exist in the following cases although no communication error occurred: A qRFC application finds out that a LUW cannot be processed any further due to a temporary error in the application and therefore calls the RESTART_OF_BACKGROUNDTASK function module to prompt the qRFC Manager to cancel the execution of this LUW and to repeat this LUW later in accordance with the specification in transaction SM59. In this case, qRFC simulates a communication error with the text "Command to tRFC/qRFC: Execute LUW once again." If this error occurs very often, you must contact the corresponding application.
STOP
·        On this queue or a generic queue (for example BASIS_*) a lock was set explicitly (SMQ1 or programs). Note that the processing of qRFC never locks a queue. After having informed the corresponding application, you can unlock and activate this queue using transaction SMQ1.
WAITSTOP
·        The first LUW of this queue has dependencies to other queues, and at least one of these queues is currently still locked.
WAITING
·        The first LUW of this queue has dependencies to other queues, and at least one of these queues currently still contains other LUWs with higher priorities.
NOSEND
·        LUWs of this queue are never sent but retrieved by a special application. These queues are only used internally at SAP (BW or CRM during communication with Mobile Clients). Even if a LUW has been read by the corresponding application (BW, CRM), this status does not change. This LUW is only deleted from the queue if this application confirms collection (collective confirmation possible). Under no circumstances should this status be reset using transaction SMQ1 and the queue activated.
NOSENDS
·        During the qRFC call, the application determines at the same time that the current LUW is not sent immediately. This is used to debug the execution of an LUW via transaction SMQ1.
WAITUPDA
·        This status is set if qRFC is called within a transaction that also contains one or more update functions. As a result of this status, the LUW and thus the queue is blocked until the update has been completed successfully. If this status takes longer than a few minutes, check the status of the update or the update requests using transaction SM13. After a successful retroactive update, the blocked LUW is sent automatically. You can reset this status in the qRFC Monitor SMQ1, and reactivate the queue. Note that this can lead to possible inconsistencies in the application data between the two systems.
If you are using Releases 4.0x, 4.5x, 4.6A or 4.6B, and an update function with the "collective run" type exists in a LUW, an error in the kernel may cause this status. The queue also hangs in this case. This error has already been corrected with a kernel patch (see note 333878).
ARETRY
·        During LUW execution the application has diagnosed a temporary problem and has prompted the qRFC Manager in the sending system via a specific qRFC call to schedule a batch job for a repetition based on the definition in transaction SM59.
ANORETRY
·        During the LUW execution, the application has found a serious error and prompted the qRFC Manager via a specific qRFC call to cancel processing of this LUW. Information from the affected application is required to solve the problem. To solve the problem, information from the affected application is required.
MODIFY
·        Processing of this queue is locked temporarily because the LUW data is being modified.
Table ARFCRSTATE
You can use transaction SE16 to display the status:
EXECUTED
·        The related LUW is completely executed in the target system. The system waits for an internal tRFC/qRFC confirmation from the sending system before this entry is deleted.
HOLD
·        The corresponding application has processed this LUW in parts and wants this LUW to not be repeated in the case of subsequent network or communication errors (see SAP Note 366869 if there are many entries with this status).
WCONFIRM
·        During a LUW execution the application has prompted the tRFC/qRFC Manager to set status HOLD. If the LUW execution has already been completed but this application has not yet signaled the logical LUW end and if the tRFC/qRFC-internal confirmation from the sending system has been received, then this LUW receives status WCONFIRM.
If the respective application informs the tRFC/qRFC Manager about the logical LUW end, then this entry is deleted (see also SAP Note 366869 for more details).
Queue Status in SMQ2 and Table ARFCRSTATE
Use
Depending on the way a Logical Unit of Work (LUW) is processed, an inbound queue or the table ARFCRSTATE (status table of the LUWs in the tRFC/qRFC target system) can have different statuses.
Inbound Queue
The following statuses may be displayed in transaction SMQ2:
·        READY
The queue is ready for processing. This status should only be a temporary status. However, in the following case this status can also be permanent: A queue has been locked manually using transaction SMQ2 or using a program, and then unlocked without being activated at the same time. This queue must be activated explicitly.
·        RUNNING
The first LUW of this queue is currently being processed. If a queue in this status hangs for more than 30 minutes, this may mean that the work process responsible for processing this LUW has been terminated. In this case you can activate this queue again. Note that activating a queue in status RUNNING may cause a LUW to be executed several times if this LUW is still being processed in the target system at that time. We therefore recommend a waiting time of at least 30 minutes before you reactivate the queue.
·        SYSFAIL
A serious error occurred while the first LUW of this queue was being executed. The execution was interrupted. When you double-click on this status, the system displays an error text. For more information on this error, see the corresponding short dump in the target system (transaction ST22). No background job is scheduled for a retry and the queue is no longer processed. To solve the problem, information from the affected application is required. See SAP Note 335162 for the error text "connection closed".
·        CPICERR
A network or communication error occurred while the first LUW was being executed. When you double-click on this status, the system displays an error text. For more information on this error, see the syslog (transaction SM21) or the trace files dev_rd and dev_rfc*. Depending on the registration of this queue (SMQR), a background job is scheduled for a retry. See SAP Note 369524 for the error text u201CLogon failed". Status CPICERR may also exist in the following cases although no communication error occurred: A qRFC application finds out that a LUW cannot be processed any further due to a temporary error in the application and therefore calls the RESTART_OF_BACKGROUNDTASK function module to prompt the qRFC Manager to cancel the execution of this LUW and to repeat this LUW later in accordance with the specification in transaction SM59. In this case, qRFC simulates a communication error with the text "Command to tRFC/qRFC: Execute LUW once again." If this error occurs very often, you must contact the corresponding application.
·        STOP
On this queue or a generic queue (for example BASIS_*) a lock was set explicitly (SMQ2 or programs). Note that the processing of qRFC never locks a queue. After having informed the corresponding application, you can unlock this queue using transaction SMQ2.
·        WAITSTOP
The first LUW of this queue has dependencies to other queues, and at least one of these queues is currently still locked.
·        WAITING
The first LUW of this queue has dependencies to other queues, and at least one of these queues currently still contains other LUWs with higher priorities.
·        ARETRY
When the LUW was processed, the application diagnosed a temporary problem and has prompted the qRFC Manager with a specific qRFC call to schedule a background job for a retry, based on the registration in SMQR.
·        ANORETRY
When the LUW was processed, the application diagnosed a serious error and has prompted the qRFC Manager with a specific qRFC call to stop processing this LUW. To solve the problem, information from the affected application is required.
·        MODIFY
Processing of this queue is locked temporarily because the LUW data is being modified.
Table ARFCRSTATE
You can use transaction SE16 to display the status:
·        EXECUTED
The related LUW is completely executed in the target system. The system waits for an internal tRFC/qRFC confirmation from the sending system before this entry is deleted.
·        HOLD
The corresponding application has processed this LUW in parts and wants this LUW to not be repeated in the case of subsequent network or communication errors (see SAP Note 366869 if there are many entries with this status).
·        WCONFIRM
During a LUW execution the application has prompted the tRFC/qRFC Manager to set status HOLD. If the LUW execution has already been completed but this application has not yet signaled the logical LUW end and if the tRFC/qRFC-internal confirmation from the sending system has been received, then this LUW receives status WCONFIRM.
If the respective application informs the tRFC/qRFC Manager about the logical LUW end, then this entry is deleted (see also SAP Note 366869 for more details).
PS reward me if usefull
reg,
suresh

Queue Probelm in SMQ2

Similar Messages

Maybe you are looking for