If your AS/400 is used as the central development system in a larger network, then it’s likely that, as you make code changes and create new applications, you are constantly propagating those fixes and enhancements to remote systems. If this is the case, then you know what a pain it can be getting changes to the other sites. For many shops, using the Send Network File (SNDNETF) command is the only way to accomplish this. Using SNDNETF allows AS/400 shops to send source and data files, including AS/400 save files, to other AS/400s on the same SNA network. Once there, objects can be restored or compiled and placed into production.

An Oldie but a Goody

For years, this technique has worked fine, if a bit slowly, and, in fact, is still the procedure du jour in many shops. Using SNA to propagate source code and object changes to remote AS/400s is great because you can use it between any two AS/400s that have a modem connection. It’s not all peaches and honey, though. There are problems with this technique. For one thing, it’s pretty slow, especially when sending large files.

The problems don’t end there, either. To use SNDNETF, you’ll have to configure the Systems Network Architecture Distribution Services (SNADS) settings using the Configure Distribution Service (CFGDSTSRV) command on each AS/400 that you’re going to send network files to. Once that’s done, you’ll still need to configure line descriptions and controllers and make sure that all settings on both networks match. While this isn’t rocket science, it can be a formidable task. As the last piece, after you have everything configured correctly, you must ensure that both ends of the connection have the QSNADS subsystem up and running before you’ll be able to send data.

When all is right with the universe, you’re ready to send your changes to the target system. This method has worked well for years, but there are better ways to manage your code changes and software upgrades. In this article, I’m going to tell you about one of them.

The Concept

One of the biggest problems with using SNA is that it doesn’t take advantage of all the advances in communications, such as TCP/IP and the Internet. Most AS/400s are moving away from SNA and moving to TCP/IP networks. In just a few years, it’s likely that all AS/400s will be on this type of network. If you haven’t already, you should be preparing your shop to reap the benefits of using the TCP/IP services. I’m going to show you how to do just that.

The concept for this technique is pretty simple. You want your programmers to be able to create all their code changes and enhancements in the same way they’ve been doing for years. What you’re going to do, however, is put the onus of implementation on the user rather than on the programmer. After that, it’ll be up to the user to decide when the changes should be implemented.

There are several reasons for doing it this way. One is the issue of timing. By making it a user responsibility to upload and restore object/code changes, you free the programmer of the responsibility of coordinating with the user a time when the upgrades can take place. If the users have all the changes in hand and can easily apply them at their leisure, then it’s a piece of cake for them to find a spare 10 to 15 minutes when no one is using that particular system, and the software can be upgraded. If it’s up to the developer to do this, he’ll constantly be trading phone calls with the user, trying to find a time when he can log onto the user’s system and restore or compile the changes.

You want a system that will let a programmer write a piece of code, package it for the user, and then let that user upload it when he has the time. Making that concept a reality is a bit more complex than it sounds. The solution will be made up of the following pieces:

• One AS/400 command

• One AS/400 CL program

• One AS/400 display file

• Two AS/400 physical files

• One AS/400 RPG IV program

• One PC-based FTP server program

• InstallShield

Most of these you’ll be familiar with. You may not be as familiar with the concept of an FTP server or with InstallShield.

Why an FTP Server?

Everyone knows that you can run an FTP file transfer on the AS/400. If you have two AS/400s connected to the Internet, it’s a simple matter to transfer FTP files between the two systems. Or, if you have a PC connected to an AS/400 via TCP/IP, it’s very easy to use the PC’s FTP client to transfer files to and from your AS/400. What is not so simple is transferring files directly from the AS/400 to the PC. This is because, unlike the AS/400, most PCs do not act as FTP servers. To do so, they’d need an FTP server package on them.

In my solution, you want to be able to automatically FTP your program and code changes in the form of a save file to the PC, where it can be packaged using InstallShield. If you wanted to, you could run FTP commands from the PC and send them to the AS/400 to save objects and download the changes, but that requires an extra level of complexity

and familiarity with FTP and PCs that many traditional AS/400 programmers don’t possess.

