Lesser-Known Features of Work With System Activity

Hopefully most of you now know that in the 6.1 release, IBM moved the Work with System Activity (WRKSYSACT) command from the Performance Tools licensed program product into the base operating system. WRKSYSACT has been around for a long time, but it has a few features that you may not be aware of.

Work with System Activity is a great tool for getting a basic understanding of what is happening on your partition in terms of performance. WRKSYSACT will show you jobs, threads, and tasks that are using system resources – CPU utilization, synchronous and asynchronous I/O, storage allocation information, etc. WRKSYSACT is the only green-screen command interface in the operating system where you will find information about tasks. Other command interfaces – such as WRKACTJOB – only show information about jobs and threads.

It would take far too much space to write about all of the things you can see through WRKSYSACT; rather, there are a few features that I want to discuss in more detail.

 

WRKSYSACT in Batch Mode

First of all, did you know that you can run WRKSYSACT in a batch monitoring mode and write the performance data to a file? You enable the batch mode with the OUTPUT parameter; by default this is * and the information is presented on your display. But there are two additional options, *FILE and *BOTH, which will write the performance data to a database file (QAITMON in QPFRDATA by default). You can specify the sample intervals with the INTERVAL parameter (which also controls the auto-refresh intervals as well) and how many intervals are collected (NBRITV parameter). When you take the option to write the data to a file, a job named WRKSYSACT is submitted to QBATCH to collect the performance data.

The Print Activity Report (PRTACTRPT) command can then be used to print out a report from the sample data collected by WRKSYSACT. The PRTACTRPT command can generate a summary report as well as a detailed report and has options to allow you to specify a timeframe of interest, specific jobs you may want in the report, as well as what criteria the report should use in ordering.

 

Wait Information

Wait information will tell you what a particular job, thread or task is waiting on when it is waiting to do more work. I wrote about wait accounting in “i Can Tell You Why You're Waiting” some time ago. You can also see wait information using WRKSYSACT; you simply need to determine which job/thread/task you want to look at, and use option 6, Wait detail, for that job or task. Option 6 will bring up a display that will list the wait categories for that job/thread/task. Be aware that this is a high-level summary of the kinds of wait for that job or task. However, it make give you some clues about what job or task you need more detailed information for; you can then use the Performance Data Investigator with Collection Services or Job Watcher data to view detailed wait information.

 

Storage Allocated/Deallocated

WRKSYSACT will also show the storage allocated or deallocated by a job/thread/task by pressing the F11 key to get to View 4. I wrote about “Understanding Disk Space Usage” and in that blog reviewed WRKSYSACT and the storage allocated/deallocated information.

 

Scaled CPU

Scaled CPU time is a metric that can be used to determine if energy management features, such as power capping or power savings, are in effect on your IBM i partition. These energy management capabilities can be turned on through Active Energy Manager, which is a plug-in to IBM Systems Director. When you use these energy management features, the system's processor may run at lower or higher frequencies, which can affect your partition's performance. I wrote about this topic at length in the blog “i Can Understand Scaled CPU Time.”

On the WRKSYSACT display, the value “Average CPU rate” will be displayed if you are using energy management capabilities. This rate is an easy way to determine if your processor has been slowed down due to power capping or power savings.

One final note – one thing that has not changed with WRKSYSACT is the limit of one user at any given time. WRKSYSACT collects a lot of information from critical interfaces in the operating system and the limit of one user ensures limited contention on those critical interfaces.

 

 

 

 

IBM i Diagnostic Tools – i Does it Better

A few weeks ago, I wrote about Job Trace, followed by an update on how you can instrument your applications for IBM i job trace. Job trace is but one of many tools used to collect diagnostic data on i.

The diagnostic tools integrated within the operating system provide the capability to collect detailed data that's required identify and resolve the root cause of software problems. The tools used for problem determination fall into two main categories -- the tools used for functional problems and the tools used for performance problems.

Tools used to resolve function problems -- whether the problem might be incorrect results, errors and exceptions, or unexpected failures -- are generally tools that support dumps, logs, and traces. On i, logs are generally in the form of messages; job logs, message queues and the history log are well known by i users.

