IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Pish.

Run reporting tool called Report Maker against GreatPlains/Btrieve. Early iteration required nobody else be in the system, before Brequest was in use.

Export 123 spreadsheet. Break out 10-key, add up a bunch of shit.

Type added-up new shit into a new 123 spreadsheet. Also, write keyboard macro to re-enter new shit into Great Plains in a different company.

Run Report Maker report against the same data in the new Great Plains company, extracting some summary stuff that Great Plains generates. Enter into YAN 123 sheet.

Manually combine the original 123 sheet from above with the latest 123 spreadsheet. Put into a new sheet. Also break out 10-key to add some stuff up.

Rinse, repeat.

During the attempted migration to SBT, the management fuckwit in charge of this nightmare fought hard against getting rid of it, because she wouldn't have needed so many serfs in her fiefdom.

Side story: the serf who ran the keyboard macro would spend 10 minutes setting it up, then stare and drool for 2 hours while it ran. She just had the macro bit and the GP client on her box, and the real work was one on the Netware server with Btrieve. Since it took 2 hours, the management fuckwits decided that she needed a Pentium. We fought back for more hardware for the Netware box, but were overruled. The Pentium submitted requests faster than they could be processed, so we got reports every day that the computer would "hang."
Also, Big Major Fucking Crisis was that the speaker was too loud and the beeps stopped the other serfs from "working."

We spent about a week timing stuff, and showed that what used to take 2 hours now took around 75 minutes. Every time. Logic and data being futile though, we were told that we had misallocated resources in buying her an ineffective computer, and were told to put the original 486 back because it was "faster" because it didn't "hang."

4 weeks later, I had jumped ship, and so had my boss. Later they found out that we actually had _done_ a bunch of stuff that we hadn't had time to automate and were therefore doing by hand, and I made more in contract fees in about 3 months than my yearly salary had been. They also added like 6 more keypounders because, amazingly, the above system (and the others like it) didn't scale very well.

I googled for this company awhile ago, and found a resume of a guy who had taken them from Btrieve and Access(reporting system) and Foxpro (SBT) to SQL server. Another guy took them from Informix back to Access. I don't know how they got to Informix, but i'm assuming that the idea was that a new server would fix all their fucked up processes.

Oh another thought--we did an ISO 900? type of attempted re-engineering. Everybody had to write mission statements. Inventory, which was complicated, was to be handled like this: "Warehouse employee unloads incoming pallets. Enters into computer. Computer takes care of the rest." That was _spec_.

(Think story is topped!)
FAQ! We're scrod!
New Okay, try this one.
Legacy data in Clipper. Clipper program written to extract report data to 1-2-3 spreadsheets one period at time. RPG program written involving a single table that contains the columns to store the names of four of the 1-2-3 spreadsheets. User of RPG program populates the four columns with 1-2-3 spreadsheet names. 400 then issues an RPC call to launch MS Excel and load a workbook with an "Auto_Open" macro. The XL macro connects via ADO to the table populated by the RPG program to get the names of the 1-2-3 spreadsheets to "update" (i.e. mangle the numbers in them). Then the XL macro does a "save as webpage..." and writes the files back to a share on the 400. The XL macro then issues an RPC call back to the 400, calling another RPG program that ftp's the XL generated XML over to the intranet server sitting right beside the machine running the XL macro.

Lesson: "See, the 400 is an integral part of what we do."

Back at ya ;0)
bcnu,
Mikem
New I can beat that, but
I'll have to dig out old system flow charts. I was a consultant in a "body shop" (for the unwashed, body shop is a term used to refer to a company that rented out my services, sortta like a pimp...) and on the bench. I was asked to review the payroll proceedures. I don't recall all the details, but I remember identifying 5 (FIVE) places where the same time data was being input prior to the payroll be generated. Shortly after the analysis, I was released...
New umm...yeah...
that's a mess. My stupid process was more drone-based than silicon-based--that was a Good Thing for me, cause they could yell at each other about whose 10-key skills weren't up to standard, rather than making me troubleshoot rube golberg computing.

So, I can't beat _that_ contraption.
FAQ! We're scrod!
     This is getting hilarious. - (mmoffitt) - (10)
         Umm, really? - (drewk) - (1)
             I was just relaying what I'd been told. - (mmoffitt)
         Send that one into Shark Tank. -NT - (admin)
         no scroll? - (cforde)
         Pish. - (rickw) - (3)
             Okay, try this one. - (mmoffitt) - (2)
                 I can beat that, but - (jbrabeck)
                 umm...yeah... - (rickw)
         You - (Ashton) - (1)
             Ahh, to be the fly on the wall for - (Arkadiy)

Be still, my beating heart.
63 ms