VIRTUAL PANEL DISCUSSION

All right, great. Why don’t we go ahead and get started. Thank you all so much for coming to the webinar today. This is actually a different kind of a webinar for us. And we’re really excited about the new format because we actually have Timothy Prickett-Morgan here who is the head honcho over at IT Jungle, my favorite IBM i publication. So welcome Timothy and thank you. And what I’m excited about is we have a couple of IBM i end users here to have a panel discussion that Tim’s gonna moderate so that you can actually hear from end users some of the things that they’re doing to modernize their existing IBM i applications. So rather than just talking about products or solutions, we’re gonna have them talk about sort of the challenges they face and some of the things that they’ve done. Now, we actually recorded the initial panel discussion just to make sure we didn’t run into any technical glitches. So I’m gonna go ahead and start by playing the recording, but they are all here and they’re gonna be ready to answer your questions at the end of the recording. So if you have any questions, please enter them in the Q&A section. So you can go to the Q&A button and enter any questions that you might have for our end users. So with that, I’m gonna go ahead and start the playback of the panel discussion. 

Welcome to Hear It Straight from the Users, Real Stories of IBM i innovation. I’m Timothy Prickett-Morton and I’m co-editor of the 400, a publication at IT Jungle that covers the IBM i platform. Thank you so very much for joining us. Joining us today for a conversation about APIs is Harlan Williams of CDR and Tim Love of Wright Flood and Dan Magid of Eradani. So let’s start by having everybody talk a little bit about themselves. Harlan, let’s start with you. Tell us about yourself and your company. You bet. My company is Creative Data Research. We’ve been in business since around 1978. We’re an IBM i business partner. We work in the convenience distribution area. So our customers are distributors who sell to convenience stores. It’s a niche industry. A lot of governmental regulations and manufacturers involved, which opens up an opportunity for a company like us to be in business and stay that way. We have roughly 100 customers spread nationwide and very happy. We love the IBM i. We feel like it’s a good, stable, robust platform. We’ve been on it for a long time. We love what IBM does with their technology as they continue to build out and add things to it. And that’s a little bit about us. I love the niche angle. There’s so many niches for this platform. When I was a cub reporter starting out on the 400, I can remember, I would pick an industry every month because we were monthly, can you believe that? Monthly. And I would do dog food one week and Campbell’s Tomatoes the next week and hotels the next week. And I learned so much about the economy and various industries and their particular needs. So I’m interested to hear what’s interesting about distribution for convenience stores. This is one I did not know about. So yay. Tim, tell us about RightFlood. I’m the chief information officer at RightFlood. We’ve, we’re a participant in the federal flood program. We’re the largest, write your own. We also offer some other flood products as well but that’s all we do. From beginning to end customer service, we do all of our own printing output. And we’ve been using the IVMI since the beginning of our participation in the program. All right, Dan, tell us about Eradani and what you’re doing to help make APIs easier to use or you can get people to use them in. Okay. Things like open source languages, including things like React or Angular, Python. So we work with those customers to take advantage of those applications. And basically our main product is our Eradani Connect product that creates a wrapper around the IVMI that makes it very, very easy for open source developers to access the IVMI and for IVMI, excuse me, for IVMI developers to access open source web services and functions right from their RPG programs. And it runs, does it run on the IVMI platform itself or does it run on a control plane server that’s separate from it? How’s the architecture of this and how tightly coupled is it to the IVMI platform? It’s a great question because it really depends on what the user needs. It can run basically anywhere. It can run on a Windows platform. It can run on a Unix, Linux platform. It can run directly on the IVMI. Depends what the customer needs to do and what their environment is like. So for example, they need to be on at least seven, two or later of the operating system in order to run on the IVMI because it’s all built in open source and IBM created all of the open source capabilities, the package managers, the open source support in seven, two. And so we need to be on seven, two or later to run directly on the IVMI. But if you’re not on seven, two or later, you can run it on an external Linux or Windows server and then we’ll talk directly to the IVMI. Gotcha. And it’s important to note that, you know, this is a fairly new technology. I mean, APIs have been around for a long time, but I don’t think a lot of programmers in the IVMI will necessarily think at that API level all the time. Correct me if I’m wrong. They think more of developing their own applications, compiling them and then, you know, letting them loose in production eventually after some QA. This is a different kind of programming. It’s more modern. It’s more like the way, you know, hyperscalers and those guys build things. And I think it’s a good thing. So I think the first thing we wanna know is how do you decide to adopt a new technology like this? And we’ll start with Harlan again. Harlan, talk about what decision process you had to go through to say, hey, you know, let’s try a different way of doing this. Let’s go look at this API server and figure out how we can make use of it to do exactly what Dan says.

