Here’s Why You Shouldn’t Modernize Away From COBOL

In this webinar, we discuss the pitfalls of trying to move away from COBOL and strategies to ensure data integrity and stability within your COBOL application.

Jeff Wood
Good morning, or good afternoon, good evening, as the case might be. I know we have several people joining us from around the world today. Hello World. My name is Jeff Wood, and I’m one of the engineers here at FairCom. Today’s webinar will focus on data corruption and implementing high-availability, disaster recovery strategies. While we wait for other participants to join us, we have three quick poll questions for you. These will help us kind of understand who you are and how you’re actually utilizing your COBOL. So with that said, let’s go ahead and launch the first poll. As you can see right there in front of you, you’ve got”What is your job title?” Pick one. Hopefully you’re the Manager/CTO/CIO, but if not, then maybe the End User or System Admin. Everybody’s important in an organization, right? Okay. So just take a second to fill that out for me.

And while we wait for the votes to come in, I’d like to share a fun fact with you. Did you know that prior to COBOL’s birth in 1959, computer manufacturers developed their own languages to run their own computers? Man, what a monopoly, huh? I’m glad that’s over, right? Goodness. Okay. With that, we’re going to go ahead and close that poll out and move on to the next poll. And the next poll deals with “How much time did it take you to recover from your last COBOL outage?” Hopefully not very long. Hopefully it didn’t have any, right? It could be one to two hours, three to five hours, greater than five hours. I don’t know. So, another fun fact, while we would compile the votes, 80% of in-person and 95% of ATM transactions use COBOL-based technology. That’s pretty phenomenal why we want to eliminate data corruption, right?

Obviously, banks are using COBOL. We don’t want data corruption in banks. Not at all. All right, let’s close that poll out and go to our last polling question. Last polling question actually deals with “How do you develop your COBOL reports today?” Are you actually in COBOL doing it? Are you using external reporting tools? Are you using an external database? Or you don’t even use reports because you can’t really access your COBOL data? Well, that’s an issue, and hopefully, we can help you out with that. All right, let’s go ahead and share the last fun fact for today. And you understand why high availability and disaster recovery is important? Because COBOL is in 92 of the top 100 banks’ data management infrastructures. So obviously you want to make sure you have high availability in dat a quick way to restore your data if necessary, right?

Okay. So let’s go ahead and close those out. And then real quick, we’re going to go ahead and walk through each one of ’em and share the data with you guys to show you who’s in the crowd. Let’s share these results with you. Actually, we got a good mix. I love it. We got a lot of developers and architects in, in the crowd. That’s awesome, right? We’re going to hide those results and go right onto the second poll. In the second poll. You can see, oh goodness, taking you guys almost more than five hours. That’s unfortunate. Hopefully we’ve got something we’re going to show you today that will hopefully take care of that for you. All right, let’s hide those results and move into the last poll question that we had today. And this last poll question, you are using reports, and that’s pretty cool.

We’re going to show you how you can use reports with SQL. If you use SQL as your data, it’ll be pretty awesome. Let’s hide those results and move on. All right, thanks again for the polls. Let’s move on to why we are here today. We’re going to be talking about how you can eliminate data corruption in COBOL, and how to implement high-availability disaster recovery strategies to mitigate challenges if they do occur. In order to help us better understand how to eliminate the data corruption and implement the high-availability disaster recovery strategies. I would like to introduce our Director of Business Development, Evaldo Oliveira.

Evaldo Oliveira
Hi Jeff

Jeff Wood
And our Director of Client Services, Joe Darnell.

Joe Darnell
Hey, Jeff.

Jeff Wood
We’ll start out with a presentation followed by a live demo, and we’ll close out highlighting a couple of great questions asked throughout our webinar. But before I pass things over to the guys, let’s take care of a few quick details. We encourage you to ask us any questions throughout the session using your chat box in the go-to. You can submit them, we’ll do our best to answer them as they come, and Evaldo and Joe will pick up some of the most critical ones in the final Q&A session. But don’t worry, we’ll answer all of them via email after the webinar. Keep an eye on your inbox. Also, this webinar is being recorded and will be emailed out so you can have access to it at your leisure. All right, I think that covers the basics. Let’s dig in.

Joe Darnell
Yeah, thanks Jeff. Appreciate it. I’m Joe, and this is Evaldo. Normally we’d like you guys to see us. We’re actually dressed real nice today, but obviously technical issues on the GoTo webinar site. So the camera may or may not kick in at any point, but we are dressed for success today. , yes, . So really quick, thanks for coming today. Here’s the agenda of today’s webinars. Today’s 1 of 3. We’re going to go through a brief FairCom company overview, talk about the RTG product overview. Evaldo’s going to take everyone through a great live demonstration and talk about the supportive platforms of RTG, followed by a bunch of free stuff, including a shirt, a download of our software, and a free proof of concept. Are you ready to hit it? Yep. Mm-hmm. , so briefly about FairCom.

FairCom is based in the US with offices in Europe and South America. This year is 40 years for FairCom. That’s 40 years of delivering high-performance database technology for mission-critical applications. One of the main things why customers select us is that no administration is really needed. So as you can see on your screen, these are just some of the companies that have used c-tree database technology. You know, Evaldo, over the years, you and I visited many customers, and one of the stories that sticks out for us today is two logistics companies that manage to move a billion packages a day utilizing our software on the backend. They chose us because of the ISAM technology with ACID-accurate data at their fingertips at huge speeds. I mean, that’s pretty impressive.

Evaldo Oliveira
Yeah, it is. And Joe, all these customers, what they have in common is that they are all mission-critical environments. They all have the need for high throughput. So these are ultrahigh fast databases running and they are using c-tree as the database behind their applications. So I would like to mention, for example, Bank of New York Mellon. They use us for their fund management application — hundreds of thousands of transactions per second. It’s absolutely needed. And, you mentioned during the presentation really quick here, Joe, that they all use our ISAM technology. ISAM stands for Indexed Sequential Access Method, and this is how FairCom was born. So we developed our technology from the beginning as an ISAM database designed for high speed and high availability. And it’s not a coincidence that ISAM is exactly the same technology that’s used under COBOL. And I think that explains why we have this technology called RTG. And we’re going to talk a lot about that in a minute here.

Joe Darnell
Great. Well, I think COBOL is in the core of thousands of mission-critical systems worldwide, and it’s constantly growing, but that creates lots of business pressures. I think one of the biggest things that comes up is corrupt data and data loss.

