QRFC Monitoring ( qRFC Version 6.10.

045 )
SMQS QOUT Scheduler
Topics

- SMQS (QOUT Scheduler)

1. How many QOUT Schedulers are there in a system?
2. Registration of a destination
3. What is the meaning of the different statuses of a QOUT scheduler?
4. What is the meaning of the different statuses of a destination
5. Menu options SMQS
 Registration Table
 Edit
 Goto
 Information
6. When does a QOUT scheduler become active?
7. How can you activate blocked queues again?
8. How should the resources for the QOUT scheduler be configured?
SMQS ( Qout Scheduler )
Normally, all LUWs will be processed immediately in parallel from the QRFC-
Manager in the source system. Unfortunately, problems can arise if the receiving
system is not able to handle a huge number of parallel RFCs. Then, the sending
system receives log entries, like ‘time out during allocate’. This phenomenon can
occur, if the receiving system is not able to handle the amount of incoming parallel
RFCs. On the other hand, if the receiving system could handle all RFCs and the
sending system is substantially smaller , it could be, that all dialog work of the
sending system was used by the parallel RFC. If this happens, you will find status
entries in SM58 or SMQ1 like ‘Sysload’ but this status was not used up to version
6.10.45. In older releases up to version 6.10.035, there was a batch job scheduled to
restart the tRFC/ qRFC, which restarted the tRFC/ qRFC via server groups in parallel.
This led to the problem that the destination system got a heavy RFC load.

Hence, qRFC Version 6.10.045 offers the possibility to define the maximum
number of parallel processing to a certain destination. Now you have the
possibility to steer the number of parallel processing to a destination. This works
for tRFC, as well as for qRFC.
To have more resources in the sending system available we work with a RFC server
group. So it is possible to send the tRFC/ qRFC via one or more application servers.
The server group ‘DEFAULT’ is defined as default setting (as depicted in the
screenshot below). This means, that all active application servers will be used to send
the tRFC/ qRFC to the registered destination. If necessary, you can change the server
group, in case you only want several application servers to send the tRFCs/ qRFCs.

External server programs (e.g. archive systems) had the problem that only one
process was available. If a huge amount of tRFC is created, or the server program
needs more than 20 seconds for a none registered, or more than 60 seconds for a
registered program, you receive an error message like ‘timeout during allocate’ or
‘server program not registered or busy for more as 60 s’ in the gateway trace. This
can be avoided now, if you register these server programs with the maximal
connection number of 1 ( if the registered program is registered once ). The transfer
speed of the data will increase , because the R/3 transfers the tRFCs/ qRFCs only via
the customized number of connections . No CPIC error message will occur ,as was
mentioned above, due to overload.

1. How many QOUT Schedulers are there in a system

There can be one QOUT Scheduler for every SAP client, if you work with registered
destinations.
SMQS screen

Scheduler-Attributes:
- Scheduler Status Status of the Scheduler. To see the current
status you should refresh the screen.
- Last update Time and date of the last activation of the
scheduler.
If the scheduler is active, the time is updated
every 2 minutes.
- Name of AS group Shows the name of the used RFC server
group. The group name ‘DEFAULT’ is
standard and uses all available application
servers in the R/3 system. The RFC server
group can be changed via menu ‘Edit’
‘Change AS group’. Please be sure that the
RFC group used here is available in RZ12. It
is not necessary to maintain AS group
‘DEFAULT’ in RZ12.
- Number of Entries Displayed Number of registered destinations

- Host Id the server, which activates or activated the

scheduler

2. Register a Destination
To register a destination you can push the Registration button at the left upper
side. Then you will get the destination registration screen (see below), to
register a single destination. Different to the inbound queue, the registration of
a generic destination is NOT possible.
 - Destination Name of the registered destination (only single name possible)