Right, we had traditionally used a case tool product since the early 90s to produce our software on the IVM, the AS400 at that point in time. And as time grew, we needed to build out and do other things with it. We looked at when we use screen scraping type of technology to do some things, but there are definite limitations built into that. And we wanted to get away from a proprietary set of tools. So we embarked on probably about a three year process as we looked at a lot of different things. We looked at possibly even moving off the IBM i, which we didn’t want to do, different proprietary things. And what we, after the going through the process for several years, we decided that the open source was the best way for us to go because what it enabled us to do was since IBM had stepped up to the plate and added a lot of open source things into the system that allowed us to continue to use our legacy objects that we created on the IBM i and advance and move out and take advantage of things that are out there like NPM packages and things of that nature where you’re not constantly recreating the wheel, you can leverage it, which is just what you had talked about, Timothy, where the old way of thinking about things was, if we didn’t build it in-house, we didn’t trust it. We didn’t accept it. We didn’t want to outsource things. But in the modern world, what you’re going to do is find building blocks, things that you can rely on and use those because there’s no point in writing authorization tokens for yourself when somebody else has already created that. So that was kind of the process that went into that whole thing for us. And for you, it sounded like that you’re keeping the core applications you’ve created. And I always remind people, it’s, what do you get if you take all of that logic that’s in the database or wrapped around the database in RPG, sometimes Coldfall, but usually RPG, sometimes Java. If you just pick that up and move it, you haven’t done anything. And there’s always a risk of touching that code because if you go re-implement it, you can introduce errors. And it’s been debugged like crazy for decades. So why on earth would you change it? That’s true. And in our circumstance, it is a living software. So we’re continually add things, see into things. So we couldn’t just abandon that and in the 80s, we had a software page around IBM’s system 36. I’ll show my age a little bit there. And we moved over to the AS400. We rewrote our package from scratch to take advantage of relational database, things of that nature. And that was an agonizing experience for us and our customer base, because basically it was sort of like throwing the baby out with the bathwater. And that’s a process you don’t really wanna go through if you can avoid that. So what this approach allows us to do is continue to use the things that we have and build more modern objects and things without just abandoning all the business logic that has been developed and so forth over the past several decades. Do you use that to grab other pieces of software that someone else might have developed to do the integration too? So it’s not just about, oh, well, I’m gonna do something in Python now over here because all the kids do Python or whatever, and then we can integrate it into that existing system that we have. It allows you to pick stuff up from somewhere else too, if you decide to do that, if you expand your business or the functionality that you had it makes it easier to integrate with anything, I assume. And your customers are people that do this for a living. So they might have other pieces of software too. True, absolutely true. All right, so Tim, tell us about how you go about the process of coming to a decision to take this approach instead of whatever you were doing in the past. So give me a story that begins with, we were here and we went through this process and now we’re here. So I’m always interested in narrative art. Sure, and our scenario is very similar to Harland’s except for it didn’t last the years, many years. So we took this approach. We’re looking to, we’re a flood insurance company and everybody comes to our site to get their flood insurance quotes, right? So we went to expose that. And so, APIs on the 400 are doable without a technology like this. However, it’s very difficult and long suffering in order to achieve. So with the Eradani Connect that we implemented here, we’re able to write a bunch of APIs that we are now able to expose to not only our partners, but other third party tools that do multiple comparative rating and allow them to rate, numerous products at one time. And so going, and we’re using the same, like you mentioned, the same RPG programs in the backend that run our old agent portal and run our green screen applications. They all call the same code base. And so we’re able to reuse that and keep that running. We didn’t throw anything out and just being able to call those programs directly help us expand our footprint in our marketplace. So Dan, how normal is it to do things this way in the real world? You know, I mean, talk to me about how other platforms do or don’t do this. Like, are we advanced in having something like Eradani on the IBM i, are we ahead of the game? Are we doing it smarter than other platforms? Are we catching up to other platforms? Is there an API server for Windows and Linux systems that does this for legacy? I don’t know, you tell me, C and Java programs. I don’t know what, I don’t have a compared to what here. So, and that makes me nervous whenever that happens. So give me a compared to what. So what we have in the IBM i world, in fact, the really huge advantage we have in the IBM i world is we have these applications that have been built over decades that are very, very functional, that are richly functional and that are finely tuned to the way our companies do business. The issue that we have is that they were built in a time when we built large monolithic systems where the user interface, the database, the programs were all tightly integrated.