Evaldo Oliveira
Yeah, that’s a very common problem. Many, many of our customers reported that and came to us looking for help. What happened here, Joe, is that along the years COBOL is now handling way more than it was designed for. So a lot of the systems were designed decades ago, and you’re going to see here in a minute, that it has nothing to do with the COBOL language. The challenge is more on the data side. But the truth is that when you have thousands and thousands of concurrent users — sometimes even to the hundreds, it depends on the workload — Concurrency is not properly well-managed on the COBOL environment. And you start to see some files being corrupted. Most of our customers told us they don’t even know which files were corrupted, so they had to just go back and rebuild everything every day, every night. But even rebuilding, they were risking losing data, and a lot of times they actually lost data. So, yeah, that’s a big challenge.

Joe Darnell
Yeah. How about backend restores being corrupt as well?

Evaldo Oliveira
Well, yeah, since the data files are corrupted you try to protect yourself by doing backups, but usually the backups of those COBOL data files are done by copying files. But you don’t know exactly which files are corrupted or not. So you have, you have really to hope that you’re copying the right ones. We have, we have some customers telling us, for example, that they, to make, to make sure they protect themselves against corrupted data files. They copy their files every 15 minutes just so that they have kind of a data set that they can trust on. But then when something goes bad and they go back to the restore and try to try to restore an old backup many times those restores are not reliable, and they’re also corrupted. So the file gets corrupted, the backup is not trustable, the restore is corrupted. So it’s a big problem.

Joe Darnell
Yeah, I totally get that. One of the other things that come up is most companies have business continuity plans now where they have high availability and disaster recovery plans, but COBOL seems to be left out of most of them.

Evaldo Oliveira
That’s exactly right. For the same reason, right? The COBOL has not been designed for such a sophisticated architecture. Building a Failover strategy, and even something more complex like a disaster recovery site on top of your COBOL system is a big challenge. It’s not easy because of the way COBOL operates. But at the same time, you don’t have the safety net of having a Failover because you have encrypted files. Your backups are not working very well, and you have no way to Failover if something really goes south. And you have to stop your application.

Joe Darnell
And this seems to be kind of the trifecta here. It all creates a potential disaster with systems down, which is a major panic situation.

Evaldo Oliveira
It is, yes. A major loss. We have seen many, many cases where the applications are down for a few days they have to go back and roll back restores for like a week ago or even more than 10 days ago. This is all not good. And of course, while this is happening, your system is down and everybody’s in panic.

Joe Darnell
Yeah, that’s never a good thing, you know? But some companies, as they look to modernize it, it puts pressure on these managers and architects because there’s lots of business challenges that come along with this. I think people’s go-to reaction is, let’s just rewrite this application.

Evaldo Oliveira
Yeah. Trying to solve the problem. I’m sure a lot many people from the audience here probably went through this already. Someone approached them and said, “Hey, you just rewrite this whole thing and move on from COBOL and do something else.” We don’t think COBOL is the problem at all, right? The COBOL language is just another language. Rewriting the application is high risk. It’s a big challenge. Usually it’s very, very expensive because it’s mostly addressed via services. So you, you have a bunch of people rewriting code and then consulting, you know, sometimes there are some tools, but at the end of the day, it’s very risky because you are just rewriting everything. You’re throwing away all your business logic for decades, and then going back to version 0.1 of your system. So, no, I don’t think this is the best way to go to solve these problems.

Joe Darnell
Yeah, it’s not a good way to spend time and money. But then, most people then consider, why don’t we port the application of all them?

Evaldo Oliveira
Yeah. Porting is kind of a mid step. So we have seen some customers trying to solve and modernize the environment by moving platforms. This happens a lot because some of the COBOL systems are running in old machines. Like we have seen some customers running SCO, for example, and they cannot buy new parts for those machines anymore. It kind of solves part of the problem. Yes, you have a little bit of a breath time here because you have a newer machine, but it’s not going to solve your data corruption issues because that’s actually still there. Again, the problem is on the file system, the data that’s being managed by COBOL has nothing to do with the platform where you’re running, plus it’s too expensive. You’re going to have to buy all the machines again, right? So porting, it’s not the way either.

Joe Darnell
It’s such a high-cost situation. It’d be nice if there’s a good balance here with some kind of integrating applications to keep the TCO low and also mitigate your risk.

Evaldo Oliveira
Yeah, and I guess that’s the main message of our series of webinars here. You know, like I’ve been saying this has nothing to do with the COBOL language. It has all to do with the fact that your data is sitting in a proprietary environment and then it’s not being properly managed. the way that the COBOL runtimes manage this in the files is not robust enough and has not been designed for the volumes that you have right now, much less for mission-critical environments like this. But if you solve that and you find a way to integrate this data to other environments, your life changes completely. And we give you a lot of different abilities to take advantage of all the investment you have in COBOL. So a lot of those business pressures go away.

Joe Darnell
Yeah, I agree with you. But when you integrate the applications, I think people are really looking for the solution, right? And as you can see here, here’s a traditional COBOL architecture with FairCom RTG. Now, we talked about ISAM technology, the history of FairCom, a little bit about COBOL. There’s some kind of some overlapping things here, Evaldo. Can you talk about that a little bit?

Evaldo Oliveira
Yeah, let me explain. So this slide is here to show to everybody what’s actually going on behind the scenes when you’re running a COBOL application. It might be familiar to many of you, those more experienced in how the COBOL environment works. but you can see, Joe, what’s really, what’s really matters here is the fact that you can see the source code. So those, these are the COBOL programs, right? Usually they are pre-compiled into some kind of object file. But then what happens is that your COBOL runtime is in charge of taking those programs and executing them, but it’s also the COBOL runtime that does all the IO. So you can see here the IO is done on what you call a file system. And I mentioned ISAM before. So COBOL is also an ISAM (Indexed Sequential Access Method) system.

There are many different types of files system out there, like a list on the right here. Some of those most popular ones, like Vision, for example, this is from AcuCOBOL. We have C-ISAM. C-ISAM is the common one under microfocus. There are many others. I mentioned B-trieve here. But the bottom line here is it’s really important to understand that the COBOL runtime is doing all the access. So what happens is that when you have a few COBOL programs, reading a few files here and going to some records, that’s not a big deal. It was designed to kind of this workload. I would say something like 5 to 10 concurrent users on top of the same file and the same record, should be fine. But when you start to go into hundreds of users concurrently reading and writing into the same record, into the same file, this architecture here cannot handle those workloads. And that’s where your data corruption starts to happen. So you can see, Joe, it has nothing to do with the language or your programs. It has to do with the way that the solution has been implemented many years ago.

