Viewing Job Level SQL Metrics with the Performance Data Investigator

Previously I wrote about Job Level SQL Metrics in Collection Services. In this week’s blog, I will review the support added to the Performance Data Investigator (PDI) to allow you to view and analyze these job-level SQL metrics.

First, you must have the latest Navigator for i PTFs installed as reviewed in the blog Navigator for i Enhancements. You will also want to verify that you have the PTFs installed and activated that were noted in the Job Level SQL Metrics in Collection Services blog.

The GUI for the new SQL metrics is contained in a content package named Database. This content package will only show up under the list of perspectives in the Performance Data Investigator if you have the Performance Tools licensed program product (5770-PT1) installed; you just need the manager option. Put another way, the enablement for the database graphical interface in the Performance Data Investigator is shipped with PT1.

Once you have the latest Navigator PTFs installed (along with the performance tools and database group PTFs that I reviewed previously), you will discover you now have some new perspectives available in the Performance Data Investigator. In particular, you will notice a new Database folder that includes Database I/O perspectives and SQL Performance Data perspectives. The following screen capture shows this:

You need to drill down into the Database I/O and subsequent folders to find the graphs and charts of data you can now view on Physical Database I/O metrics – as you can see from the following screen capture, you have several views of these database metrics:

If you have not followed the activation instructions required for the Collection Services PTF I previously wrote about, you will get an error if you try to view one of these physical database I/O charts. This is because the underlying data is not collected. Refer to SI47594 PTF Special Instructions for details.

An example of the Physical Database I/O Overview chart is below. You can see the SQL-related physical I/O metrics are summarized by time for the selected collection.

There are several different ways you can view the physical database I/O – by job, thread, user profile, current user profile, subsystem, or server type – to give you various ways to view and analyze the metrics.

You will note that the Performance Data Investigator now also supports viewing data from the SQL plan cache and the SQL performance monitor. I don’t have time in this blog to go into details on using PDI to look at this data, but for those of you who are interested in database performance, it’s worth getting current on your PTFs and checking out these new features.

The Performance Data Investigator development team has created documentation on developerWorks that summarizes the latest enhancements that have been made. There is an article on the new Database content package that you can look at for more information.

Finally, there are some recent changes that were not discussed in the prior blog regarding the SQL metrics. My previous blog stated that this was only supported on the 7.1 release, but the database metrics are now also available on the 6.1 release! Please read the Spring 2013 documentation (which is a subset of the Performance on the web documentation) on the IBM i developerWorks site to get the details regarding the support added to 6.1 and the required PTFs. If you read that Web page, you’ll discover that I have even more to blog about in coming weeks!

 

 

Job Level SQL Metrics in Collection Services

Late last year, IBM enabled new support to collect SQL metrics in Collection Services. I’ll be covering this new capability in two blog articles:

1. This blog will review the new metrics that are now collected and describe what you need to do to enable the collection of these additional metrics.
2. A subsequent blog will review the support added to the Performance Data Investigator to allow you to view and analyze these metrics.

Collection Services collects a wealth of information, but metrics related to SQL operations were limited.  The tools used for DB2 and SQL performance analysis are separate from the system performance tools; interfaces such as the DB2 Health Center, SQL Plan Cache and Index Advisor, among others, are what you need to use to understand database performance issues.

The most recent PTFs augment the tools already available for SQL performance analysis and there are now SQL metrics collected at the job level. This allows you to begin your performance analysis with Collection Services and determine if SQL operations are a contributing factor. You will probably still use the DB2-specific tools for digging into the details, but you now have insight into the SQL operations from Collection Services data.

This enhancement is only available on IBM i 7.1 (i.e., it is not available on 6.1) and requires that you have installed the latest DB2 Group PTF SF99701, as well as SI47594, which provides the Collection Services enablement. It’s also a good idea to ensure that you have the latest Performance Tools Group PTF, SF99145, installed as well.

Just installing the required PTFs is not sufficient. There are activation instructions you must take to enable the collection of these metrics documented in the SI47594 PTF cover letter. The instructions are rather lengthy but not difficult to follow. The Job Level SQL Metrics article on developerWorks also documents these activation instructions.