- Maxconn Specify the maximum number of used dialog work
processes to execute the qRFC-LUWs to the defined
destination. See 4 (the status WAITCONN)
- Maxtime Maximum runtime of the scheduler within one roundtrip. This
is necessary for the scheduler to have a fair handling of a large
number of different registered destinations.
- No_TRFC if this feld ist selected, only qRFCs will be processed by the
Outbound scheduler whereas tRFCs will be be processed
asynchronously ( tRFC manager)

Before you register a destination you should maintain the appropriate destination in
SM59.
In case you register a destination which is unknown in SM59, you will receive a
SYSFAIL error. In this case, the scheduler is not able to resend the LUW. To resolve
the state, you have to reset the queue status first and then activate the queue again.
The picture below shows a registered destination

- Clt. Client where the scheduler works for.

- Dest. Specify the maximum number of used dialog work
- Type Shows, whether the destination is registered ( R ) or
unregistered ( U ). You can change to unregistered, if you first
mark the queue and then select the Deregistration button.
- No_TRFC if this feld ist selected, only qRFCs are processed using the
the outbound scheduler whereas tRFCs continue to be
processed using tRFC manager.

Utilized push buttons

Delete all selected queues.

Refresh the view of the current screen.
Show the Scheduler status which is also shown
in the first three lines in a separate screen. You can push
the bell again to reach the previous screen.
To register a certain destination. The scheduler will be
activated immediately and process all tRFCs and qRFCs
whose destinations are registered.
To register a certain destination without activating the
scheduler .
To deregister a certain destination.
 You can branch directly into the tRFC monitor.
All tRFC entries (SM58) with the corresponding
destination will be shown. First of all, you should select
the destination which you are interested in.
You can branch into the qRFC monitor. All
qRFC entries (SMQ1) with the corresponding
destination will be shown.

3. The definition of the ‘Type’ attribut

The ‘Type’ attribute in SMQS has the following values and meanings:
o "R": The destination has been registered with the Outbound Scheduler.
The Outbound Scheduler executes the transfer or processing of the
tRFC/qRFC records.
o "U": The destination has temporarily been unregistered. All entries
with this destination remain in the ‘Transaction Recorded’ state until
the destination has either been registered or the entries have been
manually activated via SM58 (for tRFC) or SMQ1 (for qRFC).This is
necessary to debug the tRFC/qRFC function or to suspend the
transmission for a certain time.
o "N": The destination has been excluded from the Outbound Scheduler.
The transmission is executed as before (immediately and
asynchronously to the application).

4. What is the meaning of the different

statuses(eigentlich:stati) of a QOUT Scheduler?

The following statuses of a QOUT Scheduler are possible:

Status descriptions
INACTIVE - The QOUT Scheduler is not active
STARTING - The QOUT Scheduler is currently in the START phase.
ACTIVE - The QOUT Scheduler begins to register the first
destination
WAITING - asynchronous Activation of the destinationen is started and
then the next destination is being activated:
- The QOUT Scheduler waits for free DIALOG work process.
- Activation of all destinations ended, but ?roundtrip? from a
destination or few destinations is/are not finished
SYSFAIL - A serious error occurred in the current operation of the
QOUT
Scheduler. Double-clicking the status displays the respective
error text. Other analyses of the syslog (SM21) or
development traces (dev_w*, dev_rfc* and dev_rd) may be
 required for the fault determination. After solving the problem
the QOUT Scheduler will not automatically restart the LUW
of the registered destination. You have manually reset the
queue status (sysfail) of dedicated queues. This can be done in
transaction SMQ1. .
CPICERR - A communication error occured in the current operation s of
the LUWs of the destination. It breaks off then for further
activities.

5. What is the meaning of the different statuses of a

destination

The following statuses of a destination are possible:

Status descriptions
INACTIVE - The activation of the destination is finisched
- The activation is not relevant for the destination, because
e.q.no LUWs for this destination is available
- The destination at this moment isn’t registered (Typ U oder
N)
ACTIVE - the activation of the destination was started. That means,
there is LUWs of the register destination to activate.
WAITING - The QRFC queue of the destination is ?treating?
asynchronously
- tRFC LUW of the destination is starting asynchronously
- a LUW of the destination is starting
- no free dialogue WP for activating a LUW available
- the activation of LUWs is started, despite the fact it still
runs
WAITCONN - the number of activated jobs of LUWs for a destination has
reached the given value (MAXCONN). It waits for the
completion of a started job.
SYSFAIL - An Error has occurred with the asynchronous start of an
individual LUW of the destination. It breaks off for further
activities.
CPICERR - A communication error occurred in the current operation of
the LUWs of the destination. It breaks off for further
activities.
 6. Menu Options SMQS

Registration table
- Print Print the shown screen.
- Reorganize Delete the complete registration of the destinations.
The contents of the tRFC/ qRFC will not be affected.
- Exit Leaves the schedule monitor.

Edit
- Choose If a line is selected you can change to this certain
destination(SM59). You can check the connection to the
destination by pushing the Test connection button.
- Registration Has the same effect than to push the registration button.
Registers a Destination, so that the scheduler will execute the
tRFC/qRFC which are registered .
 - Registration without activating Register a destination without starting
the scheduler.
- Deregistration Deregister the selected destination.
- Delete Delete the selected registration entry.
You can do the same by selecting the trash can in the upper
left corner .
- Change AS group If the scheduler starts the processing of the LUWs,
a server group will be used to process. The used
application server group can be seen in the third row. If
the name of the application server group was changed
(different from DEFAULT), you should ensure that the
server group is present in the transaction RZ12.
- Activate scheduler Starts the scheduler. The last start time and date can be
seen at the second line in the upper left corner. Also, the
status in the first line will be changed during run time. It
will show an ‘active’ status.
- Change View Show scheduler status.
- Cancel Leave the current screen

Goto
- QRFC Administration Branch to the menu to trigger events within the QRFC
- QRFC Ressourcen Indicate the possible resources for tRFC or qRFC.
The AS group consists of one or more application
servers, and the application server shows its maximum
number of dialogue work processes for tRFC and qRFC.
- Back Leave the current screen and change to the session
manager screen.
Information
- Version Shows the current qRFC version. The current qRFC version can be
different from the R/3 version.

7. When does a QOUT Scheduler become active?

As soon as a LUW is created and has a registered destination, the QOUT Scheduler in
this client is activated by the qRFC manager, if it is not yet already active. You can
also activate the QOUT Scheduler in the current client in SMQS .

8. How can you reactivate blocked Queues ?

If a serious error occurs during the execution of a LUW, this queue receives the status
SYSFAIL or ANORETRY (to be seen in SMQ1). For this queue, no automatic
processing occurs through the QOUT Scheduler. After you eliminated the error cause
after consultation with the person in charge of the application, you can use SMQ1 or
branch from SMQS to the outbound queue to reset the status of individual Queues. A
queue may also be blocked by the status "STOP". Note that qRFC itself NEVER
blocks a queue. Thus, if you see the status "STOP" in SMQ1, this status has been set
by a qRFC application or by an authorized user in SMQ1. The QOUT Scheduler will
not activate this queue until this queue is unblocked by the affected application or
using SMQ1. If a queue is blocked by the status "STOP" for a longer period of time
and you are sure that the queue was not blocked manually by the use of SMQ1,
please contact the corresponding application.

9. How should the resources for the QOUT Scheduler be

configured?
As already mentioned, using RZ12 defines a group of application servers for a QOUT
Scheduler. Moreover, using RZ12 also increases the 'Minimum number of free work
processes' for each of these application servers from 1 (default) to 3, so that you can
also log on to these application servers via SAPGUI. Depending on the number of
registered destinations, a lot of RFC links can be opened at the same time. Therefore
you must adjust the default values of some profile parameters for task handlers or
gateway of the chosen application servers. The following only describes some
important parameters. In the case of more problems with a resource bottleneck, you
should read notes on the task handler or gateway (these include Note 74141).