Joe Darnell
So how does RTG fit in this whole thing?

Evaldo Oliveira
Well, because what we do is we replace the file system. So we have a full database that manages all your access to your data. The beauty of our product called RTG is that it has been designed from the beginning as an ISAM database. So we are record-oriented, we are file-oriented, and we developed APIs that allow you to plug RTG, underneath your COBOL runtime by just replacing the file system. So you see, Joe, you don’t have to touch anything on the source code. You know, you don’t have to change anything on your logic. We preserve all the logic. So all the IO that COBOL was used to do stays exactly the same with RTG.

Joe Darnell
I think that that’s a lot of people’s first reaction when we start talking about how this has no changes to the source code.

Evaldo Oliveira
That’s correct. Yes. But then because we are a full database, it’s a complete database solution here. We bring a lot of additional benefits like you see on the slide here, right? So the very first one is that, from now on, you have a full client server technology running here. And you can interact with our server, with our database server, for example, to do some hot backup. So you don’t have to stop your application. You can go straight to the database and copy your files. You know, we guarantee the restore. So everything you back up through us, we make sure that if someday you have to go back and restore that data, it is a guaranteed restore. This is a transactional database, and I think that’s the secret sauce behind our technology here.

We eliminate data corruption because everything is under transaction control. So this is native, you don’t have to worry about. You might be asking, “Well, but my COBOL applications don’t control transactions. I don’t have start transaction, commit or roll back over there.” You don’t have to. You can if you want to, but you can even add this kind of capability to your language with us, we support it, but you don’t have to automatically return on transactions, on each files on the IO. You’re going to see here in a minute how that works.And what that means is that if something goes wrong, for example, is if you run out of power, your machine is down. When RTG RTG gets back, it’s able to detect what transactions are supposed to be recovered. And we bring the database to an integrity mode again. So we have automatic recover for you. You don’t have to worry about rebuilding files anymore.

Joe Darnell
I mean, I was sold on those first two, but also security is a huge concern. So we can secure your data at rest and the communication.

Evaldo Oliveira
Yes, exactly. The list goes on and on and on, right, Joe, because it’s a complete database, like security you mentioned here. So we support communication security like SSL and TLS. The example that then we’re going to see, we’re going to see two machines talking to each other remotely. So it’s a network communication going on. You want to protect the data that’s flowing around. Don’t worry, we do it, we support encryption on the files. It’s a key-based encryption. So we give you all the control and different levels of encryption you want to have. We have full user management control. It can be integrated with some single sign-on solutions like LDAP, for example. So it really extends the protection of your COBOL data, which is probably sitting right now on the disc, maybe using some kind of individual encryption system. But in most cases, what we have seen is that the data is actually open over there and it’s a multithreaded solution.

Joe Darnell
That’ll prove overall performance of this.

Evaldo Oliveira
Exactly. Yeah, because the diagram you saw before on the original file system running underneath the COBOL runtime, that is a single-threaded solution. So it scales very badly. With us, RTG is a full multi-threaded database. What that means is that you can have thousands and thousands of connections simultaneously to our database, and we’ll make sure, we’ll use all parallel systems that are available on the hardware. And if you run out of capacity, all you have to do is to upgrade your hardware and buy more CPU or buy more memory. And we’re going to take advantage of that. You know, you’re going to scale up very well. We’re designed for this kind of workload.

Joe Darnell
Yeah. We’ve been considered an engineering database, right? We want to let you customize it to what you need and how your architecture’s set up. You know, we don’t want to force someone into a particular corner. As you’ve mentioned before, this is really a full solution. Even though you’re coming up to us for one reason, like, you need an HA/DR plan. You’re looking at, you know, integrating with JDBC or Python, or you want to attach your BI tools, which is why we kind of broke up this webinar series today. We’re talking more about the provider to prevent data loss and high availability. but our other webinar series about modernizing your applications and about integrating with BI tools. So be sure to check those out.

Evaldo Oliveira
Yeah. That, I think that’s a very important message. The moment you switch your focus from your COBOL environment, from the language and your programs into your data set there are so many things you can do. And here is a short list of the kind of benefits we bring to the table with RTG. Most of them have to do with the fact that we are a full transactional database that will start to manage your dataset. And by doing that by itself, it already improved so much. We eliminate data corruption. We give you different ways to handle the backup, you know, interacting with our database.You can scale as large as you want, as large as you need. But there are many other benefits. Some of the webinars later this week — and we encourage everybody here to watch this tomorrow and Thursday — I think these are nice to address. We’re going to talk a little bit about integration tools as well. So there, the focus is going to be on data loss.

Joe Darnell
Yeah. And I think at the end of the day, no matter which pressures you bring over, what solutions you’re looking for or put into your system, it really comes down to TCL, right? The total cost of ownership and how to reduce that, because there’s a lot of pressure with that.

That’s correct. Just by, by doing that, by adopting our technology, you reduce so much the total cost of ownership of your platform because you eliminate some processes that you don’t need anymore. No, you don’t have to do, like — we have one customer where, I mentioned they were doing backups every 15 minutes. Well, now they’re doing backups only once a day because they trust their backup. This is a big economy in terms of resources and people, right?

Plus there’s some possibilities of revenue increases. You know, what you look at the feature sets that you’re allowed to do with the COBOL or even the data mining that you make may uncover.

Evaldo Oliveira
Correct.

Joe Darnell
Now, Evaldo, we’ve been talking a lot, right? I think we need some more COBOL.

Evaldo Oliveira
Yeah, we definitely need more COBOL,

Joe Darnell
I’m going to hand this off to Evaldo right now, and Evaldo’s going to take you through a demonstration on your screen.

Evaldo Oliveira
Yeah, and by the way, we were discussing a little bit about how we can show data corruption. It’s not very easy to simulate a situation of a corrupted data file. I think it’s really important to give you the message here that data corruption is solved with our technology because of the features we just showed to you here, right? So we protect your data, we shield your data with a transactional, fully transactional database designed for mission-critical. We’re going to go through some steps here showing how that works. But the demo is going to be focused on something a little bit more sophisticated I guess, which is the next step. We are talking about building a Failover. So you’ll see how to take one data file. The demo runs on top of a commercial COBOL application.

It’s called Passport from one of our partners, Passport Business Solutions. It’s a commercial COBOL application that we don’t even have the source code. So it’s really interesting to see how we can do this without touching the source code. On the other hand, it’s also a character-oriented application. We think it’s nice to show it in a character. COBOL, we know many COBOL environments out there are already, web-based. That doesn’t matter for us, because our focus is on the data. But I think like if you show it works with character-oriented, it works with any environment, right? So before we start, let me show really quick here how this works, right? So I’m not going to go today — the focus is not going to be on this, on how to set up this environment, but I want to show you here — I mentioned before, this is a commercial COBOL application, and it’s based on AcuCOBOL.

So like I was showing in the slide, Joe, you can see here running on the AcuCOBOL environment, just telling it to give us some information about the system. You can see here natively, it comes with the Vision file system. But we also added FairCom RTG as an additional file system over here. So that is the trick, right? So we have all the tools and the, and the drivers for you to adjust your COBOL environment and add an additional file system, so you don’t have to replace your file system. You can keep some files running under Vision. As a matter of fact, the demo here, we’ll go through one single file conversion to show how that works, okay? And it’s really critical because it helps you to decide. You don’t have to do a big bang approach while you convert all your files.

Most of our customers end up converting all their files, but the truth is that this is all you have to do, okay? So just add an additional file system and Intel, the COBOL runtime that c-tree RTG is is an extra one, okay? So typically like any kind of COBOL environment this application is not different than others. It’s a structured in terms of folders and data files. So let me show you here how this looks like. So you can see here it’s an ERP solution. so we have different folders for accounts payable, accounts receivable. So accounts payable zero zero is for the fake demo company, zero, zero. It’s the folder that holds all the accounts payable files. We’re going to be focusing on this particular file. Venfil00 is a file that has all the vendors from this fake company, okay?

But I’d like to show this here. Maybe try to connect to your existing environment and see if you feel like this is familiar. It has also index files. AcuCOBOL keeps the index files externally in .vix files. And it really changes depending on the COBOL environment. Some environments have everything inside a single file. The most common scenario is having the indexes. None of that really matters for us because we respect all that. Okay? So you have a Venfill00, that file right now, you’re going to still have a Venfill00 that file with us, okay? You have your own indexes coming from your COBOL application. We’re going to keep all that and we’re going to preserve all your indexes as well, you know, and give you way more. So I like to show this just to show like how applications are structured.

You can see there are multiple different folders here. But let me start an application really quick here and then just take a peek at how it works. So I mentioned before it’s a character enter application. So I’m going to log in into the 00 fake company, the XYZ, right? So just go over here, yes, let me log in. And this is just really to give you some sense of what a COBOL application is, right? So you can see here typically menu oriented and this case character oriented, it’s just browsing around the menus. You can see accounts payable right here. That’s where we’re, we’re going. And here’s the vendor file. So if I hit enter here, I can just start to browse a file, just like a typical global data file. So this is Venfill00 that we’re seeing behind the scenes, okay?

So that’s like the environment that our that the audience probably has similarly running in-house right now. Okay? So Joel, let’s see what we do. Let’s take this Venfil00 that file and convert that into a RTG-managed data file. Okay? So the way we’re going to do this here is, I’m not going to go through the entire process. I’m going to more show it to you because I have the demo working in the background, and I don’t want to go through the whole process in details. You guys might want to watch tomorrow and on the next day. I’m going to show more like in details how this works. Right now I’m just going to explain the steps here, okay? To preserve the, to preserve the demo we have in the background.

So the very first step here we want to do is we want to extract the data coming from your original data file, right? So we want to take the Venfil00, and read all the data that’s inside the file, okay? So the way we do this changes depending on our COBOL environment. In this case here, we’re going to use a utility from AcuCOBOL called vutil with the dash and load option, okay? Fairly simple. All you have to do is to run the application here, you can see I extracted the data into a dump file, okay? And that’s it, right? This is just ready to get the data, but to make sure that our demo works, and I don’t want to mess up with my file, let me take the original file, Venfil00 and move it to a backup file.

So there’s no more of Venfil00 at this point. And to prove that this is not just slideware, that’s not just click bait. Let’s prove it here really quick. Let’s go back to the application and show it here. Like let me type the right password. There you go. It’s the secret password. Cannot tell anyone. So come back here in vendors, and you can see that now there’s an error in application, right? So this error here is very, probably, sadly familiar to some people because that’s what happens when there’s a corrupted file going on. So in this case, it’s happening because the file’s not there anymore. We just moved the file, right? we’re just in the process of creating a new file. So the way to create a new file from this point on is just an extra few steps.

And what we want to do here is to make this Venfil00, that file become a RTG file. Okay? So here’s where I’m just going to show you how to do it. I’m not going to do it, but the very first step would be to create an empty file on RTG. So you can see I use now one of our utilities called ctutil with the dash make option, okay? And I have many different ways to create the file. I’m going to use, in this case, the external file descriptor, xfd file. Just because we have them, you don’t have to, but the xfd for those that are not familiar, has a description of the data schema for the file, okay? If you don’t have the xfd, we have other ways to create this here, but I would do this, I would run this command ctutil dash make Venfil00 and create an empty file, okay?

The next step would be after I create an empty file, I would import the data from the original file set. So still using the same utility ctutil that we have. but now with the dash load option, you would run from the dump file, you would run a load into your Venfil00. Now a RTG file, okay? So this is essentially extracting the data from your original file and importing the data into c-tree, okay? With the add option here. So just adding additional records, okay? And the last step here would be, at this point here, I would have a full RTG file converted from your original data file. But the application’s still not working because the file is under RTG. But we have one less step, which is telling the COBOL runtime that for this file, I don’t want to use Vision, I want to use RTG as the file system.

Joe Darnell
So one of the things we talked about is like they can take a phasal approach to this. Some customers move everything over, some can do it in certain phases, correct?

Evaldo Oliveira
Yes.

Joe Darnell
And for the purposes of this, we’re moving one file, but we can move the whole systems over. And this is also something our engineers can work with you guys on if you give us a call.

Evaldo Oliveira
Yeah, that’s very important because if you remember, Joe, you saw we added a file system, right? So we’re not forcing anything to change here at this point. I’m going to tell the COBOL runtime that, hey, for Venfil00, I want you to use c-tree instead of Vision, right? Vision’s still there, but for this file, I want you to use c-tree. This particular step changes depending on the COBOL runtime you have and the COBOL compiler you using. For vision, the way to do this is by setting up an environment variable with the underlying host name on the name of the file. So it’s fairly simple. All I have to do is this, okay? And now if I go back to my application let me run the application again. You’re going to see that at this point here, log logging in again on 00 company, right? You’re going to see that, now, if I go back to vendors, you can see that it’s working again and I’m browsing the data file. But now this is a RTG file,

