Reinventing the wheel

[nycsusan@hotmail.com]

Reinventing the wheel

By multiple environments, I meant multiple parallel dev & qa environments. Ours had to handle checking object down to dev in the "A" environment, or "B", or "C", etc. Also, checking up into QA "A", QA "B", QA "C", and back down to Dev again. Yours sounds like one vertical path to production. Ours had 12 paths (environments) with multiple levels (dev, sys test, QA) leading to production. And don't forget, it had to handle distributing the objects to different production machines, and that varied from one release to another. Are you still thinking this is something easy that you could code in a week?

[David Abramowitz]

Reinventing the wheel

This is too easy, and far too common, and it's done by people who should know better e.g. American Software, Inc. (ASI) uses its own algorithm to compile COBOL programs. Any COBOL moidifications made by an ASI customer can not use the COBOL compiler, or SDA for desigining screens. - All code entered must be shifted over one byte to the right to account for a seven digit sequence code. The code is then fed into a pre compiler, which in turn feeds the code into the COBOL, and DDS compilers. This also means that you can not use the SEU syntax checking facilitiies. Lawson Software uses it's own screen designer, and code generator. This not only bypasses SDA, and RPG, but makes their use impossible. My very first position at McCormick and Dodge introduced me to a program that read every record in a file just to count the records. The experienced programmers were blissfully unaware of the S/34 OCL statement that went: ?F'A,filename'? to get the number of records. A mainframe programmer I know wrote a "snap" dump COBOL routine, and physically attached the code to every COBOL program in the shop, just in case something went wrong. The code was huge and slowed down everything. I had to fight tooth and nail just to get him to look at a native AS/400 dump, in order to show him that the routine was superflous. That's just my immediate recollection. If I think about it, I'm sure I can come up with a lot more. Dave

[David Abramowitz]

Reinventing the wheel

Sue Behrens wrote: I worked in a place that wrote their own change control software instead of using the native one on AS/400 or Implementer Sue, this may be necessary. There is a PRPQ change management (of a sort) add-on to PDM, but it must be purchased. Products like Implementer, Turnover, etc. must also be purchased. The decision to get a package or develop in-house is (to me) an either/or situation, rather than redundancy. Change Management Author Dave

[T.Holt]

Reinventing the wheel

Are you still thinking this is something easy that you could code in a week? Maybe Bret's package couldn't handle this sort of stuff, but then again, maybe it didn't need to. Maybe one good reason to reinvent the wheel is because what's on the market it more than what's needed.

[David Abramowitz]

Reinventing the wheel

Sounds like management material to me! :-) Dave

[Guest.Visitor]

Reinventing the wheel

Susan, Not with the level of environments I dont. : Yes, ours is strictly vertical. We have the TEST for development, the TEST PRODUCTION where things go for "live testing" prior to production and the PRODUCTION environment which is just (as we know) a fancy name for another library list. -bret

[T.Holt]

Reinventing the wheel

That's just my immediate recollection. If I think about it, I'm sure I can come up with a lot more. Those are all good ones. I especially like the one about ?F'A,filename'?. Every once in a while, someone contacts MC wanting us to publish a utility he's written that drops all logical files and rebuilds them when you revise a physical file's DDS. We always ask, "Have you looked at CHGPF lately?"

[nycsusan@hotmail.com]

Reinventing the wheel

Maybe one good reason to reinvent the wheel is because what's on the market it more than what's needed. I agree with that 100%, Ted. Bret asked why writing a change control application was so difficult. I pointed out that if you need to handle the situation such as the one that I outlined, it IS difficult code to write. Here's a question for you? Is it really reinventing the wheel if whatever exists on the market doesn't suit your needs? That can go both ways - either all the products are overkill for your needs, or they are insufficient for your needs. If there is nothing "just right" out there, then how can it be deemed reinventing the wheel? It seems fairly subjective as to how much difference is enough to label it an innovation, rather then a duplication. I am trying to think back for examples, and I am (so far) only recalling examples of people writing utilities that were BETTER than what was available, not wasted effort at all. This is a good topic to think about on my drive home tonight, while stuck in traffic!

[David Abramowitz]

Reinventing the wheel

I've thought about it a bit, and have come up with a common thread. Every time I've been in an AS/400 shop that used to be a mainframe shop, and is still staffed by mainframe programmers, I find superflous code, and even entirely redundant fuctions. This is not the programmers fault. If they had proper AS/400 training, (or even any AS/400 training), they could have saved themselves a gazillion person-hours by using existing facilities, rather than reinventing the wheel. Dave

