TCP/IP Redundancy with Virtual Ethernet in IBM i

This week's blog was written by Colin DeVilbiss. Colin develops Communications and Virtual I/O support for IBM i in Rochester, MN. Thanks, Colin!

IBM i 7.1 Technology Refresh 3 added support for Ethernet Link Aggregation, as previously featured in the i Can blog "Ethernet Link Aggregation in IBM i" and the tip IBM i Aggregate Ethernet Lines on IBM developerWorks. An aggregate line description combines multiple physical Ethernet ports. The line description can then be used for TCP/IP configuration just like any other line description, but the incoming and outgoing traffic will be spread among the available ports. As a side benefit, the line description will remain active as long as any of the aggregated ports are available.

Link aggregation is a great redundancy solution for IBM i partitions that have multiple physical Ethernet ports available, all of which can be connected to a single Ethernet switch that has support for link aggregation. However, as some have commented on those articles, link aggregation does not work with virtual Ethernet ports that are connected to the internal Ethernet switch of the Power Hypervisor. This means that it is not useful to partitions that connect to the network via a Shared Ethernet Adapter (SEA) in a Virtual I/O Server (VIOS) partition or via an Ethernet layer-2 bridge provided by an IBM i partition (which was also added in Technology Refresh 3).

 

SEA Failover

One solution is to use a pair of VIOS partitions, each with an SEA bridged to the physical network, and to have the Shared Ethernet Adapters configured for failover, which provides redundancy without any additional configuration in the bridged partitions.

 

Virtual IP Addressing

Bridged IBM i partitions can get Ethernet redundancy from the existing Virtual IP Address (VIPA) support provided by IBM i. Specifically, I will describe solutions based on VIPA Proxy ARP.

Unlike other IP interfaces, a VIPA is not bound to a line description. Instead, the user chooses a list of existing IP interfaces that will serve as proxies to connect the VIPA to the network; these are called its preferred interfaces. They are kept in priority order, and the VIPA will be serviced by the first active interface in the list.

 

Physical Interface With Virtual Backup

Given this, we can build a setup that will default to using a physical Ethernet port but will use a virtual Ethernet port instead if the physical port becomes unavailable. For this example, we assume that the IP addresses below are all available and appropriate to the system's network, the physical Ethernet port is managed by line description PHYSETH, the virtual Ethernet port is managed by line description VIRTETH, and that VIRTETH is bridged to the physical network by a VIOS SEA or IBM i layer-2 bridging. We create an IP interface on each port, then create a VIPA, preferring the physical interface over the virtual Ethernet interface.

 

ADDTCPIFC INTNETADR('192.168.1.2') LIND(PHYSETH) SUBNETMASK('255.255.255.0')

ADDTCPIFC INTNETADR('192.168.1.3') LIND(VIRTETH) SUBNETMASK('255.255.255.0')

ADDTCPIFC INTNETADR('192.168.1.4') LIND(*VIRTUALIP) SUBNETMASK('255.255.255.255')

    PREFIFC('192.168.1.2' '192.168.1.3')

 

Once all three interfaces are started, the VIPA should be accessible from the network via PHYSETH; if PHYSETH fails, then VIRTETH will take over.

When each partition has a physical interface available, this can be a great solution. Each partition has control over its own physical Ethernet resource, and a single bridging support partition can provide a backup for all of the other partitions simultaneously.

For direct use, this requires that the first line description in the preferred interface list will fail if it can't access the network (for example, if the cable is pulled or the Ethernet adapter or switch fails for some reason). This is true for IBM i physical Ethernet ports (and for aggregate line descriptions) but not true for bridged virtual Ethernet ports (which are not connected directly to the network). Thus, this solution requires changes if we want to support failover between two virtual Ethernet ports.

 

Virtual Interface With Virtual Backup

This can be done by writing a program that does some level of direct health check for each preferred interface and rearranges the preferred interfaces so that the first is always working. Attached below is an example CL script that monitors each preferred interface to see that it can ping a specific remote IP address, and changes the priority order if the first interface becomes unavailable while the second is available.   Download 121912 monitor

Given this, we can fail over between two virtual Ethernet ports. This enables more complicated configurations that provide Ethernet redundancy for the clients without setting up any failover between bridging partitions.