The reason for these special instructions has to do with the fact that the file, QAPMJOBMI, needs to be updated to a new level to support these additional metrics.  Specifically, an updated template file for QAPMJOBMI is shipped in QSYS with the additional fields. This template file will only be used when creating a new QAPMJOBMI file in libraries where it doesn't already exist. Existing collection libraries (for example, QPFRDATA) that contain a prior version of QAPMJOBMI will not be affected by the PTF.

Once you have the required PTFs installed and completed the necessary activation instructions, you will have SQL metrics in your job-level Collection Services data. The Performance Data Investigator can then be used to view and analyze these metrics. As I mentioned earlier, I’ll write more about the PDI support in a future blog. To be prepared to use this new capability, review the blog Navigator for i Enhancements and install the PTFs as documented in that blog.

The following are the new metrics now available for collection:

New Collection Services metrics for SQL:

The following SQL performance metrics are collected as part of the *JOBMI category.

1. SQL clock time (total time in SQ and below) per thread (microseconds)
   The amount of clock time (in microseconds) this thread has spent performing work done on behalf of an SQL operation.
2. SQL unscaled CPU per thread (microseconds)
   Thread unscaled SQL CPU time used. The amount of unscaled processor time (in microseconds) this thread has used performing work done on behalf of an SQL operation.
3. SQL scaled CPU per thread (microseconds)
   Thread scaled SQL CPU time used. The amount of scaled processor time (in microseconds) this thread has used performing work done on behalf of an SQL operation.
4. SQL synchronous database reads per thread
   Total number of physical synchronous database read operations done on behalf of an SQL operation.
5. SQL synchronous non-database reads per thread
   Total number of physical synchronous nondatabase read operations done on behalf of an SQL operation.
6. SQL synchronous database writes per thread
   Total number of physical synchronous database write operations done on behalf of an SQL operation.
7. SQL synchronous non-database writes per thread
   Total number of physical synchronous nondatabase write operations done on behalf of an SQL operation.
8. SQL asynchronous database reads per thread
   Total number of physical asynchronous database read operations done on behalf of an SQL operation.
9. SQL asynchronous non-database reads per thread
   Total number of physical asynchronous nondatabase read operations done on behalf of an SQL operation.
10. SQL asynchronous database writes per thread
    Total number of physical asynchronous database write operations done on behalf of an SQL operation.
11. SQL asynchronous non-database writes per thread
    Total number of physical asynchronous nondatabase write operations done on behalf of an SQL operation.
12. Number of high Level SQL Statement count per thread
    The number of high level SQL statements that executed during the Collection Services time interval. This count includes only initial invocation, independent SQL statements. It does not include dependent SQL statements invoked from within another SQL statement. This count also includes initial invocation, independent SQL statements which failed to execute successfully.

 

 

 

 

Integrate Web Services With DB2 for i 7.1 Part Two

This week's blog article was written by Nick Lawrence. Nick works for IBM in Rochester, Minn., on DB2 for IBM i. His responsibilities include full-text search for DB2 and SQL/XML. Thanks, Nick!

In part one of this two-part blog entry, the idea was introduced that DB2 for i could be integrated with a Web service, using the user-defined functions in the SYSTOOLS schema and the built-in SQL/XML support. Part one includes a number of links to information about the user-defined functions, and also to information on the built-in SQL/XML support. One important resource was a link to a whitepaper that provides the complete details for these functions.

The second part of this blog entry examines a specific scenario where the data from a Web service is converted into relational rows and columns.

Suppose that a delivery service stores its vehicles' fuel and maintenance costs in a DB2 for i database. In addition to the actual expenses incurred, the application's processing involves the weekly national average cost (per gallon) of fuel. In other words, an SQL query might reference the national average, or the average might be stored in the database for auditing purposes.

This problem has two parts to it.

1. The database must retrieve an XML document that contains the current week's average fuel prices from a Web service (this example uses a Web service located at http://www.fueleconomy.gov).
2. After retrieval, the XML document needs to be transformed into rows and columns.

Figure 1 is a diagram of this setup.

Figure 1 - Web service interaction with DB2 for i

Using the functions that have been provided in SYSTOOLS, we can use SQL to get the average fuel price for the current week as an XML document. This is accomplished using the HTTPGETBLOB function and is shown in Figure 2.

Figure 2 - Retrieve current fuel prices

VALUES
 XMLPARSE(DOCUMENT
   SYSTOOLS.HTTPGETBLOB(
     --- URL ---
     'http://www.fueleconomy.gov/ws/rest/fuelprices',

     --- HTTP request header ---
     '<httpHeader>
       <header name="Accept" value="application/xml"/>
      </httpHeader>'
   )
 )

