Skip to Content
0
Former Member
Apr 20, 2010 at 02:57 AM

How To: Isolating a dialog instance?

439 Views

6TB ECC system. We are about to start Archival runs. To minimize the general user community from the performance impact on the CI, came up with the bright idea of a separate dialog instance just to run archival runs (batch/BTC). This is the key point, only archival jobs that we specifically trigger to run on the dialog instance (ie sm37 batch server selection)

Configured an Windows Dialog Instance on W2K3 against a Unix Central Instance.

To Isolate the instance I performed the following:

- SMLG, Logon Server Groups: created dialog group "DO_NOT_USE" to at least give an idea to any "smarties" who try to select a different logon group in SAPGUI (which is only IT, general users have logon pad)

- RZ12, RFC Server Groups created special "archival" RFC group

- SM61, Batch Jobs Server Groups: Configured a standard and archival batch server groups.

We the above 3 configuration in place I would have thought the instance was isolated, nothing would start unless explicity started on the instance. WRONG

After starting the instance I can see running on the dialog

a) TP's may run on the instance if we perform run a migration. This works fine...but I didnt want it to run on the dialog

b) Dialog processing occurs, can see standard user dialog processing running, no users are logged in with AL08/SM04, but can see processing running in SM50. Again processing is not crashing or failing, but again I didnt want anything to run on the dialog.

c) Batch processing. Can see batch jobs running. again didnt want them to start on the dialog (unless it was an archival job that is explicity define to run)

It seems that the CI SAP dispatcher has the dialog server as a resource to be used, and it starts using it dispite my attempts to isolate it with SMLG,RZ12,SM61.

In regard to c) Batch processing, what I could see was our existing scheduled batch jobs have been defined without a server group (or server) and thus the scheduler triggers the job to start on any free BTC process on the CI or DI. This can be fixed by changing the 1000 or so batch jobs to explicity define a batch server group (ie the CI).

Any suggestions to keep the dialog instance from being used (except of course for the archival BTC jobs)?