Joe Darnell
Right? So now we’re going to take advantage of all the things that c-tree has to offer.

Evaldo Oliveira
That’s correct. This file, Venfil00, at this point, is completely protected. You’re not going to have data corruption going on in this file anymore. No, it’s protected under our transactional system. So it is already with transaction on. So what that means is that we can recover automatically into the file if, if there is any problem or something. So you, just by doing this simple step, you could back up this file if you want. So we protect everything here on Venfil00.

Joe Darnell
Yeah, I think that’s a critical point there, the fact that we can guarantee that file, the auto-recovery of that file.

Evaldo Oliveira
Yeah, exactly. And then you mentioned some of the additional benefits. it’s not the focus for today, but let me show this anyways. To make it easier for us to run it on the demos, I’m going to make this file available on our SQL interface as well. Okay? So to do that, there’s one final step. You don’t have to take all your COBOL files and make them available on SQL. you can do it one by one, but we, we didn’t mention here was kind of briefly mentioned, but the moment c-tree RTG is installed, you not only protect all your data, you get a full SQL server on top of your COBOL data. So we do it, it’s our SQL server, it’s our rational database, it’s also transaction controlled. So what that means is that you can run transactions on the SQL side and also on the COBOL side, the way to do this, still using ctutil and now extensively using the external effort file descriptor because this is where we get the data type mapping from COBOL to SQL, but with an option called SQL-lize.

Joe Darnell
Is that a FairCom term?

Evaldo Oliveira
It is a FairCom term, yes. We invented the SQL-ize COBOL data. What it means is give access to SQL through our SQL server to COBOL data files, okay? fairly simple process to be done here. And once I run this command here, I can switch over. Let me switch over to some of our set of tools. We have several of them. I’m going to show some of them here today. Lemme switch over to what we call the SQL Explorer tool, right? So you can see SQL Explorer in this case SQL Explorer is connected to the same machine. We’re running the demo over there where c-tree SQL is running as well. And like I mentioned before, we have a full SQL server, right? So it supports store procedures. We have triggers, you know, we can, you can do views, for example, building across views.

And that particular file Venfil00 is right here. Okay? So this is now a COBOL data file, but it’s being seen and managed as a SQL table from our SQL Server side. So we’re not duplicating any data here, Joe. This is exactly the same file, okay? And if I come over here and, and click on table records, you’re going to see like it’s going to load. Here we go. That’s the same file we’re seeing there. And it’s quite interesting. We can show you some examples. We’re going to show in a minute here how this goes. What happened here behind the scenes was essentially a SQL query that you can now just run SQL. This is a topic for our webinars tomorrow and the next day, right? We’re going to show in more detail the advantage of our SQL interfaces for us. Here’s an easier way for me to show you what’s going on when you build a Failover, how you can use this technology to build a Failover server and protect a hundred percent of your data. Okay?

Joe Darnell
Yeah. I think if they find this interesting, the fact that you have real time access to that COBOL data, once you let c-tree manage it, it’s pretty interesting. So check out the other webinars. Definitely, we’ll dig a little more into it.

Evaldo Oliveira
Yeah. And now let’s switch over to show you how we can protect this data with a separate machine that is a real-time replica of your main data. So because we are a database managing all your data files from this point on, in this case just Venfil00. But in more typical scenarios, everything. You can tell our database to create replicas in real time of this main database. And to do that, let me switch over to another tool we have here called Ops Manager. Okay? So ops manager is for operations manager. and what it does is that it’s our graphical user interface allows you to manage a farm of RTG servers. You can see here we have the main RTG server running here. This is the one we’re running right now, but I also have here set up a second one called FairCom S centos, right? So this is my replica, okay? This is where I have a Failover. It’s a completely different machine. Let me show you here, let me bring it up here. So you can see it’s running a completely different environment. I have c-tree running here in the background as well. Let me bring it up here to show you. Like, here’s c-tree server running in the background over here. Okay? So a completely different machine with a replica. It’s designed to be a replica of the main server here. Okay?

Joe Darnell
Well this is a great user interface because it doesn’t matter the topology of the architecture in your network. You can set up a hub and spoke. You can set all different scenarios up. Again, we allow you to customize this.

Evaldo Oliveira
That’s correct. All you have to do is to drag and drop information from here and there, you see? And that’s how you build replications, right? So in this case, I already have what we call a replication plan design. Here, let me double-click and show you what it looks like. So what is a replication plan? This is all based on our transactional engine and our realtime replication capabilities, right? So what we do is we design a solution that’s based on publisher and subscriber concepts.

Joe Darnell
So, very similar targeting source?

Evaldo Oliveira
Yes, exactly. The source server is the publisher. So any RTG server here can publish information, okay? And then what it does, is it decides which files it wants to make available for other servers to subscribe to. So in this case, I already have a subscription running here. But let’s take a look at this. Like, for example, I’m going to look into the publisher side. So what happens here with the publisher side, you can see, Joe, down here, I have Venfil00 that I already published as one of the files. I want to be able to share, okay, so the way this works is I come over here in root. No, we don’t want to switch anything here. Let’s just leave it alone here. Don’t, I don’t want to mess up with the blind here. . Yeah, essentially we show you all the list of files that you have over here. We can scan it remotely. You can see that there’s some options here, like local directory or remote directory. And you pick whatever file you want. I want this file here, Venfil00 which is the one we just converted, okay?

Joe Darnell
And you can publish different plans too. So if you have different servers that want to subscribe to different, different parts of your plan, then you can set up multi-brand time plans.

Evaldo Oliveira
That’s correct, yes. In this case here, we want to make sure that this server is publishing Venfil00 for whoever wants to have access to that data. In this case, who wants to have access to that? It’s just a second machine, right? We want a centos machine to see the data. So I can just hit preview here. You’re going to see this is telling me where the target server is going to store Venfil00.dat. Okay? So it’s just a folder and you can decide it and you really, you can put it in different places. You know, you can have different controls. We do support bidirectional replication. Bidirectional replication always. We always strongly recommend to be careful because of data conflicts. We have some tools to manage that conflict. But in this case here, it’s just a simple replication one-to-one.