For example, consider a system with several IBM i partitions, two of which have physical Ethernet resources. In each of those partitions, we configure a layer-2 bridge: the first bridge through one Power Hypervisor virtual LAN (VLAN), and the second through a different VLAN. Then, in each of the other IBM i partitions, we configure two virtual Ethernet interfaces and VIPA as above, with a virtual-to-virtual failover script. In half of those partitions, we choose the first bridge as primary; in the other half, we make the second bridge primary.

In this system, all of the physical Ethernet resources are being used, and the physical network is unaware of anything in the configuration. If one bridge stops working for any reason, the half of the partitions that were using it will start using the other bridge. This can provide acceptable service on systems with several IBM i partitions but not a lot of available physical Ethernet resources, at the cost of some additional configuration work.

In short, IBM i and Power Systems network and virtualization technologies give users the tools they need to meet their performance and redundancy targets. We are always looking for ways to improve our networking options as well.

 

 

Performance Data Collectors in IBM i

There were significant changes to the IBM i performance tools in the 6.1 release. The ability to collect additional types of performance data, management of this data, and a graphical interface for viewing and analyzing this data were added. I often speak on performance topics, but I have not written much about them. Since there is much to cover, this will be the first in a series of articles. A good place to start is to review the performance data collectors available on i.

Beginning with the 6.1 release, there are four different types of performance data you can collect; two of them newly integrated into the operating system with that release. IBM i has the richest set of performance data compared to any other operating system; I believe it is a substantial differentiator, giving i users greater insight into how their machines are functioning.

 

Collection Services

Collection Services has been part of the operating system for many releases. Most administrators should be aware of it and using it regularly. Collection Services collects performance data from throughout the operating system on an interval basis and is designed to be running continuously. The overhead for data collection is not significant, but you do need to carefully manage the data that is collected. The major change with Collection Services in the 6.1 release is that it was changed to always be running by default.

Collection Services is used for day-to-day management of your system's performance; you use it for your baseline performance data collection to more quickly determine if changes have occurred that affect performance. It's the underlying data for Management Central System Monitors, it's the data that is sent to IBM if you use PM for Power Systems, and it's also the data that's used for trending and capacity planning purposes.

 

Performance Explorer

Performance Explorer, commonly referred to as PEX, has been part of the operating system since the V3R6 release. PEX has three modes of operation and can collect statistical performance data as well as trace data. Today, PEX is generally used for two reasons: 1) as a performance collector to aid with detailed application performance analysis, and 2) to collect detailed performance for diagnostics on the most difficult performance problems. PEX used to be used much more, but the development of the Job Watcher performance data collector has changed that.

 

Job Watcher

Job Watcher first appeared around the V5R1 time frame. Job Watcher was initially developed by the Rochester Support Center as a tool to aid performance diagnostics. Job Watcher and the graphical user interface used to analyze the data proved to be very powerful for performance diagnostics. The iDoctor offering was the first place where Job Watcher was made available to our clients. Since Job Watcher was so effective at performance diagnostics, it was built into the operating system with the 6.1 release.

Job watcher can collect much of the same information that Collection Services does, but it collects much more; call stacks, SQL statements, wait information (see i Can ...Tell You Why You Are Waiting for more information about waits), activation group information, Java information and more. In addition, while Job Watcher uses a sampling technology similar to that of Collection Services, Job Watcher has the option to sample as fast as possible, which can provide data similar to a trace.

Job Watcher is the most commonly used performance data for detailed diagnostics. The Rochester Support Center performance analysts, as well as the performance consultants in IBM Lab Services generally use Job Watcher. Nearly every performance problem can be resolved with Job Watcher data.

 

Disk Watcher

Disk Watcher is a specialized performance data collector that collects data specifically for disk operations. Its use is intended for detailed diagnostics of disk performance problems or for the use in optimizing disk I/O in applications.

All of these performance data collectors have a set of commands that you can use to define the data you want to collect, commands to start and end the data collection, and commands to manage the data. There are graphical user interfaces that I'll cover in the future as well.

