While I was on my vacation, they installed a new IBM i model M25 at work for development.
It’s quite nice … and significantly faster than the previous 820 we had.
It reminds me of my last job … when we upgraded from a D35 to one of the new “RISC” systems (they had just come out). After the upgrade was complete (long and very painful process, due to a vendor lying to us), I was getting panicked reports from users about their important jobs ending abnormally.
When we were running the D35, reports and various processes took a very long time to complete. If the user received a ‘Job 000123/USERID/JOBNAME completed normally on 03/02/09 at 09:49:22.’ message too soon after they submitted the job, they knew it had failed.
Well, because the new system was so much faster than the old system AND the problems we had during the upgrade, they were assuming that their jobs had failed.
I asked them to check the output of their jobs to see if everything looked right. Oddly enough, everything did look fine. I took 2 or 3 similar calls from each department before the word got out that the system was going to perform a lot better than it used to.
None the less, one VP insisted that I investigate why things were finishing so much faster than they used to. It took about 20 minutes for my boss and I to explain to him that this is exactly what we paid all that money to IBM for.
‘one VP insisted that I investigate why things were finishing so much faster than they used to. It took about 20 minutes for my boss and I to explain to him that this is exactly what we paid all that money to IBM for.’
Classic.
NICE!!! Way to go users…
I would be ROTFL if it wasn’t for the fact that I have had to explain the same thing to people over the years. The truth is always the most funny.
Another performance related story … WAY (way way) back when I was working on the S/36 … I was asked by a client to see if I could improve the performance of a specific report … the report was run monthly and took 36-48 hours to run. It wasn’t a complex report, but was very important.
I started looking at the program and quickly determined that there was NO reason it should run so slowly. I then looked at the OCL that invoked the program.
On the ‘// FILE’ statements, I noticed some IBLOCK & DBLOCK keywords. The IBLOCK keyword controlled how much of the index was loaded on each read and the DBLOCK keyword controlled how many data records were loaded on each read.
Well, for the file was read sequentially, the DBLOCK was small and the IBLOCK was huge … for the indexed files that were read to pick up information about the sequential file records, the IBLOCK was tiny and the DBLOCK huge.
Thus, the sequential file was loaded into memory one record at a time but a huge portion of it’s index was loaded (which wasn’t used). Additionally, for each CHAIN done in the program, a huge number of data records were read (most of which were not used). This wasted an incredible amount of time.
So, without changing ONE line of code in the actual report program … I modified the IBLOCK & DBLOCK statements to be more logical and re-ran the report. It finished in 30 minutes.
I gave it to the end user … and they were quite skeptical. I had to spend the next 3 days proving that the report was still accurate.