Cause all I want is to build a Failover machine for the main one, right? So that’s the concept of the replication. This replication plan in this case is already published and it’s already up and running. So everything that’s happening on the main server over here is actually already being pushed on the second server over there. Before switching over to show how this works, let me show you some other options here. this is a full system that allows you to control and monitor what’s going on with replication. So you can see there are many different options here. Like for example, I want you to remember the last position you were on the transaction side to make sure that you recover. In some cases where you don’t want to degrade old transactions, for example. We have options where you can pull or you can push the data and all that changes a little bit in terms of performance and what you want to do.

So we give you all these controls. Here we go all the way to tell you like, I want to turn on some warning alerts for, depending on the latency on the network, right? Network is always something that’s a little bit out of control. So if you have a replication set up, you can tell our server, Hey, if the second server is more than 30 seconds late in terms of the transaction where it’s supposed to be, raise a latency of warning for example. Or even turn something like if it’s more than 300 seconds delayed, maybe network is down, and actually the server is already wrong. It’s too far back. So don’t use it as a Failover, for example, we have all these alarms ready for you, okay? Yeah. So it’s fairly simple to use it, okay? The only way to go here, you can see there are some indications like graphical integrations.

This is green because it’s actually running. and I can come over here and see what’s going on with this replication plan. Like you can see here all the statistics of transactions that happen, you know, and everything that’s going on. We show you the latency. let’s see this actually live and running, how this works, right? Let’s come over here. So let me switch over here. So I mentioned this is the table sitting on the main server, we just convert, right? So what happens if I come over here in one record like this for example, and I don’t know, change something here. Like for example, change the name of one vendor, huh? Just to enter here. So I just updated one of the vendors here, changed his name from Wordify to Wordifying, okay? Just to show how this is actually real stuff, right? Let me go back, let me get application running here. [Inaudible]. So this is all going on in the main server, right? So this is like typical. How it would be if you had your own application running over there. If I go back to the application, you can see if I come back to vendors here you’re going to see that it changed already to Wordifying, right? So this is the same data set, right?

Joe Darnell
That’s great. The realtime access to that data without any source code changes,

Evaldo Oliveira
Correct! Yeah. So in this case, what happens is that behind the scenes here, I run a SQL query and update SQL query and updated the data just because I was using our SQL Explorer interface, but you don’t have to, whatever changes in COBOL will change here as well and so on. But the beauty of this is that now because we have replication running here, I’m pretty sure that the change adjusted here is already replicated over here. So let’s take a look at that and let’s switch to the second server. Okay? So here’s the second server. I already have it open here just for the sake of simplicity and time for the demo, but I can come over here to Venfil00. You can see it’s the same file over here that we replicated. if I go to table records here, you’re going to see in a minute, here’s the data. And you can see Wordifying here as the second as the data that was changed and replicated over there, right? So this can go on and on. Like for example, let me do something here, just to show the whole thing altogether. If I come over here and move it back to Wordifying, for example, let’s say someone changes something here. Now I move back to Wordify over here. No.

Joe Darnell
Now you’re just having fun with this.

Evaldo Oliveira
I do have fun with this. Yes, , I can come over back. Let’s look into the activity. You’re going to see those transactions are right here. So they just happen, right? So it shows the latency, they were immediate transactions, so they didn’t take any time because it’s just everything running in the same network here. So it’s really nice. You can see a lot of extra information coming in here from the servers. You can see those that didn’t work if anyone didn’t work, we have the exceptions and so on. But then let me go back here to the SQL Explorer and just hit refresh on this guy here and load this table again. And you’re going to see that it changed back again to Wordify here. So replication is live here and running and making sure all the data is going across each one of the servers. So at this point, Joe, this FairCom S Centos server right here is a Failover for the main server over here with all your data sets on COBOL available in real time and you can do whatever you want with this data.

Joe Darnell
Yeah, so you probably do whatever you want with that data that, you know, there’s lots of good opportunities here. You know, one person may come to us and be like, well we want to use it as the Failover scenario, or we may want to use this as a reporting server and query against it and hook our BI tools to it so it doesn’t impact the production environment.

Evaldo Oliveira
Exactly. Yeah. So now let’s simulate a crash, right? Let’s, let’s get into the fun zone here. So let me take out here and let’s assume that you had a problem with your main application and something happened and it’s not working anymore. So the crash here, I’m going to simulate the crash just by running, I’m just going to stop our server, c-tree server in this case, it’s just a simple way, right? I don’t want to pull the plug here, it’s going to take too long to bring everything back. But let’s assume I stopped my server here, c-tree server right now and just — so if I stop c-tree server, if you remember, c-tree server was in charge of Venfil00, right? So Venfil00 should not be working anymore and it will simulate a situation where the application is down. Okay?

Joe Darnell
So, I shouldn’t have access to it.

Evaldo Oliveira
Yeah, exactly. So if I go back to the application, we have to wait a few seconds here just to make sure that the server is shut down. If I wait, and I go back to the application at this point here the application and try to read Venfil00, you’re going to see the duplication has an error and it’s not going to work. Let me see if this server is done already. Sometimes it takes a few seconds because we have lots of connections going on here behind the scenes. Yeah, the server is done already, right? So I can switch over here, and you can see Ops manager shows that to you. It’s grayed out. This means the server is not up and running. Replication now is in red, shows to you that its replication is not working right now. You don’t have to worry about any of this. We recover automatically everything for you. So when it comes back, we just catch up again. You know, everything will be in good shape again. We make sure everything is fine.

Joe Darnell
So now you can use that as your production data and now while you work on the original production server, right?

Evaldo Oliveira
Exactly. So now FairCom S, centos is still running. So all I have to do is to switch over to switch my application over here. Before we do that, let’s see if the application is actually down, right? So let’s make sure the application is not — we’ll go back to the application and try to read that file again. And you’re going to see that I can type really quick here. So, you can see there’s an error of Venfil00 site. The application is down. That’s the panic you were talking about in the beginning, right?

Joe Darnell
The system down. Panic.

Evaldo Oliveira
Panic, yeah, exactly. You don’t have to panic anymore. No panic anymore because now, what we have, we have a second server real time available there that all you have to do is to switch your COBOL application over there for us. That’s fairly simple. All you have to do is to tell the COBOL runtime, Hey, don’t connect to the server, connect to the remote one. So again, for vision, just set up an environment variable. There are different ways to do this, but at this point here already, let me show you this configuration file. This is one of our internal configuration files. So if I take a look at this here I can copy it, right? Right. Here you go. You can see this configuration file is pointed to the FairCom centos server. Okay?

So I’m telling it, hey, connect to a different machine for a Failover. But once you do this, if I go back to the application here and run the application again at this point, application will show you we’ll connect to the second remote server over here, go back to vendors, hit f1 and you can see it’s up and running again. And it’s back. And to show you that this is not just slider again, let me go back here to, let’s go back here to SQL Explorer and show that this is the centos machine. So what happens if I come over here and change this guy to Wordifyance, whatever, right? Let’s put something weird here. Okay? So like this, okay, new startup of a vendor here came up. Wordifyance. Let me go back to the COBOL application and let me go up here to the vendors. Let’s scan this file again, and then you can see it changed to Wordifyance, right? So this is how fast you are able to have a Failover machine just by adopting FairCom RTG and putting your files to be managed under us.

Joe Darnell
You know, I think the great thing is a lot of people can identify with this because it exists out there, but a lot of people don’t know that it exists for your COBOL data. Yeah. And just like letting c-tree manage that opens up the doors to it.

Evaldo Oliveira
Absolutely. Yeah. So remember everything we did here, just to recap, Joe, is that we took one file and we put it under RTG management, and that means we are on transaction control. RTG has a full set of tools. So I’m going to show some of them, like for example, we have something called c-treeACE monitor. That show shows you all the locks, you know, everything that’s going on behind the scenes. I have to reconnect the server here. I don’t want to go into that, but like we have other tools. Like for example, we have, we have gauges. Okay, where are my gauges here? See if we can show them there are here somewhere, here are the gauges, right? So we have additional tools that allow you to connect and keep monitoring your file, your database. So these are all benefits that RTG immediately brings to the table. But then beyond that, we allow you to create replicas. And you saw only one replica. But the most common scenario with our customers, Joe, is that they end up building multiple replicas. They have a hubs spoke architecture or a chain architecture where some of the data goes for SQL. Some of the data goes for Failover.

Joe Darnell
And they’re running DR in different data centers. I mean, it gets pretty complex with some of these, some of the key customers.

Evaldo Oliveira
Yeah, and very sophisticated. But you see now at least you can do the planning, right? You can do the Failover.

Joe Darnell
It’s good and bad. Right? It could be as sophisticated as you want it to be.

Evaldo Oliveira
Yes, exactly. Yeah. So that’s the demo. Joe, let me switch back over to the slide sets here.

Joe Darnell
Well, thanks, Evaldo. I think we definitely got some more COBOL there.

Evaldo Oliveira
Yep.

Joe Darnell
And as you guys, as you can see on your screen there, this is, we talked about the replication for COBOL. This is kind of an overview of it.

Evaldo Oliveira
Yeah. Replication is the key point here. Because, again, because it’s transactional, as you see it on the slide here, you can see the log file. These are transactional log files that we keep. Because it’s a transactional database, what we do is we allow, on top of the transactional log, everything that’s committed can be replicated somewhere. So you can think about this as a way to transport data and get it anywhere you want. We give you some callbacks capabilities, so while you are doing the replication, you can transform this data. So we have customers using that to mask personal information. For example, take the data from the production environment, replicate it to developers, but mask personal information. There are many, many different ways. I think the possibilities are really huge here.

Joe Darnell
I mean, we have an evolutionary system here and allowing your COBOL to be a part of that solution. I emphasize “solution,” because I think we’ve reiterated the fact that everyone comes to us for different reasons. And a lot of these companies chose us for high performance and reliability.

Evaldo Oliveira
That’s correct. Yeah. So I think the critical summary here is really that this is a full database managing your file system. Quite different from what you have today. Right now, most of the problems you have today with your COBOL system are relying on the fact that the file system is not very robust and has not been designed for the volumes and the mission criticality that you have today. So once you adopt RTG, you get a transactional database taking care of all of your COBOL I/O. Okay? We introduce transactional automatically. You have automatic recover, you don’t have to worry about situations like a crash or something. We bring it back. You have hot backup with guaranteed restore and full security

Joe Darnell
And no need to change the source code. I keep on saying that, it’s very important, but that’s great for people to understand. When you guys reach out to us and work with us or engineers, we work with you one-on-one, you’ll see that. And I think they got a taste of that through your demonstration there.

Evaldo Oliveira
That’s very critical, Joe, because you saw in the demo, we didn’t show a single line of COBOL code. You don’t have to, we don’t have to touch the COBOL codes to bring this kind of benefit.

Joe Darnell
So it’s my situation unique or whatever? Have you seen it? Well, what’s our saying around here? Not in the mainframe. We support it.

Evaldo Oliveira
That’s exactly right.

Joe Darnell
We have lots of different partners out there. Like I said, we’ve been around for 40 years and we keep on evolving this product year over year, over year. So we’ve got old versions, new versions. So don’t be embarrassed if you’re sitting there like, “oh, my version’s way too old or you haven’t seen this or you haven’t been a part of that.” We have great partners out there as well.

Evaldo Oliveira
Yeah. Yeah. I guess you can see a list along the list is really long. You know, this is just a partial list. We support way more than that. The very first one is Veryant. Veryant is a very good partner for us from the beginning. They have a very cool COBOL solution called IS COBOL that takes your COBOL application, converts it to Java, you know, and lets you run anywhere you want. Well, RTG is the OEM file system natively coming with is COBOL. If you haven’t heard about them, encourage you to check them out, it’s really nice. But we support AcuCOBOL, which is what you just saw in the demo here. All kinds of different versions, you know, even older ones. Micro Focus, we go back all the way to version 3.0, this is from the 80s. Micro Focus is a partner as well. So we go all the way up to the latest and greatest Visual COBOL, but even RM/COBOL, you know, and all kinds of different platforms.

Joe Darnell
Exactly. And when we talked about keeping the TCO low, you know, lowering the cost of this process, your vendor maybe wanting to get you new runtime licenses and, well you, you know, you just have to move the data over. You know, you want to move the red hat or something like that.

Evaldo Oliveira
Yeah, and I guess the message here is really don’t be shy. Okay? Don’t think your environment is too old or Oh, I don’t think they support those platforms. Don’t worry about that. Okay. We’re very used to seeing all kinds of different old operating systems. We have customers running SCO, we have customers running NCR Unix. We can help everybody. And if you have some kind of different COBOL that you’re not used to, let’s say a less common one that’s not in the list here, talk to us. Okay. We’re always open to see how we can help you.

Joe Darnell
Well, as you can see here, here’s just a summary of all the features and advantages of the complete solution RTG has to offer.