In Figure 2, the URL identifies the resource that is to be obtained, and the HTTP request header indicates that the data should be returned in an XML format. The XML document that is returned from the Web service is shown in Figure 3.

Figure 3 - Returned XML document

<?xml version="1.0" encoding="UTF-8"?>
<fuelPrices>
  <cng>2.12</cng>
  <diesel>4.16</diesel>
  <e85>3.47</e85>
  <electric>0.12</electric>
  <lpg>2.56</lpg>
  <midgrade>3.89</midgrade>
  <premium>4.04</premium>
  <regular>3.75</regular>
</fuelPrices>

The XML document shown in Figure 3 is not useful in SQL unless SQL has a way of understanding the relationships and data defined by the document. Fortunately, the XML support in DB2 for i 7.1 includes the built-in XMLTABLE table function. Figure 4 shows a query that uses the XMLTABLE function to convert the XML document in Figure 3 into a result set (rows and columns).

Figure 4 - Current fuel prices as rows and column

SELECT fuel_prices.*
FROM
 XMLTABLE('fuelPrices' PASSING
  XMLPARSE(DOCUMENT
    SYSTOOLS.HTTPGETBLOB(
      --- URL ---
      'http://www.fueleconomy.gov/ws/rest/fuelprices',

      --- HTTP Request Header ---
      '<httpHeader>
        <header name="Accept" value="application/xml"/>
       </httpHeader>'
    )
   )

 COLUMNS
   "regular"  DOUBLE,
   "midgrade" DOUBLE,
   "premium"  DOUBLE,
   "diesel"   DOUBLE) fuel_prices;

Figure 5 shows the result set that was created by the query in Figure 4.

Figure 5 - Result set

 

The query in Figure 4 is an SQL query, meaning that it can be easily incorporated into other SQL statements or queries that need to reference the data in Figure 5. An example of how to join data from a Web service with relational data is included in the whitepaper.

Although the HTTP GET request might be the most commonly utilized HTTP method, the SQL UDFs can also invoke the POST, PUT and DELETE HTTP methods. The additional HTTP methods can be invaluable for causing a Web service to take some action in response to an event that happens in a DB2 for i database. Some examples of these HTTP methods are included in the whitepaper.

The HTTP functions really make it easier to access Web services, allowing a software architect more time to figure out the most effective way to use the service. The built-in XML support allows developers and architects to spend their time utilizing the information in XML documents, rather than writing code to compose and decompose XML.

 

 

 

Integrate Web Services With DB2 for i 7.1

This week's blog article was written by Nick Lawrence. Nick works for IBM in Rochester, Minn., on DB2 for IBM i. His responsibilities include full-text search for DB2 and SQL/XML. Thanks, Nick!

The existence of Web services creates the potential to unite the data from remote sources with the data that is stored locally in a relational database. For customers who have not yet upgraded to the latest technology updates of DB2 for i 7.1, integrating a Web service with DB2 for i might be complicated. A combination of non-SQL and SQL code is usually needed to send the HTTP request, and also to construct, interpret and process the messages that are exchanged between the client and server. These infrastructure-related details are not what most developers want to spend their time on; the more desirable option is to focus on using the Web service as a tool to understand and process the business data.

Utilizing a Web service is a lot easier with DB2 for i 7.1 because of two important features:

1. Built-in XML support
2. HTTP user-defined functions (UDFs) in the SYSTOOLS schema

Both of these features are available in the DB2 for i PTF group SF99701 level 23. A portion of this support also exists in previous PTF group levels; however, IBM recommends that customers always load the most recent updates to get the latest enhancements and fixes. An additional requirement is that the HTTP UDFs require Java 1.6 or later (5761-JV1 Option 11, 12, 14, or 15) in order to run.

The built-in XML support is important because XML is commonly used for sending and receiving information between clients and Web services; thus, being able to process XML within SQL is extremely helpful. The integrated SQL/XML support that is available in DB2 for i 7.1 is a significant improvement over the non-integrated XML solutions for DB2 for i that had to be used in previous releases.