And so now we want to take advantage of these open source technologies, the productivity of being able to download modules and add them through the system or some of the connectivity that Tim talked about, the ability to talk to your customers and to your business partners. And so the question is, so how do we integrate all that great functionality that we have in the system with this new technology? And so that’s what we’re finding more and more people on the IBM i are looking to do. I think that the move to rip and replace IBM i’s, sort of what Harlan talked about earlier when he was talking about the things they looked at. And a lot of people went down that road of looking at, let’s replace it with different technology. And they found that that was very, very risky, very, very expensive and took way longer than anybody thought it would take. So now people are coming back and saying, wait, we’ve got this great platform with these great applications. How do we just integrate what we have with this new technology? And that’s really sort of what we focus on with our customers. Let’s talk about the decision to use this tool. How did you go through a process to figure out that your Eradani was the right thing? Did you find other alternatives or is this the only game in town or the best game in town? Let’s talk about how you picked Dan’s product. We’ll work with you backwards, Tim, back to Harlan. Okay. So to be honest, no, they’re not the only game in town. There’s a few other players in this market. And we looked at all of them. I think one of the main driving decision makers for us was the use of open source technologies. The use of things that are already existed out there without locking you into a particular tool set, a particular GUI or a particular development cycle, development tool to use. That was key for us being able to leverage Node and natively just the way it was meant to be implemented without using any special way of altering it in order to incorporate it. So that was key to us is that in the end, if we ever chose to move away from the IBM or things like that, that connector piece is the only piece that has to be looked at. The Node server runs by itself and runs Node code just like you would write for any other application. And I assume for new applications, you’re coding in Node, you maintain the existing, I assume RPG applications as well. And over time you might decide to implement certain things or not, as you see fit. I would suspect that there’s not a desire to rewrite everything in Node over the next decade. You rewrite things as they make sense. Talk about that process for one second while I’ve got you. Sure, so what we’ve decided to do is anything new that we’re writing that touches another API. So we could be consuming somebody else’s. We’ve extracted that from the RPG and from the IBM i and we’ve put it into our Node servers, which use the Eradani Connect. So we would be connecting both internally and externally through the same function. So we’ve created like an API layer outside of the IBM i that both can leverage by the IBM. RPG programmers can call those same services now and it’s like calling another RPG program or it can be leveraged via just regular API services outside of that. Gotcha.

So Dan, you’ve basically recreated the technology independent machine interface at a higher level. Actually, actually from a, you know, from a conceptual perspective, that’s really very accurate. What we’ve tried to do is say, let’s make the connections, make that all independent. So I can write my interface, my front end, my APIs and whatever language I wanna write them in and use whatever technology I want. And I can continue to maintain my IBM i, RPG, COBOL, CL code, however I wanna do that. We’re just doing the translation between the two. So as Tim said, if someday down the road, you decide you don’t wanna use Eradani Connect anymore, you can pull out our connection layer, put something else in and all of your code still works. Everything will work just fine. So you’re not locked into our way of doing things. Well, the best thing you could do then Dan is to make it hook into Windows and Linux servers and do all these kinds of things. So it’s sticky and gluey and you can’t pull it out. But that’s my advice. How did you come to this, go through this process to figure out that your Eradani Connect was the right thing for you to do in your particular situation? I’m curious how real people are making these decisions. Right, we had looked around at some things and the tool that we were using to render green screens, the case tool, they had another product we could migrate to, but it was a proprietary tool. And it was gonna be a large, just as large a learning curve to change to that, but then we would still be in that box. And we just didn’t have a lot of confidence that that was the right decision for us as a company moving forward. We wanted to get into open source. We know there’s a huge base of JavaScript type programmers scattered worldwide. We wanted to leverage the MPM packaging type of concept where you’re consuming building blocks stuff there. We wanted to get into APIs, which the IBM I could do. But what Eradani Connect provided for us was it sort of insulated us from some of the complexity because they had wrappered it. So those are kind of the things that we went through. And what we had actually looked at a tool that would convert our case tool into RPG3, but we just felt like even though that’s a great language, we felt like if we went to JavaScript, that was a better long-term solution for us. I noticed you said RPG3 there, not RPG4, ILE. I meant to say RPG3. Oh, three. Oh, I thought you said three. I was like, that’s not a model. I mean, to some people it is, but no. But I have written RPG3 and nothing against it. I got nothing against it. I just thought, did I hear that right, you know. Yeah, but basically that was it. We just wanted to position ourselves where we were able to move around. And like Tim had mentioned in his conversation, we didn’t want to be pigeonholed into a box. We wanted to be able to separate the business logic from actually the program that’s running and have that all independent. So as Tim was saying at some point, if you want to connect to a different server and do something different, the only thing that changes are your connections to another database. So all those things were the appeal that we found attractive to us. What are the challenges you had doing this? That’s the next question I have. So nothing is ever as easy as anybody explains it to be, at least not in my experience. Well, the barrier- Slipping on ice. Slipping on ice is that easy, yes. Yeah, a lot of times the barrier to entry on anything like this, you don’t even know where to begin. You don’t know what questions to ask. You don’t want to make- Oh, Harlan, it looks like- In that arena, because they were able to give us some guidance. And the fact that they had raffled some of the IBM complexity and removed some of that was a good thing. And they also helped us to do a proof of concept project so we could sort of get our feet wet and get our team, our initial team up to speed. And we’ve had some recurring meetings going on to help bring our small team up to speed. So those are the kind of things, those are the challenges is, if you take people that are writing code, that’s typically IBM i type of code that was written over the years to transition them to learn the new programming stack, all the different pieces that you have involved. Those are kind of the barriers to entry for any company trying to make that transition in there. And also we had another programmer on staff who lived in the Microsoft world and iOS type of world at writing things there. And what this tool set has enabled us to do is to more tightly bind people running, writing other types of code so that we have a more unified team and we can share code, which is also a very nice benefit for going to open source. Understood.

