Linux Desktop for AS/400 Developers

This is a very cool idea: Linux Desktop for IBM i Users

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.