A prior blog article on Find All my Performance Collections in One Place reviews the Collections task in the Navigator for i Web console. The Collections task can be used to see all of your performance collections, regardless of what type, in one consolidated interface.

As I noted at the beginning of this article, IBM i's performance data collectors are second to none; the combination of Collection Services for day-to-day performance management and Job Watcher for detailed diagnostics provide a powerful combination of tooling that can’t be beat.

 

 

 

Removable Mass Storage

With the October/November announcements, IBM i now supports a new type of removable media. Removable spinning disk (RDX) has become reliable and relatively fast, and can be used as a cost competitive save restore device. Prior to this support, removable media was either Tape or Optical. IBM calls this new type of device Removable Mass Storage (RMS).

RDX cartridges are very reliable, they are ruggedized to withstand a drop from up to 0.9 meters (36 in.) without damage, and they never need cleaning. A cartridge can be placed in either a USB or SATA dock to access the data.

Performance is better than typical for low cost tape drives (DAT), and the SATA device can achieve rates over 180GB/Hr. Chapter 9.31, RDX Device Performance, in the November 2012 Performance Capabilities Reference has the details.

Save/restore operations are done just as with a DVD, for example SAVLIB DEV(RMS01). Because it is an optical class device, you can also use IFS to manage data, e.g. WRKLNK OBJ(‘/QOPT/RDXVOL’). Commands are the normal optical storage commands (WRKOPTVOL, INZOPT, etc.). The IBM i 7.1 Information Center has a new section on Removable Mass Storage (RMS).

Rather than create all new commands, we recognize that the media is random-access and spins, with fixed size physical blocks. That is similar to optical devices, so RMS devices are “optical class” devices to IBM i. RDX Docks are available as CEC installed SATA devices on 6.1.1, or as SATA or USB devices on 7.1 with Technology Refresh 5. Cartridges may be from 320GB to 1TB. Hardware details are available.

IBM i 6.1.1 support reports the dock as a 632A (generic DVD) when directly attached, and as a 632C (virtualized DVD) when a client.

IBM i 7.1 Technology Refresh 5 will report the device as a 63B8 regardless of native attached or virtualized client. This release may host the device, but only to another i partition.

There is no VIOS support for RDX drives.

The external USB devices allow the cable to be unplugged without a configuration change (removing the IOA from the partition, or powering off), but the device should be varied off (VRYCFG) before the device is unplugged.

The announcement material for new I/O features and the developerWorks article on IBM i IO Support Details have additional information.

 

This week’s blog was written by Jim Tilbury who is the lead of the IBM i removable media team. Thanks, Jim!

Starting TCP When the System is IPLed

Years ago, when TCP/IP was starting to become the networking standard of choice, it was not automatically when the system was started. You had to edit the system start-up program to automate starting TCP/IP and related interfaces and servers.

In the V5R1 release, the work management component provided the ability to automatically start TCP/IP when the system was started with the addition of the IP attribute “Start TCP”. The default is *YES, but you can change it to *NO to control the starting of TCP/IP yourself.

When the system automatically starts TCP/IP, it does so after the controlling subsystem has started; thus this support works for coming out of restricted state as it does for a partition IPL. When starting from an IPL or restricted state, work management also starts the QSYSWRK subsystem. QSYSWRK is required for TCP/IP functionality since many of the daemon jobs run in that subsystem; the start TCP/IP processing job (QSTRTCP) also runs in QSYSWRK.

When the STRTCP command is left as shipped by IBM, the start TCP processing will first start the defined IPv4 interfaces, the IPv6 interfaces, and the Point to Point (PPP) profiles. The STRTCP processing submits a job named QTCPSTSVRS which starts the application servers. This job is not synchronized with other STRTCP processing, so it can begin to start servers before the interfaces have all been started. TCP Server start-up processing should handle these dependencies and have retry logic if necessary. You configure TCP application servers to start with TCP/IP by specifying the “Start with TCP/IP is started” or the “Autostart” attribute. The blog I wrote earlier this year, Automatically Starting TCP Servers when TCP/IP is Started, discusses this in more detail.

