Read Everything!

Some two decades ago, I didn't read the cover letter for a HIPER PTF, so I was unaware of its special instructions, and almost a year after it was applied, my negligence caused a catastrophic failure in one system. Those unread directives compelled the reader to rebuild the storage directories, but since that wasn't done, an upgrade of the operating system caused every DASD page to be marked as free, and over a period of several hours, the AS/400 slowly ate its storage, one page at a time, damaging many objects before we were able to wrest control and recover.

Image of the hung GUI that I uploaded with the PMR.

Besides the refrain to backup, backup backup, the second most important task in computers is to read everything before-hand. This week I neglected to peruse the read-me page for the HMC PTF MH01560, mostly because, frankly, there is nothing more boring than an HMC read-me document. In all the years I've been installing them, there has never once been anything in their texts that would have caused me to deviate from the normal installation steps. However, in this read-me's "Installation" section there was one tiny sentence that read "This fix must be installed using the HMC updhmc command; not the GUI." It doesn't relate why one must do that, just commandment to not.

Though this bit of negligence was not as bad as my catastrophic faux-pas of the 90s, when the GUI got hung, I opened a PMR and was politely informed by the support tech that, ahem, right here, sir, it say do not use the GUI. I have since closed the PMR and asked them to please burn it, such was the level of my embarrassment. If there's one positive to this experience, it turns out the CLI application is very fast and easy to use, and I'll probably use it over the GUI in the future.

This article was supposed to be a heads up to those upgrading to v8r8.4.0 and applying required PTF MH01560 with the updhmc command, but it devolved into a confession of inadvertently providing support techs with material to laugh about during their coffee breaks. In any case, I hope you'll all have a safe holiday season, and maybe someday I'll write about the two PMRs I opened a year apart for the same issue that were both PBKC. Though both times, thankfully, it was someone else's KC.

AS/400 Gets a Mention

