Before the actual post begins, a very happy, but belated, Programmer's Day to everyone! Programmer's Day is the 256th day of the year (of course!).
This week's blog was written by Jon (with American punctuation and spelling contributions by Susan) for reasons that will soon be obvious.
Last night I was busily coding my brains out on a new RPG Open Access handler and needed to use RPG's good old SortA op-code. That got me thinking about sorting in general and the fact that many of today's RPG programmers probably don't understand the mechanics behind sorting. In fact I find that many of today's programmers don't understand the underpinnings of much of what goes on behind their code, but we'll get back to that later. In the meantime, we needed a topic for this week's blog and so ...
For me it all began a long time ago on a different planet, well--at least in a different country. As a beginning IT pro I started out in the world of punch cards which was how all data entry was handled at my first job. In fact all data storage was in the form of punch cards. Customer addresses, account balances, invoice line items were all on punch cards. At the time a few systems around used magnetic tape as the primary storage media but they were reserved for large systems used by banks and large manufacturing companies. A few disk systems were also around, but their capacity and cost meant that all but the biggest shops used them primarily for the operating system, program storage and work files for use during processing.
Needless to say as the junior in the department I got all of the jobs the senior staff didn't like doing. As a result one of my earliest duties was to be responsible for sorting the cards into the order needed for processing. For example, to take all of the batches of transactions that had been accumulated during the week and sort them into customer number and invoice number order so that a weekly customer sales report could be produced and a summary card produced for each invoice. The card sorter in our shop ran at 750 cards per minute (cpm). That was scary fast considering that you were expected to be able to add cards to the input hopper and extract them from the output hoppers all without stopping the machine. It took me a week or three to get the hang of doing that without jamming the machine and wrecking a bunch of cards. At 750 cpm you could mess up quite a few before the sensors registered the jam!
So how did mechanical sorting work? Well, let's take a customer number as an example. A heap of cards was placed in the input hopper and the column selector (yes you could only work on one column at a time) was set to the right-hand position of the number (i.e., the least significant digit). Once the start button was pushed, the cards shot though the machine and dropped into the relevant hoppers 0 through 9. You then gathered the cards carefully in order and placed them once again in the input hopper, being careful to ensure that all the 0s went first followed by the 1s, 2s, etc. By preserving the groupings like this you ensured that this time the cards in the 0 hopper were in themselves in sequence 00s, 01s, 02s, and so on. This continued until the entire customer number had been processed at which point the cards were in sequence. Or at least that was the theory. Since we were dealing with mechanical processes it was not unheard of for a card to be mis-selected and end up in the wrong hopper. So the next task was to take the cards to the collator and run a sequence check, manually correcting any issues found. Finally the cards were ready for processing and my part of the job was done.
Interestingly, I have found uses for this basic knowledge in other areas over the years. On one occasion a customer had to provide the auditors with the original customer order slips for specific invoices (most auditors didn't trust these "new-fangled" computer systems). There were thousands of them, just in boxes by the month. It seemed like it was going to be a lot of work, but we applied the same sorting process to them, grouping by first the last digit, then the next, and so on until they were in sequence. then we just handed the boxes to the auditors and told them to help themselves to whatever they wanted.
Of course modern memory-based sorting methods don't work exactly the same way, but I still feel that my knowledge of the fundamentals is helpful. A knowledge of punch card coding helped me understand the structure of coding systems like EBCDIC and ASCII. That in turn helped me to appreciate systems like DBCS and UCS--not to mention being able to derive easily memorized wifi passwords--well, they are easy for me to remember anyway!
I really hope that devices like the Raspberry Pi, which we blogged about earlier, will help more people get involved in the fundamentals again. That reminds me--we just got our notification that we can order ours--must remember to do that.
This week's blog was written by Jon (with American punctuation and spelling contributions by Susan) for reasons that will soon be obvious.
Last night I was busily coding my brains out on a new RPG Open Access handler and needed to use RPG's good old SortA op-code. That got me thinking about sorting in general and the fact that many of today's RPG programmers probably don't understand the mechanics behind sorting. In fact I find that many of today's programmers don't understand the underpinnings of much of what goes on behind their code, but we'll get back to that later. In the meantime, we needed a topic for this week's blog and so ...
For me it all began a long time ago on a different planet, well--at least in a different country. As a beginning IT pro I started out in the world of punch cards which was how all data entry was handled at my first job. In fact all data storage was in the form of punch cards. Customer addresses, account balances, invoice line items were all on punch cards. At the time a few systems around used magnetic tape as the primary storage media but they were reserved for large systems used by banks and large manufacturing companies. A few disk systems were also around, but their capacity and cost meant that all but the biggest shops used them primarily for the operating system, program storage and work files for use during processing.
Needless to say as the junior in the department I got all of the jobs the senior staff didn't like doing. As a result one of my earliest duties was to be responsible for sorting the cards into the order needed for processing. For example, to take all of the batches of transactions that had been accumulated during the week and sort them into customer number and invoice number order so that a weekly customer sales report could be produced and a summary card produced for each invoice. The card sorter in our shop ran at 750 cards per minute (cpm). That was scary fast considering that you were expected to be able to add cards to the input hopper and extract them from the output hoppers all without stopping the machine. It took me a week or three to get the hang of doing that without jamming the machine and wrecking a bunch of cards. At 750 cpm you could mess up quite a few before the sensors registered the jam!
So how did mechanical sorting work? Well, let's take a customer number as an example. A heap of cards was placed in the input hopper and the column selector (yes you could only work on one column at a time) was set to the right-hand position of the number (i.e., the least significant digit). Once the start button was pushed, the cards shot though the machine and dropped into the relevant hoppers 0 through 9. You then gathered the cards carefully in order and placed them once again in the input hopper, being careful to ensure that all the 0s went first followed by the 1s, 2s, etc. By preserving the groupings like this you ensured that this time the cards in the 0 hopper were in themselves in sequence 00s, 01s, 02s, and so on. This continued until the entire customer number had been processed at which point the cards were in sequence. Or at least that was the theory. Since we were dealing with mechanical processes it was not unheard of for a card to be mis-selected and end up in the wrong hopper. So the next task was to take the cards to the collator and run a sequence check, manually correcting any issues found. Finally the cards were ready for processing and my part of the job was done.
Interestingly, I have found uses for this basic knowledge in other areas over the years. On one occasion a customer had to provide the auditors with the original customer order slips for specific invoices (most auditors didn't trust these "new-fangled" computer systems). There were thousands of them, just in boxes by the month. It seemed like it was going to be a lot of work, but we applied the same sorting process to them, grouping by first the last digit, then the next, and so on until they were in sequence. then we just handed the boxes to the auditors and told them to help themselves to whatever they wanted.
Of course modern memory-based sorting methods don't work exactly the same way, but I still feel that my knowledge of the fundamentals is helpful. A knowledge of punch card coding helped me understand the structure of coding systems like EBCDIC and ASCII. That in turn helped me to appreciate systems like DBCS and UCS--not to mention being able to derive easily memorized wifi passwords--well, they are easy for me to remember anyway!
I really hope that devices like the Raspberry Pi, which we blogged about earlier, will help more people get involved in the fundamentals again. That reminds me--we just got our notification that we can order ours--must remember to do that.
Connect With Us: