Sunday, 26 August 2012

#ibmi hints and tips #17: About reusing deleted records

I have been caught out so many times on this one ... If you create a physical file with CRTPF (whether using DDS or not), the default setting is REUSEDLT(*NO). If you create it using SQL, the default is REUSEDLT(*YES).

Tuesday, 14 August 2012

Interested in becoming a member of the IBM Electronic Support Client Advisory Panel?

I've been asked to publicise this IBM initiative for those with an interest in online technical support.

The Electronic Customer Support Advisory Panel meets on the 'phone every other month to review future plans for electronic support and to provide input about what they need from the Support web site.

This would take up about an hour every other month.

Participating gives members the opportunity to influence the enhancements and changes IBM makes to its electronic support; it also gives IBM a better understanding of what customers need and want in the next generation of support, and how IBM can address them.

If you're interested, I have more details and the necessary IBM contact information - you can get in touch with me at

Friday, 10 August 2012

#ibmi hints and tips #16: A small fact about CPYTOSTMF and CPYTOIMPF

I have only recently realised the simple fact that CPYTOSTMF and CPYFRMSTMF work with 'program described files' (as IBM i still, scarily, calls them), i.e. physical files created using CRTPF without DDS, while CPYTOIMPF and CPYFRMIMPF work with proper database files, i.e. physical files created using either DDS or a SQL CREATE TABLE. I'm sure you were all aware of this, but just in case ...

#ibmi geographical and national language handling overview

Or 'How to turn a dollar into a pound without even trying'.

I've been planning this one for years - needed a lot of research (most of what I thought I knew turned out to be wrong). I hope it makes sense, but as always please do let me know of any errors, omissions, or lack of clarity.

The document is at

Saturday, 4 August 2012

#ibmi hints and tips #15 : ODBC and CCSID 65535

Something I forgot to mention in my recent DB2-for-non-i-developers post is that database tables created using DDS are frequently left to the default CCSID of 65535, which means 'treat stored data as binary'.

This causes trouble when you access the database via ODBC (or indeed JDBC - see hint/tip #14), since alphanumeric fields are not transcoded, resulting in a lot of EBCDIC data that is meaningless in a PC context. (If you get a load of incomprehensible output with lots of @ signs in it, this is what's happened - the @ signs (hex 40) are spaces in EBCDIC.)

To resolve this, you need to tell the ODBC driver to ignore the 65535 setting and transcode the data. (It will use the CCSID on your user profile.) Here's the setting:

First post on Expert Integrated Systems blog

Back in June I attended an IBM PureSystems Social Media Residency at IBM Research Triangle Park, Raleigh, North Carolina. It was a fabulous experience. I learned an unbelievable amount, both about the PureSystems platforms and about the practicalities of marketing via social media, and I met a lot of really interesting (and nice) people. Anyway, one point of all this was to get the 15 residents blogging regularly about their particular angles on PureSystems. My first effort was published yesterday: More to come soon, hopefully.