Brother Cozzi's "Top Ten RPG IV Requirements"

Recently Brother Bob Cozzi, the eminent leader of the RPGers Order,  published a list he called the Top Ten RPG IV Requirements. I would like to respond to that list and proffer some of my own:

1. %JOBLOG(): While I have the greatest respect for Brother Cozzi this requirement leaves me feeling,... feh. Our lord Ib'm saw fit to provide us with the QMHSNDPM API and I've been using it so long I know the parameters by heart.
2. %CONCAT(): I can see this being kind of useful, kind of like the sprintf() function from the "C" run-time cannon, but there is a difficulty when it comes to numeric fields. What if you want some to keep the leading zeros. It seems to me that it would be easier to just string everything together in a character expression.
3. %GETENV and %PUTENV: Great idea. Don't know why our Lord Ib'm hasn't implemented these built-ins yet. They would be very useful. What's the difference between this and using the Unix "getenv" and "putenv" functions to do the same thing? [Thanks to Father Klement for reminding me about these two functions as I had completely forgotten about them.]
   
4. %STDOUT: What's the difference between this and using the Unix "open" with the "read" and "write" functions to do the same thing? Am I missing something? (And by the way, what's wrong with switching to embedded SQL? I've been doing it now for a number of years and I love the fact that if you add a field to a record format you don't have to recompile everything.)
5. %REGEX: Can't really comment 'cause I haven't used the APIs yet.
6. %TOLOWER and %TOUPPER: This already exists and it's really easy. Two named constants and the %XLATE() built-in and you're done. I can't imagine our Lord Ib'm wasting his time on this.
7. Native Support for UTF8 (ASCII): This is a good one. I'd love to have a CCSID keyword to identify the data in the field and the internal support to convert the data as it's being moved into or out of the field.
8. 3rd-party Add-On Library Support: Great for developers, but I suspect that the vast majority of AS/400 programmers like myself won't care too much.
9. Reclamation; of columns 1 to 7 in free format syntax: I don't mind the /free and /end-free requirement or the loss of columns 1 to 7 as I too use it to mark changed code. What has always bugged me is the requirement that the executable code ends at column 80. It's a 100 byte line and we should be able to use its full length if we want to. In free-format languages one isn't restricted to the end point of the file, so why should free-format RPG be that way too.
10. Port RPG IV to Windows 7 and Mac OS X and Linux: Great idea as it will expose the followers of those false religions to the beauty of iSeries worship.

---

My top ten: 

1. Free format everything in RPG including the "D" and "F" specs and remove the end-of-line restriction at column 80.
2. %LEN and %DECPOS should be compile-time BIFs when the parameter is a single field. (When the parameter is an expression they can revert to being run-time BIFs.) I've got some routines where there are more named constants specifying %LEN and %DECPOS than local variables.
3. Null Terminated Fields: I'd go further on item number 7 in Brother Cozzi's list by asking for an additional keyword that identifies a character field as null terminated. Every time you use it or change it the compiler would automatically handle the null terminator. 
4. Expand *JOBRUN date formats: Currently restricted to *MDY, *DMY, *YMD, and *JUL. They should be expanded to *EUR, *USA, *ISO, *JIS, *LONGJUL, etc., which would also require the O/S folks in Rochester add these values to the DATFMT attribute of the job. I can't tell you how many times I've had to write code to get around this restriction in full date processing in an international environment. 
5. Expand date functionality to include date formats required by such things as email headers, RSS, *DTS (internal date format for message fields), etc. The learning curve on the MI instructions and/or Unix API's for them all was daunting.
6. Fix Data Display Problems in Debug: In debug, displaying the data at the end of a passed pointer has always had problems. I've got code all over the place where a structure pointer has been passed and it points to a space that contain pointers to other structures and the debug facilities in WDSCi and the green screen can't display the data they point to because of the underlying design of debugging data stored in the program object.
7. Multi-dimensional arrays: Every other language I've ever worked with has had the facility for arrays with more than one index. How is it that RPG has survived all of these years with one index?
8. Dynamic arrays: Many of us have written service programs that allow an RPG program to expand the size of an array on request and I think it's time that the RPG compiler got this feature. Instead of being a fixed size stored in the program it would be an allocated heap space. If I was designing this feature I'd add a new parameter to the DIM keyword that allows *EXPAND or *FIXED along with the dimension that would constitute the space allocated initially. Whenever a program specified an index that was out of bounds the run-time functions would simply re-allocate the space.
9. Parameter signatures in RPG procedures (aka Procedure Overloading): This would be similar to what is currently available in O-O languages like Java and C++. We can do this with SQL UDFs, so why not with RPG procedures? This would also make it a lot easier to interface with C++ procedures. It would also be nice to not have to use *OMIT and *NOPASS if you didn't want to. 
10. RPG classes: Another facet of Java and C++ that would be useful. It would also make it easier to interface with Java and C++ objects because the JNI hoops one must jump through now are too daunting to be useful.

