IBM i Services is the hottest, and coolest, thing to hit systems admin since…well, maybe since ever! And its constantly updated SQL tables will give you a whole new slant on managing your i.
Have you heard about IBM i Services? No? Well then, you're in good company because apparently no one at IBM has either. Go ahead; go out to IBM's website and search on "IBM i Services." If you find anything, let me know because I sure didn't. Yet this product looks like a sure bet to be a winner for those who are managing an IBM i.
What Is It?
In short, IBM i Services (which I will refer to as just "Services" for the rest of the article) is the brainchild of Scott Forstie, the DB2 for i Business Architect, SQL Development Leader, and IBM i developerWorks content manager.
In essence, it's a series of DB2 views that look like traditional physical file catalogs on the surface. These views provide the consumable interface for SQL users, while behind the scenes, User-Defined Table Functions (UDTFs) provide accurate query data to the user. Most of these services return their answers quickly, and all of them can be easily accessed by SQL.
But We Have Commands
Of course, the way we have always gotten management information is to issue one or more vaunted IBM i commands or APIs, and that is still a very valid way to get information. It's up to date, it's easy to use, and we are familiar with it. But there are some issues that make going after info like this with SQL very attractive.
First, if you want to use an API, you're going to have to write a program. With SQL, all you need is a command line or SQL interface.
Second, if you want to use a command, then the info you are going to get back is fixed. Yes, you can vary it somewhat by using the command parms, but pretty much you get what you get. It may be too much; it may be too little. With SQL you can use the Select, Where, Group By, and other statements to get just what you need.
Third, again if you use a command, then it may be necessary to use several commands to zero in on what you want. That means there is going to be some manual work on your part to pull the data from the different commands together. No way that can be fun. And it's even worse if the command doesn't have an OUTPUT parm on it. With SQL, you can combine data from several tables to get output that is just what you want. And you can then download that output to Excel or some other format so that it is ready to roll.
Fourth, SQL is a standard language across many platforms and languages, which means you don't need to know really anything about the i to get the info you want. Even Windows people can do it.
All in all, while commands and APIs are great for some things, using SQL to access the Services DB2 tables makes good, good sense.
Fine. What Do I Have to Know?
Well, the first thing you need to know is SQL. And a lot of us don't. But all of us should. You can argue all day long about whether embedded SQL is better than RPG I/O for use in RPG programs, but you can't argue that a solid familiarity with SQL is a must for i people today.
Don't have a lot of experience? Then download the DB2 for i SQL Reference Manual and get started. You don't have to read the whole thing, but you can certainly quickly get yourself up to speed for elementary SQL statements.
Second, you need an SQL environment or tool to issue your SQL commands. One option is to use the RUNSQL command and type your SQL statement into the SQL parm. Or you may prefer to issue STRSQL on a command line and then key your SQL commands into the lines that open up. Each command is treated separately, and the results are displayed on your screen. Probably the best option is the Run SQL facility within Navigator or whatever it is called in your particular installation. One of the advantages of this tool, of course, is the ease with which you can convert your output to an Excel spreadsheet.
Third, you need to know the table names and the data that is associated with that table. There are two libraries on the i where this stuff seems to be located: QSYS2 and SYSTOOLS. Problem is, you can't just do a WRKLIB and look for the SQL views, etc. in each.
Probably the best place to go is https://ibm.biz/DB2foriServices. This website lists the tables that are part of this feature and the libraries where those tables exist. Want to know what data is kept in a table? Simply click on the table name and you will be sent to a web page that provides complete information on the columns in that table and the information they contain. Can't ask for more than that.
So give it a try. It's simple, it's sophisticated, and it's another way to go if you are trying to dig up information on your i and how it is used.