Why SQL? Why Now?

January 14, 2004 Raymond Everhart

SQL has been available on the AS/400 and iSeries for years. When SQL was first introduced, it was not widely embraced, because of limitations and performance concerns. Since then, IBM has improved SQL on the AS/400 and iSeries so dramatically that in some cases it outperforms “native” RPG and COBOL record-level access. In spite of the many improvements, many programmers have not yet explored what SQL can do for them.

What about you? Can you be persuaded, in just a few short paragraphs, to use SQL? Let me start by saying that SQL is just another programming language. Like all

Deleting with a Generic File Name

January 14, 2004 Hey, Ted

I’ve been working on the AS/400 for almost 15 years now, and I’ve always thought that a physical file could not be deleted until all the logical files based on the physical file had been deleted. However, while working on a problem dealing with deleting a physical file when a logical may or may not exist, I tried using a generic file name. My reading of the DLTF command description led me to believe that the files would not be deleted. To my surprise, the files–the physical file and the two logical files–were deleted. Did I misunderstand the description? Is

Functions Can Modify Parameters, Too

January 14, 2004 Hey, Ted

Steven Gray suggested that it’s a good idea for an RPG function subroutine to return a data structure. I think he’s on the right trail but barking up the wrong tree. Barbara Morris pointed out that it’s more efficient to modify a data structure as a parameter of a subprocedure. I suggest that the best approach is to combine the strengths of the two methods.

I understand and fully appreciate the enthusiasm many programmers feel for functions. Compared with traditional RPG coding methods, nesting an %INT function within a %SUBST function within a %CHAR function, for example, eliminates

Admin Alert: Three Common Mistakes in CL Administration

January 14, 2004 Joe Hertvik

With a mature operating system like OS/400, there are plenty of subtle tricks you must understand in order to ensure that you are administering your system correctly. This week’s “Admin Alert” looks at three common OS/400 administration mistakes and explains how to avoid them and keep your shop running smoothly.

MISTAKE 1: NOT GIVING A SUBSYSTEM ENOUGH TIME TO END

This is a common problem in CL programs that restart a subsystem by issuing an end subsystem command, followed by a call to restart the subsystem. A simple example is the following piece of CL code used to perform maintenance

OS/400 Alert: Spoofing and Demonstrations

January 14, 2004 Shannon O'Donnell

In this issue of “OS/400 Alert,” I’ll alert you to the concept of spoofing and offer suggestions on how to protect yourself from it. In addition, I’ll tell you know about some useful technology demonstrations made available by IBM for the iSeries Navigator tool. If you have been wanting to learn how to use iSeries Navigator for your operation but were not sure what it could offer you, you won’t want to miss out on these great demos. Finally, I’ll tell you about the viruses that are causing this week’s worries.

HAVE YOU BEEN SPOOFED?

Spoofing in our Internet-connected world