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.
Tuesday, October 12, 2010
Tuesday, October 05, 2010
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:
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.
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.
Friday, October 01, 2010
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.
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.
Friday, September 24, 2010
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.
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.
Sunday, September 05, 2010
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:
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:
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 | ✔ |
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:
- 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.)
- 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)).
- %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.
- 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.
- 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.
- 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.
- %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.
- 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.
- 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')
- 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.
- 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.
- 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.
- 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.
- 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.
Sunday, April 18, 2010
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 science. 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 supplies. -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/engineering 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 architecture. 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 Rutgers 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 science, 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 considering 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 direction 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.
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 science. 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 supplies. -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/engineering 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 architecture. 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 Rutgers 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 science, 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 considering 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 direction 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.
Saturday, February 27, 2010
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:
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."
Your message was not sentOf 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.
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
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."
Wednesday, February 17, 2010
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.)
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.)
Wednesday, November 04, 2009
Saturday, October 24, 2009
Brother Cozzi's "Top Ten RPG IV Requirements"
Recently Brother Bob Cozzi, the eminent leader of the RPGers Order, published a list he called the Top Ten RPG IV Requirements. I would like to respond to that list and proffer some of my own:
My top ten:
- %JOBLOG(): While I have the greatest respect for Brother Cozzi this requirement leaves me feeling,... feh. Our lord Ib'm saw fit to provide us with the QMHSNDPM API and I've been using it so long I know the parameters by heart.
- %CONCAT(): I can see this being kind of useful, kind of like the sprintf() function from the "C" run-time cannon, but there is a difficulty when it comes to numeric fields. What if you want some to keep the leading zeros. It seems to me that it would be easier to just string everything together in a character expression.
- %GETENV and %PUTENV:
Great idea. Don't know why our Lord Ib'm hasn't implemented these built-ins yet. They would be very useful.What's the difference between this and using the Unix "getenv" and "putenv" functions to do the same thing? [Thanks to Father Klement for reminding me about these two functions as I had completely forgotten about them.]
- %STDOUT: What's the difference between this and using the Unix "open" with the "read" and "write" functions to do the same thing? Am I missing something? (And by the way, what's wrong with switching to embedded SQL? I've been doing it now for a number of years and I love the fact that if you add a field to a record format you don't have to recompile everything.)
- %REGEX: Can't really comment 'cause I haven't used the APIs yet.
- %TOLOWER and %TOUPPER: This already exists and it's really easy. Two named constants and the %XLATE() built-in and you're done. I can't imagine our Lord Ib'm wasting his time on this.
- Native Support for UTF8 (ASCII): This is a good one. I'd love to have a CCSID keyword to identify the data in the field and the internal support to convert the data as it's being moved into or out of the field.
- 3rd-party Add-On Library Support: Great for developers, but I suspect that the vast majority of AS/400 programmers like myself won't care too much.
- Reclamation; of columns 1 to 7 in free format syntax: I don't mind the /free and /end-free requirement or the loss of columns 1 to 7 as I too use it to mark changed code. What has always bugged me is the requirement that the executable code ends at column 80. It's a 100 byte line and we should be able to use its full length if we want to. In free-format languages one isn't restricted to the end point of the file, so why should free-format RPG be that way too.
- Port RPG IV to Windows 7 and Mac OS X and Linux: Great idea as it will expose the followers of those false religions to the beauty of iSeries worship.
My top ten:
- Free format everything in RPG including the "D" and "F" specs and remove the end-of-line restriction at column 80.
- %LEN and %DECPOS should be compile-time BIFs when the parameter is a single field. (When the parameter is an expression they can revert to being run-time BIFs.) I've got some routines where there are more named constants specifying %LEN and %DECPOS than local variables.
- Null Terminated Fields: I'd go further on item number 7 in Brother Cozzi's list by asking for an additional keyword that identifies a character field as null terminated. Every time you use it or change it the compiler would automatically handle the null terminator.
- Expand *JOBRUN date formats: Currently restricted to *MDY, *DMY, *YMD, and *JUL. They should be expanded to *EUR, *USA, *ISO, *JIS, *LONGJUL, etc., which would also require the O/S folks in Rochester add these values to the DATFMT attribute of the job. I can't tell you how many times I've had to write code to get around this restriction in full date processing in an international environment.
- Expand date functionality to include date formats required by such things as email headers, RSS, *DTS (internal date format for message fields), etc. The learning curve on the MI instructions and/or Unix API's for them all was daunting.
- Fix Data Display Problems in Debug: In debug, displaying the data at the end of a passed pointer has always had problems. I've got code all over the place where a structure pointer has been passed and it points to a space that contain pointers to other structures and the debug facilities in WDSCi and the green screen can't display the data they point to because of the underlying design of debugging data stored in the program object.
- Multi-dimensional arrays: Every other language I've ever worked with has had the facility for arrays with more than one index. How is it that RPG has survived all of these years with one index?
- Dynamic arrays: Many of us have written service programs that allow an RPG program to expand the size of an array on request and I think it's time that the RPG compiler got this feature. Instead of being a fixed size stored in the program it would be an allocated heap space. If I was designing this feature I'd add a new parameter to the DIM keyword that allows *EXPAND or *FIXED along with the dimension that would constitute the space allocated initially. Whenever a program specified an index that was out of bounds the run-time functions would simply re-allocate the space.
- Parameter signatures in RPG procedures (aka Procedure Overloading): This would be similar to what is currently available in O-O languages like Java and C++. We can do this with SQL UDFs, so why not with RPG procedures? This would also make it a lot easier to interface with C++ procedures. It would also be nice to not have to use *OMIT and *NOPASS if you didn't want to.
- RPG classes: Another facet of Java and C++ that would be useful. It would also make it easier to interface with Java and C++ objects because the JNI hoops one must jump through now are too daunting to be useful.
Subscribe to:
Posts (Atom)
Posts