What’s your language on the other side? What did you pick on the other side of the APIs? What are you developing in now, I guess? Yeah, I mean, we’re using Node.js, we’re using JavaScript. Right now we have a React for a front end. We’ve looked at Angular. Those can be interchanged, but it’s better to find one horse and sort of understand that and write it. So right now it’s a React front end, a Node.js server, JavaScript, which is fairly easy for an RPG programmer to get up to speed on. There are great tutorials and things of that nature out on YouTube and things. So you can get people up to speed and sort of build that process out. And the new programmers, or the younger ones or the different ones, I don’t know which words to use to describe them, but probably all of them, they don’t have to care if there’s an IBM i in the back. And that’s a little scary to me. I got a little nervous, my pulse started racing a little bit there. But it doesn’t matter. They’re just gonna see a service and subscribe to it basically and use it. Right, for them it’s transparent. It’s a service that they’re going to use and they really don’t care about what’s under the covers on the back end. And that’s the beautiful part of that open source and that type of approach. So Dan, why don’t you just rename this thing MySQL or something like that? Exactly, yeah, just to pick up on, so Harlan’s group actually has really made a huge amount of progress. They’re actually bringing over some of their IBM i programmers into the JavaScript world. And they’ve really picked up on JavaScript and are rapidly building new applications. I think JavaScript is the safest bet. I mean, you’re gonna use JavaScript on the interface and you’re gonna use Node on the server, wherever you wanna call that. I guess on the other side of your Eradani in some cases, it seems to be the fastest growing pair of languages. I put them in the same bucket because they’re virtually the same. If you don’t think they are, let me know. But they’re close enough. Yeah, I do also wanna bring up that actually, Tim actually drove one of the other big innovations that we got engaged in, which was, we’ve started working with Tim on calling into the IBM i. So kind of similar to what we’ve been doing with Harlan, which is building a new user interface and then talking to the IBM i. But then Tim brought to us, he said, what I really need, what would really be great for us is the ability to call from the IBM i directly out into open source web services so that we can take advantage of all the functions and capabilities that are out there. 

And so that drove sort of the second half of the Eradani Connect product, which is- Did you expect you needed to do that? You would get to it eventually? Or did you expect the demand would be later? What was your expectation? It was something we had thought about, but we really, my experience had been, people are looking for ways to modernize the user interface. They’re tired of the green screen and they wanted something new. So we wanted to make that process really easy. So that was what we focused on first. But it’s really interesting. What we have found actually, is that we’re getting a whole lot more interest in this idea of calling out from the IBM i to web services to take advantage of all the, calling out to Google Maps or calling out to the weather service or calling out, we’ve got customers who use VIN numbers to get information about cars and tax information from the government. So taking advantage of all this information that’s out there and integrating into their IBM i applications. And that’s predominantly on that side, RPG, RPG free and Java, I assume, that they’re programming in and they don’t wanna have to think about all that other stuff. They have the same problem. So I think that’s very interesting that it’s a two-way street and not just a double lane, one-way street. So I think that’s healthy and you’re helping make it easier for people to make the case that they can keep the platform.

So that’s a good thing. All of you are doing that. Yeah, I think Tim, like I said, Tim really is the one to drive it. Do you wanna talk a little bit about what that was? Yeah, do it. Yeah, and I apologize if I guess I wasn’t clear earlier when I was saying it outside in or inside out, is that’s what I was referring to, either RPG programmers calling web services that are actually in Node, right? Or taking the Node application that we’ve already exposed to an API service that they’re coming into the RPG programs or coming out of the RPG programs. So just one of the things was, is to give it a little bit of credit, Eradani was already kind of on that path of being able to do that. But what we realized is some of the web services, especially today, can be dynamic in their size and with the return. Sometimes we get one record back, sometimes we get 100 records back and they can be varying lengths of sizes. So that’s what Eradani has really helped us refine and get better at is when in an RPG program, when you have to call out to a web service, you mentioned like a Google API to get address or geocoding. That’s pretty standard. You know pretty much the size and the length or maximum size and lengths that you can get back. But when you’re doing a quoting application, it all depends on the risk. And we may be able to offer you one product, we may be able to offer you three products or four products. And so that’s where some of that dynamics definitely comes into play. And just hitting, you know, we approached it a little bit different than how Harlan did. We’ve tended to keep our programmers separate. You know, the Node guys and Java guys, the web guys are on one side and the RPG guys are on the other. Do they have buns? Do they like point at each other? I mean. They do. You know, when you’re in the office and you know, you have the cue boards, right? You stand up over the cubes, but it’s, you know, we want to get to that point. And I think Eradani, this Connect tool will help us get there once they start understanding each other and understanding how that program call works. I think one of our biggest challenges to this, not only learning Node and learning a different way to use JavaScript, right? Most of the web guys were skilled in that, but it was also taking some of our larger monolith RPG programs and trying to break them down into more service oriented style programs that do one thing. You know, I want to clean an address. I want to look up a geo code. I want to rate this one product instead of doing, you know, God programs that does everything from top to bottom. Talk about the return on investment from this and the business benefits here just a little bit. I realize these things are very hard to quantify. They’re difficult to qualify in some cases too, because when you just simply need to do something or you’re not going to be able to have a business, it’s like, all right, well then how do you qualify that? It’s like, you have to have, you have to have modern programming languages and programmers who can tweak code or you’re not going to be in any business at this point. So I realize this is kind of difficult to do on the spot, but I’m going to put you on the spot anyway, I don’t care. So Tim, you go first.