Traces can be collected at the operating system level (aka, “above the MI”) or at the Licensed Internal Code level (aka, “below the MI”). There are different kinds of traces that are used depending upon what part of the system needs to be traced -- job trace, LIC trace, communications trace, trace TCP application and many more. “Flight Recorders” are a special always on type of trace that can be dumped out when necessary to start problem determination without recreating the issue.

Dumps are methods to collect detailed data, whether that data is for a job, an object or a data structure. Dumps may be used to collect internal information as well as application data details. Dumps can be initiated from commands and APIs, as well as the Display/Alter/Dump service function.

Performance tools provide the capabilities used to aid with the root-cause resolution of a performance problem; performance tools are generally used to identify why something isn't performing as it should, optimizing and tuning performance to keep it running well, and planning for future growth. The i performance tools tend to collect data at all the various layers of the system (the OS and LIC), so different tools are not required depending upon where the problem is suspected to be. The IBM i performance tools include Collection Services, Job Watcher, Disk Watcher and Performance Explorer. A future blog article will explore the different kinds of performance data collectors and when you would use each type.

The following simple diagram shows the primary diagnostic tools for functional or performance diagnostics and whether the tool is used for operating system or LIC diagnostics.Perhaps one of the biggest challenges is understanding all the tools that are available and when to use each one -- after all, there is a very rich set of diagnostic tools built into the operating system.

The second challenge is capturing the data needed for root cause problem resolution -- often times the required traces are not running the first time a problem occurs and the problem must be recreated with additional diagnostic tools enabled to required debug information is collected. That's why some of the capabilities built into the operating systems are always on, allowing for some level of troubleshooting without the need to recreate the problem. Messages, flight recorders, Service Monitor and Collection Services are all examples of features that IBM intends to have running all the time to enable this “First Failure Data Collection” -- the ability have the detailed information to begin diagnostic sleuthing the first time a problem occurs.

This rich set of diagnostic tools is a differentiator for IBM i; everything you need for diagnostics is built into the operating system. Analysis of that data, however, might present other challenges! On other platforms, diagnostic data is often simply written to flat files (called stream files on i) and are often just text strings, with little consistency from one piece of software to another on how the diagnostic data is collected. The development team for the i operating system has guidelines on how code should be instrumented for functional and performance diagnostics and the consistency these guidelines provide is a major value-add of i.

Two excellent Redbooks resources cover the diagnostic tools for i:

• i5/OS Diagnostic Tools for System Administrators: An A to Z Reference for Problem Determination 
  This redbook was written with the V5R4 release, but the information is still applicable to 6.1 and 7.1.
• End-to-End Performance Management on IBM i
  This redbook covers everything you might want to know about performance management on i, including all of the performance tools that are built into the system and the basics of when and how to use each.

 

 

Customizing a Perspective in PDI

If you’re on IBM i 6.1 or 7.1, I hope you've already tried out Performance Data Investigator (PDI) to analyze your performance data. If so, you may be ready to modify or change some of the provided charts and tables for your analysis preferences. Today, I’ll highlight how you can use Design Mode to customize charts.

If you haven’t tried PDI yet, check out Dawn’s article “Getting Started with the Performance Data Investigator” and then come back to read on customizing the perspectives.

In order to customize a perspective, you'll need to make sure that you have Design Mode enabled. With design mode enabled, additional advanced edit features become available. You'll be able to edit and save perspectives into any unlocked content package. To enable Design Mode, go into Investigate Data, select the Options button which appears at the bottom of the Perspective List panel to get to the Options panel. On the Options panel, click on the Enable Design Mode checkbox and select OK.

You'll want to create a new content package to have a place to save your modified or created perspectives that will be visible and usable by others on your system.

Start by displaying the locked perspective you want to modify (with any valid collection for that perspective). Then select one of the Edit buttons available to get to the Edit Perspective or Edit View panel.

From the Edit Perspective panel you can edit the perspective information (Name and Description), add a view or select a view to edit.

