March 23, 2006
Talkback: Your hands-on hacks
Filed under:
Talkback
In Hands-on hacks get the job done we highlight some brilliant IT workarounds from the rank-and-file. Share your heroic hacks below.
Posted by Mike Barton on March 23, 2006 05:34 PM
| TrackBack (0)
Share your thoughts by clicking on the Your hands-on hacks link above, and then sit back and enjoy your twenty minutes of online fame as an IT hero.
OK, this hack goes way back to the early 70's.
We had a Burroughs mainframe with several tape drives. One of the drives failed and was needed for a large tape sort project (remember disk was scarce and expensive). A large resistor in the drive had failed and a replacement would take two days. This resistor was rated at 50 watts and handled a lot of current as it dealt with a motor control and provided braking current to the motor.
We were desperate so we used a 100 watt light bulb as it had very close to the correct resistance. Just to make it more interesting the light bulb was red in color. The light was wired into the circuit using cables with alligator clips. It worked and worked well.
But everytime that the drive was accessed there was this bright red light from the back of the cabinet. During some phases of the sort process we had a disco effect.
When the real part arrived I sort of missed the flashing red light.
The company I work for is very internet dependant. Most of our systems are web based and hosted by providors.
Our upstream internet providor had a fire in the one of there facilities. The one that provides our internet access.
After the start of the panic phone calls, I set up a spare laptop as a router with a celular broad band card. Placed in place of our internet router. The access was not what it was on our T1, but it got us back on line.
We ran under this set up for 2 days successfully unitil our providor could move our services to another location.
Also from the early 1970s we had a program that was taking 15 hours a night to run on an IBM 370 computer. It used fourteen reels of 9-track tape as input at 9600 bytes of information per inch of tape and the time it took and night to batch-process the data was putting our daytime online job at risk. I was given the task of "fixing it."
I considered the job's tasks, and the fact it was written in COBOL. Without even looking at the code I theorized that there was nothing in the job that should keep an IBM mainframe of that time busy for 15 hours, and therefore it had to be something really stupid, done by someone who did not know how a computer physically works.
I looked at the output of the online job that created the tapes and realized that the programmer was outputting 80 byte blocks on a start-stop tape drive (think 1/20" of data and 3/4 inch of inter-block gap, and the time to start and stop for each block written and read), and that a simple blocking factor of 100 to create an 8000 byte block might solve the problem.
For a week I was busy with other problems. Finally a "panic meeting" was going on and my boss sent me in to settle the problem. On the way to
the meeting I punched out one Job Control Language (JCL) card that overrode the blocking factor on the ONLINE job, which the offline job picked up automatically by reading the tape header.
The offline job then went to taking only five hours in one night, and only using one tape of input, giving much more room to grow in the
future.
We rely on our Internet service for doing EDI and communicating with our customers and suppliers as well as our company VPN's. We are not a large company so we don't have redundant services for things like Internet services. One day our Internet just stopped working. Long story short, our ISP owed their service providers more money than they could come up with and the plug was pulled on our frame relay. Help from our bankrupt ISP was non-existent and the main service provider was going to take at least 2 months to get us up and running again, not an option. With help from our parent company, we set up a wireless network between our company and an employee that lived about 5 blocks away using dishes and spare equipment scrounged from various helpful people. We borrowed his high speed cable Internet service until we could come up with a permanent solution. There was a railroad track with frequent trains and trees in between the dishes, just barely line of sight, but it kept us going for almost a week until we could get set up with a completely new service. A redundant service provider is now being seriously considered.
Sir,
Page 32 Infoworld 05.29.06 Virtualization helps swing an exchange upgrade? impels me to ask: why is a Virtual Machine not routinely used everywhere, and for many purposes? It permits two identical (as well as many different) operating systems on the same machine, usable in so many ways.
The simplest example I can think of is one of today's potential problems of the upgrade to IE 7. We all know that some apps will die in this environment, but no one is sure of all potential application killers. Answer: simply install (my choice VM Ware) and have a second copy of ones complete operating system running on-line in the virtual machine during any patches and/or upgrades. Absolutely nothing can reach and disturb your real base OS system through error this way – far better protection than backups.
The following is for any un-initiated. You first install VM Ware as an application within whatever operating system you have (mine is Win XP Pro). VMW now allows you to format and install additional OS's as though they were going into bare hard drives. You may now copy your entire OS into one of these virtual machines, and run it. One can easily switch between any of these various real and virtual machines.
I am an old-old-old IT engineer who (in my day) had to be proficient in design, hardware, software, installation and startup. Now I recognize that I have fallen way behind the field in knowledge and need safety nets. (My first DIGITAL computer was oversight of 104 an/fst2 early warning system sites each containing dual 38 cabinets of vacuum tubes). So, my home network of two computers (mine & wife's) is set up with each containing two identical WinXP operating systems using VM Ware, normally running in the virtual machine's OS.
I have been doing this for a long time but got careless about normally running in my virtual copy and now have regrets. A recent automatic upgrade by MS did something to my computer which now continuously reports (entirely falsely) that I may have a pirated copy of XP. Her machine still runs along quietly but mine has this (so far) apparently incurable problem because I left it running overnight in the base OS.
Richard E, Law
5575 Sundance
Las Vegas, NV 89110
702-438-5305
DickLaw@juno.com
I had a client using a medical office management system which worked fine. Except when they tried to send via modem the Medicare file so that they would be paid. Medicare kept rejecting the file as having an invalid header record. The header information was hard coded into the medical office managment system and could not be changed by the office or myself as it was a proprietary product.
To the rescue came GWBASIC.EXE. Once I talked to the medicare people and figured that there were two bytes in the header that were incorrect. They were at bytes 128 and 129 of the first line of the file. (called the header record)
Piece of cake for an old basic programmer
in Basic, opened the file for random access with a length of 1 and counted down to 128 and performed a get of byte 128, changed it and them put it back. did the same with bytes 129.
All was well with the Medicare people. I then embelished the code a bit and compiled it under quickbasic 6.0, putting a few checks to make sure that most anyone could change the file.
Even the consultants that specialized in the Medical office manager product asked for copies of the program to help their clients.
Just goes to show that DOS is not dead and sometimes a simple solution to a complicated problem is the best.
GWBASIC.EXE even works in a CMD window under VISTA.
Here's "vendor can't get it to work so I did"..
I was working for a midsize bank and supporting the collections department. They're just bought a new "fully automated" collections system. Only thing was their "fully" automated collections app took 2 hours to crunch numbers in the morning. (And that was on a new-for-the-time 733mhz PIII!) After a few months, the boss was coming in early to start it running so it would be ready with reports when everyone else got in. She figured she could do her paperwork during that time. She ended up smoking cigarettes waiting for it to finish.
A solid year of my vendor telling me "send me this file", a day later "apply this patch" or "change this parameter", "No other bank with your same datacenter provider has the same problems", etc etc and finally the personal credit department got mad and so did I.
I wrote a (long) batch file with lots of FOR commands - and told her to launch it before she left for the day and lock the workstation. A few hours of coding and two days of debugging when it didn't work correctly passed - and we had her coming in at 9am instead of 7am with everyone ready to roll. I didn't want to resort to this but it was one of my tasks to get done however I got it done - and I was getting minimal help from the vendor at best.
This thing sat there and repeatedly checked the minute of the day. If it hadn't changed, the batch file looped. If it did change, it checked for the first of two needed files shared out of a datawarehouse app - if it wasn't there, it looped. If it was, it checked for the second. If that wasn't there, we looped. If it was, it ran the collections program with the parameters to import everything, then deleted the files and exited.
Did this thing eat a load of CPU power? Yup. Did we need it when it was eating it up? Nope. Network bandwith? Killed it? Check. Need it at that time of day? No. Boss happy? Yes. Pers Credit boss happy? Very much yes.
Vendor happy? Nope - I sent him a copy of the code and told him he was "free to use it for other clients since his appears not to work". Cost: UPS to make sure workstation didn't go down. Benefits: Many man-hours, two bosses off my back!
On an ancient PC, in a realtime control environment, I'd run out of timers and timer interrupts. The solution was a bent paperclip.
How?
Well, I used the paperclip to connect the serial port 'transmit' line to the 'recieve' line. Then, I wrote a serial port interrupt service function that read a byte from the serial port then immediately sent a byte out. At 9600 baud it took about 1/1000th second for the transmitted character to arrive back at the port (after travelling through the paperclip) - which was just about perfect for my needs. Varying the baud rate let me adjust the interrupt frequency.
When the product shipped, it came with a $10 RS232 'dongle' that did the identical job to the paperclip at about 10,000 times the price!
For more than 14 years, my work as an Independent Consultant performing HRIS implementations is providing services both during and after the installation. Originally, I was only providing implementation service but as the system became progressively stronger, my assignments became increasing longer. Not due to the complexity of the implementation, but due to the fit/gap analysis as well as to the ''missing parts'' that would not keep the HRIS system(s) operating smoothly. Most of my work during post-implementation now focuses on two areas - data retrieval for reporting purposes (data mining, business intelligence, HR analytics) and interfaces.
The first area - data retrieval - came about when a client had two vendors running the HRIS environment. The HR, compensation and benefit data were entered into one system while some of the same information was entered into the Payroll system. Several reports that were retrieved on the old system on a frequent basis now had to be retrieved from both systems. The results? The users of the reports ended up requesting the information on two separate files so they could mesh it together in Excel and/or Word. I was able to propose and convince that the information from both systems could be centralized in MS Access and then emailed to the users in a very economical fashion (not to mention with a lower rate of errors due to the manual messaging of the data from the two separate files). This is now a billable application I can provide to HRIS departments using multiple-systems.
The second area - interfaces - resulted from a vendor that delivered a hosted payroll system without the time and labor interface (yes, they were billed for the interface but you've got it - they wanted to charge a hefty sum for the installation of a new one in spite of that fact). I was able to create a program within a week that would retrieve the same data from their system and format the data that would be accepted by the new time keeping system. The cost for installing the new interface was beyond $75,000 - mine was one week's pay (at an independent consultant's rate, of course). Word has it that the work-around works better and more efficiently than the original interface, based upon anonymous resources within the payroll vendor.
One more hack experience - another payroll hosted client discovered that the patches applied to their payroll system changed the interface file format drastically. The resulting impact - the time keeping system would need to be changed as well (and no, the payroll vendor was not going to pay for this). Taking the same program noted above and making some minor tweaks, within 30 minutes the client had a new interface up and running. The savings? About the same as that noted above as well.
Now the majority of my HRIS post-implementation work comes from data retrieval and interface needs.
Les O'Brien
Principal Consultant, CGServices USA
www.cgservices.com
Disaster Recovery Plan was on the intranet for a few years. One document that was key to communications had a password. When it was needed, no one knew the PW! Had to call Ex-employee from two years back who did remember it.