Another important change occurred in the 6.1 release. Prior to 6.1, when TCP/IP was started, it would start the QTCPIP and QTCPMONITR jobs in the QSYSWRK subsystem and these jobs controlled TCP/IP. However, if these jobs were ended, then TCP/IP would also end. To improve the reliability and availability of TCP/IP, these jobs in QSYSWRK are no longer used and the QTCPCTL and QTCPWRK system jobs are used instead. The QTCPCTL job is responsible for managing requests that are sent to the QTCPWRK job. The QTCPWRK job manages the starting and ending of TCP/IP, and the starting and ending of interfaces and PPP profiles. The QTCPWRK job also acts as a message relay agent for TCP/IP related messages. This allows the TCP/IP protocol stack to remain active when in restricted state. Typically, the restricted state is for tape back-ups that use TCP/IP. Refer to the 6.1 Memo to Users for more information on the change to system jobs for TCP/IP processing.

I have heard about clients having issues reliably stating TCP/IP servers when starting TCP/IP at IPL or when starting from restricted state. This can be due to the dependencies between subsystems and the server jobs. Some server jobs run in subsystems other than QSYSWRK; some servers allow you to customize the subsystem in which they run. If the subsystems required by a TCP server are not started before the server jobs are started, problems can result. If you have problems with TCP/IP servers automatically starting after an IPL or coming out of restricted state, you can customize the system's start-up program (specified by the QSTRUPPGM system value) to control starting the subsystems and server jobs.

IBM has a support knowledge-base article titled “Starting TCP - Using the IPL Attributes Versus the System Startup Program”. If you call IBM Support with a problem related to the STRTCP processing at IPL, the IBM support representative may discuss the information documented in this article.

However, the STRTCP IPL attribute processing has improved over the years and using that IPL attribute is the recommended way to STRTCP. If you have specific errors when using the IPL attribute to start TCP/IP, IBM support will need to know the details (Is TCP not starting as a whole? Is a specific server not starting? etc.). It is possible that more complex environments may need to use a customized start-up program to get all the servers correctly started.

However, if you encounter server start-up problems, or if you can recreate problems that cause you to add DLYJOBs to your start-up program, you should open a PMR so the IBM development team can understand the issue and work on a resolution.

Finally, the IBM i Information Center has a section on TCP/IP Troubleshooting. Within that documentation there is a section on Timing Considerations that reviews the general considerations for setting up your own start-up program to start TCP/IP and TCP Servers.

 

 

 

Fall COMMON and Past Blog Entries

This week, I've been busy with Fall COMMON and haven't had time to write a new blog article. In the absence of a new blog this week, I wanted to recommend that if you haven't read some of the past blogs, you should. Some of the early ones published in the fall of 2009 are still very pertinent and of interest.

One example is the ability to Display CPU Utilization for All Partitions, which is republished here this week:

i Can .... Display CPU Utilization for all Partitions 

In last week's blog, I mentioned that with the latest Performance Data Investigator enhancements, IBM i now provides physical system charts that display the overall CPU utilization for the physical box and all partitions, regardless of operating system.

This is an exciting enhancement that many of our customers have asked for, so I want to tell you more about it and how you enable this feature.

Many IBM i customers are using logical partitioning with their systems. When using multiple partitions, many customers want to understand the overall utilization of their processing capability, across all partitions, regardless of whether the partition is running IBM i, AIX or Linux. To do this, many have created their own customized solutions by querying Collection Services data from each partition and pulling together an overall view of CPU utilization; but if you have AIX or Linux partitions, there’s missing information unless you have the skills to collect and understand the performance data from those partitions as well.

With POWER6 hardware and IBM i 6.1, you’ve been able to collect CPU utilization information for the physical system since firmware level xx340_061 was introduced late last year. However, that just enabled the collection of the data; IBM provided no way to view it. With the updates to the Performance Data Investigator I reviewed last week, additional charts are now available for Physical System views of CPU utilization that now let you easily view this data.

However, there are some specific configuration requirements. As I’ve already said, you must be running on POWER6 hardware with a minimum firmware level of xx340_061. You also must be using the IBM i 6.1 release. Then, you must also enable the collection of this performance data for the desired partition. You only need to collect this data on one partition and it must be an IBM i partition. The CPU utilization information collected will reflect work done in partitions running AIX and Linux as well as IBM i, but AIX and Linux don’t support collecting this data. Only IBM i has this data collection capability.

