In
Flight MagazineIn
Flight Magazine
Welcome to the first InFlight Magazine for 2002. You may notice a few changes (or you may not). First of all, I'm playing with a trial copy of Dreamweaver 4 and I must say it's pretty darn nice. Now if only I can find somebody in New Zealand to take my money off me for a licensed copy in the next 23 days, I'll be dead chuffed. This issue has a decidedly non-mainframe flavour to it - not that we're jumping ship, it just turned out that way.
I've also switched (over my dead body) from WordPerfect to MS-Word and I'm hanged if I can persuade the printer to print this thing properly so the Inflight Magazine is now officially "e-mail only".
In this issue :-
If you recall in last December's Inflight Magazine, I mentioned that there was a new time-saver on its way for PC Key/Master (not for the mainframe version). What our friends in development have done (thanks, Greg) is to add some new EasyLogic timings. Take a look at this example. It checks to see if anything is entered into field4 and, if it isn't, it skips over fields 5 & 6 and marks field 6 as having been verified. At the end of verifying the format, it once again sets field 6 to "not verified" so that the next record will need to have field 6 verified as usual.
This is a great way of handling those formats where you have many lines of information that are often left blank, for example a format that lets you enter someone's name followed by the names of their 10 children. This type of EasyLogic lets you skip over all the children once the first one has been missed out.
AFTER field4 EDITS IF field4 IS NOT ENTERED SKIP TO field7 ; Skips field6 (field6 is a verify field) ENDIF
AFTER field4 VERIFY IF field4 IS NOT ENTERED SET VERIFIED field6 SKIP TO field7 ENDIF
AFTER-VERIFY SET NOT VERIFIED field6
To get hold of a copy of PC Key/Master with all these neat new EasyLogic options, just drop us an e-mail and we'll get one on a courier, or even in an e-mail to you.
As an aside, we've taken a quick show of hands around the office and discovered that we have two each. We've also voted Greg Iwinski & the Key/Master support guys at Mercator the best technical support team of the year.
Everyone
is acquainted with PKZIP, possibly the most popular piece of PC software around.
We’re responsible for the AS/400, mainframe and Unix versions in this part
of the world and we thought you’d like to know a bit about how PKZIP manages
to compress your files to such a tiny size without losing any data (end of plug).
PKZIP uses a "Lossless" compression algorithm (unlike JPGs and other
graphics that lose some data in the interests of maximising compression).
Small data files contain very little redundant or repeated data whereas large datasets will have far more redundancy and so compress more effectively. This article, so far, contains the character string "data" 6 times and I dare say I’ll use it again before I’m done. Similarly, a large proportion of the numeric fields in any database are full of zeroes, crying out for compression.
PKZIP achieves its high compression rate by compressing the data twice using two different algorithms. The first compression is done using the Lempel-Ziv-Welch algorithm (so now you know what LZW stands for). LZW works by building a dictionary of "phrases" (groups of one or more bytes) from the file. When a new phrase is found, LZW checks to see if it’s already in the dictionary and, if it is, replaces it with a much smaller token. If it isn’t in the dictionary then it’s put there and a new token is created. LZW works extremely well with text as text is full of repeating patterns. LZW builds a new dictionary for each file so that it is independent of the actual data in the record – this article uses "compress", "data" and "algorithm" more often than I would normally use them in a letter home.
The size of the tokens used by LZW is a function of the original file size - this means a large file can have many tokens and a small file will also compress well: this paragraph would compress well simply by replacing "e " and " a" with tokens. PKZIP uses a modified version of LZW that improves upon the classic implementations in the way it discards dictionary entries when the dictionary fills as well as reblocking the data for more efficient storage.
Once LZW has done its stuff, PKZIP unleashes the Shannon-Fano trees algorithm on the file - a "probabilistic compression" method that relates the size of a token to the probability of the character being in the data. This cuts the number of bits needed to represent the most commonly used characters - individual characters are hung on a tree structure with the most common ones near the root. The less branches that have to be followed to reach a given character "leaf", the less bits there are in the final value. As an example, suppose the letter 'e' occurs 2,000 times in this newsletter (yes, I have counted them) while 'q' appears 6 times. Stored as 8-bit ASCII or EBCDIC, they'd account for 2,006 bytes. If we can pack the letter 'e' into 4 bits while letting 'q' get blown up to 12, our 2,006 bytes is now down to 1,009.
The end result of PKZIP compression is a reduction in file size of 50-90% for typical data and text files. And, if you've wondered why BMP files always compress so well and JPGs don't, it's because BMP is very crude, describing a picture pixel by pixel ("red dot", "red dot", "red dot" etc) while JPGs are already compressed ("486 red dots", "213 blue dots" and so on). You can find out more about PKZIP here.
 |
