Get to know some of our talented authors featured in our author spotlights. You can see interviews, detailed biographies, and book summaries of some of the best in the industry.
KRANZ: My first exposure to the IBM midrange was as a night operator on the System/34, then later on I moved up to the System/38 and the programming side of the shop. When the AS/400 debuted in 1988 I made the move and never looked back. I’ve been both an in-house employee and a contractor; I prefer contracting because it allows me to see the best and worst of dozens of companies’ systems and processes. When you see what works and what doesn’t you make better design decisions for your clients
When you work hard you also play hard. My wife and I recently completed our Rescue Diver certifications and we’re working our way towards our goal of Dive Instructors. There are no pagers or terminals at 60 feet and the only interfaces you have to deal with are your regulator and the 180lb lingcod swimming nearby.
KRANZ: I’ve traveled around the country teaching AS/400 classes for six years, and one fact keeps emerging: Being proficient in one technical discipline in no way guarantees proficiency or even aptitude in another discipline. The best UNIX COBOL expert may not be your best choice for an AS/400 RPG/IV coder. Identifying who has the best skillset for the position is critical in keeping your shop moving forward with its existing and new technology. I was thrilled to be able to write the AS/400 questions which help rate all of the midrangers in the market.
KRANZ: The best part about writing the questions was realizing the depth of knowledge you had to have to be a competent developer. When I would write a question and think “What do I need to know to answer it?” I uncovered two or three more questions that needed to be asked first, like peeling an onion, to get to the core competency.
KRANZ: I was tapped by an AS/400 training firm to write their RPG/400 classes, so I developed three courses for them and taught them around the country. The technical writing came as a natural second step from teaching the courses.
KRANZ: I read all of the AS/400 and iSeries manuals when a new operating system release comes out. The “What’s New this Release” gives overviews of the new features, and I make a point to try each one and see where it’s useful. I also read the industry magazines, subscribe to list servers, and spend a lot of time with Seattle’s iSeries User Group, of which I am past-president.
KRANZ: The AS/400 and iSeries will be around for a long time, due mainly to its remarkable stability and versatility. Many companies have tried to convert from the AS/400 to another platform, only to return after a failed conversion or 6 months later because the new platform turned out to be too labor- and cash-intensive, and unstable. The iSeries will continue to evolve into a stable Internet platform, along with the tools to build complex systems quickly and efficiently.
I would like to see IBM make small-end iSeries boxes available on-the-cheap to budding development firms, to increase the number of applications available for sale to the public. In my opinion the best way to build demand for the iSeries is to have a larger group of software applications available for use, which will in turn drive demand for the hardware.
KRANZ:In the past three years I’ve interviewed over sixty candidates for various positions, and hired about twelve. The best way I’ve found to determine the best candidate is by a technical screening, and ReviewNet has the best range of tests for any skillset. Most shops today require a developer or technician to be skilled in multiple disciplines, such as SQL administration and Network management, or iSeries development and MQ-series protocols. ReviewNet allows me to test a candidate for the knowledge I need him or her to have to accomplish our goals. As an IT manager I also don’t have to be conversant in all of the technologies I need to hire; I can rely on ReviewNet to rate the candidates for me and show me which ones are worth pursuing further.
KRANZ: In the past three years I’ve interviewed over sixty candidates for various positions, and hired about twelve. The best way I’ve found to determine the best candidate is by a technical screening, and ReviewNet has the best range of tests for any skillset. Most shops today require a developer or technician to be skilled in multiple disciplines, such as SQL administration and Network management, or iSeries development and MQ-series protocols. ReviewNet allows me to test a candidate for the knowledge I need him or her to have to accomplish our goals. As an IT manager I also don’t have to be conversant in all of the technologies I need to hire; I can rely on ReviewNet to rate the candidates for me and show me which ones are worth pursuing further.
KRANZ: The talent pool in the iSeries is not growing, so some shops have resorted to the philosophy of “a bad body is better than no body at all”. My ReviewNet test on RPG/xx looks for those design and programming skills absolutely necessary to develop an efficient, well-designed, maintainable program. Spaghetti-coders will fail because the questions are geared towards those who are structured, know the underlying features on the system, and understand how to write code you can post on the wall for others to see.
KRANZ: Being exposed to the nuances of others’ bad programming, at 2:00am when no one is available, gives you a clear understanding why developers have a duty to create bulletproof code. The system operators and on-call support staff are the ones who usually lose sleep because the programs were written poorly, and not the one who wrote it.
I’ve met both the best and worst developers in the business. What distinguishes them is their skill in manipulating an iSeries to get the job done fast, efficiently, and with code that is both readable and maintainable. The top developers use the best features of the system to their advantage; the worst use the most arcane functions to cause the most undesirable results. To wit:
A developer (I’ll be nice) had to process Order Details in a nightly job. The program would fetch the Order Header and, if not found, somehow indicate there was a problem with that one order. The most reasonable way to do this would be to print an error line on a report and go on to the next Order Detail. That was too easy. When the Order Header was not found, he loaded a numeric field called “BOMB” with the value 0. Then he executed the line “BOMB DIV BOMB = BOMB”. A divide-by-zero caused the program to explode without warning, notify the operator, who would then page the on-call support who would have to dial in and figure out why the program errored on a divide-by-zero, copy the bad Order Detail records out, restart the job so it didn’t re-process the already-read Order Details, and then try to go back to sleep. When I asked him about why he coded it that way he said “Hey, why not? I don’t get called”.
This is why I use ReviewNet.
|