To enable the collection of this performance data requires the setting of a configuration parameter on the HMC or Integrated Virtualization Manager (IVM). On the HMC, there’s an "Allow performance information collection" checkbox on the processor configuration tab. Select this checkbox on the IBM i partition that you want to collect this data. It's not quite as simple with IVM; if you’re using IVM, you use the lssyscfg command, specifying the all_perf_collection (permission for the partition to retrieve shared processor pool utilization) parameter. Valid values for the parameter are 0, do not allow authority (the default) and 1, allow authority.

Once the performance data collection support is enabled, Collection Services will collect this additional information. At each collection interval, Collection Services will collect partition configuration and utilization information from the hypervisor; the data is stored in a file named QAPMLPARH. 

The latest update to the Performance Data Investigator includes additional perspectives in the Collection Services content package for this data in a folder called "Physical System." It also includes the following charts: 

• Logical Partitions Overview
• Donated Processor Time by Logical Partition
• Uncapped Processor Time Used by Logical Partition
• Physical Shared Processor Pool Utilization
• Physical Processors Utilization by Physical Processor
• Dedicated Processor Utilization by Logical Partition
• Physical Processors Utilization by Processor Status Overview
• Physical Processor Utilization by Processor Status Detail

Here’s an example of the Logical Partitions Overview chart, which shows configuration data and CPU utilization for all logical partitions on the system:

If you’re on POWER6 hardware, but have not yet installed IBM i 6.1, you may want to think about creating a small i partition and experimenting with this new capability to manage your machine's processor utilization across all partitions.

 

CPF1240 and CPF1241 Messages Contain Summary Performance Data

You probably know that the CPF1164 (Job Ended) message that is sent to the history log contains some basic performance information regarding the job that ended. You can't see the details of this information via the Display Message Description (DSPMSGD) command or via the Display Log (DSPLOG) command, but the data is available in the history log files and you can write application programs to retrieve this data.

The basic performance information on the CPF1164 message includes:

• Date and time the job entered the system
• Date and time the job started
• Total response time (for interactive jobs)
• Total transactions (for interactive jobs)
• Number of synchronous auxiliary I/O operations

The Performance Information and QHST section in the Information Center is where documentation on this can be found.

What you may not be aware of, is in the IBM i 6.1 release, basic performance information was also added to the CPF1240 (Job ended abnormally) and CPF1241 (Job completed normally) messages.

Unlike the CPF1164 message, the performance information on the CPF1240 and CPF1241 messages is part of the message description and you can display the information with the DSPMSGD command. For example, a DSPMSGD CPF1240 will show the following information at the end of the technical description information:

   -- Entered system date and time:      &9

   -- Started date and time:             &10

   -- Job type:                          &16

   -- Job subtype:                       &17

   -- CPU seconds used:                  &11

   -- Synchronous auxiliary I/O:         &12

   -- Asynchronous auxiliary I/O:        &13

   -- Ending code:                       &14

   -- Secondary ending code:             &15

And by looking at the field data of the message, you can find the details of the data type and length for each of the replacement variables.

There are a few minor differences from the data that is included with the CPF1164 command.

• The total response time and total transactions fields are not part of the information on the CPF1240 and CPF1241 messages; these messages are only sent for batch jobs and total response time and total transactions are only applicable to interactive jobs.
• Asynchronous auxiliary I/O counts are included on the CPF1240 and CPF1241 messages.

Functional Usage Capabilities, Part 2

A reader comment from last week's blog asked the question: 

Where can I find detailed documentation that describes exactly what each of these FUNCTION IDs controls? Does one of the available function IDs allow me to control interactive SQL usage? I have some users (new programmers, support people, etc.) where I want to prohibit the DELETE, UPDATE, CREATE operations but allow a SELECT operation.

I'll answer the second part of the question first: No, function usage does not allow you to control interactive SQL use. You can control access to DB/SQL administration and monitoring facilities however; the DB/SQL function usage is new in the IBM i 7.1 release and Authority Options for SQL Analysis and Tuning describes the new function usage capabilities.