So like, what’s the benefit to the business? And I mean, in dollars and cents kind of benefits, not just, you know, the programmers get to do what they want to do. Help us understand the real benefits to this approach. Sure, I think for us, the real benefit to the program, to this approach is being able to take our programs and expose them to third party, for us, it’s third party raters, right? There’s a number of companies out there that are developing either a homeowner’s rating product or multiple flood rater products. And now that enables us to have more exposure to our products. So- That helps make a sale. I mean, it’s like- Right, if we’re not quoting, we’re not, we can’t sell a policy that we didn’t quote. So to be able to turn this out and say, hey, you can call this API and we’ll return to you a flood quote. And now that can be- That’s a pretty linear benefit. It is, it is, it’s pretty straightforward. Yeah, it’s, but it’s putting, trying to put dollars and cents on it, right? How many quotes do we have to do? But the more you’re quoting, the more you’re going to end up writing as well. Has it increased your quote rate or it just gets you where you need to be so you can compete? I think it sounds probably more like the second one than the first one. Well, it’s, yeah. So we’ve been, we’ve had this out there for a few months now, able to be integrated. And we have seen our quote volume increase. We’re still trying to quantify exactly these quotes versus agents coming on because they still, there’s still a completion process, right? You can start it through the third-party rater, but the complexity of the flood product, unfortunately, still requires you to come to us to complete it out. That’s more of a reprocessing than the transaction processing. A human being’s got to get involved or do everything. So what you’re saying here is people are the bottleneck. Great. Thanks a lot. We’re trying to eliminate people. Yes, well, welcome to computing. I mean, it does that eventually. But in the meantime, we’re all going to have jobs. So Harlan, talk about the business benefits for you. Like how do you quantify it and qualify it in terms of money or throughput or more business, better business? How do you think about it? Well, you know, we’ve had a lot of internal discussion and it’s sometimes hard to quantify, but certainly the intangibles that are hard to qualify. Do you want to still be in business doing this? Are you going to get left in the backwater? You must modernize just to stay relevant in today’s world. So that’s one part. And how you convert that into money, I mean, and monetize that, if you’re out of business, obviously you’re not making anything. But part of it, that’s part of the equation. But then also, in our system, our ERP system that we have, we need to interface the things in the modern coin of the realm for talking to each other through APIs. And manufacturers in our little segment of the world are beginning to start, they would prefer to use APIs as opposed to EDI when it fits the bill. And so these are things that you need to remain viable. Also for us, as far as trying to quantify a return on investment, it opens the door for us to create new products and new things that do things differently than we did before in the green screen world. And so those definitely become things that we will sell and use that. So you have all those competing for, actually, complementary forces that are ongoing. And really, inside, you know that you need to do it. You can’t sit still in this business. If you don’t want to be a lifetime learner, you shouldn’t be in the computer business. You have to be able to adapt and be agile and quick to react, maybe sometimes not as quick to react as we’d like to be. But that’s the driving force for us, is we want to be relevant. We’re in it for the long term. We’ve been around since 1970, and we’re not going away. Well, that shows a certain amount of longevity. When I started Aichi Jungle, our tagline was survive, adapt, thrive. And then after about a decade, I said, well, it’s really survive, adapt, repeat. Thrive might happen, but I haven’t seen it yet. And there’s honor in that, right? We’re all in small businesses trying to do a good thing to help each other in some way. I don’t think we need to get rich. We just got to get it done. So I’m good with that. 