From the Edit View panel, you will see the specifications that make up the view and can be modified (Name, Type, DataSet (SQL), Drilldown options, Chart properties such as DataSeries and Thresholds).

By selecting ModifySQL, you can view and make changes to the SQL that creates the data set. This information could be helpful to an experienced SQL developer.

By selecting the Edit button for a Data Series, you can make changes to how the data will be displayed for the chart.

Editing the data series allows you to view and change the way the performance collection is charted. You will be able to modify some of the specifications such as the range and type of chart (bar or line, stacked or clustered), color and pattern choices, breakdown dimension and tooltips.

After editing a locked perspective, use the Save As button to save the changes into a new location. Select the new package created and change the name if desired. Click on Save. When you return to the Perspective List panel, you will see the newly saved perspective.

The capability to edit perspectives in Performance Data Investigator is a great way to give you exactly what you need for analyzing performance data. For a more in-depth description of editing, go to the IBM Systems Magazine article or developerWorks iZone IBM i Performance Data Investigator - Edit Perspectives article. 

 

This week's blog article was written by Lora Powell. Lora is a member of the Performance Tools team in the IBM i development lab and works on the Performance Data Investigator. Thanks, Lora!

 

Job Log Output

Last week I wrote about Job Log Pending. With job log pending, you do not have to write job logs to spooled files.

At the end of that blog, I mentioned how you can use the Log Output (QLOGOUTPUT) system value or job attribute to take advantage of job log pending. This week, I'll explain the values available for “Log output” and give some general recommendations.

There are three options for the log output system value: 

• *JOBEND – the job log is written to a spooled file when the job is ended. This is the default value and is compatible with prior releases and how job logs were generated.
  
  
• *JOBLOGSVR – when the job ends, the job log remains in a pending status until the job log is written to a spooled file by the job log server.
  
  
• *PND – the job log is not written to a spooled file, but remains in a pending status.

While the shipped value for log output is *JOBEND, IBM recommends that you use the job log server. Using the job log server has a major advantage - the generation of the spooled job logs is handled in a more controlled manner. Remember the scenarios I described in last week's blog where you could potentially have hundreds or thousands of jobs writing job logs at the same time? That is a significant drain on system resources. By having the job log server generate the spooled job logs, the system controls the amount of work that is done at one point in time; if there are a lot of job logs to be written, the job logs will remain in a pending state until the job log server can write the job log to the spooled file.

But do you really need all those job logs written to spooled files? If you don't, you should think about using the pending attribute. Job logs that are in pending status will never have their job log written to a spooled file unless you take explicit action to do so. The system's automatic cleanup function will removing pending job logs in the same manner as it removes spooled job logs. If you need to display or print a pending job log, you can use one of the following methods: 

• Use the Display Job Log (DSPJOBLOG) command and direct the output as required.
• Use the WRKJOB or WRKUSRJOB command on ended jobs with pending job logs, similar to how you would work with an active job.
• Use the Work with Job Logs (WRKJOBLOG) command.
• Use the Change Job (CHGJOB) command to change the Log Output value from *PND to *JOBEND. This will write the job log to a spooled file and move the job to output queue status.

 

Job Log Pending

Job log pending has long been a possible state for a job log. When a job has a pending job log, the job has ended but the job log has not yet been written to an spooled file. In older releases of IBM i, this could occur when you powered down the system – the job logs would be saved in a pending state and the job logs would be written to spool files when the system was powered back up.

Every job on the system has a set of job structures, as I described in the IBM i Job Structures blog earlier this year. Job log messages are stored in an internal structure that is called the “job message queue.” The “traditional” behavior is for job log messages to be written a spooled file when the job ends.

However, think about certain scenarios: You end a subsystem that ends many jobs. You have a network failure that causes all Telnet sessions to be terminated. You have a runaway job in a loop that creates an unexpected number of jobs that do a small amount of work and then end. Or other situations where a large number of jobs are ended at about the same time.