When I started to compose this article, I was thinking “This will be such an easy blog to write!” Was I wrong! I knew a lot of components had taken advantage of the function usage capability, but I didn't realize just how many. And of course, I also thought that the documentation on the various function IDs would be mostly a matter of pulling things together, but I was also wrong about that.

So where can you find some additional documentation?

Three places:

• If you use the Display Function Usage or Work with Function Usage commands, you can display information about each Function Usage ID. One piece of information is the Description, which provides a brief overview of what that Function Usage ID is for.
  
  However, the easier approach is to use the GUI. The Host Applications listed use the descriptive name which is much more meaningful than the QIBM... ID you find on the command-line interface. The screen capture below is an example of what you will see. Many of the functions are self-describing and you can pretty easily figure out what is controlled from the description.
  
  
  
  
  
• Search for the QIBM... string in the IBM i Information Center (I used 7.1). This search will return all the interfaces that check on the specified identifier and you will get a pretty good idea of what the function is for. However, it turns out that not all function IDs are documented in the Information Center, and those that are generally have information scattered.
  
  
• Internet search. Some of the functions have had articles written on them when they were first made available. An Internet search on the QIBM.... string may find some additional information beyond what is in the IBM i Information Center.
  
  

When I started to write this blog, my intent was to include the full set of documentation and chase down information on the IDs that are not documented in the Information Center. However, when the initial draft of this blog was at 16 pages (!). I realized this was a topic beyond what I can cover in the blog.

I will complete the documentation on the function IDs and it'll be published in some other way – either as an article here on the IBM Systems Magazine site, or perhaps something on the IBM i developerWorks site (or maybe both). I'll comment on this blog when that article is available.

Finally, there is an old Redbooks publication, Operations Navigator V5R1 Volume 1: Overview and More, that has a good chapter on Application Administration that is still applicable. Note that the Redbooks pub is based upon the Operations Navigator client, but the capabilities are the same, even in the browser (Director Navigator) added in 6.1.

 

Functional Usage Capabilities

Did you know that you can limit access to system functions by registering which users can access which functions? You can allow access or deny access via the functional usage capabilities; depending on the component, you could allow one user to change some settings and allow another user to only view those settings. Many system components support the use of function usage capabilities to provide more granular access to their capabilities. Functional usage does not eliminate or replace the need for securing resources on your system; it simply provides an additional way to control what functions a user can access.

There are:

• Three commands
  • Change Function Usage (CGGFCNUSG)
  • Display Function Usage (DSPFCNUSG)
  • Work with Function Usage (WRKFCNUSG)
• A set of APIs in the security category under User Function Registration Facility APIs
• A graphical user interface that allows you to manage the function usage on the system. The GUI for this capability is under Application Administration – Host Applications, within System i Navigator (where it is an optionally installable component) and Systems Director Navigator.

The User Function Registration Facility API set was first introduced into the system way back in V4R3, so this capability has existed for quite a while. The commands were introduced in V5R3, which improved ease of use since a program no longer had to be written to implement it.

The first use of limiting function access within the operating system was in the V4R5 release when the Trace Connection (TRCCNN) command was introduced. Service commands required *SERVICE special authority; but *SERVICE special authority is quite powerful, and it's very likely that you'll want to allow someone to collect a dump or a trace, but not want them to have *SERVICE special authority. Today, most all of the service commands (trace, dump, watch) are supported with customized access via functional usage.

Since the introduction of TRCCNN, more system components have added support for granular access via functional usage. You can see the full list of functions supported with the DSPFCNUSG or WRKFCNUSG commands by taking the default of *ALL. The GUI also provides a list of all functions that are available.

The GUI for this capability can be found under Application Administration; it is the Host Applications category that provides this support.

• Default Access allows all users to access the function by default 
• All Object Access allows all users with all object system privilege to access the function
• Customize allows you to add or remove users or groups in the Access Allowed and Access Denied lists.

The following screen capture shows the kind of information you can see with the Display Function Usage command. In my example, you can see that I have allowed user DAWNMAY to access trace functions, even though DAWNMAY may not have *SERVICE special authority. User DAWN is not allowed to access trace functions.

 

Three Years of 'i Can'