The sample HTTP UDFs in SYSTOOLS allow developers to access Web services from SQL, without having to write their own special purpose code or tools. The functions are samples, meaning that they are not covered under the IBM service agreements. Some customers will use the functions in their final solution without change; other customers will design and implement their own tools that do exactly what those customers need. Customers who build their own solutions still get an advantage in that the IBM-supplied tools can be used during the development of the application—allowing the development process to be more agile.

Be on the lookout for a "Part Two" i Can blog entry that will demonstrate an SQL query that uses the new HTTP functions and the built-in SQL/XML functions to convert data from a Web service into rows and columns. I expect Part 2 will be published in a few weeks.

For those developers who need an in-depth explanation of the new technology, the DB2 for i development team has published a whitepaper, Accessing Web services using IBM DB2 for i HTTP UDFs and UDTFs, that describes the HTTP functions in detail. In addition to the functions themselves, this paper provides several examples for accessing resource-oriented (ROA/REST) Web services, and service-oriented (SOA) Web services that employ SOAP as a protocol.

In addition to the whitepaper, a large number of resources are available for developers who are interested in this technology.

HTTP functions added to SYSTOOLS covers the announcement information.

For those who are familiar with DB2 for z/OS and DB2 for LUW, those platforms have delivered similar HTTP functions, and you’ll find information in the article, Accessing HTTP and RESTful services from DB2: Introducing the REST user-defined functions for DB2, on developerWorks.

The DB2 for i development team plans to publish an article specific to DB2 for i on developerWorks. This blog entry will be updated with a link when that article is available.

The DB2 for i development team has published an extensive amount of information on the SQL/XML support available in DB2 for i 7.1:

* The IBM i Information Center now includes an SQL XML programming guide.

* There is a tutorial for XMLTABLE in the previously mentioned SQL/XML Programmer's Guide, Using XMLTABLE to reference XML content as a relational table.

* See also my previous i Can blog post on XMLTABLE, i Can Use XML in a Relational World.

* See also a two-part general overview of XML and how to use it with DB2 for i:

XML Meets DB2 for i

Using XML With DB2 for i

* RPG programmers may find the RPG examples in this article, Using RPG to exploit IBM DB2 XML support, helpful.

* A whitepaper, Replacing DB2 XML Extender with integrated IBM DB2 for i XML capabilities, has been recently published that offers an extensive comparison between the built-in XML support and the XML Extender option of the DB2 Extender product (5761-DE1 and 5770-DE1). The paper illustrates solutions for common problems using the built-in XML support and includes several RPG examples.

* I have posted a short summary of the advantages that an integrated XML solution offers on Mike Cain's DB2 for i blog, Integrating XML – Past, Present, and Future.

XML is a complex topic. If you are looking for education or consulting, consider IBM Lab Services. The DB2 for i Center of Excellence team works closely with the DB2 for i development team and provides DB2 for i customers with exceptional training and consulting services.

i Can Use XML in a Relational World

This week's blog article was written by Nick Lawrence. Nick works for IBM in Rochester, Minn., on DB2 for IBM i. His responsibilities include full-text search for DB2 and SQL/XML. Thanks, Nick!

In this most recent round of announcements, IBM has included support for the XMLTABLE table function in SQL. XMLTABLE is designed to convert an XML document into a relational result set (rows and columns) using popular XPath expressions. This function has been referred to as the Swiss army knife for working with XML because it can help solve a wide variety of XML related problems.

A good tutorial of what XMLTABLE is and how it works can be found in the SQL XML Reference (a new book in the Info Center). The examples show how XMLTABLE can be used to perform a query over XML data in a DB2 column.

What may not be obvious from the documentation is that, the XML support included in DB2 for i can be of enormous help for Web-enabled applications, even when all of the data in the database is stored in a pure relational model.

Consider this example:

Suppose I have an SQL table that I created with the following SQL statement:

create table orders(
     order_id bigint generated always as identity
              (start with 1000 increment by 1),
     cust_email varchar(255),
     order_ts    timestamp,
     product     varchar(255),
     primary key (order_id));

And assume that I’ve inserted the following rows:

insert into orders (cust_email, order_ts, product)
values
('[email protected]',
 '2012-04-15 13:00:00',
 'Camera'),

('[email protected]',
 '2012-04-16 12:00:00',
 'lens'),

('[email protected]',
 '2012-04-01 11:00:00',
 'Book'),

('[email protected]',
 '2012-04-15 13:05:00',
 'Book') ;

My application will receive a request from the Web (in XML format) that contains a customer email and a date range. The application is expected to query the table and return matching orders in an XML format.

