So I'm working on this project right now that requires me to connect to an old JD Edwards system running on a DB2/AS400 platform. For the past two days I've been ripping my hair out trying to figure out why certain tables/columns returned from the JDBC driver (called JT400) are in Binary format. Come to find out that a lot of older AS400 systems use a data format called EBCDIC, which is basically a alternate to ASCII that's built for easy compatibility with punchcards. Yes, you read that right - PUNCHCARDS.

Basically, everything I expected to be a varChar was coming back from the AS400 JDBC Driver as a Binary/ByteArray object in CFMX. I looked high and low for an explanation and finally found the JDBC configuration options for the JT400 Driver. Looks like there is a connect string option that tells the JDBC driver to convert the binary types into varChar!

Once I found this information, all I had to do was add "translate binary=true;" to the end of the JDBC URL and all was good! A couple of notes here though... 1) Yes, there is a space in there, and yes, you should leave it in there. 2) Case matters - lowercase the whole thing or it's not going to work.

For some unknown reason, I held onto the conference packet from the first ColdFusion conference ever, organized by Robi Sen and Mark Broner, held in 1998 at Colorado State University in Fort Collins Colorado. I've scanned some of the contents of the packet and put them online. Come check em out for some nostalgia.

Notable content includes:

• Session schedules and descriptions
• Proposed specs for Fusebox 1.5 (?!?!?!)
• CFDJ Vol 1 / Issue 1 (promo cardsheet)

Note that you can click "show all sizes" at the top (you may have to be logged into Flicker to see it) if you want to see the full size images.

As I'm getting more and more into developing Flex 2 apps, I am running into silly little annoying problems and am going to start blogging them so I can find the solution when I forget and it happens again.

Problem: The ColdFusion Wizards in the Flex Builder 2 require you to connect to the CFMX server using RDS in order to get table information. In my case, I was getting to the screen where you choose an RDS server and datasource - but and the datasource box was empty. I knew there was a valid datasource at that location, and Flex Builder wasn't complaining that I'd given it a bad RDS password.

After a bit of troubleshooting, I found the following in CFMX's exception.log file: "File not found: /CFIDE/main/ide.cfm". This essentially means I didn't enable RDS when I installed CF. Whoops.

Solution: Since main/ide.cfm isn't an actual physical file, you have to tell CFMX that you want it to intercept calls for this file and handle them for you (enabling RDS). This is done via an entry in the web.xml file, typically located in [cfmxroot]/wwwroot/WEB-INF/. Just open up the file and do a find for "RDS". Two entries should be in there, both commented out. Simply uncomment them and restart CFMX.

Done.

As a side note, if Adobe's listening, it would be nice if Flex Builder were smart enough to tell you when RDS authentication fails or RDS isn't enabled on the target server.

Ben's coming to town May 1st! I just posted details to the SDCFUG website and it should be a good one since Ben's promised to demo ColdFusion integration features never yet seen outside of Adobe! Hope to see you there!

As it turns out, coldfusion.runtime.Array datatypes turn into java.util.Vector datatypes after WDDX deserialization. This isn't much of a problem for the most part. After all, the CFMX Array datatype is based on the Java Vector datatype. CF still views it as an array, and you can still treat it just like an array in CF code. However, there is at least one place it *does* matter - invoking and consuming webservices. It seems that when one of these java.util.Vector datatypes is passed to certain webservices, you will get the infamous and annoyingly indescriptive error that it "Could not perform web service invocation "X" because java.lang.IllegalArgumentException: argument type mismatch". Yowza. I've confirmed the behavior with some folks at Adobe, so hopefully it will be corrected with the Scorpio release. In the meantime however, I am getting around this problem by recreating/rebuilding the array before posting it to the webservice. A little annoying, but it works. If you want to test this gotcha yourself, here's some sample code to play with: <cfscript> testObj = arrayNew(1); </cfscript> <!--- returns coldfusion.runtime.Array ---> <cfoutput> Object Type Before: #testObj.getClass().getName()#<br /> </cfoutput> <!--- serialize/deserialize array ---> <cfwddx action="cfml2wddx" input="#testObj#" output="x" /> <cfwddx action="wddx2cfml" input="#x#" output="testObj" /> <!--- returns java.util.Vector ---> <cfoutput> Object Type After: testObj.getClass().getName()#<br /> </cfoutput>

Being built in the spirit of Ruby on Rails, ColdFusion on Wheels is very promising.

As posted to Slashdot today, the source code for an algorithm has been posted that promises to find MD5 collisions, making it even more important to add some salt to any use of hash().

Two posts back to back about the same SDCFUG meeting? Yes! In addition to talking about Lazlo and WebOrb, Charlie Arehart will be giving us an update on integrating .NET with CFML on BlueDragon. This is a welcome and timely update for our group as several of our SDCFUG members work in shops where both .NET and ColdFusion are used side by side, with varied levels of success.

This week at SDCFUG, Charlie Arehart will be presenting Lazlo and WebOrb, which provide functionality similar to Flex and Flash Remoting, respectively. If you are in the San Diego area this Wednesday, I would strongly suggest checking the presentations out!

Occasionally, when dealing with a CFMX cluster you are unsure of which instance or even what machine is really executing the code you are running. In these cases, the following codebit can be a lifesaver to discover where your code's really running. Hat tip to Pete Keleher for the instance code.