Whatever

Found this drink Whatever and Anything in Singapore. The flavor varies from one to another and you can’t tell from the label except if you read the ingredients.

It was funny. “What can I get you to drink?” the waiter asked. “Whatever…”, I replied. And Whatever can be Anything. It sheds a whole new perspective to being indecisive and irresponsible of your diet at the food table.

With each can, you may get a different flavor at random. So far I’ve not managed to order the same taste twice with Anything.

And while I’m at it, I might as well make it my new culture.

Someone argued with me to change a line of Java code from int a=1 to int a=0x01. Like, wow, that makes a whole lot difference. The next time this happens, I could just go Whatever. Or maybe when someone thinks they can get me to say yes by posing the same question in a different manner though the answer is still no, I could just go Anything.

Maybe what they should come up with next is a Nevermind drink. Perfect for their neighboring Malaysians whom practice the tidak apa (nevermind) mindset and attitude made popular by the decadent Malay race.

It may not give them a clue, but hey, Whatever. They may not like it, but like Anything ever? And most of the time, they go Nevermind anyway.

Finally, I can bring forth my sarcasm literally. And it quenches thirst too.

White Board

Most programmers claim to understand but can’t explain it. The vendors I dealt with in China and Dubai claims to able to do it, and then repented.

I don’t get it. What is so hard about IBM packed fields?

Packed field is an efficient way to store numbers, maybe not as efficient as an int but it’s commonly used on the IBM AS/400 platform.

Digits 123 can be represented in ASCII hex 313233 or in EBCDIC hex as F1F2F3. Packed field stores the number directly as hex 123F, which is neither ASCII nor EBCDIC. This shortens the size required to store digits. The last nibble (half of a byte) can be either D or F representing a negative or positive integer.

The obvious benefit is of course, if you’re paying your bandwidth by the number of bytes you’re transmitting, you’d want the data compressed. Packed fields keep numeric fields’ size small.

Someone asked me, assuming you know it’s a packed field with certain length, how do you test for a valid packed value?

This is what I came up with in ILE RPG:

 *
H BndDir('QC2LE')
 *
D getHex          Pr                  ExtProc('cvthc')
D                                1A
D                                1A
D                               10I 0 Value
 *
 * Use with entry parameters
D pValue          S             20A
D pResult         S              1N
 *
 * Use with working fields
D                 Ds
D  xHex                         40A   Inz(*Blanks)
D  xHexS                         2S 0 Dim(20) Overlay(xHex:1)
D  xHexA                         2A   Dim(20) Overlay(xHex:1)
 *
D xLen            S              5U 0 Inz(*Zeros)
D xPos            S                   Like(xLen) Inz(*Zeros)
D xVal            S                   Like(xLen) Inz(*Zeros)
 *
D cNumeric        C                   Const('0123456789')
D cYes            C                   Const(*On)
D cNo             C                   Const(*Off)
 *
C     *Entry        Plist
C                   Parm                    pValue
C                   Parm                    pResult
 *
C                   Movel(P)  cNo           pResult
C                   Eval      xLen = %CheckR(' ':pValue)
 *
C                   If        (xLen > *Zeros)
C                   CallP     getHex(xHex:pValue:%Size(xHex))
 *
C                   For       xPos = 1 By 1 To xLen
 *
C                   Eval      xVal = %Check(cNumeric:xHexA(xPos):1)
 *
C                   If        (xVal > *Zeros) And (xPos < xLen)
 *                  Not last byte and value contains non-numeric.
C                   Leave
 *
C                   ElseIf    (xPos = xLen) And
C                             ((%Subst(xHexA(xPos):2:1) <> ‘D’) And
C                              (%Subst(xHexA(xPos):2:1) <> ‘F’))
 *                  Last byte and value contains non-acceptable
 *                  non-numeric.
C                   Leave
 *
C                   ElseIf    (xPos = XLen)
C                   Move      cYes          pResult
 *
C                   Else
 *                  Try to ridicule the compiler.