In each of these scenarios, you can potentially have hundreds or even thousands of jobs that will all end at about the same time. If all of these jobs that are ending are also writing their job logs to spooled files, you can imagine the additional workload that would put on the system - writing job logs is a fairly expensive operation. Do you need to have all those job logs written? Do you have a need to save those job logs at all?

In the 5.4 release, IBM made job log pending a much more valuable and available option to use for job logs.

Rather than writing job logs to spooled files, job log pending allows you to keep the job logs in the internal form that is used when a job is active. No additional system resources are required to keep a job log in pending form (other than the job structure used to store information about the ended job).

Job log pending is controlled by the Job log output system value (QLOGOUTPUT) or the Job log output attribute on job descriptions.

There is much more to be written about job log pending, which I will do in subsequent blogs.

 

 

 

IBM i Job Structures

Last week, I wrote about detaching spooled files. As I was writing that article, I started to describe the IBM i job structures. It became apparent that there was too much information for that one blog, so this week I'll review IBM i job structures.

There is little formal documentation on job structures. You can find bits and pieces in the Information Center if you look at the documentation for the Display Job Table (DSPJOBTBL) command or the Create Job Structures API. The Display Job Table online command help ('green screen' help) probably has the most information regarding job structures.

Every job on the system has three main pieces that I generally refer to as “job structures”:

• an entry for the job in the job table
• permanent job structures
• temporary job structures

The “job table” is also called the “work control block table” and is the primary data structure used to keep track of all jobs in the system. Jobs on job queues, active jobs and ended jobs with spooled output all consume an entry in the job table. The job table is of limited size and can hold approximately 485,000 entries; thus the upper limit on the Maximum Number of Jobs (QMAXJOB) system value. It's not a good idea to run near the maximum number of jobs, as I described last week. The system job table should be kept to a reasonable size, and if you generally have a consistent number of jobs, the system will automatically do this for you.

The system has a built-in notification mechanism for when the job table is nearing its maximum capacity, as configured by the QMAXJOB system value. By default, the system will send the CPI1468 message (“System job tables nearing capacity”) to the QSYSOPR message queue (and to the QSYSMSG message queue if it exists) when the job tables are 90 percent full. IBM has provided the capability to customize the percentage at which this message is sent. PTFs for 5.4 (SI29585) and 6.1 (SI30171) provide this support (no PTFs are needed for 7.1 as this support is part of the operating system). You create a data area named QMAXJOBPCT in QSYS to control the percentage at which you want the warning message to be sent. See the PTF cover letters or the redpaper referenced at the end of this blog for the detailed instructions.

If you have a 'run-away' job situation occur where you have many more jobs than is typical, you may want to consider compressing the job table. This is an action that is done at IPL and can be long-running. You should only do this when necessary. The system IPL attribute of Compress Job Tables controls this; the default value is *NONE and is recommended. If you have a need to compress the job tables, use the value of *NEXT. The Rochester Support Center has a couple knowledge base articles regarding job tables and job table compression that you may find helpful:

• Slow IPLs and Job Table Compression
• Job Table Capacity

The permanent job structures are as the name implies -- permanent and survive IPLs. These job structures are what allow ended jobs with output to remain on the system until the output is deleted or detached from the job. The permanent job structures consist of three main pieces:

1. the spool control block
2. the job message queue (for job log messages)
3. the local data area

The temporary job structures are temporary, do not survive IPLs and are only associated with a job when it is active. There are many parts to the temporary job structures and they include such things as:

1. the process control space
2. the qtemp library for the job
3. the job performance data space for performance data
4. … and several other structures

The permanent and temporary job structures are created ahead of time and managed by the system. They are recycled for reuse; that is, once a job ends, the temporary job structures can be used by another job. Once the job has left the system (ended and no spooled files associated with it), the permanent job structures can be used by another job.

The Total Jobs (QTOTJOB) and Active Jobs (QACTJOB) system values define the initial values for the total permanent and temporary job structures. The Additional Total Jobs (QADLTOTJ) and Additional Active Jobs (QADLACTJ) system values define how many additional permanent and temporary job structures are created when necessary.

