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."

Enterprise Extender PTFs Again

Once again the list of v5.4 Enterprise Extender recommended PTFs has left off some important patches. MF47274 & MF47275 can cause HPR-IP controllers to remain in an unusable VARY ON PENDING state, and varying them off and on again doesn't fix it.

Our lord Ib'm should have added MF47838 & MF47839 to the list. (Note that MF47838 supersedes MF47275). However there is still a problem because sometimes IPLing or restarting the system from a restricted state causes the controllers to again remain in a VARY ON PENDING state. Fortunately, this time it can be fixed by varying them off and then on again. Not a show-stopper, just an annoyance.

Ib'm support tells me there are two test PTFs that will resolve that problem too and they're in the process of granting me access to them. My advice to the users of HPR-IP controllers is to ignore MF47274, MF47838, and MF47839 until these test PTFs become available.

(Please see the comments for updates.)