midrange.com - In My Humble Opinion

An interesting thread has received a lot of attention recently on the rpg400-l list with the subject "RPGIII to get a facelift?" (see here to browse it in the archives). Among the many posts in this thread is one by Scott Klement that makes the point that in order to get people to move from RPG III (or even RPG II!) to RPG IV IBM needs to provide user visible features that are only accessible with RPG IV. The users referred to here are not programmers or managers, but data entry people or other non-techie types. Scott gives a few examples such as graphics capabilities or XML features. While true, this idea is only half right. In order to get people to move to RPG IV features must be provided that are only feasible in RPG IV, as Scott suggests. However, it is up to the programmers and developers, not just IBM, to provide such features.

What is a programming language, anyway? More or less, it provides instructions and manipulates memory. What distinguishes one language from another is how it provides the syntax and methods for doing so. With RPG IV we have a language that has great flexibility to accomplish the two main things a language does as stated above: we have a number of ways to manipulate memory and a number of ways to provide instructions. In fact, the only thing we can't do is provide our own BIFs. And this is what IBM needs to change. We should be able to write:

%mybif(%trim(%myotherbif(myvar)))

This change needs to come from IBM.

But this isn't the kind of feature Scott was talking about. Nor is it the kind of thing that an end user is going to see. So where do these features come from? The answer is us. IBM's obligation is to provide the language with flexibility to accomplish the two tasks of providing instructions and manipulating memory. We are under obligation to do the rest.

Let's look at an example. Enhanced graphics is certainly something the users would see. As is HTML integration. Perhaps most interesting is the idea of combining both. Imagine a 5250 screen with embedded HTML in it. That HTML could be something as simple as a GIF or as complex as a web application. But my point is that the HTML could be directly imbedded in the 5250 data stream. 5250 emulators such as tn5250 could embed Gecko (the HTML renderer in Mozilla) directly into the emulator to handle such HTML streams. A special attribute in the 5250 data stream would indicate that data following it is HTML. Another special attribute (or maybe the same one) would indicate the end of the HTML stream. Then a simple EXFMT would send the combined 5250 and HTML data to the 5250 client and voila! a feature the user can easily see and benefit from.

What is required to make such a feature? First, a 5250 client that can handle such data. That is certainly doable by us, the developers. Many projects exist that embed Gecko. Most of those projects are not backed by some large company. It is certainly reasonable that the iSeries community of developers could add such capability to a 5250 emulator.

Second, we need to get the HTML data into the 5250 stream. IBM could do this and add it to DDS and EXFMT. But can only IBM do it? It seems reasonable that an independant developer could write a function that when called writes HTML data to the 5250 data stream as described. This may involve some serious MI coding and a lot of work. But it could be done. Package it up and make it available to everyone. Suddenly, RPG IV has something that users want that they can't get with RPG III.

This wouldn't be the first time that great innovations and improvements originated outside of the company that produced the platform. Much of the UNIX world exists because people outside of AT&T starting adding features they thought were useful. Indeed, without outside contribution UNIX would have probably ended up being a niche operating system forever forgotten in the research lab. But regular (though talented) folks got involved and today we have Sun Microsystems, Cisco, BSD (in all its many flavours), Linux, and Mac OS X.

Let's not wait for IBM (or anyone else) to do things for us. If we can reasonably do something ourselves then we should. There are many great features that users would want that require the new capabilities in RPG IV. Let's charge ahead and create them!

Today midrange.com is 11 years old.

Of course the concept behind midrange.com is even older ... the domain was registered 11 years ago.

I find it quite amazing that something that started as a 286/8 Compaq Portable II with a 2400 baud modem could have grown into something as useful as this.

I've decided to repost some of the old IMHO articles that were on midrange.com.

Currently I only have Dean Asmussen's articles (who passed away in the spring of 2003) as sort of a homage to his memory.

I'll have to contact the other authors to make sure they want their old articles reposted.

Found this on Search400 ...

... how to change your FTP server to use a port other than the default port of 21. Ports in the range of 0-1023 are reserved and well-known ports, with port 21 being the established standard for FTP. The reason most people want to do this is to make it harder for someone to gain unauthorized access to your FTP server.

Although this may make it more difficult for someone to discover that you are running an FTP server, this by itself will not prevent someone from being able to discover and potentially hack into your FTP server. If you decide to use this technique, keep in mind that this is no substitute for other types of security and should be viewed as only a very small piece of your security infrastructure. If you have existing FTP programs or scripts, you will need to change them to access your new FTP port.

For anyone who has tried to do this, you may have noticed that the port can't be changed using the CHGFTPA command. Here is how to make the changes.

1. Enter the command WRKSRVTBLE and scroll down to the services that are labeled ftp-control.
2. Display and print these entries.
3. Use the command ADDSRVTBLE to duplicate these entries exactly as they appear, with the exception that you will specify a new port number. To get lowercase values to stay lowercase, make sure they are enclosed in single quotes. When you specify your new FTP port, you should avoid using the reserved ports of 0-1023. You should also try to avoid using other ports that are already defined.
4. Compare your new entries to the existing entries that are on port 21 to ensure that everything is an exact match.
5. Delete your existing entries for service ftp-control that is on port 21.
6. End and restart TCP/IP.
7. If you wish, entries labeled ftp-data can also be changed in a similar manner.

When you access FTP from the AS/400, you will now have to specify the port. From the AS/400 the FTP command would look like this:

FTP RMTSYS ('10.10.10.10') PORT (21021)
From the DOS prompt, it would look like this:

C:WINDOWS>ftp
ftp> open 10.10.10.10 21021