As I wrote last week, ended jobs with spooled output continue to use a job table entry and the permanent job structures for that job. Detaching spooled files can free up those structures for use by other jobs and reduce the number of jobs on the system.

Jobs can also have their job logs in an pending state (job log pending). I haven't yet written about job log pending, but jobs with pending job logs also consume an entry in the job table entry and a permanent job structure. Good job log management can reduce the number of jobs on the system and I will write more in the future about job log management.

The redpaper “Best Practices for Managing IBM i Jobs and Output” has more information on this topic along with recommendations for setting the system values to control job structure management by the system, considerations for job table compression, more information on the job table warning PTFs, as well as suggestions for reducing the number of jobs on the system. This redpaper is one I consider a “must read” for all IBM i administrators.

 

 

Avoid Locking Libraries in the Library List

There is a system value, Library Locking Level (QLIBLCKLVL), that you can use to control whether libraries that are in a job's library search list are locked. This system value is not new – it has been around since the V5R1 release – but it seems that it’s not very well known as I've talked with several people who’ve never heard of it.

The Library Locking Level system value has the default value of '1', which indicates that the libraries in the library search list are to be locked in each job. Each library in a job's library search list is locked when the job is started and the locks are released when the job ends.

As the number of active jobs on a system grows, the number of locks just for libraries can get very large. Consider an example where there are 1,500 user jobs and the library search list has 10 libraries – that's 15,000 locks held on the system just to protect those 10 libraries. This is not an efficient use of the system's locking table. This affects the performance of job initiation and termination when the locks are allocated and released; it also has an effect on overall system performance as there is a single lock table and additional overhead as this table grows very large.

The “Best Practices for Managing IBM i Jobs and Output” Redpaper documents IBM's recommendation of setting this system value to 0 to not lock the libraries in the library list.

While IBM recommends setting this system value to 0, to not lock the libraries, it could not make that value the default value because, without additional changes, setting this system value to 0 would allow a library to be deleted or renamed even when the library is in the library search list.

If you change the QLIBLCKLVL system value to 0, you need to take an additional step to prevent the libraries from being deleted or renamed—you just need one job to allocate the libraries you want to protect. This job can be set up as an autostart job that runs in the controlling subsystem; it would simply do an Allocate Object (ALCOBJ) on each library that needs to be protected, then loop on a Delay Job (DLYJOB) command. This job would remain active until the controlling subsystem is ended or the job is explicitly ended.

By using this strategy, you can protect the libraries from being deleted or renamed and you can greatly reduce the number of locks on the system.

One final point - the QSYSARB system job locks the libraries that are defined in the system library list (QSYSLIBL) and the user library list (QUSRLIBL) system values. IBM has a support article on this. 

 

 

 

PTFs for Additional Work-Management Controls

The work-management team recently made available some changes with PTFs to help control the behavior of job creation for cases when a program may get in a loop submitting jobs. The change made with the PTF is to slow down the creation of new jobs when the system is approaching the limit for the maximum number of jobs (QMAXJOB system value). 

QMAXJOB defines how many jobs can be on the system and includes all jobs: jobs submitted to a job queue, active jobs and ended jobs with spooled output. When the system reaches the limit specified by QMAXJOB, no more jobs can be started and the system can become inoperable. 

There’s a warning message--CPI1468 “System job tables nearing capacity”—that’s sent to QSYSOPR when the system is nearing the limit of the maximum number of jobs. Support was added to customize when these messages are sent with the following PTFs:
•    6.1 - SI30171
•    5.4 - SI29585
•    This same function exists in 7.1 without additional PTFs

By default, the CPI1468 is sent when the job tables are 90-percent full. In some situations, that’s too late and you don’t have time to recover from the condition. Create a data area named QMAXJOBPCT in QSYS with the desired percentage value at which you want the message to be set. The PTF cover letter has more detail.

The new PTFs that slow down the creation of new jobs when the system is approaching the QMAXJOB limit are:
•    7.1 – SI40568 
•    6.1 – SI40569
•    5.4 – SI40571