[Guest.Visitor]

Reinventing the wheel

Ted, Good point and thanks for taking some heat off me. It's true my package does not do this and does not need to. But mostly, it's because I did not really think of it. This is a really simple concept. I wrote the LIBRARIAN system to handle checking in and out of source code, compile to test or production and control what user ID is able compile into production. One thing I forgot to mention is that it also creates a copy of the BEFORE version of the production source code being compiled, if a copy exists. It uses the source name as the key and writes it to a 112 byte file. There is an option to browse this file and remove the source code entries. I spent more time on making it accessible to only one person at a time and who can compile into production than I did anything else. The rest is just plain old subfiles. -bret

[T.Holt]

Reinventing the wheel

Here's a question for you? Is it really reinventing the wheel if whatever exists on the market doesn't suit your needs? No, I don't think it is, but I hadn't thought about it until you raised the point. What an interesting question. But that place that did their own EDI translation was doing a lot of different transactions with a bunch of trading partners. It seemed madness to me for them not to license a package. EDI changes, as new releases come out to replace old ones and the big-guy trading partners force the little guys to change with the times, even though the little guy doesn't benefit. The EDI software vendors have a roomfull of people keeping up with all this stuff, doing all the programming changes, etc. The little company I knew couldn't have thrown that amount of resources at the problem. They were doing what the EDI software vendors were doing, but not as well.

[Guest.Visitor]

Reinventing the wheel

Ted, This is a good point. Yes I do develop code for our system if there is not something on the market that will do. Whether it be too costly, too weak or overkill. Market drives our purchases. These nice things are driven by priorities. We were expecting some consultants who were coming in for a month or so and we wanted to control their access. It was less costly to develop inhouse as I was finished with the big project (at the time) and the cost involved to purchase a package which would be used to secure consultants was just too much money for the benefit. I spent the evening (at home) and drew up my files, how I wanted it to work, and some simple screens. I showed them to my boss who said to work on it in my spare time. Not that I have a lot of spare time, but before lunch and after hours it grew into a decent (for our use) product. I have talked with him about submitting the code as a program of the month to Midrange. -bret

[nycsusan@hotmail.com]

Reinventing the wheel

The difference between "innovation" and "duplication" is very subjective. I used to work with a guy who constantly wrote utilities that built on (improved upon, IMO) existing commands. A simple example of option 14 Compile, from PDM. He added a little command, called Q, that automatically compiled the program into QTEMP, with a XREF, so you didn't have to go in and change the settings by hand every time. Some people may say it's not that much bother to prompt the compile option and change the settings, and it's revinventing the wheel. I say it was a nifty little short cut when I just wanted a program listing with an xref, but I didn't really want the compiled object to go anyplace except for QTEMP. There's another scenario to consider. What if all of the existing products on the market are just too expensive? Let's go with the Change Control Software example ... let's say some techie guru type wrote a complete change control application that did everything that a package like Implementer does. Let's assumme all the bells and whistles are needed, and let's assume the guru wrote flawless code. If the shop cannot afford to buy something like Implementer, is it reinventing the wheel if someone has to duplicate the functionality for financial reasons? Hmmmm.

[J.Wells]

Reinventing the wheel

"He added a little command, called Q,......." Thats what I call working smarter, not harder! I too like to use these types of 'shortcuts'. Among the ones I use all the time are 'IM' - Runs the APLUS job implosion, EX - APLUS explosion, FU - APLUS files where used (no comments from the peanut gallery (yes, you Bret!)), SD - start debug, DO - DSPOBJD, SJ - SBMJOB, etc...... What are other peoples favorites? Has MC ever compiled and printed a list of favorites?? BTW, I suppose I did reinvent the wheel because I think APLUS supplies a file with similar shortcuts. Also, Susan, compiling to QTEMP is a nifty idea. I have always used the compile option of *NOGEN. Is there any advantage to either? Joe

[nycsusan@hotmail.com]

Reinventing the wheel

Also, Susan, compiling to QTEMP is a nifty idea. I have always used the compile option of *NOGEN. Is there any advantage to either? Ha! Good question Joe! Early on, I was told about QTEMP, so that's what I use. I never bothered to look at *NOGEN. Right now I am in a class (well, on a surfing break obviously ... ) and I cannot look up *NOGEN from here. I am guessing it means that the compiled object will NOT be created? If so, does the SPLF listing still get printed? If your way gets you a compiled listing without generating a compiled object, then I'd guess that your way makes more sense. Perhaps this *NOGEN thingy wasn't available when my techie guru guy friend learned his QTEMP trick?