Thoroughly Modern: Taking The Pulse Of IBM i Developers

January 22, 2020 Timothy Prickett Morgan

It takes someone who has experience in application development to create and sell tools that help make a developer’s job easier. We think about the tool creators, but when it comes to getting people to adopt a new technology, the technical sales team at any software company is the bridge that connects developers of tools to the developer of applications who can be helped by those tools. In this edition of Thoroughly Modern, we are talking with Stephen Flaherty, a technical engineer at Fresche Solutions, about what IBM i developers are thinking about and doing today.

Timothy Prickett Morgan: Let’s start off by having you share a little bit about yourself and your background.

Stephen Flaherty: I started RPG programming in the early 1980s, and I worked for many types of organizations in the manufacturing, retail, and software development industries. That gave me experience with RPGII, RPGIII, RPGIV, and RPG ILE. I also worked as a consultant for two companies as well during my career. This experience exposed me to many software packages, such as MAPICS, Prism, MacPac, JDA, JD Edwards, and HFA.

TPM: Can you share a bit about the activities that you were responsible for prior to Fresche?

Stephen Flaherty: I was responsible for everything RPG related, from fixing bugs to enhancement requests and working on large conversion projects (from one software package to another or upgrading a package). All of those tasks back in the day were manual efforts as far as debugging and scanning the code manually. It would take hours to scan thousands of lines of code looking for hard-coded values, looking for files where used. We had some tools available to us that were provided by the operating system. But for the most part, it was always a manual effort.

TPM: Were there any particular tasks that were a little bit more tedious than others? Things that were time consuming in the day-to-day routine?

Stephen Flaherty: If I were given a support ticket, which were either bugs or enhancement requests, I had to do the impact analysis manually with a green screen tool, hoping I didn’t miss anything such as queries, data areas, data queues, variables that are hard coded and buried deep within the source code. Many, many hours spent on that research.

Then when the coding and the unit testing was completed, I had to document the changes, which usually required drawing a flow chart by hand using Visio or ABC Flow Charter. This took many hours to accomplish, and if I made a coding change the next day or even the next week, I had to remember to go back into the file server where that flow chart resided and update that one box and key in that one arrow.

The bottom line is that IT departments are thin on resources and programmers don’t like to do documentation.

TPM: I write for a living and I wouldn’t want to do documentation, and the few times I have done code, I was annoyed that I had to do it. In any event, is this typically the process that IBM i developers still use to accomplish those tasks today or has it evolved over time?

Stephen Flaherty: I’m finding that a lot of IT shops are running legacy systems. The RPG developers have been there for 20 years to 25 years, and they do have tools, but they’re still using the things we had available to us via the operating system, such as start debug command, Find String PDM, AS400 query, IBM i query, DFU (data file utility), and then multiple commands on the IBM i, such as display file field description, display file description, display object description, display objects and work with objects.

So all of those commands coupled with those tools, you have to use a combination of them to get the answer that you’re looking for. Additionally, you could purchase software. I had exposure to Abstract Probe, Hawkeye, and DBU from Pro Data when I was programming.

TPM: What does the typical developer environment looks like today? Back in the day, people had separate systems to development and test and did not run these workloads on production systems, and for good reason. That test/dev box might be the prior generation of machine in the shop, or a smaller box that was newer. I suspect that logical partitions, which have now been around for two decades now, changed things, and cloud is changing them again.

Stephen Flaherty: The ideal architecture would have a development IBM i partition and a separate production IBM i partition/server. You want to have the source and objects on your development IBM i, and that’s where you code changes and test. You would have a change management software package that checks out source, checks in source and promotes only the object to production. You never want to have source on production box. You also don’t want to have source in two different places because soon enough someone’s going to modify that source and you’re going to have a mismatch and you’re not going to know which source goes with which object, and it’s a mess.

So that’s ideal. But I’ve been in many shops where they’ve had one IBM i partition that is running their business, which is production, but they also have a development and QA library set up in the same partition. They also have John’s library and Mary’s library and they don’t have a change management system. And they’re copying source out of production and they’re putting it into their own libraries. And then along comes programmer B and he or she checks out the same source, not knowing that it’s already checked out, and they’re both making coding changes to the same source member, and then they clobber each other when they move it back into production.