With these PTFs, the system adds delays to starting new jobs when the number of jobs is at 90 percent of the QMAXJOB setting. Override this percentage by creating a data named QWTSBSDLY in QSYS; for example, you could have the threshold be set to 80 percent. There are no delays if the number of jobs in the system remains below that percentage.

The delays start at a half second, but are increased as the system approaches the QMAXJOB limit. A single delay isn’t noticeable, but if you have a job that’s looping starting jobs, these delays can add up and offer some protection to keep the system operational as you approach the QMAXJOB limit. You can still run out of job-table entries, but it will take longer and you’ll have a little more time to react to the situation.

In 2008, we wrote a Redpaper, “Best Practices for Managing IBM I Jobs and Output (and a few other special tips)." This Redpaper covers general recommendations for improved management of jobs and output. Provided in that Redpaper is a sample CL program source for a Submit Job (SMBJOB) exit program. The submit job exit program is the best way to control the runaway submission of many jobs.

Another set of PTFs were provided that change the default behavior of the system to briefly display the end-of-job display when an interactive job ends. Previously, when an interactive job was ended, the end-of-job display would remain until the user pressed enter or 30 seconds had passed.  With these PTFs, this delay is removed and the interactive jobs are ended immediately without delay due to the end-of-job message; the message is still sent, but is only seen briefly. This change is helpful for ENDSBS, for example. Prior to the PTFs, ending an interactive subsystem would generally not end the jobs right away because the end-of-job display would be displayed for 30 seconds for those jobs where the user didn't press enter. With these PTFs, the jobs are ended right away.

These  PTFs are:
•    7.1 – SI40867
•    6.1 – SI40866 

The PTF cover letters containing documentation on how to create a data area named QWTEOJDSP in QSYS to get the old behavior back.

Find Hot Spots Using Program Profiling

This blog is written by Bill Schmidt, the team leader of the IBM i Optimizing Translator team.

Here’s another tip for improving the performance of your ILE applications. In my last blog entry, I explained when argument optimization may speed up your programs and service programs. Today, I’d like to talk about another technique you may not be familiar with: program profiling. As with argument optimization, a full description of program profiling can be found in chapter 13 of IBM i ILE Concepts (SC41-5606-09).  For simplicity, I’ll just call it “profiling” in the rest of this post.

The idea behind profiling is to find the hot spots in your program–the most frequently executed procedures, and paths through those procedures. Once the hot spots are identified, the optimizing translator performs extra optimizations on those portions of your code to speed them up. Normally, the translator doesn’t know which paths are most important, so it tries to optimize all paths equally. With profiling, the translator can do a much better job.

Profiling Overview

At a high level, profiling consists of three phases:

• Instrumentation

• Data gathering

• Optimization

In the instrumentation phase, code is compiled with a special option, asking the translator to insert extra “profiling hooks” into your code. These hooks are small snippets of code, designed to count how often various events occur within your programs, such as how often a procedure is entered or how often a loop is executed.

In the data-gathering phase, instrumented programs are run for a while, using input data that’s representative of what you expect your programs to normally see. The hooks in the instrumented programs will maintain a table of counters that are stored away as part of the instrumented program or service program objects.

In the optimization phase, you compile your code a second time, this time with a different option that asks the translator to use the gathered profile data. The translator analyzes the counters and determines the hot spots in your code. This information is used to optimize each procedure for better performance and to package the hottest procedures together for more efficient use of computer memory. This is called applying the profile data.

When to Use Profiling

It’s important to note profiling improves the performance of your application level code.  It doesn’t improve other aspects of the system that affect performance. For example, if your application spends 90 percent of its time in system calls to access the database, profiling can only improve the performance of the other 10 percent. In such an application, the benefit from profiling may be minimal. If, however, your ILE application spends at least 25 percent of its time in the application code, then you may see a noticeable improvement from profiling.

Programs and service programs consisting of many procedures with frequent procedure calls will generally see more improvement from profiling than those having only a few procedures. This is because profiling is used to improve automatic inlining of one procedure into another, and the optimization to package hot procedures together is more effective when there are many procedures. However, programs with only a few procedures can still see significant benefit from profiling.

