Anybody know any good reinventing-the-wheel stories? I could use a few illustrations for an article I'm writing. Here's one: I knew a place that wrote their own EDI translation software.
Unconfigured Ad Widget
Collapse
Announcement
Collapse
No announcement yet.
Reinventing the wheel
Collapse
X
-
Reinventing the wheel
Ted, Laugh all you want. I took over a shop in Oklahoma that had a /400 for a couple of years. They were still using interal files in the s/36 special environment. At the time they had Premenos EDI software that did not lend itself real well with non-externally described files. It was easier for me to write my invoices (EDI 810 documents) to a file that our trading partner accepted. It saved weeks of time and allowed me to get the staff to start migrating to a true /400 environment. Nyah, Nyah! -bret
-
Reinventing the wheel
Anybody know any good reinventing-the-wheel stories? I could use a few illustrations for an article I'm writing. Here's one: I knew a place that wrote their own EDI translation software. I worked in a place that wrote their own change control software instead of using the native one on AS/400 or Implementer. I must say, the homegrown system was a LOT easier to work with than Implementer. They "reinvented the wheel", but it was for the greater good, IMO! Also worked for a company that had it's own "dial-up" system for orders to be sent electronically to vendors. It has since been replaced by EDI. I am not sure if EDI was an option when their Dial-Up System was implemented. Other than that, I haven't seen too many instances of these ... more often, I see LOTS of people doing things manually, or "the long way", simply because they are not aware of what can be done on the AS/400 to help them. For example, I had a Tech Designer instruct me to use the mainframe Job Scheduler package ESP to initiate jobs on the AS/400 because he was not aware that th4 400 had a job scheduler of it's own. Also, I have seen people make full time careers out of sending reminder e-mails or checking status reports, when those sorts of tasks can easily be automated. In fact, I had a boss that wouldn't allow me to set up an automatic e-mail reminder precisely because it would leave an employee with nothing to do! Sad, but true.
Comment
-
Reinventing the wheel
It aint sad if you were the guy/gal who has nothing to do and now have no job. This person held the job title and was getting paid the salary of a Systems Analyst. Because of the Y2K salary inflation, she was making just a few grand less than the Technical Leaders in the group. Because she did nothing, and was responsible only for mindless clerical tasks, she was never called at home in the middle of the night, and she was never given responsibility because she couldn't code her way out of a paper bag. That's fine. But she was getting paid to be a Systems Analyst and her primary job responsibility was to CODE! If she couldn't handle coding, she should have been put into a job she could do. The manager didn't want to deal with the problem, so he allowed her to do "busy work" all day at the salary of a programmer. This was far WORSE than "reinventing the wheel", it's preventing the wheel from being invented! This situation destroyed that group because morale went South. This person went for TWO YEARS as a Systems Analyst and still did not know the difference between source and a compiled executable object.
Comment
-
Reinventing the wheel
Your shop was not the only one that decided to write there own change management system. The previous place I worked at developed and sold Implementer and other products and we faced this all the time. Most places gave up after a year or so because of cost, or because the person who wrote the software was no longer there. At that point they decided to buy. The best ones are shops that would rather develope solutions instead of paying a few dollars for a complete solution and support. It's OK to reinvent the wheel, as long as it's better, look at Microsoft (OK, OK, maybe not better!)
Comment
-
Reinventing the wheel
David, That's one thing I don't understand. I wrote a very simple change management system for the company I work for now. It enforces check in, check out policies. It requires someone with Implementor authority to move code/objects into production. It uses job descriptions to keep compiles into production. New source can be created from here, comments, descriptions, programmers notes are stored in files vieable from here. It does not allow calls to view them from SEU, as I use IBMs. It does handle, PF, LF, DSPF, PRTF, RPG, RPGLE, CLP in calling editor and compiler. It took about a week to write and a month of part time debugging. I don't understand the concept of hard in this. It's really a simple procedure when you break it down into specific and separate functions. -bret
Comment
-
Reinventing the wheel
That's one thing I don't understand. I wrote a very simple change management system for the company I work for now. It enforces check in, check out policies. It requires someone with Implementor authority to move code/objects into production. It uses job descriptions to keep compiles into production. Did your system support multiple development environments (we had 12)? Did you system keep tabs on concurrent development and inform an anaylst WHO has the object locked? Did your system ship objects to remote AS/400's (we had 4)?
Comment
-
Reinventing the wheel
Bob, If this was the same place, you'd know it. No joke, this woman was so clueless, she actually scanned our QCBLSRC file for "FILLER" because my manager instructed her to search for ALL of the fields in XYZ file. She thought FILLER was a real field! Even when the scan produced a 250+ page report of hits on FILLER, she STILL didn't catch on that maybe she was missing something! But that wasn't the end of this story. She submitted a buttload of these worthless scans, all at once, and that brought the CPU to it's knees. This killed online response time. (That's how we noticed what she was doing ... when response time got really bad, we went to see what was hogging the CPU!. So, because response time was suddenly very poor, she calls the data center to report it as a problem, then goes home for the night. Basically, she opened an Incident Report on herself! Nonsense like this went on for TWO YEARS! P.S. Guess where she ended up? Yup, you got it! She went to Human Resources to be one of the onsite college recruiters for this company.
Comment
-
Reinventing the wheel
Susan Berhens wrote: "Did your system support multiple development environments (we had 12)? Did you system keep tabs on concurrent development and inform an anaylst WHO has the object locked? Did your system ship objects to remote AS/400's (we had 4)? " It handles three environments. Test, Production-Test and Production. I assume one set of test files for programmers but do support different library lists between many programmers. It does tell the person checking out a source, if it is already checked out and by whom. Nope. Just one AS/400 connected via WAN. All source and files resided in a local area. -bret
Comment
Comment