So Dan, when you talk to the users of your tool, what are they telling you about the kind of ROI that they’re seeing? And how do they quantify and qualify the benefits they’re getting? And it keeps them coming back for more, I assume. So it depends on the customer, because there are all kinds of use cases that people are using these things for. We have customers that have absolute, direct, quantifiable ROI, where they’re doing things that they were unable to do before. And we were working with a customer that transports cars. And one of their issues is, when they transport the cars, they actually charge for refueling those cars. And with gas, they had a great way of doing that. It was really easy. They knew exactly how to charge. But with electric cars, they didn’t know how to do it. And so they weren’t charging. They weren’t actually charging the car. I’ve got to watch you say the word charge with electric cars. Exactly. I’m using it two ways now. I realize that. Filling is the word you’re looking for. Filling the customer for charging the car, because they didn’t know how to do that. And what we found is that there is APIs that allow you to actually go out and find out what is the capacity of the battery in the car. And you can actually go out and see, well, what does it have right now? So you can actually see, what’s the delta? What did we have to actually fill up to charge that car? Creating this opportunity now to bill the customers. And they’re transporting well over a million cars a year. So this is not an insignificant amount of money that’s at stake in being able to identify that information. And again, that’s just an example of the ability to go out and get information that’s readily available. One of the things that Harlan looked at is that they provide software for convenience stores. And one of the things that customers wanted was the ability to see the nutritional information about the food that they were selling. And there wasn’t an easy way to do that. You had to go look it up. Well, there are APIs out there that allow you to go out and get that information directly so that you don’t have to go look it up. We have another customer that when customers would ask them to send them an invoice, they actually had to go into their IBM i greenscreen system to find the invoice number. Then they had to go to their invoice archiving system, which was a Windows system, key that number in, bring up the invoice, and then send it out. They used Eradani Connect to create that connection that allows them to go right from the green screen, send out the invoice number, and have it send the invoice from the Windows system. So we’re eliminating that sort of manual step in between. So there are lots and lots of different ways that people actually find to justify this. And it’s always hard to get- I should mention just one other thing is that Harlan shared with me that going out to customers and being able to show them a very modern user interface instead of a green screen interface is an advantage in the marketplace. 

So last question here before we open it up for questions. What kind of initiatives do you have that are relating to this Eradani Connect tool that you see going forward? Harlan, we’ll start with you this time. Well, the primary thing we’re working on right now, we want to not replace, but augment our green screen offerings in a web-based environment. And what we found is this makes it much more pliable for us to deploy in a cloud-based environment that a lot of our customers want to move to the cloud. And so that’s a piece of the puzzle. But also customer-facing portals for our distributor to have their customers, which would be a retail store, to come in. We have a product that we developed way back with RPG, with ILE-RPG, where it actually creates the HTML on the fly. We want to replace that with a more modern way of doing things. It’s easier to add things to and so forth. So those are the kind of things going on. And as we move forward, probably things in mobile, in smartphone, you know, modules or things to convey that information and allow to interact. We have an application that actually runs on a web-based tablet for truck drivers making deliveries. And that was written basically using screen-scraping technology, using 5250 screens in it, but showing it on the tablet like a webpage. We want to replace those things and do it because there are a lot of extra things we can do now with the technology set that’s available. So that’s kind of what’s on our mid-range. And then beyond that, things will come up and we will do them because the marketplace will continue to change. All right, Tim, tell us what you’re thinking about doing now that you’ve got this new way of doing things. So one of the things that we’ve just did is we launched a consumer-facing website that incorporates all of these APIs that we’ve created through this. And now that we see the usefulness of that, we’re actually looking to expand that to replace some of our green screen operations. So that’s kind of the end goal that we see going down there, at least on this front of things, is being able to do what we’re doing in green screens, but now putting it on a webpage. So when you bring in some, I think you mentioned earlier, younger folks, teaching them how to use a green screen, signing into a green screen terminal and using a green screen application versus using a webpage, which everybody knows how to use today. I was blazingly fast on a green screen and I still love it. Oh yeah. I just, I understood it. So Dan, I got to put you on the spot too. We asked them about the future. I’m going to put you on the spot a little bit too. What’s next for Iradani? Got this API server out there. It goes both ways now and it can reach out as well as let people reach into the IPMI. What are you going to do next? Well, we’re going to continue to extend the kinds of things that we can do with that and make it increasingly easier and easier to use. We want to just make it so that it’s really just drop dead easy for people to adopt the technology. We think that there’s a huge amount of opportunity in expanding this. And I think a direction we’re going to go in is a lot of these APIs, there are lots and lots of different ways of accessing them. So for example, if I’m a company and I want to access the transportation companies and see, you know, where’s my shipment or create shipping labels or see what it’s going to cost to ship something. The shipping companies provide APIs to do that, but every single one is different and they’re really complex. And it’s really convenient for you. So, so, so standards, please, God, no. Yeah, exactly. Everybody’s done it in their own way. And so it’s great that they have the APIs, but if I want to take advantage of, you know, we are, we’re talking to a customer earlier that said that they, they use 42 different freight companies. So to try to talk to them, Are there 42 different freight companies? Oh, there, there’s a, apparently there’s over 700 different freight companies operating in the U.S. You know, that, that people are- I met legal ones. Exactly. Yes. Where I live, it’s NASCAR, you know, but you know. Right, well, yeah, yeah. So yeah, that’s actually, that’s very funny. There’s one of the ones we saw there we thought was, was cool. It’s Billy Bob’s Trucking. I mean, it’s, you know. So, but yeah, there, so there are all these trucking companies. They all have APIs, but they’re all different. So one of the directions we’re moving in is to find these common APIs and basically do the, like you said, the technology independent machine interface, but moving that another level of abstraction where our customers will be able to write to a single API and we’ll take care of all the different APIs that are provided by all the different providers so that, that, that they can write one way to get the information. And we’ll take care of worrying about, well, is this UPS? Is it FedEx? Is it DHL? You know, who are they trying to talk to and, and make that consistent. We’ve seen that in a lot of different, different arenas. Same thing with our customers who are using VIN numbers that are like 15 different services for getting information about cars, if you have a VIN number. So what we want to do is make it much easier so that you call one place and we can take care of all the different APIs you might need to call to get that information. All right. Very good.