You know the phrase, “My, how time flies!” And it seems it has! On Aug. 10, 2009, the first i Can blog, "Why i Can," was published. Since that time, the blog has been updated almost every week and somewhere around 140 blog entries have now been written. My list of topics to write about is as long as ever; there are always new topics as the IBM i development team continues to release new function via Technology Refreshes. The list of older topics to write about is endless.

One thing that has surprised me a bit about this blog is the frequency I use my own entries as references. I have referred back to them numerous times to refresh my memory on a topic. I often get asked questions and it's nice to simply point someone to a prior blog entry that provides the answer.

My favorite or most referenced articles include:

 

• Display CPU Utilization for all Partitions
• Tell You Why You're Waiting
• PTFs for Additional Work Management Controls
• Direct the use of Navigator? Or is that Navigate the use of Director?
• Measure Disk Response Times
• Achieve Faster IFS Save Times Using SAV with ASYNCBRING

Sometimes finding the older articles can be a bit challenging. I use three approaches:

• Internet search--This tends to be my first approach. A keyword or two about the topic along with “i Can” generally finds what I'm looking for.
• Using the Archives--You can find a list of all the articles, month by month or by the various categories by which they are organized.
• Going to the specific category that you are interested in from the main “i Can” page.

You can also subscribe to the blog articles via RSS. On the main IBM Systems Magazine page, there is an RSS link next to each blog. This approach is very handy since you don't have to make an effort to get to the website to read the articles.

Another thing that has surprised me a bit is how challenging it has been to keep track of what I have written and the list of topics I have yet to write about. In fact, I have resorted to a spreadsheet that lists all of the prior topics and also includes a worksheet on topics yet to write about. I am probably one of the most anti-spreadsheet people; I hate them! But I've found it's a good way to keep track of everything that's been written; I have also saved the URLs for each article so I can easily find one that is proving difficult to pin down otherwise.

I hope you have found these blog entries to be valuable. The content will keep coming. And please, if you have topics you'd like to see written about, feel free to comment on the blog or send me a short email with your suggestions.

 

IBM i Security Never Sleeps

This week's blog was written by Scott Forstie, senior software engineer at IBM. He is the DB2 for i Business Architect, SQL development leader and IBM i developerWorks content manager. Thanks Scott!

Security never sleeps. On IBM i, we understand that we must continue to invest in delivering improved security auditing, security deployment and granularity of security controls.

To that end, this post provides a brief recap of security enhancements that have been delivered to existing IBM i releases over that last 12 months. Each enhancement has its own "fact page" on the IBM i Technology Updates wiki.

Command Language Enhancements

CL retrieve exit programs can run after command completion
The IBM i operating system supports two exit points for control language (CL) commands:

QIBM_QCA_CHG_COMMAND and QIBM_QCA_RTV_COMMAND. For each regular CL command, and proxy CL commands in the QSYS library, one exit program can be registered for the CHG exit point and up to ten exit programs can be registered for the RTV exit point.

Prior to this enhancement, QIBM_QCA_RTV_COMMAND exit programs were always called just before control was transferred to the command processing program (CPP) associated with the command being run. The enhancement allows you to be able to register an exit program for the QIBM_QCA_RTV_COMMAND exit point and indicate that you want the exit program to be called after control returns from the CPP.

Delivered on: V5R4 (SI45987), IBM i 6.1 (SI45986) and IBM i 7.1 (SI45985)

Extend CD (Command String) journal entries
The IBM i operating system allows customers to track the CL commands that are being run by a user. Auditing needs to be active before command-level auditing can be done. The Change Security Auditing (CHGSECAUD) command allows you to change the current settings for the system values that control what is being audited on the system. To turn on command-level auditing for a user profile, run the Change User Audit (CHGUSRAUD) command specifying the user profile name for the USRPRF parameter and *CMD for the AUDLVL parameter. This will cause CD (Command String) audit records to be generated for each CL command run by the specified user profile. The model file QASYCDJ5 describes the fields in CD audit records. One of these fields, CDCLP, has been redefined to convey more information concerning how the audited CL command was run.

The new values for the CDCLP field map to the values for the ALLOW (where allowed to run) parameter on the Create Command (CRTCMD) command as follows:

'Y' maps to *IPGM, *BPGM, *IMOD, *BMOD
'R' maps to *IREXX, *BREXX
'E' maps to *EXEC
'B' maps to *BATCH
'N' maps to *INTERACT

Delivered on: V5R4 (SI44854), IBM i 6.1 (SI44864) and IBM i 7.1 (SI44865)

DB2 for IBM i (database) Enhancements

Masking support in FIELDPROCs
The FIELDPROC support has been extended to allow masking to occur to that same column data (typically based on what user is accessing the data). For example, only users that have a need to see the actual credit card number will see the value while other users may just see masked data. For example, XXXX XXXX XXXX 1234.

Delivered on: IBM i 7.1 (DB2 PTF Group SF99701 Level 14)

STRDBMON pre-filtering of QUERY-400 command use
QUERY/400 commands Run Query (RUNQRY), Work With Queries (WRKQRY) and Start Query (STRQRY) already generate database monitor records. This enhancement delivers a method to easily identify Query/400 users and the queries executed via the Filter by Client Program database monitor pre-filter.

Delivered on: IBM i 6.1 (DB2 PTF Group SF99601 Level 25) and IBM i 7.1 (DB2 PTF Group SF99701 Level 14)

Simplified DDM and DRDA authentication entry management using group profiles
This enhancement allows DDM and DRDA to take advantage of a common userid and password defined in a server authentication entry under a group profile name or supplemental group profile name. The group profile name or supplemental group profile name is specified on the USRPRF parameter of the ADDSVRAUTE command.

Delivered on: IBM i 6.1 (DB2 PTF Group SF99601 Level 25) and IBM i 7.1 (DB2 PTF Group SF99701 Level 14)

Add QIBM_DB_ZDA and QIBM_DB_DDMDRDA function usage IDs
These function usage IDs block database server inbound connections and are not based on the communication protocol. The function usage IDs ship with default authority = *ALLOWED. The security officer can easily deny access to specific users or groups.

Alternative to a User Exit Program approach. No coding required, easy to change and auditable.

1. QIBM_DB_ZDA (restrict ODBC and JDBC Toolbox from the server side, including Run SQL Scripts, System i Navigator and DB2 specific portions of Systems Director Navigator for i)
2. QIBM_DB_DDMDRDA (ability to lock down DDM and DRDA application server access)

Delivered on: IBM i 6.1 (DB2 PTF Group SF99601 Level 25) and IBM i 7.1 (DB2 PTF Group SF99701 Level 13)

QIBM_DB_OPEN exit program object auditing control
The QIBM_DB_OPEN exit program has been enhanced to allow users to control which files will cause the exit program to be called, which can significantly reduce the overhead of using the exit. The open exit will be called for ALL files that are specified in a query or open if ANY of the files have specified object auditing.

Delivered on: V5R4 (DB2 PTF Group SF99504 Level 33), IBM i 6.1 (DB2 PTF Group SF99601 Level 23) and IBM i 7.1 (DB2 PTF Group SF99701 Level 12)

Add QDDMDRDASERVER server authentication entry special value
A special value QDDMDRDASERVER has been added to the ADDSVRAUTE command SERVER parameter for DDM & DRDA connections. This special value allows an administrator to configure a user to work with all possible DDM or DRDA connections to any system in the TCP/IP network via a common userid and password. Once configured for a specific user, no additional changes need to be made for that user as systems are added to the Relational Database Directory.

Delivered on: V5R4 (DB2 PTF Group SF99504 Level 32), IBM i 6.1 (DB2 PTF Group SF99601 Level 21) and IBM i 7.1 (DB2 PTF Group SF99701 Level 11)

Query Manager profile auditing
Changes made to a Query Manager profile can now be audited if auditing is enabled for AUDLVL(*SECURITY).

• A new journal entry type of X2 will contain the old and new Query Manager profile values.
• An outfile is not provided for this journal entry. Instead view QSYS2.SQLQMProfilesAudit can be queried.

Delivered on: IBM i 6.1 (DB2 PTF Group SF99601 Level 21) and IBM i 7.1 (DB2 PTF Group SF99701 Level 10)