For a two minute overview of this training click play.
Description: You'll learn useful new RPG skills by writing and testing code with Brad Stone's RPG Skills Accelerator. It covers 11 advanced RPG programming subjects, each with one or more labs. Hands-on stuff! This dynamic 25-hour training course comes with an easy-to-follow manual, and a CD with all the training exercise source code. You'll immediately use what you learn to create far better RPG programs. You also get a bonus of four RPG tools (evaluation versions).
Here is what you will learn:
Understanding ILE Learn how to create and work with sub-procedures, modules, service programs, binder language and binding directories. You'll start with simple examples that show how to create and use procedures in your RPG programs. You'll also learn valuable timesaving shortcuts that make it easy for you to create and manage modules and service programs. After completing the ILE labs, you'll be able to use these powerful techniques with your programs. These labs alone are worth the price of the training!
Database The SQL Alternative - With these labs, you'll learn how to use embedded SQL using static and dynamic statements. By mastering these techniques, you'll be able to build database queries that are much more powerful than using native RPG file I/O operations.
A Trigger Template - Working with trigger programs is still mysterious to many programmers. With triggers you can split commonly used database operations out of your application programs. This lab provides you with a trigger program that you can use as a template. Once you've written and tested the template, you can easily modify it and use it as the basis of a trigger program on any of your database files. A great time saver!
RPG Techniques Fast-paced labs will show you how to work with recursion, data queues, user spaces, sockets, and send e-mail from RPG programs.
Send Email with RPG Programs - Still struggling with the iSeries SNDDST command to send simple e-mail? Upgrade to the more powerful QtmmSendMail API! In this lab, you'll create an easy to use e-mail system, using an RPG program and a command. When done, you'll have an e-mail utility program that you can call from any application running on your iSeries. It’s magic!
Introduction to Recursion - Use this lab to become familiar with the concept of recursion. You'll work with a simple lab to compute the factorial of a number, followed by a real-life example of using recursion to print a Bill-of-Material listing.
Data Queues and RPG - In these two labs, you'll create RPG programs to write entries and read entries from the data queue. The labs demonstrate how you can use data queues to split complex applications into smaller, easier to work with components. Worth it’s weight in gold!
Working with User Spaces - Many of the iSeries APIs write to user space objects. To make use of the API, you need to know how to work with the user space. In these labs, you'll work with a set of RPG procedures to "wrapper" the user space APIs. You'll then use the wrapper APIs in an RPG program with the List Objects (QUSLOBJ) API.
RPG and Sockets - What if you could write RPG programs that can communicate with any other computer, using TCP/IP? In this series of labs, you'll learn how to use sockets, the low-level TCP/IP communication technique used to link client and server programs. You'll work with an RPG client program that sends data to an RPG server program, and get the response from the server. Now you'll be able to create programs that can accept input from any device. Neat!
System Programming with RPG Batch File Transfer with FTP - Although you can run FTP on the iSeries from the command line, you'll find it very useful to be able to run FTP from RPG programs as well. In this lab, you'll create a simple command and RPG program that dynamically builds and executes an FTP script. Using this utility, you can automate file transfers from your iSeries to any other computer.
An RPG Exit Program for FTP - This is must-have information, if you are currently running FTP on your iSeries without an effective Exit Program in place. In fact, shut down FTP until you work through this lab! The iSeries provides an FTP server that can be used to upload and download files. To use the server, you need to provide a valid iSeries user ID and password. Unfortunately, once users authenticate themselves, there are no restrictions on the FTP commands they can run. In this lab, you'll learn how to create an FTP Exit Program. The Exit Program will let you provide "anonymous access" to FTP (no user ID and password is required), and more importantly, restrict the FTP commands that are available to an authenticated user.
The IFS and RPG - Although you may be able to ignore the Integrated File System for most of your applications, you'll need to be able to work with it to write effective e-RPG programs and create HTML e-mail. In this lab, you'll learn about APIs that let you read and write to files in the IFS. Armed with this new knowledge, you'll be able to create "next generation" RPG applications that take full advantage of the advanced features of the iSeries. Hot stuff!
This is real-world RPG training that you can put to work for you right away. It’s a smart move for your organization and your career! Take your RPG programming skills to the next level with Brad Stone’s RPG Skills Accelerator. Get your copy today!
Four Software Tools Included (evaluation versions)
GETURI - With this software you can easily send TCP/IP requests to a server, view and store results. You can also retrieve web pages as data. A great tool!
MAILTOOL - Now send e-mails from your AS/400 with a simple command – even include 50 attachments!
FTPTOOL - Use it to easily configure FTP exit programs, users, operations and paths. Nifty!
OUTQTRG - With this tool you can quickly set up and configure events that can be run when spooled files become available on your system. Use it for Email and messaging. The possibilities are endless!
Skill Level: Some experience with RPG programming and database. Any RPG programmer with 1 or more years of experience will be able to successfully complete this course. This course is not intended for end-users or for novice programmers.
RPG Skills Accelerator(RSA1) Author: Bradley V. Stone $495
ILE for You and Me – Part 1 by Bradley V. Stone
The Integrated Language Environment (ILE) has been around for years now. When it first came out, there was much buzz surrounding it, as there is with any new technology. But, it was not taken into the stable of most programming shops right away. Why? Usually this happens because it’s simply too much information at once. ILE is by no means simple, but it is also not as complicated as it may initially seem.
I didn’t start using ILE heavily until about three years ago. I was approached to rewrite a piece of software that was part of our home grown package that did everything from order entry, to inventory, to doing your laundry. When I was given the challenge of rewriting this piece of software, I went out on a limb and said that I’d like to take on this project if I was allowed to use it as a testing ground for ILE. This was not a problem to my manager, and all was good.
What is ILE all About? The thing that intrigued me most about ILE was that I could write my own functions. We had already written separate programs for things such as data selection and price, tax, and shipping costs, so we already had a lot of the pieces in place to start out small. But, I wanted to modularize a lot more. Now, there are other pieces to ILE, but modularizing code with my own home grown functions interested me the most.
We all love it when IBM comes out with a new release of the operating system. The first thing I do, as do many others, is read the documentation on the new release to find all the new Built In Functions (BIFs) that have been added to RPG. A lot of these BIFs are huge time savers, other times they are used rarely, but when they are used, the time saved is almost immeasurable.
Even with all the BIFs that IBM has made available, sometimes there are functions that we need that don’t exist, or we can’t use because we are forced to compile our programs to an earlier release of the operating system, thus making some of the BIFs unusable. Other times there are functions that IBM will never release and are more specific to your software package. For example, how many times have when CHAINed to the customer master file to retrieve a credit code flag? What if we could do this in one EVAL statement. It would not only save C-Specs, but it would also eliminate the F-Spec that defines the customer master file.
The Key Pieces to ILE In this article, I will go over the key pieces to ILE as they relate to writing your own functions. First, we should go over some terminology. I have taken each major piece of ILE and defined it in what I think is a more understandable format than most documentation available on the subject. Following the definitions is a list of metaphors to help you further understand ILE. If you are new to ILE, or simply confused, please refer back to these definitions and metaphors as you read this series.
I like to go through these definitions and the metaphors before showing any code. Even though I myself usually learn by looking at code, ILE is not syntax as much as it is a method of programming. It is a good idea to have an understanding of what ILE is before you venture out to conquer the world with it.
In the following pieces of this series of articles we will dive more in depth into each of these topics and look at some code that goes along with them.
Subprocedure A Subprocedure is an operation that performs a certain task, and also could return data to the calling program. Think of a subprocedure as a BIF that IBM has supplied. The %trim BIF is probably the most used. This BIF takes the string you pass to it and returns that string with both the leading and trailing blanks removed. The %trim BIF is not magical. There is code behind it that goes through a few steps in order to return the trimmed string.
When writing our own subprocedures, we are not only concerned about using the subprocedure in our programs, but we also must write the code behind that subprocedure. It is a good practice, though, to think through what the function you are writing will do, as well as parameters that will be passed in and out. This way you won’t have to go back and make changes as different situations come up.
Module A Module is a collection of subprocedures. The subprocedures contained within a module usually perform similar or related tasks. For example, if we were to writing a whole bunch of string manipulation subprocedures, we would most likely put them all into the same module. Once we have written the code for each subprocedure, all contained within the same source member, we use the Create RPG Module (CRTRPGMOD) command to create the module. This makes all of those string subprocedures that we just wrote available from one location.
Modules are their own objects of type *MODULE. They are bound to programs during program creation time. When the Create Program (CRTPGM) command is used, there are parameters that allow you to list as many modules as you want to piece together into a program. Creating programs using modules is called “Bind By Copy”. This actually attaches a copy of the Module to the program as if the code existed in the program. Similar to writing a program with a bunch of subroutines that would be available to any program, instead of just the program that the subroutines are included in.
Service Program A Service Program is a collection of subprocedures. I know what you’re thinking. Isn’t that the same as a module? Well, you would be thinking correctly. Let me explain the difference between a service program and a module, and how the prior cannot exist without first creating the latter.
Service programs are similar to modules, but, the main difference is that service programs are not physically bound to programs. The subprocedures contained within a service program are called dynamically from the program and the service programs are not physically bound to a program.
A service program is created from a *MODULE object. The Create Service Program (CRTSRVPGM) command accepts a list of modules to use to create the service program. The service program will exist as a separate entity from your program, and will be referenced when a program that uses it is called. In other words, it’s only used when it’s needed.
When you use service programs as opposed to modules it is called “Bind By Reference.” It differs from that of a module because, as you recall, a module is physically bound to the program at creation time. A service program is merely referenced at program creation time. It’s similar to programs that you write and that are called by other programs, like a price generating program.
Let’s say you had two systems. On system A you used only modules. On system B you used only service programs. Both systems are identical, containing the same end programs. Because system A uses modules, and modules are bound physically to programs, the program objects will be much larger than on system B. Using a set of string functions as an example, you will have a copy of the string module bound to every program, as if the code existed in that program on system A. But, on system B, you will have only one copy of your string functions, in the form of a service program, that is referenced by programs that use the subprocedures contained within.
Binder Language Binder Language is a list of Procedures that are exported from a Service Program. There can be more than one list of procedures for each Service Program, but only one list can be specified as the current export list.
Binder language is used when issuing the Create Service Program (CRTSRVPGM) command. On this command there is a prompt for a source member that lists which subprocedures you want to make available for export from the service program you are creating. The number of subprocedures exported, as well as the order of these subprocedures in the binder language creates what is known as a signature for that service program. A signature is similar to a file level identifier for a physical or logical file. We’ll touch more on signatures later when we get into actual code later in this series of articles.
Binding Directory A Binding Directory is a list of Modules and/or Service Programs that can be used during program or service program creation. When a Binding Directory is specified on the CRTBNDRPG command, the system checks through the list for Modules and Service Programs for the location of any Procedures included in the program source.
You can thing of a binding directory similar to a library list. When you compile a program that contains file references, the system looks through your library list, starting at the top, for the location of the file that is listed in the F-Specs.
A binding directory works the same way. When you specify a binding directory on a CRTxxxPGM command, it uses this list of modules and/or service programs to locate any references to your home-made subprocedures.
Activation Group An Activation Group is used to isolate a specific job or set of jobs. An Activation Group contains the resources necessary for a job to run. All RPG/III programs run in the Default Activation Group.
The most confusing this about activation groups is that they are a subset of a job, not the entire system. I like to think of activation groups as “sub jobs” within a job. Each job that runs will use at least two activation groups. One activation group is reserved for system code and all other programs will run in the second.
Each activation group contains all the resources necessary to run a job. The most important of these resource are open data paths (ODPs), commitment definitions, and query management instances. If you are using a named activation group to run an open query file (OPNQRYF) command, the program that processes the data path created by the OPNQRYF must also run in that same activation group. There are other ways around this, but they are simply band-aids and defeat the purpose of using activation groups altogether.
There are three types of activation groups, named, *NEW, and *CALLER. Named activation groups are those where the user specifies the name implicitly. Specifying a *NEW activation group means that every time the program is run, a new unique system-named activation group will be created. When the program ends, the activation group is reclaimed. *CALLER activation groups use the activation group of the program that it was called by.
ILE Terms Further Explained Now that we have walked through the technical definitions of these pieces of ILE, I would like to give some more “down to earth” explanations. These “wacky metaphors” should help you further understand the main pieces of ILE.
Subprocedure A Subprocedure is like a recipe.Module A Module is like a cook book. It can contain one or more recipes that you have collected. Since they are “bind by copy”, this would be like carrying around the cook book at all times. Quick to access, but bulky. And for each different set of recipes, you need a separate book. Service Program A Service Program is also like a cook book. It contains the recipes you have collected. But, instead of carrying the cook book around, you keep it on the shelf and reference it when you need it. Thus, “Bind by reference”. This is why a service program has slower initial access, but after you have it in your hands, it’s just as fast as if you were carrying it around all the time. Binder Language Binder Language would be similar to the index of the cook book. It lets you know which recipes are in this particular cook book. But, because binder language is only referenced during the compilation of a service program, this would be similar to assembling the cookbook and using the index to know what recipes will be available in this particular book. Binding Directory A Binding Directory is like a card catalog. It lists the cook books that you have available to use. For example, let’s assume that you have a Chinese Cookbook, a German Cookbook, and a Norwegian Cookbook. When you decide what you want to make, you look for the recipe in the appropriate cookbook. Activation Group An activation group is like a kitchen in your house. Your house is like an AS/400 job. When you cook, you can cook in your main (default) kitchen. If you have more than one kitchen, you can decide to cook in any other kitchen in your house. Others, such as your nosy neighbor, cannot come and cook in your kitchens, though. This is because your kitchen, like activation groups, are only available to the owner of the house (or job on the AS/400).
Understanding is the First Step I know that all these definitions and explanations may seem tedious, but stepping into the world of ILE is not an easy task, especially if the concepts are entirely new to you. Like they always say, you must learn how to walk before you can run. For this reason, when I teach the concepts of ILE I like to make sure that people have a decent understand of the previously explained concepts before diving into code. Usually after the explanations the ideas on where and when to use ILE start popping into peoples heads.
In the next article in this series I will give some code examples that will make ILE even clearer. Soon you too will be thinking of places where ILE will fit into your software. Even if you don’t, you most likely already have some places that you could easily implement ILE. These are usually the programs that are called by many other programs within your system. Changing those programs into ILE functions is a great starting point into the world of ILE.
