System iNetwork

April 2005

April 28, 2005 11:55 AM

It's Time to Improve Our Image

There's been a lot of talk lately about IBM's new marketing strategy, and how IBM says that they'll finally market the iSeries. However, there's a major issue associated with marketing this system that we all need to work on.

We must do a better job with the way our software presents itself to the end user if we want this system to survive. And, to do that, we must give our programs a GUI interface of some sort.

For example, When you walk down the aisle of a grocery store, studies have shown that the packages that are most pleasing to the eye are the ones that sell. Not necessarily the food that tastes the best, or has the lowest price (Though those factors do help!) but the most important thing for attracting customers is how the package looks.

The same is true for your computer programs. How the screens look is absolutely vital. You should be putting as much effort into how they look as you do into how they work -- both are important!

Let me use another analogy: clothing. What's needed for clothes to be practical? They don't have to match. They don't have to look good at all, in fact. They just have to protect you from the weather, that's all. Yet, it's very important to all of us to look good. We want nice looking new clothes. We want to coordinate them so the colors look good together, they fit us well (though, some of us better than others!) and that they're appropriate for different events. How they look to others is paramount.

And that's a huge reason why green screen fails. In fact, the green screen paradigm is a big part of the decline of the iSeries. Nobody wants to invest in a system where most of the programs are green screen. It's absolutely killing our platform.

IBM has given us not one, but several ways to make them GUI. There's CGI, or much better the CGIDEV2 tools for RPG programmers. There's WebSphere and Tomcat and all that goes with them. There's HATS and Webfacing. There are many third party tools. There's ODBC, DRDA and VARPG if you want to write software that runs on the PC and communicates with the iSeries. If all else fails, you can write GUI applications that communicate with iSeries applications through sockets.

For some reason we're not doing it! When you go shopping for iSeries software, you still predominantly see green screen. That may not matter much to us as iSeries professionals, but it has an enormous impact on our users, our management, and virtually everyone else.

There's more to marketing than paying for advertisements. In order to the iSeries to remain a force in the market, the way our programs present themselves must change. Until then, it'll be a "legacy machine."

Posted by on April 28, 2005 at 11:55 AM | Comments (42)

April 20, 2005 12:15 AM

Pointers in CL?

At the spring COMMON conference, I had the priveledge to meet Guy Vig, or as he was introduced to me, "Mr. CL". He and I had a conversation about the future of the CL programming language.

Out of the blue, IBM made some profound changes to the CL language in V5R3. In fact, not since ILE support was introduced in V3R1 has CL had such significant changes made to it.

The next release of OS/400 (the one that follows V5R3) promises to continue to offer CL improvements. The proposed changes include support for pointers and defined-on variables that work like data structures.

You may be saying to yourself "Why would I want to use pointers in CL?" or even "Pointers! That's a bad idea! Leave the complicated stuff for C programmers!" At first, I agreed with that sentiment. However, as I thought about it a little more, I warmed up to the idea.

To understand why I think CL could use pointer and based-on variable support, let me explain what I feel the purpose and goal of the CL language is.

The name "CL" stands for "Control Language" and also explains it's purpose. It's purpose is to control the flow of a job, and there are certain things that are important for doing that:

• The CALL and CALLPRC commands. These are absolutely vital for a control language, since that's what controlling the flow of a job is all about, calling programs.
• The IF and ELSE commands, and support for variables. Again, part of being in control of the flow of a job means being able to perform some rudamentary calculations and use the results as conditions for whether or not a call should be made.
• Loops and GOTOs. I could argue that the GOTO command is not needed in any language today, but until V5R3 this was the only way in CL to perform a loop. The ability to loop is absolutely vital to controlling the flow of a job.

Finally, my point: For the ability to call programs, call them conditionally, and loop between them to be effective, you need to be able to pass data between them. In order for CL to be able to pass data correctly, it needs support for the various data types that are available in the high-level languages (HLLs) that it calls! HLLs have support for passing pointers as parameters, and therefore CL should be able to receive those parameters!

Just think if CL didn't have support for the *CHAR (character) data type! How would an RPG program set a variable that could be passed to a different program later? Likewise, a CL program has the ability to read a *DEC (packed decimal) from one program and pass it to another. It should have the same support for pointers and data structures!