What I use here is a PC FTP server called Serv-U that I downloaded from the Internet. This is a shareware product that, if you decide to keep it, requires a nominal license fee. I use this product to give my PC the capability of receiving FTP commands from my AS/400. It’s very easy to use and only takes about 5 minutes to install and configure. Set it up to run as a system service so that it starts every time the PC boots, and you never have to think about it again. The nice thing about this particular product is that it also lets me execute PC commands from the AS/400 without the requirement of having Client Access/400 installed on my PC. There are many other shareware FTP programs out there, so use whichever one best meets your needs. Visit the CNET Shareware.com page (www. shareware.com) as a starting point to begin looking for FTP server software.

InstallShield

The other half of the PC equation is using a package named InstallShield. InstallShield is probably the most well-known and most overlooked software in the world. It is used by more companies on a daily basis than Bill Gates has lawsuits. It’s also one of those packages that works so well that, even when you’re using it, you barely notice it.

Shown in Figure 1, InstallShield is basically a product that lets developers take all the pieces of their software (e.g., programs, menus, and data files) and condense them into one simple package that users can use to install the software on their systems. Typically, PC programmers have used InstallShield to distribute their PC-based software packages. In fact, IBM uses it to install Client Access/400, and Visual Basic (VB) has a subset of InstallShield built into it that allows VB programmers to build executable installation packages. In my solution, I take that traditional PC programmer’s approach and apply it to the AS/400-based software PTFs.

The Final Pieces

The last few pieces of this puzzle are some pretty generic AS/400 programs and files. PTFSYS is a command interface to FT0001C. FT0001C is a CL program that prompts the user for the type of save to perform; runs the save; calls the program to build the FTP script; and then runs FTP script, sending the files to the PC’s FTP server. FT0001R is an RPG IV program that actually builds the FTP script. RSTLIBNAM is a physical file that is created in library QTEMP and will be sent to the PC client during the FTP download. FTPCMDS is a work file used to hold the FTP script built by FT0001R.

On each AS/400, there should exist a user ID named FTPUSER with a password of FTPUSERID. (You’ll need to create it if it doesn’t exist.) This is the profile that FTP will use to log onto and restore objects to the various AS/400s. This user profile should be used only by this utility. Keep in mind that, by hardcoding the user profile and password, you are creating a security breach. You may want to modify the FTP script to prompt the user for the password. You can do this by simply leaving the password out of the FTP script. When you do, FTP will sign on with the FTPUSER user profile and then prompt you to manually enter the password. Also, a library named FTPLIB should exist on each AS/400. This is the name of the library the save file is sent to. Again, if the library doesn’t exist, then you’ll need to create it. If you want to change the FTP script to send it to a different library, then you’ll need to do so in the InstallShield setup script.

Putting It All Together

OK. So there are the pieces. Here’s how it works. The AS/400 programmer writes his code and compiles the programs and files. Now, he needs to get those changes (what I’ll refer to as PTFs) to the user’s AS/400. The programmer runs the PTFSYS command I’ve created. This command will save the programmer’s changes to a save file, which will then be FTPed to his client PC. Once there, the programmer opens InstallShield, opens the PTF

Distribution System project, and clicks on the Media Wizard menu option to package the changes and build the installation media (diskette, CD-ROM, packaging for the Web, etc.). The programmer then sends the installation media to the user either on a diskette or on a CD-ROM or as an email attachment. Or, if the programmer’s shop has its own Web site on the Internet, the install package can be downloaded from there. At this point, the programmer’s job is done. It’s now up to the user to decide when he will upload the changes.

When the user is ready to upload your PTFs, he will load the installation media on a PC connected to the AS/400 via TCP/IP and double-click on the Setup.exe program. When the setup program is executed, it will create a directory on the user’s PC under the Program Files directory on the C drive. The AS/400 save file you created will be copied to this directory, along with some other required installation files. The user will be prompted to select the IP address of his AS/400 from a list generated from the PC’s C:WindowsHosts file, and an FTP upload script will be created on the user’s PC. If the Hosts file does not exist, the user will be prompted to enter the TCP/IP address of his AS/400. The final step in the installation process will be for the setup program to automatically run the FTP script, which uploads the save file to the user’s AS/400 and restores it to the library the programmer specified when he created it. That’s it!