C                   Monitor
C                   If        ((xHexS(xPos) > 99) And (xPos < xLen))
C                   Leave
C                   EndIf
C                   On-Error
C                   Leave
C                   EndMon
C                   EndIf
 *
C                   EndFor
 *
C                   EndIf
 *
C                   Return
 *

So the final else condition isn’t really necessary, but I never did test this piece of code and I rather play it safe.

The code should be self-explained. Convert the value to hex, and start comparing byte by byte whether it contains valid numerical digits. Except for the last nibble, it must have either hex of D or F. Anything else is invalid.

Program returns true if given value is a valid packed field candidate.

OPCAT Mac OS X

I’m currently in Singapore attending an advanced session on OPCAT (Object Process Case Tool), a modeling tool based on OPM (Object Process Methodology).

A recent OPCAT upgrade from version 2.xx to version 3.00 also requires a JRE upgrade from JRE 1.5 to JRE 1.6. As of Mac OS X 10.4.10 the standard is still JRE 1.5. Mac OS X users would need to download Java SE 6.0 from ADC website.

After installing JRE 1.6 you need to set JRE 1.6 as the default Java Runtime version. To do this, go to Applications -> Utilities -> Java SE 6 and click on Java Preferences. Under Java Applications Runtime settings under General tab, drag Java SE 6 to be the first one on the list. Your other JREs are still on the system and you may revert if necessary.

Next, having installed (proper .exe decompression) OPCAT in my Windows VM I copied the entire folder to my Mac OS X environment. Since OPCAT is written in Java it would run cross-platform, but unlike previous OPCAT version some minor tweaking is required to get it running smooth on Mac and Linux.

There are four environment variables that must be set manually. If you ran OPCAT installer on Windows, check your system variables and you should see the following:

  • OPCAT_BACKUP_HOME=C:\Program Files\Opcat
  • OPCAT_COLORS_HOME=C:\Program Files\Opcat
  • OPCAT_HOME=C:\Program Files\Opcat
  • OPCAT_PROJECTS_HOME=C:\Documents and Settings\…
  • To set environment variables in Mac OS X, you could run command shell and use env command. For lazy bumps there’s a free RCEnvironment utility which allow users to control their environment variables in GUI from the Preferences pane.

    I have mine set like this:

  • OPCAT_BACKUP_HOME=/Users/datacrush/Opcat
  • OPCAT_COLORS_HOME=/Users/datacrush/Opcat
  • OPCAT_HOME=/Users/datacrush/Opcat
  • OPCAT_PROJECTS_HOME=/Users/datacrush/Documents
  • If this doesn’t work for Linux users, here’s a clue: The OPCAT Java class responsible for loading paths is using System.getenv().get("OPCAT_HOME"). Go figure.

    Of course, you’re free to move your OPCAT folder anywhere you want on the system, even under Applications if you wish. I would recommend that you keep OPCAT_HOME and OPCAT_PROJECTS_HOME separated to simplify any future upgrades. Just make sure your environment variables are set accordingly.

    A system restart is not necessary at this point, but recommended. A simple user logout and login would suffice.

    To run OPCAT on a Mac OS X or Linux you may ignore opcat2.exe file and click on opcat2.jar or run java -jar opcat2.jar from your command shell instead.

    Be warn though that presently some paths inside .opz files are hard coded to point to a particular directory, say file://C:\Documents And Settings\... which would cause OPCAT to fail on a Mac with a java.lang.String.subString error when loading such .opz file. This isn’t a major issue since I’m able to manually edit an .opz file with a text editor and fix the erroneous file paths. I believe future version of OPCAT would resolve this problem.

    OPCAT 3.00 has taken OPM concept a step further, having improved in areas of teamwork modeling and simulation. While the previous version had an Academia look and feel, this latest update to Prof. Dov Dori’s OPM arsenal reflects a more professional commercial product.

    Also, OPCAT 3.00 look and feel blends seamlessly with Mac OS X. Cool!

    « Previous PageNext Page »