CHR$(9)

[NotFitForPurpose]

A story about CHR$(9) on PSION Organisers, I was reminded of this in a link Martin posted about a software engineer at PSION and Scrabble, along with a post linked at the bottom.

So my business partner and I had written this really cool and sophisticated analysis program (supported with custom interfaces). The former may not be true, the latter definitely the case.

However, in a later revision, a nasty bug cropped up Intermittently with data storage. Seemingly many thousands of extremely valuable data points would occasionaly get corrupted. My partner was leaving the project, business and in fact departing the country, with my self very much ‘holding the baby’.

DataPaks were really expensive and he didn’t like changing or erasing them. So, he had written a compression routine for the data I suspected might be involved in the issue. There was no room on the program pack for comments. We were already compressing code by this point to fit onto 64k Data Packs. I understood the underlying (EPROM) technology well, so confident the issue with our code in this case.

I found my self sat on a bed located in a hotel on the North Yorkshire moors, debugging his undocumented code. When I should have been spending time with my new girl friend I had taken to the hotel!

After a good while she told me she was really bored and wanted to go for a walk! I really ‘needed’ to get that bug fixed, though was making little if any progress. So, I very reluctantly relented and went for a walk round the village and in the local valley.

Half way up the valley next to the stream, my brain popped and I remembered CHR$(9) acting as a delimiter!… My former business partner hadn’t accounted for it in the compression algorithm…or not aware. Given a certain combination of input data to the compression routine a CHR$(9) would arise in the compressed data stream. That was the first piece of someone else’s code I debugged professionally.

That’s actually the point I pulled away from PSION Organiser II commercial projects. The effort being put in was not returning sufficient and during that moment I identified other career and personal priorities.

Lessons learnt: document your code, write test routines, listen to your life partner, take a break and get your priorities right.

I am still married to her with two great kids having adventured half way around the world with my family and occasionally, I get to play with a PSION Organiser.

Amongst other items prompted by:
viewtopic.php?p=1808#p1808

This of course is going into my life journey book, don't worry the rest is only for me and my family.

[amenjet]

I am currently in the middle of implementing records and can confirm that character 9 is used to delimit the field variables in files. It's not just for database records, it is for all file handling. QCode itself uses that character to delimit the data in the buffer that the record is stored in.

I think you could store a TAB by using some other character or sequence of characters and mapping between tab and code on the way in and out of files. A bit fiddly, but do-able. Another character other than 9 could be used as a delimiter in any new implementation of OPL, but any code that takes advantage of character 9, for instance to split fields wouldn't then work without changes.

I'm not sure why they used 9 rather than a lesser used value like 0xc0 or something, but they did. Packing the fields into one buffer is probably down to the small amount of RAM in an organiser.