We’re going to open it up for questions now. Terrific. Terrific. All right, great. Well, thank you, Tim. Thanks Harlan. Thanks, thanks Timothy. And now I think, yeah, we’ve got to, should open it up for, for Q and A. So let me start my video here. Yeah, we’re not talking until we can see faces. So Harlan. All right. All right, Harlan, where are you? I’m looking for the button. It’s moved on my, for some reason. If you pull your cursor over the top of the screen, it should, it should be there somewhere. While we’re doing that, I can gear up the first question. Do you have any particular order you want me to do these things in, Dan? Or just- Whatever, whatever you see out there is fine. All right. I guess this is for both of you. Is the use of APIs helping to change the perception of IBM i as a legacy system amongst your end users? I’m saying, I’d say more, you know, also business managers and, you know, programmers too. It’s everybody, but does this help? It helps. I think the real reason it helps is because you really now can obscure it, right? You can create your own front end on this, a web application on it that’s calling the backend. So, especially with people who’ve been around, always know, knows it’s back there, but new people coming in would never know the difference of what they’re running off of, so. Harlan, what do you think? Yeah, it does change the perception because you can do things that you couldn’t do before. And, you know, content is king whenever you get into things. And so if you can provide better, easier to understand, more feature-rich content, then that’s going to raise the perception of it. A lot of people, you know, if they don’t really care what the backend is, they just want to get what they need to get when they need it. And this definitely opens up a lot of doors. 

The next question I see here, and Harlan, this is aimed at you, but feel free to pipe up on it, Tim. Was it hard for RPG developers to learn JavaScript? And I think you touched on it a little bit, but I want you to quantify it a little bit. I wouldn’t say that it’s hard, but it is a different type of interaction that a programmer has. For instance, if you’re writing RPG code, you know, it’s a procedural language. So things happen, you know, in a sequence, and they always repeat in that sequence. Whereas in the JavaScript, Node.js type of world, things are event-driven, and that opens doors where things can happen asynchronously, which is a good thing, but for an RPG programmer, that’s kind of the first thing you have to come to grips with. And the asynchronicity of things allows you to take advantage of threading, for instance, where you can have things take place in a non-sequential sequence, and you can use promises. There’s a construct in JavaScript called Promises where things come back together. So these things can be broken apart in different processing. Maybe you’re talking to the database, getting some information back, something else is going on. Maybe the database conversation takes a while to process. Those things can be divided up in Node.js in that type of environment where as the results, when they all come back and everything’s ready, then you put it together. That ability to thread is a different kind of concept for an old-school RPG programmer, but it is a super powerful thing once you come to grips with it. So that’s one aspect of it. As far as the languages, every time you learn a language, the syntax is going to be different and you’re gonna have to come to grips with that. But if you’re a programmer, you’re a programmer. All right, that’s fair enough. So the next question that came in here was, a lot of firms are looking at rip and replace from a senior management level. There’s pressure to do that sometimes. We’ve heard those stories many, many times. How did the two of you counteract that? Tim, start with you. So I guess part of the question is, is how far down the process are they to making that decision to rip and replace? But I think quickly doing a proof of concept to show what the capabilities and the strengths of something like this is and showing that, hey, we can still evolve and move quickly. I think that’s, for us internally, that was one of our biggest things is how quickly can we move, right? And sometimes the old waterfall method of getting specs in and trying to develop a program in the back end, and now being able to just reuse applications that we have and focus on the front end or focus on extending some functionality has really helped us. But like I said, you can turn around a proof of concept pretty quickly and show the capabilities of it. I think that can go a long way. Harlan, what do you think? Yeah, rip and replace for us really wasn’t much of an option, not a very attractive option because we didn’t want to start from scratch again. And our customer base said, please don’t take away the things that we have now. We don’t want to start over. We just want to evolve. We don’t want to have a revolution. We want to have an evolution of things. And only reason we would ever rip and replace is if we decided we were going to abandon the IBM i platform altogether and just go to some other thing completely. That would require us to rip and replace, but that’s not where we are. The IBM i has plenty of horsepower, it’s reliable and stable. So there was no reason, no compelling reason for us to jump off of that. So the approach with Eradani Connect gave us the ability to leverage what they had in there, use what we have that’s proven and tried and true, but to evolve into some other areas. So rip and replace definitely was not a top choice for us. And I think my observation on that would be those who could have moved off the platform or were forced basically at gunpoint by some manager somewhere have already done it. And those who are left in the base, and it’s about half the base is still here, and it doesn’t really change very much at this point, they have actually figured out that they have a technical asset, not a technical debt. We talk a lot about technical debt in the IT market these days, but there’s so much encapsulated in their applications. So my analogy, and I’m making this up on the fly, Dan, you’re giving them a technical credit card. And they can do a little spending and kind of show that there’s no reason to do everything all over again. And I said this earlier in the talk, it’s extremely dangerous to go messing around and try to implement code that has been tested over decades, that implements the very logic of the business, and it’s been tested and it works. It’s really silly to do it. So you have to do this kind of approach. What this API server is doing allows you to get the best of both worlds. You don’t have to give up that technical asset, and you don’t have to not build the new one either. So I think it’s a way to kind of split the difference.