The following code is a sample program intended to show off the power of these enhancements. It does something that you couldn't easily do in previous versions of CL -- it reads the contents of a directory in the IFS. For each tab-delimited file that it finds in the directory, it uses CPYFRMSTMF to convert it to a PF that will be later processed by an RPG program:

PGM

     DCL VAR(&NUL)     TYPE(*CHAR) LEN(1)   VALUE(x'00')
     DCL VAR(&DIRNAME) TYPE(*CHAR) LEN(200)
     DCL VAR(&EXT)     TYPE(*CHAR) LEN(4)
     DCL VAR(&POS)     TYPE(*INT)  LEN(4)
     DCL VAR(&SUCCESS) TYPE(*INT)  LEN(4)
     DCL VAR(&HANDLE)  TYPE(*PTR)
     DCL VAR(&ENTRY)   TYPE(*PTR)
     DCL VAR(&NULLPTR) TYPE(*PTR)
     DCL VAR(&STMF)    TYPE(*CHAR) LEN(640)

     /**********************************************************/
     /*  This works like a data structure  It's 796 chars      */
     /*   long with a field called &NAMELEN in positions 53-56 */
     /*   and a field called &NAME in positions 57-640         */
     /**********************************************************/

     DCL VAR(&DIRENT)  TYPE(*CHAR) LEN(796) +
                       STG(*BASED) BASPTR(&ENTRY)
     DCL VAR(&NAMELEN) STG(*DEFINED) DEFVAR(&DIRENT 53) +
                       TYPE(*UINT) LEN(4)
     DCL VAR(&NAME)    STG(*DEFINED) DEFVAR(&DIRENT 57) +
                       TYPE(*CHAR) LEN(640)


     /**********************************************/
     /* Open the /edi/incoming/custdata directory: */
     /* the API returns a NULL pointer to indicate */
     /* failure.                                   */
     /**********************************************/

     CHGVAR VAR(&DIRNAME) VALUE('/edi/incoming/tabdata' *CAT &NUL)

     CALLPRC PRC('opendir') PARM((&DIRNAME)) RTNVAL(&HANDLE)
     IF (&HANDLE *EQ &NULLPTR) DO
        SNDPGMMSG  MSGID(CPF9897) MSGF(QCPFMSG) MSGDTA('Unable +
                  to open directory!') MSGTYPE(*ESCAPE)
     ENDDO


     /**********************************************/
     /* Read the contents of the directory, and    */
     /*  convert each stream file that ends with   */
     /*  '.TAB' to records in a physical file:     */
     /**********************************************/

     CALLPRC PRC('readdir') PARM((&HANDLE *BYVAL)) +
                            RTNVAL(&ENTRY)

     DOWHILE COND(&ENTRY *NE &NULLPTR)

        CHGVAR VAR(&STMF) VALUE(%SST(&NAME 1 &NAMELEN))

        /* extract the last 4 characters from the filename */

        IF (&NAMELEN *GE 4) DO
           CHGVAR VAR(&POS)  VALUE(&NAMELEN - 3)
           CHGVAR VAR(&EXT)  VALUE(%SST(&STMF &POS 4))
        ENDDO
        ELSE DO
           CHGVAR VAR(&EXT)  VALUE('    ')
        ENDDO

        /* if the last 4 are '.TAB' add to our PF, and  +
           delete the original so that it doesn't get   +
           processed again                             */

        IF ((&EXT *EQ '.TAB') *OR (&EXT *EQ '.tab')) DO
            CPYFRMIMPF FROMSTMF(&STMF) TOFILE(TRANMAST) +
                       MBROPT(*ADD) RCDDLM(*CRLF) FLDDLM(*TAB) +
                       RPLNULLVAL(*FLDDFT)
            DEL OBJLNK(&STMF)
        ENDDO

        CALLPRC PRC('readdir') PARM((&HANDLE *BYVAL)) +
                               RTNVAL(&ENTRY)
     ENDDO


     /**********************************************/
     /*  Close the directory                       */
     /**********************************************/

     CALLPRC PRC('closedir') PARM((&HANDLE *BYVAL)) +
                             RTNVAL(&SUCCESS)


     /**********************************************/
     /*  Call an RPG program to process the new    */
     /*  transactions                              */
     /**********************************************/

     CALL PGM(PROCESS)

ENDPGM

The IFS APIs are just one example. There are many useful APIs that become accessible with pointer support! Other examples include string handling functions and database reading/writing/updating. The only thing preventing you from doing this in CL in V5R3 is that there's no pointer data type.

Do you have an opinion of whether pointers or other features are right for CL? If so, please post your comments as a reply to this blog entry.

Posted by on April 20, 2005 at 12:15 AM | Comments (4)

April 19, 2005 6:26 PM

CGI & RPG - Dynamic Duo

I continue to be amazed by what can be done with a little RPG and the CGIDEV2 tool from IBM. Folks that have struggled with web development on the iSeries really needs to look at leveraging RPG skills with the easy web deployment using CGIDEV2. Can you think of a more secure and reliable web server than the iSeries? I can't!. And, what better way than to access iSeries data than using the same platform! For any web development, look inside at your own resources before using anything else!

Posted by on April 19, 2005 at 6:26 PM | Comments (19)

April 15, 2005 11:56 PM

iSeries Loyalty.

My current job is away from the iSeries – I advise small businesses on eCommerce. This month I visited a small accountancy business and was talking to the client when he mentioned that he recently worked for a larger enterprise which he named. This company I had heard of – it is, or was, a large AS/400 user with an international presence. Although I had never worked for this enterprise, I had worked with people who did.

So we got chatting about this company and the AS/400 (it is nice to find someone who knows what an AS/400 is.) Some of the things he said made me think. Paraphrasing slightly, he made comments such as:

'They were getting rid of the AS/400 or i-something as it is now called – it is old technology.'

'All the systems were old text-based screens and no-one wants to work with them any more.'

'There were a number of AS/400 loyalists – if you were to cut them in half they would have AS/400 written inside them.'

For the first comment, it seems to me that IBM have an issue in the way the AS/400, sorry iSeries, sorry i5 is marketed – this is not the first time I have heard such comments. We, who work with this box, know of its class leading technology but the message does not appear to be getting through to the decision makers. No wonder sales are stagnating.

For the second comment, I wonder who is at fault. Is it IBM or the management of the company? Although I am an advocate of the efficiency of text based business systems in some circumstances, this is not what the world currently wants. So is the iSeries at fault or the IT management of the company for not updating the user interface?

For the third comment I have mixed feelings. It is good that there is a core of iSeries loyalists who can champion this amazing machine (why isn't IBM using them to spread the word?), but I wonder if they themselves are still stuck in the past, developing green-screen applications that people are now uncomfortable working with. Did they champion class leading, modern applications or deliver just another 5250 application.

Until quite recently, I still came across those refusing to move to RPGIV, preferring to stay with RPG3/400. So I suspect that a graphical interface is beyond their expectations. The management then see attractive Windows systems and ask why this cannot be done on their expensive iSeries.

The rest is history…

Posted by on April 15, 2005 at 11:56 PM | Comments (10)

April 5, 2005 1:51 PM

The Global Economy - SOX

We certainly live in a global economy. This was driven home to me here in the UK by the amount of coverage in this weeks computer press given to the Sarbanes-Oxley bill. For example, one paper had a double page spread on the impact of SOX on UK companies.

The reason for this is the impact the bill has, not only on British or European companies that have a listing in the US, but US companies operating on this side of the Atlantic. It appears that these regulatory controls affect the operations of the companies outside the US.

I then go on to read that other companies, without any operations in the US but trading with US companies, may have similar requirements imposed upon them by their trading partners (the sentiment appearing to be: if we have to comply, so should you).

Then, there are the UK and European software houses that produce packages that sell in the US. Not only do they have to contend with the practical business differences between Europe and the US (such as the differences between US sales tax and VAT), but also the new US regulatory requirements will have to be accommodated.

In addition, there are also new regulatory hurdles in this country to be crossed, with legislation coming from both the UK government and the European Union.

So, it looks like that over the coming few years, IT departments in this country are going to have the same fun/pain that our US counterparts have been having.

Posted by on April 5, 2005 at 1:51 PM | Comments (3)