For simplicity, let’s suppose I’ve retrieved my request XML document from the Web and stored it in a global variable:

create or replace variable  order_request xml;

set order_example.order_request = xmlparse(document
'<OrderInfoRequest>
   <CustEmail>[email protected]</CustEmail>
   <MinTs> 2012-04-14T00:00:00 </MinTs>
   <MaxTs> 2012-04-30T23:59:59 </MaxTs>
</OrderInfoRequest>' );

For my sample data and the request above, let’s assume a valid response needs to be structured like this:

<?xml version="1.0" encoding="UTF-8"?>
<InfoRequestResponse>
    <MatchingOrder>
        <OrderId>1000</OrderId>
        <CustEmail>[email protected]</CustEmail>
        <OrderTs>2012-04-15T13:00:00.000000</OrderTs>
        <Product>Camera</Product>
    </MatchingOrder>
    <MatchingOrder>
        <OrderId>1001</OrderId>
        <CustEmail>[email protected]</CustEmail>
        <OrderTs>2012-04-16T12:00:00.000000</OrderTs>
        <Product>lens</Product>
    </MatchingOrder>
</InfoRequestResponse>

Without the SQL/XML support in 7.1, this could be a complex task that would involve both an SQL query and some external code to deal with the XML aspects. However, this can now be accomplished with a single SQL query.

The first thing to understand is that we can join the SQL table to a result set generated by an XMLTABLE invocation.

The SQL query that follows returns only the rows that match the specifications within the provided XML OrderInfoRequest document:

select   ORDER_ID,
         CUST_EMAIL,
         ORDER_TS,
         PRODUCT
from
orders,
xmltable('OrderInfoRequest'
  passing order_example.order_request
  columns  "CustEmail"  varchar(255),
           "MinTs"      Timestamp,
           "MaxTs"      Timestamp
) info_request
where
 orders.cust_email = info_request."CustEmail" and
 orders.order_ts >= info_request."MinTs" and
 orders.order_ts <= info_request."MaxTs";

Creating the XML response document can be done by combining the above query with SQL publishing functions. Each of the rows generated by the above query must be converted into “MatchingOrder” elements. The rest of the document must then be constructed around those values.

This might seem complicated, but the trick is to construct the document “inside out,” using common table expressions and arrogations to create the inner values that are repeated.

The following query is all we need to satisfy the application’s requirement.

-- intermediate result set of
-- “MatchingOrder” Elements
with matching_orders as (
 select
  XMLELEMENT(NAME "MatchingOrder",
             XMLFOREST(ORDER_ID AS "OrderId",
                       CUST_EMAIL AS "CustEmail",
                       ORDER_TS AS "OrderTs",
                       PRODUCT AS "Product")
             ) AS ORDER
 from orders,
      xmltable('OrderInfoRequest'
               passing order_example.order_request
               columns "CustEmail" varchar(255),
                       "MinTs"     Timestamp,
                       “MaxTs"     Timestamp
               ) info_request
 Where
  orders.cust_email = info_request."CustEmail" and
  orders.order_ts >= info_request."MinTs" and  
  orders.order_ts <= info_request."MaxTs"
)

-- build InfoRequestResponse element
-- around matching orders
select
XMLSERIALIZE(
  XMLDOCUMENT(
      XMLELEMENT(NAME "InfoRequestResponse",
                 XMLAGG(matching_orders.ORDER)
      )
  ) AS CLOB(1G) CCSID 1208 INCLUDING XMLDECLARATION
 )
from matching_orders;

You may have noticed that the XML xs:dateTime is not a valid lexical format for an SQL timestamp (and vice versa). This is an annoying problem for hand-written solutions, but the SQL/XML functions handle the conversions between the XML types and SQL types automatically for us. Designing the code with SQL/XML ensures that the result is well-formed XML.

The learning curve for using these XML functions can be a little steep. But in the long run, using this support will make the process of modernizing an application to incorporate Web technologies easier. Avoiding the need to write special purpose code to include XML data in your SQL queries makes it easier to adapt and expand the scope of the application as the Web-facing components evolve.

For a more general overview on the XML data model and what it means to DB2, check out these recently published articles:

http://www.ibmsystemsmag.com/ibmi/developer/general/xml_db2_part1/

http://www.ibmsystemsmag.com/ibmi/developer/general/xml_db2_part2/

Announcement for XMLTABLE:

https://www.ibm.com/developerworks/mydeveloperworks/wikis/home/wiki/IBM%20i%20Technology%20Updates/page/XMLTABLE?lang=en

 

 

 

 

 

Query/400 Modernization

This week, Dawn planned to blog about the Print_Query_Definition stored procedure as a great way to help you manage your hundreds or possibly thousands of Query/400 objects. Now I can't do the topic any kind of justice like she can, but she recommends a great article we just posted by Gene Cobb. 

"Sinking in a Query/400 Quagmire?" is a walkthrough of the database and query management problem and how this tool, introduced in V5R3, can help. It also provides some useful examples and offers up IBM Lab Services to help with your Query/400 modernization. 

Dawn will be back next month but she's taking a short break for personal reasons. 

—Tami Deedrick, managing editor, IBM Systems Magazine, Power Systems edition

 

 

Multi-Threaded Interactive Jobs?

A comment was posted to last week's blog on IBM i Job Structures. It read:  

Dawn:
This job structure article jogged my memory regarding a recent situation which I witnessed with a Series i customer. They have multi-threaded INTERACTIVE jobs running on their system. Can you sometime explain the concept of multi-threaded interactive jobs? I know and understand multi-threaded batch jobs but know nothing about multi-threaded interactive jobs. How are they created? What purpose do they serve? From a performance standpoint, does QPFRADJ adjust activity levels for multi-threads of interactive jobs? Any additional info would be helpful. Thanks!

An IBM i programmer cannot create secondary threads in an interactive job; the allow multiple threads parameter on job descriptions is ignored for interactive jobs and you will receive an error if you attempt to run a program that starts secondary threads when in an interactive job. This is because interactive jobs are not thread safe. One reason interactive jobs are not thread safe is because I/O to display devices is not thread safe. 

So how can a multithread interactive job be created? 

Threads were introduced to the system in V4R2. In V4R4, the threads support was extended to add “system threads.” System threads are threads of execution used for system functions and can be created in any job, including interactive jobs and jobs that have the allow multiple threads job attribute set to *NO. Because system threads can only be used by operating system developers, there are expectations for how those threads are used to ensure thread safety issues do not occur. Java uses system threads and several DB2/SQL functions in the operating system also use system threads for parallel operations.

You'll find no documentation in the IBM i Information Center on system threads. There are bits of documentation, however, that will give you small clues about them. For example, the command help for the allow multiple threads parameter includes the following statement: “Specifies whether or not the job can run with multiple user threads. This attribute does not prevent the operating system from creating system threads in the job.”

Next week I'll write about threads and the performance adjuster.

 

Subsystem Configuration for SQL Server Mode Jobs

SQL server mode jobs are the jobs named QSQSRVR that run in the QSYSWRK subsystems. One of the more common concerns that has been raised with QSQSRVR jobs is the difficulty to manage them, and in particular, the inability to configure the subsystem in which they run.

By default, the QSQSRVR jobs will run in QSYSWRK. IBM has made available PTFs on the 6.1 and 5.4 releases to allow you to control the subsystem in which these jobs run. You will need to create an environment variable to turn on the capability to run these jobs in other subsystems. The PTF solution is rather simple; the environment variable indicates that the QSQSRVR server mode jobs should run in the same subsystem as the requesting job.

It is also recommended that you add prestart job entries to the subsystem where the QSQSRVR jobs will be run. Prestart jobs allow the job to be available when the request is received, as well as allowing the job to be reused and are important for best performance. If the prestart job entry does not exist, a batch immediate job will be used, which has more overhead.

See the PTF cover letters for the detailed instructions on creating the environment variable and setting up the prestart job entries. 

• 6.1 – SI33949 
• 5.4 – SI33298 
  
  

In the 7.1 release, this capability is now part of the JDBC connection properties and the CLI connection attributes. You specify the server mode subsystem where the jobs should run. By default, the jobs will run in QSYSWRK, but you can specify a specific subsystem name, or you can specify *SAME, which indicates the QSQSRVR jobs will run in the same subsystem as the job making the request.

Like described above for the PTF solutions on 6.1 and 5.4, on 7.1 you should also ensure that a prestart job entry exists for the QSQSRVR job in the desired subsystem description. If the prestart job entry does not exist, the QSQSRVR job will run as a batch immediate job.