All right, what’s the next one here? Let’s see. Sam asked, we’ve been using IWS, and I wanna say he’s gonna say YAML, but I don’t know these acronyms very well. Y-A-J-L, I don’t know what that is. That’s Yagile, that’s YAML. Yagile, I know what YAML is. It’s a yet another JavaScript library, I think. Oh, for heaven’s sake. All right, so anyway, we are struggling with inconsistent data coming from web services. Does this approach make dealing with incoming data easier? And I don’t know, Dan, you wanna take one? Go ahead. Yeah, so we talked to a lot of customers who are using Yagile. I think up until recently, that’s been the most popular thing. Yagile is basically, it’s an open source library that Scott Clement actually has customized so that it runs on the IBM i, and the idea is it parses JSON so that you can use it in an RPG program. The difficulty that we’ve seen customers run into is that RPG is not really a great language for doing JSON parsing. JSON is JavaScript Object Notation. It is built for JavaScript, and so JavaScript is really good at parsing JSON. Trying to do that work in RPG is really, really hard, and we just see that a lot of customers have been struggling with trying to do that JSON parsing using the IBM i tools. I don’t know, Tim or Harlan, have you guys looked into any of that or ran into that? Oh, I’m not familiar with either one of these two tools, but yeah, we do have some, again, you can run web services off the IBM i, right, and we do that, and we do still have some of that in place, but it is, like you said, it’s very difficult to do. It’s very difficult to maintain, and then if you need to add a couple more objects in there into your payload, then it makes it harder to add those in, test it, and promote it. Keeping it outside the eye is where we found the most benefit, and this kind of goes back to our conversation earlier in the recording where we talked about RPG calling out to a web service. Let a node handle all of that object handling, you know, and prep it in such a way that it can now be passed back into an RPG program for understanding. I agree. When you get into, if you’re trying to parse JSON objects out in RPG, I sure wouldn’t want to have to do that very much because it’s super difficult. When you have the tools already there, you know, in Node.js and the Java world to do that type of parsing, if you try to do that in an RPG program, it’s kind of mind-blowing to me because you might get a return, a dataset return that has many, many things in it. It’s not just a fixed set of parameters that come back. They vary, and so that makes it very difficult in an RPG unless you’re much sharper than I am to figure out how to do that. I think that, you know, having the right tool for the job is an important piece of that puzzle, and I think that they would find consistency doing it with the Airadani type of approach as opposed to the other process. It’s probably doable in the other one, but I think you have to do a lot of heavy lifting in there in the course of that.

Dan, how much time do we have left? I think we’re actually about out of time. I think… They gave us the hook right on time. We’re, like, right there. So, yeah, so we do try to keep them on the time we scheduled. So let me just thank you, Tim, so much for facilitating this. Thank you, Tim Love and Harlan Williams for participating. I really appreciate it. I think this has been really informative, a great way to talk to people about what is going on in the IBM i world. And I don’t know if, Tim, Timothy, if you want to close anything, close it up in any way. I just want to say thank you. I had fun. I enjoyed this greatly. I learned a bunch of things, and I learned a new acronym that I really don’t need. Well, thank you, everyone, for attending, and we will make the recording of this webinar available. So if you’d like to show it to other people in your organization, we will send you out that link. But thank you, everybody, very much, and have a great rest of the day.