A Bit More Detail

Let me go over that in a bit more detail. CL program FT0001C is executed from the PTFSYS command and displays the screen shown in Figure 2. Based on the save type chosen, either the Save Object (SAVOBJ) or the Save Library (SAVLIB) command will be executed to perform the proper save. The programmer also enters the name of the libraries to save and restore to. This information is used by InstallShield to build the FTP upload script on the user’s PC when he runs the Setup.exe program to install your software. RPG program FT0001R builds the FTP download script that sends the save file to the programmer’s TCP/IP-connected PC.

For this to work correctly, the files must be downloaded to the same directory on the PC every single time. When you download the code for this utility from the MC Web site, you’ll find a Setup.exe program.

Run this program to install all the code on your AS/400 and create a directory named MC PTF Distribution System under a directory named MC, which is under the Program Files directory on your PC’s hard drive. You can change this directory name if you want, but beware that, if you do, the instructions on including files in the InstallShield build will need to be changed to reflect the new name. The path names hardcoded in the RPG IV program will need to be changed, too.

Using InstallShield

I’ve included a generic setup script for InstallShield that you can use in your own system. When you purchase InstallShield, you’ll receive the User’s Guide with it. This guide will explain many of the commands shown in the script. Familiarize yourself with the commands I’ve included in the script and modify them to fit your own needs. To create the basic InstallShield package required for this utility, you’ll need to perform a few steps, which are outlined in the InstallShieldUsage.rtf file. Keep in mind that, as you learn more about using InstallShield, you can make your own package as complex as you like. The complete setup and usage instructions for using InstallShield with this utility are contained in two text files included with the download from the MC Web site. InstallShieldProjectSetup.rtf describes the steps you take to create your own InstallShield installation project using the generic script I’ve included here. InstallShieldUsage.rtf contains instructions on how to use InstallShield on a regular basis to create your own software installation media.

What You’ll Get when You Download

All of the AS/400 code, the PC FTP batch files, a shareware version of the FTP server, a generic InstallShield setup script, a Readme.txt file, and the two InstallShield setup and usage text files are included in the download file you can get from MC’s downloadable code Web site at www.midrangecomputing.com/mc. Once you’ve downloaded the code, click on the Setup.exe program to run the setup and install the software on your AS/400 and PC. View the Readme.txt file for system requirements and late-breaking installation notes.

You will need an active TCP/IP connection to your AS/400 to load the software on the system, and the AS/400’s FTP server must be started. Also, before you run the Setup.exe program, create an AS/400 user ID named FTPUSER with a password of FTPUSERID. If you already have a user profile on your AS/400 named FTPUSER, you will need to modify both the RPG IV program and the Install Shield script to use a different user ID. Make sure you give these profiles enough authority to save and restore objects on your system. The source code and objects required for this utility will be placed in a library named MCCODE in a source file named MCSOURCE on your AS/400. The Setup.exe program will create this library for you using the FTPUSER profile.

User Empowerment

Once your user has the setup media (diskettes, CD-ROM, or what-ever), he simply clicks on the Setup.exe program on the media, and your software PTFs will be uploaded and restored on his system.

At first glance, this sounds as if it’s a lot of work. But really, after you create the initial InstallShield project and install the FTP server on your PC, it’s amazingly simple. The programmers create code changes just as they always do and have only two additional steps: Run the PTFSYS command to save and download those changes to the client PC, and click on a couple of menu options in InstallShield to build the installation media. After that, it’s just a matter of getting those changes to the users so that they can upload them when they are ready. Managing software distribution has never been easier!

References and Related Materials

• Cat Soft Serv-U FTP Server Web site: www.cat-soft.com
• CNET Shareware.com page: www.shareware.com
• InstallShield Software Corp. home page: www.installshield.com

Figure 1: You’ll need to modify the InstallShield script before you can use this utility.

Figure 2: Run this program to save and download your code changes to your PC.