My favorite radio show This American Life mentioned the AS/400, twice! (Be still my beating heart.) The name of this particular episode (#496) is When Patents Attack, Part 2 and the small mention is in 2nd half of the broadcast, which you can listen to at their website.

It starts around 38 minutes into the program. I was listening to the podcast when one of the commentators said "They decide they need a specific type of computer to backup all the data, something called an AS/400." I nearly fell off my chair. I don't know why, but I became not unlike a drooling fan-boy of an obscure band, and I've just heard my favorite song of theirs on the radio. It's too bad the AS/400 expert connected to the story is part of a patent troll operation, and one of the main subjects of the show. Despite all of that, I was giddy with delight and had to share.

Sound and Fury

RPG

On May 16, 2012 Mel Beckman wrote a piece in iProDeveloper called "Is RPG Dead?" where he argued that it was. Readers of this blog will recall that it caused a huge firestorm within our community to the point that many were calling for Mel's head on a platter.

I was as shocked as the next RPG programmer that the language was dead, but all of the vociferous reactions left me cold. What was needed, I thought, were cooler heads and reasoned rebuttal; During this period a line from Macbeth, "full of sound and fury, signifying nothing", kept running through my head. One day a little poem came forth. I had originally posted it on Facebook on June 1st and now that the hub-bub has died down I thought I'd post it here:

There is much sound and fury in this tale whose hour upon the stage was spawned by Mel and the walking shadow RPG sits quietly in the mezzanine contemplating the maelstrom of which she is the subject. The poor players on the stage will strut and fret and expel their rage and in the end we all know that they will be heard no more, ultimately signifying nothing.

(Most of phrasing came from Macbeth's long winded response to the news, near the end of the play, that his wife was dead.)

Update 10/6/12

Once all of the initial shouting died down there were some very good posts written that rebutted Mel's assertions. I'd like to mention three of them here:

• RPG is Dead - Long Live RPG and RPG: Not Dead Yet by Jon Paris and Susan Gantner
• RPG is Dead? Are You Serious?! by Scott Klement

Book of SBMJOB, Chapter on CMD

Read it here.

Years ago when I was a novice studying the liturgy of the 38 System, I started writing an early version of the book of SBMJOBALT simply because it annoyed me that I couldn't prompt its Request Data (RQSDTA) chapter. Apparently, the development angels of our lord Ib'm found this frustrating too, because when the new testament of the 400 was released, the book of the SBMJOB had a new chapter named CMD that allowed prompting. That wasn't all, of course. Our most holy lord Ib'm blessed us all with two other wonderful verses for this chapter:

1. If a CL program submits a CALL command, the program it calls will appear on the Display Program References (DSPPGMREF) output for the submitting program.
2. On the PARM parameter of those CALL commands, the CMD parameter can also handle data in CL variables so that you don't have to build a command string beforehand.

Hallelujah!

Of course, every far-reaching testament has some annoying errors of omission. At the following link I describe two of them and my simple solutions for both: Get the SBMJOB Command's CMD Parameter to Cooperate

Spammer is a Meathead

Of the many chores I do around the parish, one of them is dealing with the spam that comes across my desk. Of late I've been getting piles of stuff from what must be the most clueless spammer on record. My client won't display any of the contents because the entirety of each email is so malformed that it can't be deciphered. I have to edit it myself just to get SpamCop to interpret it. Check out this typical example of the piles of goo I've been getting from various locations around the world. (I've highlighted the most blatant bits of silliness):

---

From - Mon Jun 25 09:30:16 2012
X-Account-Key: account9
X-UIDL: 1896-1135197712
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-path: <clueless@spammer.com>
Received: from mta34.srv.hcvlny.nowhere.com
 (mta34.srv.hcvlny.nowhere.com [167.206.5.102]) by mstr13.srv.hcvlny.nowhere.com
 (Sun Java System Messaging Server 6.2-9.20 (built Jul 15 2010))
 with ESMTP id <0M6500F02Z6RUD90@mstr13.srv.hcvlny.nowhere.com> for
 no.one@nowhere.com; Mon, 25 Jun 2012 04:20:51 -0400 (EDT)
Received: from SEMA (95.9.36.33.static.ttnet.com.tr [95.9.36.33])
 by mta34.srv.hcvlny.nowhere.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTP id <0M6500J6JZ5K9TL0@mta34.srv.hcvlny.nowhere.com> for
 no.one@nowhere.com (ORCPT no.one@nowhere.com); Mon,
 25 Jun 2012 04:20:51 -0400 (EDT)
Received: (qmail 7526 by uid 670); Mon,
 25 Jun 2012 08:23:07 -0200From: "Enlargement pils Sample"
 <clueless@spammer.com>To: <formula1nut@nowhere.com>Subject: Thrill her more
 every nightDate: Mon,
 25 Jun 2012 08:06:40 -0200Message-ID: <005f01cd52c4$82452690$86cf73b0$@com>MIME-Version:
 1.0Content-Type: multipart/alternative;
 boundary="----=_NextPart_000_005E_01CD52C4.82452690"X-Mailer: Microsoft Office
 Outlook 12.0Thread-Index: AcjupAzv1ypgP1yJ50d8AifghGpFJw==Content-Language:
 en-usThis is a multipart message in MIME
 format.------=_NextPart_000_005E_01CD52C4.82452690Content-Type: text/plain;
 charset="us-ascii"Content-Transfer-Encoding: 7bitJay Leno found taking
 drugshttp://debatablecommerce.com/------=_NextPart_000_005E_01CD52C4.82452690Content-Type: text/html;
 charset="us-ascii"Content-Transfer-Encoding: quoted-printable<html
 xmlns:v=3D"urn:schemas-microsoft-com:vml"
 =xmlns:o=3D"urn:schemas-microsoft-com:office:office"
 =xmlns:w=3D"urn:schemas-microsoft-com:office:word"
 =xmlns:x=3D"urn:schemas-microsoft-com:office:excel"
 =xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint"
 =xmlns:a=3D"urn:schemas-microsoft-com:office:access"
 =xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"
 =xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882"
 =xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema"
 =xmlns:b=3D"urn:schemas-microsoft-com:office:publisher"
 =xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet"
 =xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet"
 =xmlns:odc=3D"urn:schemas-microsoft-com:office:odc"
 =xmlns:oa=3D"urn:schemas-microsoft-com:office:activation"
 =xmlns:html=3D"http://www.w3.org/TR/REC-html40"
 =xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/"
 =xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =xmlns:D=3D"DAV:"
 xmlns:Repl=3D"http://schemas.microsoft.com/repl/"
 =xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/"
 =xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml"
 =xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd"
 =xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/"
 =xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/"
 =xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#"
 =xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp"
 =xmlns:udc=3D"http://schemas.microsoft.com/data/udc"
 =xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema"
 =xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"
 =xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/"
 =xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/"
 =xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
 =xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap"
 =xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile"
 =xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart"
 =xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/"
 =xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup"
 =xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig"
 =xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=nature"
 =xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006="
 xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml"
 =xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=ps"
 xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages"
 =xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=es"
 =xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/="
 =xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=lishedLinksService"
 xmlns:Z=3D"urn:schemas-microsoft-com:" =xmlns:st=3D"=01"
 xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META
 HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =charset=3Dus-ascii"><meta
 name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"><style><!--
 /* Font Definitions */ @font-face=09{font-family:"Cambria Math";=09panose-1:2
 4 5 3 5 4 6 3 2 4;}@font-face=09{font-family:Calibri;=09panose-1:2 15 5 2 2 2
 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal,
 div.MsoNormal=09{margin:0in;=09margin-bottom:.0001pt;=09font-size:11.0pt;=09font-family:"Calibri","sans-serif";}a:link,
 span.MsoHyperlink=09{mso-style-priority:99;=09color:blue;=09text-decoration:underline;}a:visited,
 span.MsoHyperlinkFollowed=09{mso-style-priority:99;=09color:purple;=09text-decoration:underline;}span.EmailStyle17=09{mso-style-type:personal-compose;=09font-family:"Calibri","sans-serif";=09color:windowtext;}.MsoChpDefault=09{mso-style-type:export-only;}@page
 Section1=09{size:8.5in 11.0in;=09margin:1.0in 1.0in 1.0in
 1.0in;}div.Section1=09{page:Section1;}--></style><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026"
 ></o:shapedefaults></xml><![endif]--><!--[if gte mso >9]><xml> <o:shapelayout
 v:ext=3D"edit">  <o:idmap v:ext=3D"edit" data=3D"1" ></o:idmap>
 </o:shapelayout</xml><![endif]--></head><body lang=3DEN-US link=3Dblue
 vlink=3Dpurple><div class=3DSection1><p class=3DMsoNormal><o:p>Jay Leno found
 taking drugs</o:p></p><p class=3DMsoNormal><o:p><a
 =href=3D"http://debatablecommerce.com/">http://debatablecommerce.com/</a></o:p></p></div></body></html>------=_NextPart_000_005E_01CD52C4.82452690--
Date: Mon, 25 Jun 2012 04:20:51 -0400 (EDT)
Date-warning: Date header was inserted by mta34.srv.hcvlny.nowhere.com
From: clueless@spammer.com
Message-id: <0M6500J6RZ5M9TL0@mta34.srv.hcvlny.nowhere.com>
Content-transfer-encoding: 7BIT
Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and wrapped.
Original-recipient: rfc822;no.one@nowhere.com

---

See what I mean? There are no carriage-return/line-feeds (CRLF) before the header keywords (From:, To:, Subject:, X-Mailer:, etc.), the boundary separators, the envelope keywords, before the envelope's content, or most other areas that could benefit from a strategically placed CRLF. I haven't even bothered to try and figure out what's going on in the HTML envelope near the end, but it looks dreadful.

This has been going on for weeks and every email has a different link for a different "product". I can't believe this meat-head is actually getting paid for these malformed missives of debatable commerce. It has to be one person running some kind of scam and has no idea that almost none of it is actually being read by their "target audience".

A Call for Prayers to Solve the Problem of List Parameters and Variables in CL

Feature Requests and Requirements

Greetings worshipers of our lord Ib'm and the most holy "i". Today I would like to talk about an issue that has been with us since the days of the old testament. Yes, I'm talking about a chapter in the story of the land of System/38 and king CPF.

Since those early days we who toiled in semi-darkness, right through to modern times, were bedeviled by specifying variables for list parameters in CL programs. For every other parameter on the system, if we needed to specify a variable we were good to go, but to this day, even with the most holy "i", we’ve never had a good way to specify a variable with list parameters.

I think I've hit upon what I consider to be a workable solution to this intractable conundrum, but it will require the minions of our lord Ib'm to make three changes. It will also require many prayers from the faithful to prod its angels to effect these modifications. Towards this end I recently wrote a piece for System i News called Solving the Problem with List Parameters and Variables in CL. If you agree with the arguments set forth in that post then please register your prayers for this change by going to the COMMON Feature Requests and Requirements page and voting for the following requirement requests:

• Arrays in CL #212: "Problem: The CL language does not have array support, which is something that would be very useful." Regular readers of this blog might recognize this as requirement #4 in my blog post Top Ten Requirements for CL Enhancements.
• Qualified data structures in CL #215: "Problem: Currently CL variables whose storage is defined inside another variable (known in RPG as a data structure) cannot be qualified to that variable. CL modules are getting more and more complex given the expanded features IBM has introduced. The number of variables are getting larger and so are the number of data structure sub-fields and they must have unique names within the module. It is getting harder and harder to devise self-documenting field names with only 10 characters to work with, which was the problem that RPG had for many years before IBM allowed for qualified data structures." Regular readers might also see some resemblance to requirement #10 in my aforementioned blog post Top Ten Requirements for CL Enhancements, but of course it's been somewhat improved.
• List Parameters and Variables in CL #216: "Problem: ...(redundant verbiage redacted-see 2nd paragraph of this blog post)... If you specify one list element you're OK, but that's rarely what is needed. Often times one needs to specify multiple list elements and you can never be sure how many will be needed at execution time. The current design of the command processing environment makes this difficult."

You will also be able to vote for these requests at the COMMON Council of Anaheim gathering next month. Unfortunately I won't be able to attend, but I will be there with you in spirit.

In the name of the Corporation, the Power System, and holy "i", Amen.

Where in the name of Ib'm have I been...

Greetings fellow worshipers of Ib'm and its most holy "i".

I am writing today to explain my dearth of sermons of late, to expound on my general absence from the net-sphere (mostly blogs/Facebook/Twitter), and to make a confession of sorts. The truth be told my essays on this blog has been bereft because I have been submitting secular tomes for publication in another venue. The process of churning out said tomes, and other travails of life in 2011, has been arduous and has left little time for writing the free-wheeling missives that I've posted here over the years. While this state of affairs is rewarding, the blog, et al. has lain fallow.

I'm unhappy with this situation to say the least and I'm going to be making a concerted effort to post more on the net in the future. It is the age-old problem, post theological treatises here so that they're freely available to all, for very little remuneration. -or- Submit other content to a profit-making journalistic organization, for personal monetary gain. As so often happens, subjects that would be perfect for this blog end up not getting written because the siren song of the coin of the realm is hard to resist.

You might be asking yourself "which aforementioned organization does he shill for?" Well, to be blunt, my benefactor in this realm is the Penton Media Group, specifically System i News magazine, for whom I've written staid and professional sounding articles, tips, and (ironically) blog posts. Even more ironic is the fact that the writings on this particular blog that you're currently reading is what got me this great gig in the first place.

If the next thing you're asking is "wait, I don't remember seeing anything written by Joe Code in the magazine or website", then you'd be correct. Father Joe Code is of course the nom de plume that I adopted for the purposes of anonymity when I first started out with the blog. I didn't know how people would react to someone writing theological treatises on the monotheistic worship of our most holy "i".

The more I wrote professionally the more the anonymity started becoming a hindrance to actually posting on the blog. Also, I couldn't comment on my articles. The most I would say about them was submitting a tweet saying "my friend and colleague has posted ..." on my Twitter feed. Of course doing so has had the unintended result that this supposed secret identity is now about as secret as Silverlake was back in the 80's.

Believe it or not, the name Joe Code actually came from the Jargon File. (Also, I liked the sound of "Father Joe" better than say, "Father Steve".) For the record, my real name is Peter K. Levy and I've been programming computers, first in college and then as a career, since late 1978. If you click the link on my name it will take you to my web site. There you can click on the "Writings" link to view the secular articles that I've written to date.

The idea for an iSeries priest also came from the Jargon File. I did and do feel as if we alone know how to write the words that make the bits flip, the numbers crunch, the disks spin, and the great waste of paper. We are the select few, who wear the cassocks of our high office; muttering prayers and incantations in languages that only we understand; to do the things that will impress the board of deacons, scare the lesser priests, and confuse the parishioners.

The dialect of this blog will not change. I am a proud and humble priest of the church of our lord Ib'm and its most holy "i". I will not shirk my responsibility to enliven the ecclesiastic point of view that is so needed to enhance the meditative state necessary for enlightenment in our dank and fluorescent drenched cubicles.

Satire is important in all aspects of life and I should mention that in this blog I am not satirizing religion; I'm poking fun and satirizing our tendency as technicians to worship at the alter of one computer platform eschewing all other gods and idols. Many a flame war is the result of this tendency. We should all not judge those worshipers of false religions for they know not what they are missing out on.

Dominus, dominus, dominus, you're all Ib'm-ists now. Bless your heathen souls. May the most holy "i" reign supreme forever or, at the very least, long enough until we can all retire. ;-)

In the name of the Corporation, the Power System, and the holy "i", Amen

I Use the Ib'm i

It seems that I've been forever reading blog, forums, articles, and tweets arguing one way or the other about what to call the latest incarnation of the pantheon that we all worship. It's gotten so bad that Cardinal Klement had to write an encyclical to set some ground rules as to the proper terminology. I've been watching this argument go on and on and on with no end in sight and I don't for a minute think that this blog post will put an end to the oodles of disk storage dedicated to its living spirit, but I do hope that this story might have some bearing on it.

For years I was in the AS/400 camp. Meaning I was pissed off at our lord Ib'm for continually re-naming its liturgy and the damage it was continually causing to the AS/400 brand. That is, until I had a conversation with someone outside of our rarefied community. When he asked me what platform I worked on I told him it was the "Ib'm i". When he inevitably asked "what's that?" I told him it used to be called the AS/400. To which he asked: "Wasn't that the dinosaur platform that was supposed to be dead or dying?" I realized at that moment that the AS/400 brand was dead and it was never coming back. The whole world believes that the AS/400 is an old out-dated platform that is slowly withering away, like the HP 3000, or the DEC VAX.

Yes, I know they're wrong, but in a way they're also right, because while the AS/400 platform is alive and well, it's the AS/400 brand that is a dead-end. It belongs to the world of 5250 terminals, Twin-axial cables, Token-Ring networks, SNA, and SNADS. A world dominated by libraries, physical & logical files, OPM, RPG-III, CLP, EPM-C, SEU, SDA, RLU, out-files, and Net.Data.

Today there's a bright and shiny new brand that our lord Ib'm calls the "Power Systems running i", but since that's too much of a mouthful I like to use the much simplified version "Ib'm i". It belongs to a new world of PC clients, CAT5 cables, Ethernet & WiFi networks, TCP/IP, FTP, Apache, and NetServer. A world dominated by directories, relational databases (tables, indexes, views, triggers, constraints, etc.), SQL, ILE RPG (free-format), ILE CL, ILE C, C++, Java, API's, QSH, PASE, Eclipse, Rational, WebServices, XML, and PHP.

We're on the cusp of a new dawn and if we play our cards right it will flower into a beautiful meadow. When the outside world is invited to sees how wonderful it really is they don't need to be reminded of the dusty over grown field behind them that was repeatedly sown with salt. I'm never going to say to anyone again that I work on an AS/400 and I encourage everyone who reads this to do the same. The "Power Systems running i" or "Ib'm i" is the platform I use.

Say it with me now: "I used to use the AS/400, yes that old dinosaur. It's true; it's gone, but it's been replaced by something better, something called the Ib'm i." Amen.

CL Program to Apply Technology Refresh PTF

I had a deep sense of foreboding when I found that a HIPER PTF I downloaded came with technology refresh PTF 5770999-MF99002. These things are a pain in the butt to apply as it requires one to do the following steps: 

1. Perform a full system save, like GO SAVE, option 21.
2. Apply all microcode PTFs permanently.
3. Load the TR PTF and set it to be applied temporarily.
4. IPL the system.
5. Apply the TR PTF permanently.

On our system there were two pre-requisite PTFs that were downloaded with MF99002; plus we already had a number of microcode PTFs that were set to be applied during the next IPL. I didn't want to permanently apply these new microcode PTFs, so I took the following steps:

1. Unloaded the microcode PTFs set for delayed apply, except for those that were pre-requisites to MF99002.
2. Performed a full system save.
3. IPLed the system to apply the pre-requiste microcode PTFs.
4. Permanently applied all microcode PTFs.
5. Loaded MF99002 and set it to delayed apply.
6. IPLed the system.
7. Permanently applied MF99002.
8. Loaded the rest of the microcode PTFs and set them to delayed apply.
9. IPLed the system.

Our weekly "full system save and IPL" is full automated, so I needed some way to insert a CL program into this mix that would do the job. After finishing it I realized that others might be able to use it as well. It was designed to run in the QSTRUPPGM program, before it actually starts anything. It's assumed that the very first IPL, after the full system save, would first apply any PTFs that were pre-requisites of the TR PTF. All pending microcode PTFs to be applied, including the TR, would remain in a "Save file only" un-loaded state.

After that first IPL it would find that the TR PTF wasn't loaded yet, so it would apply all microcode PTFs permanently, load the TR PTF, set it to delayed apply, and IPL. When the system came up again it would find that the TR PTF was applied. It would then permanently apply it, load the rest of the microcode PTFs sitting in *SERVICE, set them to be applied delayed, and IPL again.

I've included the code below:

---

/******************************************************************************/
/* Program....: APYTRPTF                                                      */
/* Description: Apply technology refresh PTF.                                 */
/* Author.....: Joe Code                                                      */
/* Date.......: 02/18/2011                                                    */
/*                                                                            */
/* Create                                                                     */
/* ------                                                                     */
/* CRTCLMOD DBGVIEW(*ALL)                                                     */
/* CRTPGM USRPRF(*OWNER) AUT(*EXCLUDE)                                        */
/* CHGOBJOWN OBJTYPE(*PGM) NEWOWN(QSECOFR)                                    */
/* GRTOBJAUT OBJTYPE(*PGM) USER(QPGMR) AUT(*USE)                              */
/*                                                                            */
/* License                                                                    */
/* -------                                                                    */
/* This library is free software; you can redistribute it and/or modify it    */
/* under the terms of the GNU Lesser General Public License as published by   */
/* the Free Software Foundation; either version 2.1 of the License, or (at    */
/* your option) any later version. (Unlike the normal GNU GPL, the "lesser"   */
/* GPL allows libraries to be used in commercial/proprietary software.)       */
/*                                                                            */
/* This library is distributed in the hope that it will be useful, but        */
/* WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANT-       */
/* ABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General    */
/* Public License for more details.                                           */
/*                                                                            */
/* You should have received a copy of the GNU Lesser General Public License   */
/* along with this library; if not, write to the Free Software Foundation,    */
/* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA           */
/* (http://www.gnu.org/licenses/lgpl.html#SEC3)                               */
/******************************************************************************/

PGM

   COPYRIGHT TEXT('Copyright (c) 2011 Joe Code')

   DCL VAR(&COUNT)     TYPE(*DEC)  LEN(3 0)
   DCL VAR(&ERROR)     TYPE(*LGL)          VALUE('0')
   DCL VAR(&RCVVARLEN) TYPE(*INT)  LEN(4)  VALUE(131)

   DCL VAR(&PTFINFO)   TYPE(*CHAR) LEN(50)
   DCL VAR(&PTFID)     TYPE(*CHAR) LEN(7)  STG(*DEFINED) DEFVAR(&PTFINFO  1)
   DCL VAR(&PRODID)    TYPE(*CHAR) LEN(7)  STG(*DEFINED) DEFVAR(&PTFINFO  8)
   DCL VAR(&RLSLVL)    TYPE(*CHAR) LEN(6)  STG(*DEFINED) DEFVAR(&PTFINFO 15)
   DCL VAR(&CCSID)     TYPE(*INT)  LEN(4)  STG(*DEFINED) DEFVAR(&PTFINFO 21)
   DCL VAR(&CLSPTFF)   TYPE(*CHAR) LEN(1)  STG(*DEFINED) DEFVAR(&PTFINFO 25)
   DCL VAR(&RESERVED)  TYPE(*CHAR) LEN(25) STG(*DEFINED) DEFVAR(&PTFINFO 26)

   DCL VAR(&RCVVAR)    TYPE(*CHAR) LEN(131)
   DCL VAR(&BYTESRTN)  TYPE(*INT)  LEN(4)  STG(*DEFINED) DEFVAR(&RCVVAR   1)
   DCL VAR(&BYTESAVL)  TYPE(*INT)  LEN(4)  STG(*DEFINED) DEFVAR(&RCVVAR   5)
   DCL VAR(&LOADEDSTS) TYPE(*CHAR) LEN(1)  STG(*DEFINED) DEFVAR(&RCVVAR  41)
   DCL VAR(&IPLACTION) TYPE(*CHAR) LEN(1)  STG(*DEFINED) DEFVAR(&RCVVAR  66)

   MONMSG MSGID(CPF0000 CEE0000 MCH0000) EXEC(GOTO CMDLBL(ERROR))

   QSYS/CHKOBJ OBJ(QGPL/APYTRPTF) OBJTYPE(*DTAARA)
   MONMSG MSGID(CPF9801) EXEC(QSYS/CRTDTAARA DTAARA(QGPL/APYTRPTF) +
      TYPE(*DEC) LEN(3 0) VALUE(0) TEXT('Stop infinite loop if error +
      applying TR PTF.'))

   QSYS/RTVDTAARA DTAARA(QGPL/APYTRPTF) RTNVAR(&COUNT)
   CHGVAR VAR(&COUNT) VALUE(&COUNT + 1)
   QSYS/CHGDTAARA DTAARA(QGPL/APYTRPTF) VALUE(&COUNT)

   CHGVAR VAR(&PTFID)    VALUE('MF99002')
   CHGVAR VAR(&PRODID)   VALUE('5770999')
   CHGVAR VAR(&RLSLVL)   VALUE('V7R1M0')
   CHGVAR VAR(&CCSID)    VALUE(0)   /* Use job's CCSID. */
   CHGVAR VAR(&CLSPTFF)  VALUE('0') /* Close PTF files afterwards. */
   CHGVAR VAR(&RESERVED) VALUE(' ')

   QSYS/CALL PGM(QSYS/QPZRTVFX) PARM(&RCVVAR &RCVVARLEN &PTFINFO +
      'PTFR0100' X'00000000')

   SELECT

      WHEN COND(&BYTESRTN < &RCVVARLEN *OR &BYTESAVL < &RCVVARLEN) +
         THEN(QSYS/SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('No data +
         returned') TOPGMQ(*PRV (*PGMBDY)) MSGTYPE(*ESCAPE))

      WHEN COND(&LOADEDSTS = '0') THEN(DO) /* Not loaded? */
         IF COND(&COUNT = 1) THEN(DO)
            QSYS/APYPTF LICPGM(5770999) APY(*PERM)
            MONMSG MSGID(CPF3660) /* No PTFs identified. */
            QSYS/LODPTF LICPGM(5770999) SELECT(MF99002)
            QSYS/APYPTF LICPGM(5770999) SELECT(MF99002) DELAYED(*YES)
            QSYS/PWRDWNSYS OPTION(*IMMED) RESTART(*YES) IPLSRC(B)
         ENDDO
      ENDDO

      WHEN COND(&LOADEDSTS = '1') THEN(DO) /* Loaded, but not applied? */
         IF COND(&COUNT = 1) THEN(DO)
            QSYS/APYPTF LICPGM(5770999) APY(*PERM)
            MONMSG MSGID(CPF3660) /* No PTFs identified. */
            IF COND(&IPLACTION = '0') THEN(QSYS/APYPTF LICPGM(5770999) +
               SELECT(MF99002) DELAYED(*YES)) /* IPL action isn't set? +
               Then set it. */
            QSYS/PWRDWNSYS OPTION(*IMMED) RESTART(*YES) IPLSRC(B)
         ENDDO
      ENDDO

      WHEN COND(&LOADEDSTS = '2') THEN(DO) /* Temporarily applied? */
         IF COND(&COUNT = 2) THEN(DO)
            QSYS/APYPTF LICPGM(5770999) SELECT(MF99002) APY(*PERM)
            QSYS/LODPTF LICPGM(5770999)
            MONMSG MSGID(CPF35A8) /* No PTFs to be loaded. */
            QSYS/APYPTF LICPGM(*ALL) DELAYED(*YES)
            MONMSG MSGID(CPF3660) /* No PTFs identified. */
            QSYS/PWRDWNSYS OPTION(*IMMED) RESTART(*YES) IPLSRC(B)
         ENDDO
      ENDDO

   ENDSELECT

   RETURN

/******************************************************************************/
       /*                                                                     */
ERROR: /* Global error handling section.                                      */
       /*                                                                     */
/******************************************************************************/

   IF COND(&ERROR) THEN(RETURN)  /* Prevents an infinite loop if an error     */
   CHGVAR VAR(&ERROR) VALUE('1') /* occurs within the error handling section. */

   QSYS/SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('Unexpected error +
      occurred. See previous messages') TOPGMQ(*PRV (*PGMBDY)) MSGTYPE(*ESCAPE)

ENDPGM

---

On our small system this program added an extra two hours to the normal weekend backup/IPL. The only problem I ran into was that the microcode PTFs that I removed weren't loaded again. Apparently when you permanently remove a microcode PTF, it's also removed from the list of "*ALL PTFs in *SERVICE", meaning they can't be loaded when you specify LODPTF DEV(*SERVICE) SELECT(*ALL). You have to specifically name them in the SELECT parameter. Next week when I do this again I am going to load all of the microcode PTFs and leave the delayed apply flags shut off. (Except of course for the TR PTF's pre-requisites.)

Looking at the program again this morning I realized that if there was a subtle problem with applying the TR PTF then it might cause an infinite loop of IPLing, which would be very bad. I've since changed the program to include a safety valve in the form of a data area used to count the number of IPLs. If the count doesn't match up with what is supposed to happen then it doesn't do anymore IPLs. This amended version of the program compiles, but I haven't tested it yet. If you want to wait, it will be tested again next weekend when I apply the TR PTF to another system in our network. I will update this post with the results.

Update (2011-02-28): This version of the program did it's job and applied the TR PTF without error.

Update (2011-06-07): IBM has since issued PTFs to make this task easier, so it would seem that the program above is obsolete.

Parallel Lines

Had kind of a wild ride with this one liturgical conundrum, but I think it's resolved now. It was deep, but the ultimate solution was very simple.

The main program is written in ILE RPG and it does all of it's I/O using SQL. The main result set consists of multiple sub-selects that are UNIONed together into one giant pile. In the WHERE and HAVING clauses of most of these sub-selects it utilizes a user defined function (UDF) that does some data massaging.

This all ran perfectly fine on v5.4 of i5/OS, but after the upgrade to v7.1 of IBM i the job started behaving strangely. Sometimes it would work fine. Sometimes it would run inside the first FETCH statement all day long and take up huge amounts of CPU. Other times the UDF would function check because of invalid data in the strangest places, like on the RETURN statements.

To try and stem the function checking I added MONITOR/ENDMON blocks to all of the RETURN statements in the UDF. When an error occurred they would return *LOVAL instead. Then it started function checking on the statements that were calling the functions with the aforementioned function checking RETURN statements. It was very weird.

Over a two month period I was sending all kinds of traces, SERVICEDOCS, and job logs to Ib'm support angels. The last thing we did was set up a job watcher in iDoctor and the output found that when the FETCH was looping and it was doing so in one of the functions in the UDF. That's when they asked me if it the service program was specified to support multi-threading.

Doh!

As it turns out the SQL to create the functional stubs that called the RPG service program functions defaulted to PARALLEL while the program did not. So remember, if you're writing (or have written) an SQL UDF in a language other than SQL, don't forget that you might have to make your program or service program multi-thread capable. In RPG it means adding the keyword THREAD to the control specifications (aka H-specs) with either the *CONCURRENT or *SERIALIZE attribute. (THREAD(*CONCURRENT) did the trick for me.) Be sure also to thoroughly read the sections in the RPG and SQL manuals on multi-threaded processing.

Influencing the Heavens

While it's a lot of fun hanging out with fellow priests discussing liturgy, I think the most fun I've ever had was walking the hallways of mecca itself and getting to talk to the angels and minions of our lord Ib'm. (Especially building 20, which is a football field size room filled with our lord's most holy systems.) It's also very satisfying to know that you've had an influence in such an august environment. My instance of influence was tiny, but no less satisfying.

My support angel had arranged it all. I gave him a list of the subjects and problem areas I wanted to discuss and he set up all of the meetings. What I remember most clearly is that every angel or minion that I met said something along the lines of "this is great, we never get to speak to our ministerial brethren." After awhile I started to conclude that our lord Ib'm made it an unspoken policy to keep them all in darkness writing code away from the light of earthly interaction.

I talked to a lot of people that day and it was a whole lot of years ago, so I don't remember everything that was discussed or every person I met. I do remember speaking to angels and minions involved with PTFs, command definitions, message handling, journaling, work management, CL programming, and request message processing. There are several salient areas that stood out.

The Command Definition angel actually remembered my name because he'd worked on a lot of the PMR's I'd opened over the years. When I thought about it later I figured he was probably also the one that I had argued with on the phone for over an hour about a fix to command prompting that was made on the AS/400, but wasn't done quite as well on the System/38. (If you're reading this now, I'm sorry about that.)

At one point I walked past some cubicles talking with another minion when the hairiest angel I'd ever seen poked his head above the wall and exclaimed "you're a priest? I've never seen a priest before." (It was the theme du jour.) I felt a small pang of jealously because I of course had to cut my hair to get a job. He seemed so happy to see me I had to go over and shake his hand. He said he wrote microcode and judging from his appearance and general demeanor I have to admit that I wasn't the least bit surprised. I'll bet his code was tighter than most.

We'd been having a problem with Mimixing file records to another system. We were using commitment control and therefore everything was journaled, but we were only Mimixing a small subset of files to the other system. Consequently when Mimix was plowing through the journal receivers looking for something to replicate, it got down deep into the microcode, took over the CPU, and didn't come up for air very often. (The minions of our lord Ib'm closed my APAR on that issue as "working as designed".)

At that time a file could only be attached to one journal at a time and one of the requests I'd made of the journaling angel was for the ability to attach a file to more than one journal. With this feature we could journal those files being Mimixed to a 2nd journal and Mimix could then plow through that secondary journal and not take over the system. He said he thought it was a good idea, but he wouldn't say when or if it would ever be available.

In a subsequent release that feature was made available. However with that release the AS/400 also supported two-phase commit and this new feature was a side-effect of that support, so I can't say that I had any influence on the decision. The journaling angel probably knew this support was coming, but wasn't able to reveal it to me at that time.

I also remember speaking to an angel who was responsible for CL and Request Processing. I had designed a lot of applications that processed sub-file options using commands, so every program was a request processor similar QCL or QCMD. The problem I was having was that some commands had password parameters and I wasn't able to hide the parameter's contents using the QCMDEXC API in my request processors.

I asked him if a CL API could be created where I'd give it the message ID of a logged request message and it would handle the execution, prompting, and redaction of sensitive data. He too said he thought it was a good idea, but of course wouldn't commit to it. In a future release the QCAPCMD API appeared and it was exactly what I needed to resolve my issue. Of course that API does a great many different things with various CL environments so I can't be sure that my request had any influence.

The only request I made during that visit where I'm absolutely sure I had a direct influence was with the crew of Work Management minions that I met with. Unlike everyone else in the building they were all wearing ties. I couldn't resist asking them if their manager had made them put them on for my visit and they sheepishly admitted that he had. Meeting with them was fun and afterwards they took me on a tour of the fabled building 20.

One of the Work Management problems my shop was having was with duplicate job names. An operator would enter WRKJOB MYUSERID/MYJOBNAME and the system would send 25 or 50 messages listing all of the jobs whose name and user ID were MYUSERID/MYJOBNAME. Then they'd have to search through the job log and write down the job number (this was in the age of dumb tubes, so copy/paste wasn't possible) and enter it on the command to view the job. Since the messages didn't say anything about when those jobs had been started the operators would invariably pick the wrong job number, and so they'd have go through the list again and pick another one, and on, and on, ad infinitum. It was a pain in the butt.

The three of them didn't think there were any good solutions for this issue given how the commands were already set up. I asked if it was possible that when there were duplicate jobs the command could display a screen where the user could select the job they wanted from a list. One of them exclaimed "Oooh! That's a good idea" and immediately wrote it down. In the very next release the DSPJOB and WRKJOB commands both had a new parameter named DUPJOBOPT (Duplicate Job Option) whose default value was *SELECT. It's the only change to the system where I'm absolutely sure I had an influence.

ILE RPG %ALLOC() Built-in Function Can Fail with CEE0808

I had an interesting problem with the ILE RPG %ALLOC() built-in function recently. In one particular spot in a single program, whenever I tried to allocate some storage it failed with CEE0808 (requested storage size is not valid). The help text on the message said that the storage to be allocated was a negative number, but since it was a four byte unsigned integer that was impossible. Debugging it also showed that it was only trying to allocate a little over 3,100 bytes, so there was no issue with a signed number mapping over a huge unsigned number and mistaking it for a negative.

Searching on this message in our lord Ib'm's support site found v7.1 APAR SE44538, which fixed several problems with the RPG compiler. One of them resolved an anomaly where %ALLOC() failed with CEE0808 in programs that were optimized with *FULL, which my program was. The fixing PTF is 5770WDS-SI41005, which will require any problem programs to be re-compiled. There is a run-time PTF too that is a pre-requisite: 5770SS1-SI41000.

It's not on any cum or group packs yet and it fixes several problem, not just mine. The text of the APAR makes it look like it's a hot fix (if not HIPER), so whether you use this built-in function or not you might want to download it.

Heads up for Those Installing v7.1

This is a heads up to any priest or lay operator planning to install v7.1 with cumulative PTF package C0229710 (or above). There is a chance that the initial IPL to apply 5770999-MF99001 (required technology refresh) could fail with SRC B600-0102. You would then be forced to drive to work and slip install LIC from your physical media.

Our lord Ib'm's support angels have instructed that one must first load PTF 5770SS1-SI40878 from the HIPER group CD image and apply it immediately. Then load PTF 5770999-MF50003 from the cumulative PTF package (currently superseded by MF50836 in the HIPER group PTF SF99709), set it to apply delayed, and IPL the system.

When the system comes up you can start installing the PTF package again. Be forewarned that your attempt to load it will result in a failure message, but this is probably nothing to be alarmed about. View previous messages and most likely you'll find that it'll be because the system wants you to IPL now to install the MF99001 PTF before anything else. Once this technology refresh PTF along with its pre and co-requisites have been applied you can continue loading and applying the rest of the cumulative PTF package. (Be sure the "initialize system is complete" message has been sent to QSYSOPR before IPLing the 2nd time.)

I was very surprised that none of this was in the instructions for the cumulative PTF package. I think it would behoove our lord Ib'm if at the very least its minions added this information to the cumulative PTF package PSP document as a heads up. For more information on the technical refresh PTF see this document: FAQ for Technical Refresh for R710.

Update (Nov 11, 2010): The minions of our lord Ib'm have "re-saved" (or re-spun) the I_BASE_01 LIC installation disk, so that it now contains the 5770999-MF99001 technology refresh, among other things. They're designating it as RS-710-B. The above problems I experienced installing v7.1 on two separate systems were presumably because I was using the re-save designated as RS-710-A, but that hasn't been proven. In any case, anyone upgrading to v7.1 is advised to install from the new re-save disk as it will probably save some headaches. For more information see this web page: IBM i Resaves.

Bug in Websphere Application Server v7.0 Migration

This is a heads-up to all worshipers of our Lord Ib'm who also use the Java liturgy known as "Websphere Application Server" (WAS) -and- who are intending to migrate their applications to WAS v7.0.

Our parish was using WAS v6.0 and we intended to upgrade the most holy O/S to v7.1. The "Memo to Users" encyclical warned us that WAS v6.0 wasn't supported under O/S v7.1. It does support WAS v6.1 and v7.0, so we decided to load the latest WAS version since it had been out for quite a while now.

The migration process steps themselves are actually very easy. All you have to do is execute a pre-migration script for all of the instances (or profiles) with applications you'll be moving over. Then create matching profile names (with different blocks of port numbers) in the new version of WAS. Then you do a post-migration and -viola- it's done and it works. (Amazing!)

Except in our case there was one problem with one of the application not "deploying" to the new version of WAS. I opened a PMR with the support minions of our Lord Ib'm and they requested all manner of logs. Then they had me zip up the pre-migration directory and send that in too.

It turned that the offending application had single-quote(') characters in its description and the pre-migration script had unwittingly embedded a syntax error in the Jython code it had written. When the post-migration ran, it encountered the syntax problem and stopped the deployment for that application.

The pre-migration should have "escaped" those single-quote(') characters in the description. The Ib'm minions manually corrected the Jython code and sent it back to me with instructions on how to run it. Thank the Lord Ib'm that my prayers to the support minions were heard because the corrected Jython code ran fine and deployed the problematic application.

This problem with the Jython code generation is corrected in v7.0.0.13 of WAS which is scheduled to be released for general availability on Oct 25th, 2010. If you have single-quote(') character(s) in the description(s) of your application(s) you should either remove them, or wait until you've had a chance to install that update to WAS, before attempting the migration.

Special *NULL CL Value Undocumented Since v6.1

We've all heard about the *NULL special value in ILE RPG. It's a nifty little item associated with pointer fields. You can use it to assign *NULL to a pointer field or in a conditional statement to test if a pointer is null. Did you know that CL has had a *NULL special value since v6.1? I didn't know about it because it doesn't appear anywhere in the v6.1 or v7.1 Information Center. Nor does it appear in the PDF formatted version of the CL Programming Concepts Guide. I only learned about it recently and am a little embarrassed to admit that I had included a "*NULL Special Value" as one of My Top 10 Requirements for CL Enhancements.

I currently have a PMR open with the support minions of our lord Ib'm for v7.1 concerning un-initialized pointer variables containing errant data at start-up time. (The problem doesn't occur on v5.4.) This has lead them to open an APAR SE45175 which they said would be closed as PE (Programming Error). This is only related to the subject at hand because at one point I let the support minion know that I wouldn't have even known about this problem if CL had some kind of *NULL special value like RPG currently has. He passed this comment to the saints of development and they responded that it actually did and it's had it since v6.1. They even included a little program I could compile to prove it.

After proving it I immediately re-scoured the "What's New in CL" sections of the Information Center for v6.1 and v7.1, but couldn't find anything. Then I searched the CL sections for both releases, but came up with nada. The support minion also searched through the Info Center and like me came up empty handed. He's since notified the powers that be to get that fixed but we might not see it documented until the next release.

I also asked around and fellow high priest Father Jerome Hughes was kind enough to pass along this link to a Power-Point presentation given by Ib'm saint Guy Vig at an Omni User Group ecumenical dinner. Discussion of the *NULL value can be found on slides 93 & 94.

In any case here's the small program that the saints of development passed onto me:

PGM
              DCL        VAR(&PTR1) TYPE(*PTR) ADDRESS(*NULL)
              DCL        VAR(&CHAR1) TYPE(*CHAR) LEN(1)
              CHGVAR     VAR(&PTR1) VALUE(%ADDR(&CHAR1))
              CHGVAR     VAR(&PTR1) VALUE(*NULL)
              IF (&PTR1 *EQ *NULL) THEN(DO)
              SNDPGMMSG  MSG('The pointer is null')
              ENDDO
ENDPGM

As you can see *NULL can be used to initialize declarations (DCL) assignments (CHGVAR) and in conditional statements (IF).

UPDATE (10/06/10): Here's something pretty interesting. On a lark I compiled the program to TGTRLS(V5R4M0). I had to remove the ADDRESS(*NULL) parameter from the DCL statement, but other than that it compiled. I installed the program object to a v5.4 system and it ran exactly like it did on the v7.1 system. However when I FTPed the source to that system and compiled it the compile failed saying the "*NULL" was incompatible with the variable.

The Cult of Ib'm and the Most Holy iSeries

My sermon today concerns the deeper meaning of the cult of Ib'm and the future of its most holy computer, the iSeries.

By using the word "cult" I of course don't mean some fringe religion with only a few adherent, although we are slowly becoming that (but I digress). I mean it in the way of the ancients when they worshiped temporal objects that helped them survive and/or gave their lives meaning. For example, everyone knows that among the ancient Egyptians there was a cult of cat worship. It got its start, not top-down with prophets, visions, and visitations from the cat god, but bottom-up because it was the cats that kept the rodents in their grain stores under control.

In a recent Maxed Out blog post Chris Maxcer wrote, among other interesting things, that my blog is "not trying to disparage any religion". Of course he's right. There is no intended disparagement of any religions. If there are any computer geeks out there who are also adherents to the Abrahamic religions, please do not be offended by my conflation of the language of said religions with this little cult of ours. Outside of work many of us have pledged our souls to a deity (or pantheon of deities) of our choice, but at work our hearts belong to the lord Ib'm and its most holy computer, the iSeries; for not only does it help us survive but it gives our lives meaning.

Most of the readers of this blog are well versed in the worship our lord Ib'm and its most holy computer, but computer geeks everywhere generally are priests in the temples of other idols at the same time. Unlike its behavior in the distant past, Ib'm will no longer get wrathful and send down plagues upon your systems and withhold service when one worships idols. In fact, the minions of lord Ib'm should probably, if they're on the ball, redouble their efforts to get people away from those false religions.

It's nice when all of the worlds religions can play nice together and be worshiped at once, but life isn't always like that. In an earlier time and much larger parish than my current one, we had several of the most holy AS/400s. We even had a System/36 -and- there was some worship of the Sun god, the ancient pagan rites of the Unix daemons, and the goddess Sybase. I personally had nothing against the worship of these pagan deities in my parish. After all, the nature worship that is Unix is almost as old as the F.S. Project itself and both grew out of that ancient tradition of geekdom's distance past where the command line interface (CLI) held supreme.

Eventually some new PHB's came on board and without warning there was an inundation of adherents to the twin gods Hewlett and Packard, and their object of worship, the HPUX O/S. Along with HPUX came the twin Mephistopheles of Unix faith everywhere; I am of course speaking of the foul beasts Oracle and NT. The houses of worship for these deities did not hold the CLI in high regard. Theirs was a world of graphical user interfaces (GUIs) that mesmerized and held the bean counters in a trance such that they couldn't resist these temptations.

The most high and benevolent Ib'm and his many saints and angels were powerless to stem the tide of GUI worship amongst my flock. The temples to both the Sun god and the Sybase goddess were destroyed. The small System/36 cult was suppressed and the iSeries became a minority cult among this new tide. Attendance at my parish shrank, until finally there was no parish anymore. I too was tempted to abandon my faith, but it would have meant becoming a novice again after so many years as a high priest, so I chose to remain an iSeries adherent, but that also meant moving on.

As our lord Ib'm has taught us time and again, change happens, and we've all had to get used to that. I can't say that it's been easy watching this transition take place in our community. I attend the ecumenical conventions and I'm struck by how few young people are there. It appears that we are all aging out and that gives me pause. In addition the holy of hollies itself is slowly being inundated with more and more aspects of the pagan Unix cults. So much so that one day we may find that our beloved iSeries has become a pSeries.

Our lord Ib'm makes the light of the truth of the most holy iSeries, but we are its keepers. We have it in our hands to rise up and perpetuate this calling that gives our lives meaning. We cannot wait for Ib'm to come down from on high and preach to the masses the benefits of our faith. That's not going to happen, so we have to do it ourselves. In the same Maxed Out post Chris also wrote that Bishops Paris and Gantner were out teaching RPG to some VB acolytes and they most certainly have garnered more than a few converts. (You can read their blog post on the subject here: Good News in i Land.) Our counterparts in Japan have taken up the reins of proselytizing the iSeries to the unwashed masses and doing very well from what I've read. If we all do the same there is so much we could potentially accomplish not only for our benefit, but for future generations.

Amen.

ILE CL Does Something Weird

A little background:

In v5.4 CL doesn't have a special value of *NULL or any way of representing a null value as a literal. (This was for many years one of my bones to pick with our gracious lord Ib'm, but I digress.) To get around this I created a *PTR field named &NULLPTR and I never changed it so that it always contained a null pointer. This way I could compare pointer fields to &NULLPTR to see if they were null.

A CL module of mine contains a &NULLPTR *PTR field. It was compiled last year under v5.4 and hard-linked into a couple of programs. The module has worked fine in both v5.4 and v7.1.

Recently I had to change a couple of modules in one program, so I recompile them. This program also used the CL module, but that module didn't change. When I created the program I simply linked to the existing module object that was still stored in the source library that it was compiled into last year.

The problem:

For some reason when this same old hard-linked CL module is called within this re-created program, the &NULLPTR field isn't null anymore. It now contains a pointer, or at least it contains some kind of errant data. This causes the program to bomb out because when it tests for a null pointer the outcome of course turns out false when it should be true.

If I create the program to run under v5.4 it bombs on v7.1 but not on v5.4. If I re-compile the CL module (to run under v5.4 or v7.1) then the problem goes away almost completely (that is, until you save and restore it to another system, then it start bombing again).

The issue I have is that there are other modules compiled under v5.4 with &NULLPTR *PTR fields that might be re-linked into new programs in the future. I can't be sure the same thing isn't going to happen to them.

I have sent prayers and made sacrifices to the patron saints of support that our lord Ib'm might provide insight as to what is going on. If you're having the same issue in your parish then please say a prayer for me and post a comment and let me know what you think.

Update (10/25/2010): Our lord I'bm issued PTFs for this problem: v7.1: SI41596, v6.1: SI41595, and v5.4: SI41594.

My Top 10 Requirements for CL Enhancements

I've been noticing lately how our lord Ib'm, in its infinite wisdom, has seen fit to add many C-like features to the RPG language. There's even been talk of adding procedure overloading, which is a feature of O-O languages like C++. I, being a humble servant, am of course continually impressed by every improvement our most beneficent lord makes to RPG. Combining C-like functionality with the robust data/file handling features of RPG was a stroke of genius.

On the other hand, CL had been lying fallow for many years, stuck in a functional rut reminiscent of RPG-II. Over a period of several releases it has gotten some improvements that now make it more or less reminiscent of RPG-III.

Let's compare:

Feature	Classic CL	Modern CL	RPG-II	RPG-III	RPG-IV
Conditional	✔	✔	✓1	✔	✔
Looping		✔		✔	✔
Call Subroutines		✔	✔	✔	✔
Call Procedures		✓2			✔
Include files		✔		✔	✔
Advanced Data Types					✔
Arrays			✔	✔	✔
Named constants				✔	✔
Expressions	✓3	✓3			✔
Data Pointers		✔			✔
Procedure Pointers					✔
Internal procedures					✔
Null field mapping					✔

1-RPG-II didn't have IF/ELSE op-codes. Instead it had indicators, so while it did technically support conditional coding, it isn't exactly what most programmers have in mind.
2-Calling procedures is only supported in ILE CL.
3-Expressions are only supported in a few places, not everywhere. For instance you can't have an expression as one of the parameters in a built-in function like %SST().

I'm heartened by the fact that today CL also has support for data pointers and ILE function interfaces, which RPG-III never had. It bodes well that maybe, just maybe, CL might, over several releases, get some more of the same basic functionality that would make it reminiscent of RPG-IV.

Towards this goal, and following in Brother Bob Cozzi's footsteps, I'm laying out my top 10 items I'd like to see in ILE CL:

1. Procedure pointers: This is by far my number one annoyance. What were the minions of our lord Ib'm thinking when they gave us pointers but neglected procedure pointers? I used to envelope RPG programs with CL for file overrides. Now I find myself doing the opposite, enveloping CL programs with RPG, so that I can register abnormal termination procedures. (The latter can't be done in CL because it doesn't have a *PPTR type or a %PADDR() built-in function.)
2. Expressions everywhere: This is my number two annoyance. Currently mathematical and string expressions are not allowed in the parameters of built-in functions and many commands. Why is that? It would be wonderful if I could code something like this: CHGVAR VAR(&MYSTR) VALUE(%SST(&THATFIELD (&POS + &OFFSET) 10)).
3. %PARMS() built-in function: I've been using the CEETSTA() (ILE Test Argument) function in CL modules to test whether a parameter has been omitted. If it wasn't passed then that function will get an error, which is a rather ugly way of doing things. It would be better if our most gracious lord Ib'm provided a %PARMS() built-in function.
4. Arrays: I'm still trying to fathom how such a sophisticated scripting language has gone this long without any kind of array support. Prior to getting pointer support in CL I had to declare large fields, do a lot of calculating, and use %SST() functions. After wards I did the same calculations on large fields, but replaced the %SST() functions with pointers. Either way such machinations in CL can get really ugly. It'd be wonderful if a DIM parameter could be added to the DCL command. I also envision referencing the array elements with parentheses as is done in RPG: &MYFIELD(1), &THATFIELD(&I), etc.
5. Advanced data types: When Cardinal Klement wrote an encyclical on how to use the CPYNV MI instruction to convert floating-point data to decimal in CL, the minions of our lord Ib'm should have heard our prayers and provided support for advanced data types. That was back in '05; now it's '10 and our prayers have still gone unanswered. Basically anything that is supported by DB2 and the ILE CEE functions should be supported in CL. Not just floating point fields, but dates, times, timestamps, zoned decimal (especially for data structures), the larger decimals, and varying length fields too.
6. DB2 NULL field support: I've been using null-capable fields now for quite a while and it's supremely annoying that I can't find out in CL whether fields just read in are null or not. In CL, is the 00.00.00 in a time field a null value or is it midnight? We can't know unless we have that support. I envision something similar to the %NULLIND() built-in function in RPG.
7. %CHAR() built-in function: Have you ever run an English statement through an English to French translator, then run the resulting French sentence through a French to English translator? Has the final result ever looked anything like what you originally put in? This problem also crops up with CL and the CHGVAR command. If you take a number stored in an alphanumeric variable, say "65", and assign to a 5,0 decimal variable it'll work fine. If you then take that decimal variable and move it back to the alphanumeric field it'll come out as "00065". This has always annoyed me. Over the years I've worked out various strategies to overcome this anomaly, but I was never completely satisfied with any of them. Recently I found the CEE4JNTS API and it works great, but it only works with an 8-byte integer, so numbers with decimal digits can't be converted. It would actually be perfect if the arc-angels of our lord Ib'm could perform a minor miracle and give us beleaguered IBM i faithful the %CHAR() built-in function that would work with not only decimal numbers, but all of the advanced data types.
8. Larger field names: When RPG had 6 character field names I used to think that the 4 extra characters allowed in CL was a bonus. Now that RPG has joined the rest of the world's computer languages in allowing huge field names, the 10 character limitation in CL looks really out-dated. I've been using the larger names in RPG to write code that is more self-documenting, but it's pretty hard to do that in CL with only 10 characters at your disposal. Come on you minions of Ib'm, there's no reason that I can think of why CL can't have this support too.
9. Named constants: Would be a very nice thing to have, especially in an include file that was copied in. It could be coded as: DCL VAR(&MYCONST) TYPE(*CONST) VALUE('THIS VALUE')
10. Qualified fields: CL already allows qualification of fields for files declared on DCLF commands so why not allow qualified fields on data structures too. It'd be relatively easy to add a new value to the STG parameter. One would code it thus: DCL VAR(&MYSUBFIELD) TYPE(*CHAR) STG(*QUALDEF) LEN(10) DEFVAR(&MYFIELD 15) and the field would be referenced as &MYFIELD_MYSUBFIELD just as record format fields are referenced now.

Bonus items. Not part of the top ten, but would be nice to have:

1. Type definition (typedef, TEMPLATE, LIKE(), or LIKEDS()) support: Really makes include files that much more useful if there's Type Definition support built into CL. One could create a template definition in the include file and have it referenced to declare actual variables. I haven't worked out all the kinks in my hypothesis yet because the way in which data structures are defined in CL and other languages are fundamentally different.
2. Commands for procedures: Currently if a CL is calling a program with the CALL command you could instead write a command to call the program. It would help document the program's parameters and through help text would document the command itself. Why can't we do the same with procedures called with CALLPRC? It would provide the same documentation benefits and it could conceivably be relatively easy to implement. The commands that call procedures would only be allowed in CLLE programs. While commands that call programs would be needed at run-time to resolve the parameters and call the program. Commands that call procedures would only be needed at compile and program creation time to resolve the linkages and parameters. The CRTCMD command would have to be changed to allow service programs and the procedure within to be named as the C.P.P. The only issues to work out are how the parameter passing and the optional return value would be defined. The PARM definition statement could be enhanced to specify pass-by-reference, pass-by-value, or pass-by-reference-const. As to the return value I envision adding a parameter to the CMD definition statement to define it. Having a return value would allow these commands to appear in expressions, albeit inside a set of parentheses. If these commands appeared outside of expressions, like any other normal command, then the CL program would ignore the return value.
3. Procedure prototyping: If we can't get commands for procedures then I'd settle for procedure prototyping similar to what is done to prototype programs and procedures in ILE RPG. It would save a lot of headaches.
4. Internal procedures: Just like any other procedure based computer language, being able to define procedures in the same module would be an awesome addition to the CL pantheon. The PGM and ENDPGM statement would still be used to define the entry point of the program and the procedures would appear following the ENDPGM statement. I envision the procedure statement looking something like this: PRC NAME(MYPROC) PARM((&ARG1 *BYREF) (&ARG2 *BYVALUE)) RTNVAL(&RTNCODE) EXPORT(*NO) and the closing statement would be ENDPRC. If there was no PGM/ENDPGM at the beginning then the module would have no main entry point and could only be used as a service program or a module hard linked into another program.

One of Many Forks in the Journey

I wanted today to write an entry in this blog to convey a little part of my history. It often amazes me the paths we all take in our journeys and there were many forks in mine. The reasons I took some had to do with actual contemplation of the possible outcomes and others were the paths of least resistance. This one fork I want to tell you about today was the first step towards my current career.

Today I'm a self identified computer geek, but growing up my persona wasn't so firmly set. I didn't know it at the time, but my habits and delights did follow a pattern known to others by a rather dismissive name. I had a proclivity for math and sci­ence. I loved reading and watching anything science fiction, fantasy, Lord of the Rings. I was profoundly uncomfortable around people I didn't know, especially women. -AND- I played D&D. It all but screamed NERD.

Years ago I saw a BBC mini-series on PBS dramatizing the life of Charles Darwin. It went from his early college years through the aftermath of the publication of his ground-breaking book. I don't know if this is true or not, but in the first part he's depicted as being pretty aimless and not knowing what he wants to do with his life. I'm not trying to compare myself to his greatness, but at the time I felt the same way about my life.

My father of course wanted me to join the family business and be a salesman. To spend my days calling florists in the region, trying to compel them to buy our flowers and sup­plies. -AND- I of course wanted to do anything but that. Firstly, I'm the oldest among my siblings, which meant that I was the practice child. I had issues with my dad at the time and we didn't get along that well. Second, I'm a nerd, who could barely speak to people and I would have to cold-call florists all day? Please. Finally, florists have to get up before their customers and wholesale florists have to get up before the florists, which of course means that I would spend my entire working life rising before 4:00 am every day, including Sundays. Those of you who know me are probably smiling at the thought of me getting up that early on a daily basis. I mean I have enough trouble getting to work by 9:00 am.

Being rudderless I wasn't sure what to major in when I contemplated college. As it happened, I was a big fan of Frank Lloyd Wright and since it was math/science/engin­eering related I started out studying architecture at a small college in Rhode Island. I did excel at my technical course requirements, but something for me was lacking in archi­tecture. I was to Frank Lloyd Wright what Salieri was to Mozart in the movie “Amadeus”. I loved architecture, but when it came right down to brass tacks I lacked the necessary talent.

Two years in I decided to leave there with an associates degree and enroll in Rutgers to study civil engineering. However by the middle of the semester I knew that major was a mistake. I may have lacked the talent for architecture, but civil engineering was the total opposite. My first course in this discipline was on water: reservoirs, aquifers, aqueducts, dams, water and sewage treatment, etc. The math was both turgid & difficult and with all due respect to Civil Engineers everywhere, the subject matter bored me to death.

There was however this one little introductory course that all of us TI-30 calculator types at Rut­gers had to take: Intro to Computers for Engineers. They taught us how to use FORTRAN and we had to do our homework an IBM 370 mainframe. Our professor spent a couple of weeks acclimating us to the computer system and JCL using a pre-written “Hello World” program that we had to punch onto cards and run through the card reader. On the next assignment we had to write a new program all by ourselves and I have to admit that I was totally lost.

Remember now that this was 1978. The Apple II computer had only been on the market for a year and a half and no one in my circle of friends had even seen one. (Years later I would learn that most of the computer greats, while their contemporaries were out riding bicycles or playing ball, spent their formative years trolling computer centers. But for me, aside from playing pong on my home TV, I'd never had any previous experience with computers.)

In desperation I went to the professor's office asking for help. He tried to get me to see what I needed to do without actually writing the program for me. After much confusion on my part he finally revealed the missing pieces and I don't know what changed, but it just clicked inside my head. That moment changed my life and long story short I ended up acing the course, changing my major to computer sci­ence, and have spent my working life writing computer code.

At the end of that mini-series on Darwin's life, he's an old man and the actor narrates that he was always thankful he took the job on the HMS Beagle because it gave him something to do with his life. At the time I thought it was an odd thing to say consider­ing how his life's work changed the world, but today I understand what he actually meant. Even if he hadn't changed the world he still would have been thankful for the dir­ection it gave his life and that's how I feel too. I'm thankful that I was able to take that introductory computer course because it really did give me something worthwhile to do with my life.

Yahoo Mail Spam Filters Block Efforts to Help Fight Spam

I was wondering if any one else has had this problem. Over the past couple of weeks I've had issues with Yahoo mail blocking my admittedly small efforts to fight spam. Every day I'd forward the messages in my spam folder to organizations like SpamCop.net, spam@uce.gov, and coldrain.net. However this past week or two I'm only able to forward maybe one or two messages a day before it started to block me from doing so with the following message:

Your message was not sent

Your account has been temporarily blocked from sending messages. This block can be caused by sending messages that trigger our spam filters, or by having too many recipients in one email. We encourage you to review the contents and recipient list of your message, and try sending it at after an hour or two. Doing so will usually resolve the matter.
If you are still unable to send messages after a 24-hour period, please read our FAQ for more information and to request Customer Care assistance.

We apologize for the inconvenience.

Thanks,

The Yahoo! Mail Team

Of course I've contacted "The Yahoo! Mail Team" multiple times and I've changed my password. So far nada and now the problem is starting up on another Yahoo mail account that I forward spam messages from.

This issue is especially problematic with SpamCop because after 24 hours the timestamps in the headers of the spam messages become stale and SpamCop won't process them, so I end up deleting most of them. It's a sad irony that my endeavors to help in this fight against spam are being thwarted by the very Yahoo feature that is itself trying to protect email users by identifying spam sources within Yahoo mail. While I totally understand the purpose of this effort and applaud the work being done; In my case it's overreaching and needs to be tweaked in some way. Possibly if the the application could look at the recipient email list to see if they're being sent to spam fighting organizations first before deciding whether or not to block the account.

Update (10/25/2010): After resolving the issue way-back-when the problem has re-appeared.

Update (4/4/2011): After throwing up my hands and giving up I tried again a month later and the problem went away completely. Now I have a new problem with Yahoo Classic. It keeps fouling up the send saying "There was a problem! Not sure why, but our usually-reliable server goofed-up while sending this message. Please try again." and I try again and it doesn't work. Or if it does get sent it will fail to allow me to delete the email saying "There's a problem viewing this message. Are you trying to access a message that's been moved or deleted? Try going to the folder it's in (e.g., Inbox, Trash) and selecting the message from there. If you've tried this, and relaunching Yahoo! Mail doesn't work either, feel free to contact Customer Care about Error Code 4."