Evaldo Oliveira
Yeah, it’s a good summary. Again, connecting back to the list of customers we mentioned in the beginning, this technology has been designed for mission-critical, high-volumes environment. If your COBOL system is hitting this threshold right now, or has hit this threshold a few years ago, you are probably suffering this problem. And it has nothing to do with the COBOL language because it’s old, blah, blah, blah. We don’t think about that. You know, we love COBOL. We need more COBOL, right Joe?

Joe Darnell
Always need more COBOL.

Evaldo Oliveira
Yeah. We are here to help you protect your investment in your COBOL system and the list of benefits that we can help you if you switch the focus to the data is immense.

Joe Darnell
Yeah. I mean, you know, we really appreciate, you know, you guys coming out today for one reason. We’ve got two more days of webinars. This is just day one of all them. We’re just getting started here. Yep. I think we’ve talked a lot. Evaldo showed you a great demonstration or at least a teaser into what we can do. Now it’s time for the free stuff, right? At the end of this webinar. So don’t just log off when we close out the webinar, you’ll get a short survey. Just let us know how we did what you would like to see on future webinars. And everyone who submits the completed survey gets this cool free RTG Dino shirt.

Evaldo Oliveira
Yeah, that’s the Axe. You see, Jeff asked me in the beginning. So that’s where you see, we think COBOL is a beast, powerful beast. Well, we are here to help you to make it achieve new heights. You know, let’s tame the beast together.

Joe Darnell
Exactly. Here’s just a brief view of all of our webinars. You know, tomorrow we’ll be here at the same time talking about realtime analytics. And then Thursday we’ll be talking about how to modernize your COBOL applications by developing new modules, PHP, Python, and Java. It’s a little bit of everything. It’s just a complete package really for the FairCom family.

Evaldo Oliveira
Yep. We’ll be here tomorrow again, hopefully with cameras.

Joe Darnell
Well, we really appreciate it. As you can see on your screen there, go to FairCom.com/rtg and download a free evaluation copy. Once you do that, save some time and effort. Like I said, we’ve seen it all. Contact us. Give us a call on the 800 number there, 1-800-234-8180 or you see Evaldo and my email up there. Just reach out to us. We’ll work with engineers, we’ll get you one-on-one. We’ll kind of work through the demonstration like we did, and also for a limited time right now, $5,000 proof of concept.

Evaldo Oliveira
Yeah, that’s critical, Joe, because we like proof of concepts. We know that everything you saw here probably looks a little bit familiar, but the truth is that it’s really much different for you to make a decision if you see it working with your own environment. So we are here to help you. If you want to see how RTG would work with your application, talk to us. Like Joe said, for a limited time here, we’re giving you a $5,000 value proof of concept help, just to get your application up and running and give you a taste of what RTG can do for your COBOL system.

Joe Darnell
I mean, it’s all about time and money, right? So we offer our time for free and expedite their time to process this. I mean, it seems like a win-win. Evaldo, you did a great job today. I’m Joe, this is Evaldo. It’s been a lot of fun today. Day one of three. Right now I’m going to kick it back to your MC and host, Jeff.

Jeff Wood
All right. Hey, Joe and Evaldo. Thank you guys so much. I appreciate that. That was some awesome information. Before we get going though into the wrap up, I want to I’ve been asked to for you guys to elaborate on a couple of questions that actually came in that would be of benefit to our audience. the first one’s kind of geared towards a Evaldo and is dealing with the gentleman who basically has an international company. He has a base in us and he’s got some places in South America and also in Australia and also in Europe. What’s the reality of him being able to have this replication, you know, cross-continent, or is it more recommended to keep it in-house or what? What’s your thoughts on that, Evaldo?

Evaldo Oliveira
Well, it’s a very good question, and we did not mention that, while talking about our references, but FairCom is a global company. So we have customers all around the globe and we support many of those customers in 7×24 support options. So we have the ability to get across-the-globe support if you need, because, of course, we understand how mission-critical environments are. Right. But to your question, I guess about using replication and international then across global system probably to be able to Failover, I would recommend you to keep it in the same data center if you’re going to use replication for that. For the Failover purposes that the main purpose, it’s going to work across different states or across different cities, for example, or even across countries. The challenge is going to be in network latency.

So if you feel like you have control of that, and even in desperate situations should not be a problem if you are okay with all the latency. And so we give you all the alerts to control of that. I think probably I would recommend to have a Failover server in the same data center using real-time replication and then maybe a second server somewhere else for a disaster recovery. we’re probably talking about city to city, not country to country just because of the distance and the latency here. It’s going to work because it’s all TCP/IP based. But you might start to see some big latency coming in because of the network.

Jeff Wood
Awesome. Evaldo, thank you so much for that. I appreciate that. Joe, we have one more for you. And actually, you know, I’m kind of biased cause I think I already know the answer, but the answer or the question deals with what’s the actual cost of RTG? And my answer is it’s priceless because, you know, you don’t have to touch your code. There’s a lot of things you’re saving manpower. You’re, I mean it expedites a whole lot of things, so I consider it priceless, but I’m also a little biased cause I’m a FairCom employee. So what are your thoughts?

Joe Darnell
That’s a great point, Jeff. Unfortunately, most people don’t want to hear priceless. Though it really is a key factor that we want to be a valued partner with our customers. And we take more of a personalized approach. So give us a call, reach out to us, we work with you and customize our pricing model with your particular environment and your particular needs. It’s not a one-price-fits-all, so we really capture your particular needs and can work with you on a price. Remember, RTG is a full solution.

Jeff Wood
Awesome. I appreciate that. Thank you so much, Joe. All right. Wow. Thanks guys. I think that does it for us today. I want to thank everybody for joining us. We hope that you learned something useful. Valuable links and contact information are listed on the slide within the presentation window for your convenience. If you’re ready to learn more, consider joining us for additional webinars. Tomorrow we talk about COBOL application monetization, and the next day we’ll focus on real-time analytics over your COBOL data. At the completion of the series, you’ll find all these webinars, including today’s available to watch on-demand at the link provided in the chat area. Also, please feel free to reach out directly to Evaldo and Joe if you have any direct questions. Their emails are right there in that presentation window for you. Go ahead and jot those down if you need them. But thanks again. We hope to see you next time. Oh wait, hang on. Before we sign off, don’t forget to fill out that survey in order to receive your Proud Dino COBOL shirt. When I close out the webinar, a pop-up window will show up, and when it does, please click the close button to immediately receive the survey. All right, guys. That’s it. Sign off. Evaldo, Joe, and Jeff. Thank you.