Did you know that Reverse Polish Notation was invented by Jan Lukasiewicz (1878-1956)? Alas, nobody could pronounce his surname and so they gave this major contribution to computer science a name they could pronounce. There is no truth in the rumour that the Kiwi Fruit was named after me. |
I come from a long line of Luddites (I even had a landlady called Miss Ludd once) so this month I'm going to whinge about a piece of technology that is designed to ruin my life. I refer, of course, to the light emitting diode (or LED to its friends of which I am not one). LEDs are a scientific marvel made by sealing glow-worms in little glass bulbs and training them to glow whenever you shove 6 volts up their rear end. Electronics manufacturers have seized on them with a will, putting them in a million useful places (such as a light on your dashboard to tell you you're driving with the handbrake on) and several million useless places. I spend a lot of my working life in hotel rooms, none of which is as comfortable or as dark as my own bedroom. My constant companion is my cellphone, of course, which blinks all flaming night. (I can't put it in the bedside drawer because (a) it's full of phone books and (b) I'd leave it behind.) It blinks green to tell me I'm in New Zealand or yellow to tell me I'm not in New Zealand (I've often wondered that at 3:30 a.m.). It even blinks red to tell me that the battery is going flat. If I plug it in, it goes back to yellow and the charger's LED turns green. This light show has often kept me awake all night. Even better, who was the clown who decided to put a bright red LED on the television to tell you that it is turned off? My TV at home has an amazing feature that should be universal - when you turn it off, the screen goes black.
Don't get me wrong - I'm full of admiration for the genius who came up with these things. But please, don't overdo it. I like Guinness but I don't put it on my cornflakes. Now, if you'll excuse me, the LED on my phone is telling me that I have a call - I wondered why the phone was making that ringing noise.
25th to 27th February sees us on the road again, this time to the BiCSi Conference at Star City in Sydney. We're going to have Aperture version 7 there along with some real life data centre and network drawings. We also hope to have a pre-release copy of Aperture TechDoc version 7 fired up so you can see all the swish new technology documentation modules. And John is insisting on showing off his new metricated version of the Manufacturers' Device Specs Table as he is sick of all those hardware manufacturers who think we want to measure our equipment in inches, pounds, firkins and gallons.
We're often asked "How do I put an asset that is outside a building into a region?" Dead easy. Suppose you have some things on the outside of your building - light fittings, fire hoses - that you want to record as being in a region so that your asset & maintenance reports say where the object is. You could simply draw a polygon right round the outside of your building and attach a Space Region record to it - but that wouldn't do you much good as all the objects in the rooms would now be confused as to whether they were in C04 or in C-EXT (and Aperture would tell you so, too).
The
trick is to draw a "doughnut" polygon round the outside of the building - make sure it doesn't overlap any of the Space Regions inside the building.
Then you can attach a Space Region record to the new external space region and
all the objects you put in there will reflect the name of the C-EXT region that
they're in. You could even get jazzier and put a space region against each wall
so you can keep track of things based on which wall they're fixed to. There
is a slight fiddle in drawing this doughnut polygon and that is that Aperture
is very intelligent and, when it finds you've got back to where you started
a closed polygon, it will automatically close it. So you will need to draw the
"doughnut" with a slight gap in the top left hand corner and then
use "Move a vertex" to close the gap.
One last thing to watch out for - make sure that you don't include the area of your external polygon in any of your reports - a case of using a Where clause in your reports to exclude external areas.
Christmas, and the following month is generally a little less hectic than the
rest of the year for us and so we normally take the time to do a bit of "housework".
This year, faced with our rather unreliable gaggle of PCs running a mix of Windows
98, 98SE, WinMe and NT 4, we thought we were well overdue for a tidy up. As
you probably know by now, we are not the greatest Microsoft fans in the world,
but realistically we could find no easy way out of using Windows. So after much
deliberation, we decided to give more of our hard earned money to our good friend
Bill, and move to a standard OS. Windows 2000, and 2000 server were the OS of
"choice". A couple of minor problems to work out, our DOS based accounting
and billing systems for one, both of which are running well past their use by
date.
We were sure they would not make it past Y2K testing, but they did, but getting
them to run with Win 2000 was probably more fun than we could handle, so it
was decided they had to go.
So a new package that would meet our requirements was sourced. The jury is still
out on whether the choice was the right one, and Bev definitely has a story
or two to tell about the fun she has had with the changeover.
Apart from that it was a fairly smooth transition, and we definitely have a
more reliable environment than we had (According to Microsoft "On comparative
reliability tests conducted by ZD Labs, the average system uptime of Windows
2000 Professional was over 50 times that of Windows 98 and 17 times that of
Windows NT Workstation 4.0." , [I think Win 2000 falls over less often
because it is so much slower - Ed] When considering they are comparing Win2000
to their own unreliable products they have sold you in the past, I believe this
to be something only Microsoft could get away with. And, after downloading patch
after patch, service packs and security updates (our ISP will enjoy charging
us for that lot), maybe a little more secure. http://www.trustworthycomputing.com/
One thing we have decided on - we do not ever want to move to another version
of Windows. Hopefully, by the time we are forced to move on, there will be a
viable alternative. Meanwhile those Apple
Imac's are starting to look pretty good. http://www.apple.com/imac/ [So
does a bloody abacus - Ed]