Lord Ib'm hear my prayer, please have your minions fix the problem with READE that locks the last record in a STRCMTCTL LCKLVL(*ALL) environment. (This is the record that hasn't been read in because it's the one that caused the end-of-file condition.) This has been a permanent restriction since the System/38 days because the O/S routines that RPG is using are the ones that are locking the record. Toronto and Rochester should finally put their heads together on this one and find a solution.

New PTFs to be Tested on DEV: 08/22/09

PTFs were loaded for the following reasons:

• Recomendations:
  • High Impact Pervasive (HIPER).
• Group PTFs:
  • SF99539 (Level 108)^*: GROUP HIPER

The following PTFs were loaded for the above reasons:

5722SS1 (i5/OS):

• SI35859:
  • SE38501: OSP-DB-OTHER-RC4-MSGSQ30082 SQ30082 RC4 IS RETURNED ON DRDA
  • SE38440: OSP-DB UNNAMED COLUMN DRDA PROBLEM

---

^* -Loading this group did not result in any new PTFs being installed (they were already applied individually to our systems on previous IPLs), so only the level number was changed.

What are Lilian Days?

If you've ever used the CEEDATE() or CEEDAYS() API's on the iSeries you know that they both reference a parameter called "Lilian Days". In case you're curious, it's named after Aloisius Lilius who was an adviser to Pope Gregory XIII and an important developer of the Gregorian Calendar.

What I found most interesting (in the geeky sense) is that the concept of Lilian Days was invented by an Ib'm high priest named Bruce G. Ohms when his article "Computer Processing of Dates Outside the Twentieth Century" was published in the Ib'm Systems Journal, Volume 25, in 1986.

HTTP Group PTF SF99114 level 19 is Released on the Heels of Level 18.

Group PTF levels don't come out all that often. The HIPER group is every two weeks, but the other groups are every couple of months at least. Whenever a new version of a group PTF comes out on the heals of an earlier version it usually means that the high priests in Mecca (aka Rochester, MN) are correcting some kind of unforeseen problem. Sometimes they add a new PTF but more often than not they remove some PTF's. Always without explanation.

Last Friday our Lord Ib'm came out with level 18 of the V5R4 HTTP group PTF SF99114 and yesterday they issued level 19. In so doing they removed two PTF's from the group: 5722DG1-SI35431 and SI35432. The PTFs haven't been PE'ed, but I'm not sure whether or not I'm going to install them. On the one hand these two PTFs update the Apache server to the latest level (2.0.63) and fix a security problem (CVE-2008-2939). On the other hand it might cause other problems that our Lord Ib'm has seen fit not to reveal to us.

Recommended PTFs for Enterprise Externder is Incomplete.

The list of V5R4 recommended PTFs for Enterprise Extender (EE) is incomplete. I had to open a PMR with the minions of our Lord Ib'm because the old testament SNA communiation controllers on our development coding system failed to connect to the production systems, so we were unable to use SAVRSTOBJ.

The support priest sent me the complete list of recommended PTFs for EE and we were missing three PTFs. I have since confirmed that those were probably the three that we needed because after applying them the systems are again able to communicate using the old protocol.

When I checked I found that the EE list noted above wasn't up to date. I've sent feedback to the keepers of the web site, but as a courtesy I thought I'd post the complete list here as well:

PTF	Release	Cumulative Tape	Modules
MF40235	540	7107	*HPRIP ctlr with exchange ID defined will not vary on and SDLC XID has problem if HPR=*YES.
MF43629	540	8305	*HPRIP ctlr with exchange ID defined will not vary on.
MF42291	540	8183	DLUR and HPRIP controllers go vary on pending after Activate instead of VARIED ON, CPA58D1. MSCP changed to allow DLUR to recover on VTAM deactivate or activate.
MF42499	540	8057	NETWORK ID ALWHPTWR and HPR are *YES, ICF applications fail w/CPF5535, jobs remain in a UNKNOWN state. Sequence of BAD XID network frames case EE to be improperly initialized with invalid controller's values.
MF42587	540	8057	EE HPRIP controller remains in VaryOnPending status with no XID's being sent out.
MF45692	540	1000	EE using HPR and RTP receives timeout error. application joblogs show CPF5355. APPN&SrcSink shows RTPburst timer did not expire AND EE/HPR CONNECTION STALLS AND NO DATA IS SENT
MF44200	540	8305	EE endnode unable to locate a CICS region on ZOS LPAR
MF43891	540	8305	LDLC remains in a reset status, LatePrenegotiation XID does not send a NULL XID on its own.
MF45851	540	1000	HPR config is active, but active connections lock up, When you vary off APPC *HPRIP controllers and vl 07000C1F occurs, the process to activate PTF. An IPL will be needed to reset error condition. AND EE/HPR stops sending data when incoming stream data packet missing
MF46217	540	1000	EE task may block streams on gate before error is sent back
MF46237	540	1000	Vary On HPRIP CTL fails after IPL, XID does not complete
MF44897	545	8305	DLUR and HPRIP controllers go vary on pending after Activate instead of VARIED ON, CPA58D1. MSCP changed to allow DLUR to recover on VTAM deactivate or activate.
MF45170	545	9104	NETWORK ID ALWHPTWR and HPR are *YES, ICF applications fail w/CPF5535, jobs remain in a UNKNOWN state. Sequence of BAD XID network frames case EE to be improperly initialized with invalid controller's values.
MF44262	545	8305	*HPRIP ctlr with exchange ID defined will not vary on.
MF45881	545	9104	HEA fc181X and Virtual Ethernet fc268C lossing data in UDP layer
MF46122	545	8305	NETWORK ID ALWHPTWR and HPR are *YES, ICF applications fail w/ CPF5535 and will now accept retransmitted frames in BIND.
MF43329	545	8183	Partition/system crash with srcB6005121 on vary of EE controller
MF44072	545	8183	EE HPRIP controller remains in VaryOnPending status with no XID's being sent out
	545	do not order - test status	MF44344 - EE/HPR ICF application fails. CPF5107 E015 unbind received RTP did not check for this error
MF46366	545	1000	Vary On HPRIP CTL fails after IPL, XID does not complete
MF46218	545	1000	EE task may block streams on gate before error is sent back
MF46063	545	1000	APPC using HPR/EE gets RTP timeout
MF46064	545	1000	EE endnode unable to locate a CICS region on ZOS LPAR

IBM PE's seven PTFs for V5R4.

While my pastoral duties at this community are normally rather dull, my favorite activity is working with the most holy code (i5/OS) and PTFs (Parchment Temporary Fixes). I especially love it when I find an error in the code that causes the cardinals and bishops in Rochester to do something drastic.

A couple months ago, as part of a HIPER recommendation, we installed PTF 5722SS1-SI34484. The following Monday morning the BACKUP job was looping forever waiting for an HTTP server job to end. We didn't associate it with the PTF right away because this isn't the first time the backup got held up by something like this. By the time we'd figured out that this was a trend we'd already installed another HIPER recommendation, PTF 5722SS1-SI34576, which superceded the one installed previously.

So we were now stuck in an untenable situation. We couldn't remove the PTF and we didn't want to reload the O/S. Being in this kind of pickle can really focus the mind. I ended up writing a program that detected these zombie HTTP server jobs and killed them with ENDJOBABN.

The minions of our Lord Ib'm eventually discovered that a thread in the HTTP job was prematurely destroying the list of open files. The job would then sit there forever waiting of the files to close not knowing that that list was gone. In the end they had to PE a bunch of PTF's and since two of them were HIPER recommendations the fixing PTF (SI35317) was also made a HIPER.

Final tally was seven PE'ed PTFs and one HIPER, all from one PMR.

Some Source to Download

A colleague of mine has posted some programmer tools on his web site. Just click on the above link. The functions include service programs for Dynamic Arrays, Subfile Control, and Message Subfile Control. He's also included an example program that illustrates using the latter two service programs.

Microsoft Uses the iSeries to Run its Business.

Rumors have abounded for years that the false religion of Microsoft, who touts that large parishes can be run using Windows servers, actually runs their organization using more than a few iSeries systems. The heathens have always officially denied it, but the rumors don't go away. The story also goes that some time in the 1990's they tried to replace their iSeries systems with 1,200 Windows servers in a year-long project that was eventually scrapped because A) they couldn't process the data as fast as the iSeries and B) they had problems keeping so many servers operational.

If you have Windows XP then click this link (or cut and past it into an open browser window):
file:///C:/WINDOWS/Help/Tours/htmlTour/best_secure.htm
It's a web page that exists on every Windows XP machine as part of the Windows introductory tour.

According to supposedly well-connected sources the image on this page is from one of Microsoft's computer rooms in Redmond, WA. (I've also included it at left in case either you don't have Windows XP or the image at the above link is different on your version of the page.) The pic also appeared on the online Windows XP tour but Microsoft pulled it recently when it came to light what it represented.

The beige racks that take up most of the image on the left constitute a single AS/400 system circa 1991. (This is what the iSeries was called before our lord Ib'm rebranded all their platforms with the "Series" suffix.) The actual processor rack is on the far left. The next two are expansion racks holding feature cards and tape drives. The fourth rack appears to house the system's disk drives. (Probably not Ib'm drives.) Around this time Ib'm main frame computers were also housed in similar looking rack configurations. You can tell it's an AS/400 because there's a blue ribbon with a gold seal that runs diagonally down the side of each rack. Those are Malcolm Baldrige National Quality Award ribbons and the only IBM systems they were ever affixed to were AS/400's.

Of course to be fair the minions of that false religion would counter that the existence of a picture of an old AS/400 system on every Windows XP machine doesn't prove that Microsoft uses that system to run it's organization and I would have to admit that such an assertion is technically correct. It doesn't prove anything, but it sure is a fun urban legend, especially for a group as beleaguered as the iSeries faithful.

Thanks to my friend and colleague Rabbi Mark for bringing this one to my attention.

Why the iSeries is Awesome, part 1: Command Prompting

Command prompting blew my mind when I first encountered it. Up until that point one had to have the manual by one's side (or the MAN pages up on another session) looking up parameters and their allowable options. However on the iSeries you don't need any of that stuff (unless of course you intend to do something hairy) because command prompting puts it all on the screen for you. All you have to do is find a command line, type the command you want, press the prompt key (F4) and presto, a screen appears with the parameters the command accepts.

Now this would be awesome enough, but our lord Ib'm didn't leave it at that. Down the middle of the screen are fields to enter the parameter values. On the left is a description and on the right is a list of the possible values that could be entered in each field. If you press function key 11 it will hide the allowable values and display the name for each parameter. Many of the fields will have default values already entered and the ones that are required will be highlighted. If any mistakes are made the command prompter will reverse image the field and display messages explaining the errors. (The messages have a feature that allows you to get help on what they mean and how to recover from them, but that's a subject for another posting.)

If the list of probable values doesn't fit and you want to know what else can be entered then move the cursor to that field, press the prompt key (F4) again, and a full list of allowable values for that parameter will appear. Don't know what the parameter does? Then instead press the help key (F1) and a detailed description of the parameter and all of its special values will appear. Need an explanation of what the command does? No sweat; from the first help screen press the extended help key (F2) and a full explanation of the command comes up.

You won't believe how incredibly easy it is to traverse the a command's help to find out what you need to enter where.

Finding Commands to Prompt

"But" I hear you saying, "how will I know what commands to enter", which is a valid concern, but our lord Ib'm has thought of that as well because they have provided the hapless user with many paths to the command you need. Standardized TLA's, command grouping menus, and generic command selection are just some of the ways in which you, the hapless user, can find your way to CL Command enlightenment.

Every command starts with a verb, like Change (CHG), or Delete (DLT), or Power-down (PWRDWN--and yes, "power-down" is a verb) and is followed by a subject (or noun), like program (PGM), module (MOD), device (DEV), job description (JOBD), etc. So the command to delete a program is "DLTPGM" or power-down the system is "PWRDWNSYS".

Another way to find a command is via the command grouping menus. To display a menu you execute the "GO" command with a menu name. To see a list of every verb and subject on the iSeries go to the VERB and SUBJECT menus. You can also go to individual command gouping menus by adding the prefix "CMD" to the TLA in question that you're curious about. (ie. GO CMDCHG, or GO CMDDLT, etc.)

Generic command selection is another good way to find commands. Say you want to compile a C++ program. To put it into iSeries lingo what you actually want to do is "create" a C++ program and on the iSeries the verb "create" is always spelled "CRT". So find a command line, type "CRT*", press enter, and you'll be presented with every command that starts with "CRT" (along with a one line description of what each one of them creates). There are of course way too many CRT commands to page through, so to make the list shorter we need to add letters between the "CRT" and the asterisk(*). Since it's a C++ program add a "C" (making it "CRTC*") and you'll find a much smaller and more manageable list to page through.

Apache update v2.0.52 has problems.

On our web server V5R3 PTF 5722DG1-SI17010 causes HTTP/500 server failures. It might be related to SSL because our non-SSL web servers weren't affected. We're currently in touch with the almighty on this problem. Originally support thought it was related to another problem but the messages in the error log were different.

Ib'm requested and we collected an HTTP trace with the PTF applied and it's been zipped up and emailed to support. I'll add comments to this article when we know the outcome.