Since profiling takes some additional effort, it should be done late in your application development cycle so it isn’t done repeatedly. Typically your application should be complete and well-tested before applying profiling to improve performance.

The Commands

Instrumentation may be added when creating or changing modules, or when creating or changing service programs. Use the PRFDTA(*COL) parameter to specify that an object is to be instrumented to collect profile data.  Examples:

    (1) CRTCPPMOD MODULE(MYLIB/MYMOD) OPTIMIZE(40) PRFDTA(*COL)

    (2) CHGPGM PGM(MYLIB/MYPGM) PRFDTA(*COL)

Note the use of optimization level 40 on the CRTCPPMOD example. You must use at least optimization level 30 (or *FULL) when instrumenting code for profile data collection.

The second example is the most common way of instrumenting code. Once your program is complete and tested, use CHGPGM or CHGSRVPGM with PRFDTA(*COL) to instrument the entire program at once.

The next step is to collect profile data by running your instrumented code. Select input data that will cause your code to use the same paths while collecting data that will be used when the application is in production. Also, be sure to run your code long enough that the most important parts of your code are exercised a significant number of times, so the frequently executed paths can be determined. Note that the instrumented code will run approximately 30 percent slower than code without instrumentation, so plan accordingly!

Before you run your code with the sample input data, run the start program profiling command:

    STRPGMPRF

This tells the system you want to collect profile data. If you don’t run this command, the instrumentation hooks in the code you just compiled won’t do anything. Each hook contains a fast lookup to see whether profiling is currently enabled on the system.

Why is this necessary? Consider a complex application that spends much time in start-up activities before reaching a normal steady state. If you have such an application, you may decide you only want to collect profile data after the steady state has been achieved. In such a case, you’d start your application first, and only after start-up is complete would you issue the STRPGMPRF command.

Note also that STRPGMPRF is a system-wide command. It enables profile data collection for all instrumented programs running on the system. This is important since many applications these days run in multiple cooperating tasks. It means you must be careful to coordinate profiling sessions with all users on your system.

When you’ve finished gathering enough profile data, execute this command:

    ENDPGMPRF

This turns off profile data collection on the system. You don’t need to stop your application before entering this command.

Profile data gathering is additive. That is, if you collect data for an instrumented program once, and then collect more data for it later, the profile data counters will contain the data from both sessions. Sometimes this is what you want, but sometimes you might feel that the data you gathered wasn’t useful, and you want to start over. You can clear all the profile data counters to zero using the following command:

    CHGPGM PGM(MYLIB/MYPGM) PRFDTA(*CLR)

Once you have gathered all the necessary data, it’s time to apply the profile data using CHGPGM:

    CHGPGM PGM(MYLIB/MYPGM) PRFDTA(*APYALL)

This command causes the optimizing translator to read the profile data that was gathered in the previous step, and use it to optimize the code based on the frequently executed paths.

There are other keywords that can be used when applying profile data, but we recommend that you always use PRFDTA(*APYALL). You can refer to IBM i ILE Concepts if you’re curious about other options.

That’s all there is to it!  Your application is now ready to run, and hopefully performs faster than ever.

The Advanced Optimization Techniques chapter of IBM i ILE Concepts contains a great deal of detailed information about Program Profiling. I highly recommend that you read it if this brief overview has whetted your interest.

How to Use the Integrated Web Application Server

This week’s blog was written by Mark Schroeder. Mark is the team leader of the Web Integration team and architect of the Application Runtime Expert product. He has worked in Java and Web technologies for IBM i for the past 10 years.

Are you looking for a simple way to get started with Web applications? Are you overwhelmed by the complexity of creating an application server, configuring it, and finally trying to deploy your application into the server? Do you need a simple “on ramp” to the Web? If your answer to any of those questions is yes, then the IBM integrated Web application server (IAS) may be just what you need.

