Archive for the ‘Bugs’ Category

CPYF INCREL doesn’t work like you think.

Wednesday, August 1st, 2007

Found a funny little bug today.

CPYF … INCREL((*IF REFKEY *GT ‘TER’) (*AND REFKEY *LT ‘TES’)) 

You’d expect this to copy the records where REFKEY begins with “TER” but it actually copies nothing.  Query/SQL correctly matches the records, but not CPYF. Oddly enough, if you change the greater than (GT) to greater than equal (GE) and LT to LE it finds & copies the records just fine.

The other work around is to fully document the fields for comparison.  If REFKEY is 10A, try it thusly and it works:

INCREL((*IF REFKEY *GE ‘TER       ‘) (*AND REFKEY *LE ‘TES       ‘))

In fact, just adding one space after the ‘TER ‘ / ‘TES ‘ seems to do the trick. Why this should be is a mystery to me. Until someone explains it, I’ll call it a bug. Thanks for reading!

I’ve got 50 ways…

Tuesday, July 10th, 2007

Sometimes we forget that CL programs aren’t as refined as RPGLE programs. I was just burned on this fine point over the Month End when a new utility was added to a few dozen CL programs. In a nutshell, each of these CLs calls an external program to write one record to a log regarding the report that was just submitted. At the last minute I added the functionality to include a string of text (50A) that would serve to override the program description if not blanks.

Well, I passed ‘ ‘ for the parameter 99% of the time. The trouble is in RPGLE if you pass *Blanks for a parameter the program is smart enough to pass 50 blanks. CL is more litteral and it goes back to programming 101 - don’t pass 1 character when the receiving program expects 50! The result is that sometimes the string was blanks and sometimes it was random garbage from memory making a mockery of my loggery.

In retrospect I could have made it easier on myself by making the last parm optional but now I either have to go back and fix dozens of programs (which contain on the average 4 calls to the subroutine) or modify the receiver to check only the first digit. I chose the latter of course because time is money and cludge that works is better than a useless log.

Until next time, document that cludge!

Marginalized Madness

Tuesday, April 3rd, 2007

Once upon a time we decided that a barcode on top of the inventory tracking report would be very helpful. Indeed it is, but the report was just a good old fashioned text spool file. To add the barcode we switched from O specs to an “Advanced Function” Printer File.

The barcode printed beautifully and production increased, but for some reason positions 1-3 were overtyping. Checking the printer file everything seemed in order. The first field is 1 digit starting in position 1. The second field is 11 starting in position 3. Couldn’t be simpler, right?

Well, remember that this is AFP. If you don’t tell the printer exactly where to print each character it’ll make a guess & have fun doing so. What it did in this case, AFAICT was to attempt to print column 1 at the absolute right edge of the paper. Since the printer we were using couldn’t print right to the edge it had some fun and printed everything that would have fallen into the margin as soon as it could - in column 3. Easy fix: CHGPRTF and set the margins to .1!

That worked and the overprinting ceased but here’s the bug: When viewing the spoolfile through DSPSPLF the 400 argues with itself on where to display the data. Despite printing in column 1, the first field appears in column 4. No big deal except the report is 132 wide and now columns 130-132 are not displayed at all. That’s right, the data prints, but doesn’t display. For this reason I’m calling it a bug. AFP has been around for a few decades now and I don’t see any reason that DSPSPLF can’t correctly display the AFPDS spool files.

Now that I’ve said that I’m sure someone will remind me of a better way to get around having to set the margin. Some obscure compile option on the Printer File perhaps? Some configuraton on the writer? Hey, if you know - share the wealth!

Until next time…
ENDWTR

Client Access needs Access!

Wednesday, March 14th, 2007

I’d like to be using WDS or even CODE, but for the time being (and foreseeable future) I’m going to be using Client Access. The installed version is 5.5 which dates back to late 2002. Like a big heavy rock, CA doesn’t change much. This is a good thing. However, just like that rock, it’s rooted in prehistoric days.

My humble work PC is restricted to prevent me from breaking it. Again: Good thing. The problem comes in when “C:\Program Files\IBM\Client Access\” has only Read privileges. You see, Client Access requires read/write privs on that folder to work correctly. Here’s a short list of the problems caused by a read-only CA folder:

  1. CA uses the folder as a staging area (and default save location) for several functions. The most obvious is the .WS session file. These can be saved somewhere else and edited to point to a non-default keyboard map, tool bar, edit functions, etc. That much works great, but IBM neglected to include a method to change the default location of the display settings stored in PSCWIN.INI. Even if the file is copied to the same location as the .WS files or the “start in” folder is changed in the short cut, IBM seems to have hard coded the location of this one file. This results in client access reverting to the “Last Exit View” after a system restart and all of my sessions open with various sizes & positions. The initial “Session A” actually opens minimized. This is more of a nuisance than a problem.
  2. CA’s macro function relies on full access to folder C:\Program Files\IBM\Client Access\Emulator\Private. Macros must be stored & accessed from that folder. It’s kinda amazing to me that after goodness knows how many years they never added a “browse” button. Adding to the confusion is the fact that the folder is protected isn’t obvious from the odd error message CA kicks out.
  3. The File Transfer function does not work if invoked directly from CA. File Transfer is installed and functional because it works from Excel, but those fun buttons (or menu options) do nothing. IBM doesn’t even bother with a misleading error in this case. The buttons simply fail to do anything. If I’m not transferring a spreadsheet there’s always direct FTP I guess.

In summary, if File Transfer is broken, Last Exit View doesn’t save or Macros give a bogus error message you probably have a locked down Client Access folder. Talk to your sysadm, secofr or other Omnipotent being and ask them to fix you up. Just be careful they don’t tire of your whining and force you to use Mochasoft’s emulator instead. . .

Until *NEXT time!

The rare OS/400 bug

Friday, February 2nd, 2007

I once wrote a CLP that snatched the users info messages from their default message queue and displayed them on the attention line where they could roll through them. Linked to a simple command I called “D” this saved the user the step of typing DSPMSG and then deleting the messages. No biggie, but when we moved to V5R2 I noticed that the second message would always truncate at 25 characters. True bugs in OS/400 are so rare I had to write a sample program to verify what I was seeing.

     PGM
       SNDPGMMSG  MSG('THIS MSG IS 25 BYTES LONG')
       SNDPGMMSG  MSG('THIS MESSAGE IS 38 CHARACTERS LONG')
       SNDPGMMSG  MSG('ANOTHER ONE THAT IS 38 BYTES LONG.')
     ENDPGM

In this example the second message above would be clipped at “THIS MESSAGE IS 38 CHARAC”. I noticed it only worked correctly if the message was longer than76 characters which would have caused the message to be truncated anyway. I worked around the “bug” by appending just enough blanks to trigger the automatic truncate.

We’ve since upgraded to V5R3 and the bug is gone. I was told we had all of our PTFs on the old system, but the bug persisted for years. Anyone else still on V5R2 have the same issue? I’ll post here another day to document the other interesting bugs I’ve seen, but the SNDMSG bug remains the only one I’ve seen that wasn’t fixed by a subsequent patch.

SIGNOFF DROP(*YES)