It’s so important to get to know what’s on your system: What do you have for libraries, what do you have for source files, where do they live, and procedurally, how are you making these programming changes and how are you putting objects back into production.

Modern IBM i shops are using procedures. They’re using modules. They using ILE. They’re using bound programs. They are using DDL and they’re also using RDI, IBM’s licensed product, which is the client version of the green screen, to make those coding changes, because RDI comes with a whole plethora of other functionality that 5250 emulation does not have.

TPM: When it comes to development, what kind of code are they creating? Is it monolithic stuff still, or are they doing Web services?

Stephen Flaherty: I think they’re looking at it. I haven’t run into many shops that are really doing that, but it’s brought up time and time again, and it’s a goal. Again, we go back to the resource issue, right?

TPM: So, when you were programming, it sounds like you had access to tools that in some cases automated some of the process.

Stephen Flaherty: Yes, because every shop that I worked in, they spent money on a product such as Abstract, Hawkeye, or DBU. You would still have to use the commands that are available to you from the IBM i operating system, which were very good. But again, it’s a manual effort nonetheless.

TPM: Could you give some examples of the types of time savings that the customers that you’re working with are seeing right now, as well as some of the recommendations that you’re making to help improve productivity or impact analysis?

Stephen Flaherty: Well, what’s happening is that people have, for instance, a new developer or a new contractor that starts in the department. That’s a nightmare. We would all cringe when we had to train the new guy or the new gal. The reason being is because we knew right away it was going to take our entire day for the next two weeks to babysit them and answer their questions to get them up to speed.

But if you have a good, all-encompassing application understanding and impact analysis solution, it programmatically does everything that I used to do manually. This includes the impact analysis, building the repository of all the where-used information. With a click of a mouse, I can have a flow chart done with 25, 30, 40 boxes already drawn for me. I don’t have to take the time to do that. That’s saving me days of work. And if I can give that type of information to a new person and consultant that I’m paying $150 an hour, that’s going to save me weeks of time.

TPM: If somebody wants to onboard a developer today, what is the typical process at the companies that you are working with? And what are the different approaches that you recommend to change that process?

Stephen Flaherty: Because IT departments are so thin on resources, they often don’t have the time to fully train new employees. Or maybe they don’t have a great training process. I would recommend investing in a productivity tool to quickly get developers up to speed. That helps you understand what’s on your system, such as how many programs, how many source files, how many libraries. And when you’re given a task such as a bug fix or an enhancement request, you can get the answer you’re looking for by using the tool instead of manually scanning that source code and using the commands that are supplied by the operating system.

The tool is going to you save money and time. It’s also going to ensure that, when you make a change, you’ve captured every single line of code and every single program that needs to be changed and tested. You don’t want to miss an object, a program or a line of code and then move the change to production and have it bomb at 2:00am. That’s a big disruption to the business.

TPM: Why do people choose the tools they do, and what are they trying to do with these tools?

Stephen Flaherty: I think a lot of people are creatures of habit and they’re so used to doing things a certain way. They feel comfortable with the green screen. They know how to do Find String PDM and they know how to scan the source code.

When I help clients explore application understanding solutions, I’m usually working with RPG developers and they can see exactly what I’m doing as far as making their life easier. So I’m showing them what they’re doing today manually and comparing that to what the tool can do. Once they are shown how easy it is to use, they want to do a trial. They want to use it.

I worked with an insurance company that purchased the software and we did a test to see the difference in productivity. I told one of the programmers to, “Do what you do today using the Find String PDM. Do it the old manual way to find the problem and do the impact analysis.” And then I asked another programmer who was trained on Fresche’s X-Analysis solution to do the same bug fix.

In this case it took the programmer using X-Analysis one hour to find the resolution, and it took the programmer doing it manually close to almost two and a half days to get the same result.

We all understand the time aspect when you break this down to one hour versus 20 hours. The delta is 19 hours. But consider this: At $65 loaded overhead, that equates to $1,235 saved to fix one bug. There’s an industry metric that claims 70 percent of legacy coders time is spent on application maintenance, and 30 percent of time is spent on new development. When you consider the productivity gains over the course of a week, a month or even a year, it’s easy to see that the ROI on your investment in an application understanding tool is realized very quickly.