IAS is a lightweight, Java software-based application server that’s integrated into the IBM i operating system. IAS provides an Open Services Gateway initiative (OSGi)-based Web container where JSP and servlet-based Web applications run. Web applications running in IAS can access IBM i DB2 databases using JDBC, with support for both the native and IBM Toolbox for Java JDBC drivers.  IAS runs on the IBM Technology for Java JVM, which--combined with the modular OSGi Web container--means the server starts very fast and has a small memory footprint. The IAS server is a reliable place to run both your development and production Web environments and, since it shares some common technology with IBM’s WebSphere Application Server, once your Web application gets to the point where you need additional function and high-end performance, you can easily move it to a WebSphere environment.

But what really sets IAS apart from other application servers is how simple it is to use: creating a server and deploying Web applications is very simple. And because IAS is integrated into the IBM i operating system, there are no separate install or setup steps to get it – you already have it. Maintaining IAS with the latest fixes and updates is also simple; all updates are made via PTFs. There are no additional scripts or installers required; just load and apply the PTFs and all IAS servers are updated to the latest fix levels.

So how can you start using IAS? The easiest way to get started is by using the IBM Web Administration for i. This GUI interface makes creating and managing IAS servers easy. It provides intuitive wizards for performing tasks such as creating a new IAS server or deploying a Web application into an existing server.  Additionally, the IBM Web Administration for i provides the capability to manage many aspects of an IAS server, all from a single, easy-to-use GUI interface.

The IBM Web Administration for i is part of the Admin server that runs on every IBM i system. It can be accessed via the following URL: http://hostname:2001/HTTPAdmin.The "hostname" part of the URL is meant to be substituted with the actual host name of a customer's IBM i system.

To give you an idea of just how simple it is to start using IAS, let’s walk through an example of how to create a new IAS server. Once you have accessed the IBM Web Administration for i GUI, click on the Create Application Server link in the Common Tasks and Wizards list in the GUI’s navigation bar:

This will launch the Create Application Server wizard. The first step provides an introduction to the wizard. After clicking the Next button, you’re asked to select an application server type. To create an IAS server, select the IBM integrated Web application server for i server type:

Depending on the IBM i release, the IAS server version choice will be either V8.1 or V7.1. At this point, all that’s left between you and a fully operational IAS server are six simple steps.

Since the wizard provides very detailed information during each step, we won’t cover the entire create server wizard in detail. But here’s a brief summary of what information is required at each step in the wizard:
    Step 1: Provide a server name and description.
    Step 2: Specify the port range for the server.
    Step 3: Provide HTTP server information (name, description and IP address to listen on). The HTTP server will be the front-end Web server for the IAS application server.
    Step 4: Specify the user ID that the IAS server will run under.
    Step 5: Informational step that describes the Eclipse Help application, which is installed in every IAS server.
    Step 6: Summary of the information provided in the previous five steps.

And that’s it. Upon completion of the wizard, the IBM Web Administration for i creates and configures the IAS server and, once completed, automatically starts it. Typically, it takes a couple of minutes to create, configure and start the new server. Once the IAS server has been created, it can be managed using the IBM Web Administration for i GUI. 

Deploying applications into an IAS server is just as easy as creating a server; a wizard guides you through a few steps and, once completed, the application is deployed and automatically started for you. To deploy your application, all you need is to have it packaged into a Web Archive (WAR) file. The GUI interface will take the WAR file and convert it into the format required by IAS; this is done automatically by the GUI using a built-in conversion utility. Once the conversion is complete, the application is deployed and started. Once started, the application is ready for use.

As previously discussed, IAS is updated via PTFs. The best way to ensure you have the latest features and fixes for IAS is to apply the latest HTTP PTF group. The HTTP PTF group number for each IBM i release is:
•    IBM i 5.4: SF99114
•    IBM i 6.1: SF99115
•    IBM i 7.1: SF99368

IAS is a fast, reliable and simple way to deploy and run Web applications. The simplicity of IAS makes it an excellent on ramp to the Web by hiding much of the complexity often associated with creating, configuring and maintaining a Web application server. For more information about IAS, including a complete tutorial on creating, managing and deploying applications into an IAS server, visit the IAS product website.