So right there, it’s a time saver. You can get more done in your department. You can resolve more bugs, complete more enhancements, and that’s going to free you up as a developer to start learning some new stuff like PHP, Python or Java if you have the opportunity. Or maybe you can take on those projects that you’ve been putting on the back burner because you just don’t have the time to do it.

TPM: Who is the driving force behind IT projects these days, the IT department itself or the people who run the business? We hear a lot about how those walls have come down, but it is true?

Stephen Flaherty: In my conversations with IT directors, I’ve heard that modernization is coming from the top. They do want to modernize their applications, whether it’s moving from DDS to DDL, giving green screen applications a web GUI, whatever the case may be.

But their hands are tied. They don’t take the time to do the research because they don’t have the tools to give them accurate information that helps them create the roadmap that they need to get there. So that’s where I’m finding, it’s incredibly helpful to have a tool that frees up time so they can actually analyze their system and get to where they want to be fairly quickly.

TPM: As companies move into 2020, what are the top initiatives that they are looking to undertake right now?

Stephen Flaherty: They want to modernize their legacy systems because they’re out of control as far as the modification. The applications are so heavily modified that they’re becoming unsupportable. You can’t debug a program that’s 3,000 to 4,000 lines of code. So you’ve got to get your arms around the code base. What’s on your system? What code is obsolete? What isn’t being executed anymore? And then you can deal with performance issues. If you want to modernize, you going to have to do that maintenance anyway. But first you need to know what’s on your system.

And as people start leaving the company through retiring or moving on, the biggest thing I’m finding is there’s no documentation. All of that information is in the programmer’s head when they walked out the door, so now you’re left with no documentation. It’s going to take you that much longer when you have a bug fix. If you’re not familiar with the order entry program or you’re not familiar with the invoice print program, it’s going to take you a long time to fix that and programmers are scared to touch a program that they might break something else.

TPM: What can developers do today that would put them in a better position as well as ensure that the knowledge and skill embodied in their people can be preserved and leveraged, even after they leave or retire?

Stephen Flaherty: Right away I’m going to say that there’s tooling available that enables you to select objects, programs, files, flowcharts, whatever the case may be, and with a click of a mouse, you can easily document, for instance, the invoice batch run, which could be dozens of programs. And instead of climbing through the code and writing all the information down and doing that manually, the tool can document that flow chart for you. And that’s only one example that’s going to save you time.

Once your system is documented, that person can retire or can leave the organization, but you as an IT manager can feel comfortable knowing your system’s documented. Anybody new coming in should be able to read this information and hit the ground running day one.

TPM: What technologies or trends do you think developers should be watching out for in 2020?

Stephen Flaherty: I see a lot of RPG to Java. There’s a lot of talk about .NET, PHP, Python, DDL conversions from the DDS files, and of course, green screen to GUI.

If you’re a developer that has the opportunity to learn some of these new technologies, of course you would want to capitalize on that, because all of these still are connected to the IBM i, so you’re not leaving the platform. You’re going to learn a new language.

TPM: Do you have any final recommendations that you’d make for developers?

Stephen Flaherty: I would use modern tools to improve efficiency, which is going to reduce risk and time needed to manage applications, freeing developers to work on innovation.

This content is sponsored by Fresche Solutions.

Following 25 plus years of work in the IBM arena, starting with the System/38, with exposure to AS/400, iSeries, and now IBM i platforms, Stephen Flaherty has added numerous projects to his portfolio, all specializing in RPG coding. The opportunity he has had to be a part of multiple ERP packages such as JD Edwards, Mapics, PRISM, HFA, and MacPac, in addition to several electronic data interchange (EDI) packages such as Trusted Link, Inovis, and GXS, make him a great asset to the pre-sales team at Fresche Solutions for the American market. His current role as a technical engineer at Fresche enables him to ensure the best communication between sales and new and existing customers on a variety of products, helping clients transform or update their systems through individual strategies.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search