On-Demand Webinar

What Happens When IBM i Enters the Windows World

How Robot enterprise scheduling extends advanced automation to the other operating systems in your environment
IBM i, Windows
Recorded:
April 27, 2017

 

IBM i does not exist in a vacuum. In most modern data centers, IBM i servers stand next to Windows servers, passing data back and forth and sharing the workflows that keep business running. Even if your IBM i environment is 100% automated, you stand to lose that control when you step into the Windows world.

No matter which platform your data comes from, your goal remains the same: accurate and efficient processing above all else. You know automation can get you there, if there were only a way to extend your tools onto another operating system. Lucky for you, there is!

In this 30-minute session, our automation experts will demonstrate how Robot Schedule and its enterprise extension help you manage Windows workflows and more from IBM i, including:

  • Triggering complex tasks such as report balancing
  • Establishing job and file event dependencies across platforms
  • Entering correct parameter values
  • Fitting a process into daily, weekly, or monthly cycles
  • Ending on-call headaches and firefighting

It’s time to synchronize scheduling across your servers, integrate your business applications, and take the word “manual” out of your computer processing. Watch now to see how Robot puts cross-platform control back in your hands.

A complete transcript of the webinar is below.

 

Chuck:                 Well, hello everyone and welcome to today's webinar, What Happens When IBM i Enters the Windows World. Coming to you from beautiful Eden Prairie and Rochester in Minnesota here in the USA. Thanks for joining us.

Chuck:                 So here's the scenario. You have a batch job on IBM i that's waiting on a Windows file. You schedule the IBM i job to run at 6:00 p.m. because you're pretty sure that Windows extract file from the website will be available by 5:45. Ah, but the marketing folks decided to delay the order extract from the website until 7:00 p.m. because of a big sale, but they didn't tell you. So that evening at best there's a delay while you figure out what went wrong, or worst case, no orders get processed in orders are ready for shipment by the night crew. There's a better way to integrate your IBM i, the backbone of the organization, into the Windows world and that's where we're going to talk about today.

Chuck:                 My name is Chuck Losinski. I'm the director of automation technology for the robot product line here at HelpSystems, and every day I speak with our customers to discuss solutions we have for automation, business intelligence, security document management, and IBM I, as well as other server technology. My co-presenter today is none other than Mr. Document Management, Richard Schoen. Hi, Richard.

Richard:              Hey, Chuck. How are you doing? And for people who don't know me, I'm director of document management here at HelpSystems. I've been here since 2014 when my business was acquired, and along with Chuck I'm part of the technical solutions group bringing these types of topics to our customers and prospective customers. I have the distinction of having 29 years now background with IBM i, Windows, and Linux platforms and managing delivering forms of documents and helping with process automation. Just like Chuck, we're very busy going on that topic.

Chuck:                 All right. Richard, I'm going to turn it over to you to talk about what we're going to talk about today in the webinar.

Richard:              Sounds good. Yeah. So our plan for today is we're going to go over a few highlights from our 2017 IBM i marketplace survey. We'll review what we're seeing in regards to Windows and other non-IBM i servers used in conjunction with IBM i, and then we'll spend some time covering three interesting reasons you may want to integrate your IBM i on your Windows servers, and then along the way, Chuck will also be giving us a few technology demos as well to illustrate our integration technologies in action. If you do have any questions, make sure to answer them in the chat window and we'll address them towards the end of the webinar, and then today's webinar is also being recorded and you'll receive a link after the session.

Richard:              Well, let's talk about what we're seeing happening in the marketplace. All right, so these are responses from by about 500 of our peer IBM i businesses on the survey, and as you can see here, 67.6% of respondents have Windows servers in place, which is no surprise to me to run apps such as email, web servers, et cetera. 7.6 to 13% of respondents also have Linux or AIX as additional platforms in place as well, and we see a lot of that, I know, in our customer base. This is an indicator to me that most shops that used to rely only on IBM i for their business systems have also embraced Windows- and Linux-based systems to augment IBM i processes. I would guess that a large percentage of those shops are also embracing VMware or Microsoft Hyper-V as their virtualization platform of choice. And then for those of you who aren't aware of the Windows and Linux world has embraced VMware for virtualization much the way IBM i shops have for their IBM i partitions. So on a single Windows server you can often house several virtualized Windows or Linux servers.

Chuck:                 Richard, we do have a polling question related to this talking about business process automation challenges as well as how many Windows servers integrate with IBM i. We're going to open that poll now and you'll have a couple of minutes to respond.

Richard:              Perfect, and while that goes on we'll continue. This slide speaks to the continued strength of the IBM i platform in our shops. IBM i is still critical platform in 41.7% of our survey respondents, and then for 30% of you, at least half of your workloads still run on IBM i since critical systems are often hard to replace, and then about 13 to 15% of you may have a few critical applications on IBM i where you haven't been able to find anything comparable on another platform to what's currently out running on IBM i, so that's a good thing about our existing systems. That also means almost half of our businesses are committed to IBM i as their ongoing business platform for their most important work. And also most of you are committed to running at least one or more critical apps on IBM i moving forward. So if you couple of that with some application modernization and educating management on the importance of IBM i, those numbers should hold pretty steady in 2017 and 18 and beyond, we hope.

Chuck:                 Yeah, and an interesting tidbit from our marketplace study included the fact that about 7% of the respondents to the marketplace study are running SAP. I was just mentioning to Richard, I was at the SAP summit just this morning in Rochester, Minnesota. Ducked out to do this webinar, but a lot of modern applications obviously and with modern interfaces running on IBM i.

Richard:              Awesome. All right, so in this slide ... so in 2017 we had over 65% of our respondents who are running lights out automation fully unattended. The figures up from, it was 55.6% in 2016 and 50.3% in 2015, so definitely going in the right direction. Some of this can be attributed to management bringing in automation software to help future-proof daily operations, as one of the trends Chuck and I have been seeing is some of the older IBM team members start moving towards retirement or maybe other areas of the business or maybe into management. So if fewer people are out there with IBM i operations experience, management is embracing full automation in their shops to run jobs and monitor systems, and I would guess many of those people are using software such as Help System scheduling and monitoring software to run their IBM i automation.

Richard:              And then of the 34.3% respondent shops who are not fully automated, many of those shops are old school and say they prefer to have staff manage critical processes. Some say that automation isn't a priority for management and about 20% say their processes are way too complicated for automation. Chances are over the next few years, though, those teams will start to embrace more automation as they realize the benefit, and we're always happy to talk to anyone who thinks their processes are way too complicated to automate and give them ideas about good ways to automate their processes. Between Chuck and I, I think we certainly have lots of good ideas on what to do.

Chuck:                 Oh, absolutely, and our support staff has worked obviously with thousands of customers over the years. We've got a lot of documented key studies and options that you may not have heard about. So speaking of talking to customers, I speak with probably 300 or so different customers every year, and I have been doing that for quite a number of years now. This is what we're hearing in talking to our customers through technology updates and roadmap conversations is, first of all, I have never heard of an overstaffed it department that has IBM i in it. Typically the staff that is out there supporting multiple platforms, programmers and application developers are typically very much involved with day-to-day operations and administration staff. In fact, it's not unusual. I just had a conversation last week with a gentleman who was the programmer and the admin for a smaller power system running maybe three partitions supporting a fairly large manufacturing company.

Chuck:                 But here's what's going on. We've got more and more younger staff coming in. I know it here at HelpSystems we're definitely doing that and we're mentoring them on the INI, and they bring a lot of knowledge on other platforms, obviously, especially Windows and mobile, and so they're able to reflect a little bit differently on some of the options that are out there.

Chuck:                 So that's one of the issues that we see as small staff. Another issue we see is multiple schedulers. People are used to using Cron, they're used to using the Windows task scheduler and maybe even the native scheduler on IBM i. In order to coordinate the tasks between multiple platforms, they use what we call timer jobs, and we've all done it where you've got a process maybe running on the Windows side, you're waiting for a data extract or something, and sure that's going to be done at 5:00 for sure, and so you can run your nightly process maybe over on IBM i at 6:00. But oh, low and behold, the ... maybe the Windows process was delayed or maybe it didn't run at all, but your IBM i process goes to run. it does its update, and there's nothing there to update. That's a big issue that we see out there.

Chuck:                 Another is compliance and SLA reporting. Based on all these activities that are running across IBM i as well as the Windows world, what sort of confirmation, what sort of documentation do you have that those processes ran and completed on time? Do you have notification in place? Probably not. What we're seeing is people need that backup documentation. They need to be able to run a report to give the management and they need real-time notification when things don't happen when and as they should.

Richard:              All right, so let's talk a little bit about a couple of topics I deal with a lot lately. App dev, dev ops, and RPA or robotics process automation are all topics we're hearing more and more about as we start thinking about helping our teams get more work done. Being able to automatically test and deploy applications is a great way to put automation wrappers around your build processes, which is what dev-ops is all about. Then most companies are choosing best of breed solutions for their IBM i and their Windows and other development processes. Often we hear terms like rational developer or team concert, confluence and JIRA and chef and puppet and Jenkins are all other buzz words and terms to describe how teams are automating their software build and deployment processes, so I feel like I'm hearing almost a new buzzword every day.

Richard:              We have software to help throw together and automate all of your core IBM i and multi-platform application development and dev-ops processes without forcing your team to rip and replace the best-of-breed build technologies that you've implemented. We also support robotic process automation, which is the process of automating many of the tasks that our users do today, such as file transfers, interacting with Windows and web-based applications to grab data from websites importing or extracting data to Excel or CSV or XML, or automatically processing inbound email messages or onboarding new users. Robotic process automation allows your job in test scheduling to go way beyond just running executables to actually helping your users do their daily work faster. Pretty cool stuff.

Chuck:                 Yeah, and Richard, our polling shows the following as far as challenges to business process automation. We see coordinating multiple schedulers. That came up about 20% of the time. Custom coding for event-based triggers, the same. Report balancing manual steps that are complex to automate. Moving extracts between servers. That was a big one. Audit reporting, not quite so big. Exception notification, not quite so big but still represented in our poll. It looks like the majority have one to ten Windows servers that they need to coordinate with, so that absolutely fits with what we're seeing in our conversations with customers.

Chuck:                 Okay. Let's talk about three reasons to integrate Windows tasks with IBM i. This I like to call visualization or dependency processing across all platforms, and we're talking mobile, too. We're bringing in new staff here at HelpSystems, and no doubt you guys are bringing in new staff. Any time you bring somebody new in to your environment, one of the things you have to help them understand are the business processes. Visualization is a big part of that. Being able to show them how processes relate to one another, not just on one platform but across platforms. So as one step finishes, could be on your IBM i system, could be on another platform, that is part of the equation when triggering, for instance, in your nightly process, and when your nightly process is done, that might trigger multiple concurrent processes both on IBM i as well as other platforms.

Chuck:                 So we need a couple of things in place here. We need a modern interface so that you can communicate this business process to the end user, and then you also need to be able to coordinate processes across those multiple platforms. Robots Schedule has been the batch scheduler of choice for many organizations for decades now. This tool's actually been around for more than 30 years. It launched the HelpSystems company for batch automation on IBM i, and it was a decade ago, Richard, that we brought enterprise scheduling to Robot. A lot of people don't even realize that Robot on IBM i on your critical server can also be used to coordinate with those tasks running on other platforms, Windows, Linux, AIX. There's built in file transfer, secure file transfer, and a new interface that we're going to talk to specifically in our second demo.

Chuck:                 We now interface also to Automate. Automate is a fairly sophisticated Windows automation tool that Richard is very much knee-deep in and truly an expert on this technology, and it's used for very sophisticated Windows automation. What I'd like to do now is I'd like to share up my desktop and let's take a look at what Robot Schedule looks like for the enterprise.

Chuck:                 All right, so Richard, let me know when you can see my desktop.

Richard:              I got ya.

Chuck:                 Okay. We're going to go back in history a little bit. I'm going to just slide over the infamous green screen. We still obviously have a number of customers running the green screen, but as you look at my list of Robot jobs here, you really have no idea how they coordinate with one another, so that's one of the answers that we need to provide is how our processes coordinate with one another. All right. The Robot Schedule GUI interface is a Java-based interface, has been available for over a decade now from HelpSystems for working with your IBM i jobs. But this is also the tool that we use to work with those processes running on other platforms. So the Robot Schedule Enterprise server is software that you install on your Windows, Linux or AIX server, and then you register it back to your Robot Schedule. Running on IBM i.

Chuck:                 So on my wisdom instance of IBM i and Robot Schedule, I have these agents that are associated back. So you can see I've got AIX server, I've got multiple Windows servers, I've got Linux server, and so on. I've got a number of servers that are registered. Some are active, some are not. As a matter of fact, if one of these servers becomes unavailable and it's critical maybe to your daily process or nightly run or what have you, we can implement offline notification so if that server becomes unavailable, you can be notified immediately, maybe even before the network or server people know that that server is not available. That's built into Robot's Schedule.

Chuck:                 Okay, so let's take a look at all the jobs that are running on this particular agent. A couple of ways you can look at task activity in the Robot Schedule GUI, I can first of all look by what I would call a group or what we call an application, but it could be a functional group. So in this case, we're looking at my accounting jobs. These jobs are a combination of IBM i as well as Windows tasks. Now I can also look at that same group of jobs by agent, so if I click on just one particular agent, these are the jobs that are associated with that particular Windows server, and likewise for all the other Windows servers or Linux servers or AIX servers. I can subset my jobs or sort out my jobs by that particular server.

Chuck:                 Okay, so let's take a look at one of these jobs. In this case, this job will process an electronic funds transfer. If you're used to looking at jobs in IBM i, this is going to look both familiar and a little bit different because what we're doing is we're going to be talking to a Windows server and we're going to be sending it Windows-type commands. We're not going to be sending it IBM i batch-type commands. So this job, CLEFT proc process EFT is looking at a particular Windows server, and I can select which server I want it to run on. So that's one thing that's different in your Robot job is you have to tell that job what server to run on.

Chuck:                 Now, all the scheduling and dependency options are the same in your enterprise-type jobs as they would be for any other batch-type job. I can either schedule this job discreetly or I can say that this EFT process, EFT job has some dependency, and I'm going to show you what this looks like visually. What I want to show you first is the commands associated with this Robot job. So I'm executing an FTP process. I'm moving data from my agent to the integrated file system and I'm also using some of the reserve command variable functionality to rename the object once it reaches IBM i, and then I'm executing a copy and delete.

Chuck:                 Now how would this look visually? Let's take a look at what's known as a blueprint. This is a job flow diagram or a blueprint showing those processes. My EFT process is right here and the rest of my batch and interactive process follows that. I've got several dependencies for my nightly process. I've got a daily backup. I've got a couple of file dependencies which we're going to show. So from this interface, from this job flow diagram, we can get to things like agent event history, so we can see when for instance a Windows file was added as far as our prerequisites go from this interface. We can also get to things like the job completion history, so when did this job run last, how long did it take, were there any warnings, and so on. That is built into the product, and you can also look at this data in our browser interface, which we'd love to show you one on one when you have a moment. All right, demo one complete. Let's move on.

Richard:              All right. All right. Reason number two. So for reason number two to integrate IBM i and Windows tasks, let's talk a little bit about report balancing. This is a phenomenon. What, about a year or two ago we started hearing about this, Chuck? I think it was about that timeline, wasn't it? We're hearing about this issue more and more often from some of our banking and our insurance customers, although I imagine any industry could have this type of operational issue. So let's look quickly at a sample automated balancing process opportunity where some information originates from a website, some from an IBM i report, so definitely two different distinct sources of data needing to be tied off. Historically it's been impossible to automate a process of this nature, but by using Robot and Automate, as Chuck was describing, we can do something like this, so your process might look something like this.

Richard:              Maybe today the user logs into a website and they navigate to a selected webpage and then they download a file from the site and they upload it to the ifs to get processed. Then after the IBM i process completes, the operator rates down some totals from the website and then they go back into the out queue on the IBM i and check the report totals from the process file against the anticipated totals from a report in the website, so if the totals match, the operator can submit the next process to run. Otherwise they might need to troubleshoot. So rather than performing the manual download and then waiting around for the IBM i process to complete, what if that entire process from logging into the website and downloading the file to checking the report in the out queue could all be automated from start to finish.

Richard:              The good news is that our scheduling and automation components can help automate these mixed platforms completely, thus helping operations team remove processes that are fraught with manual checks. Chuck, out on our next slide, it's another example of balancing workflow that Chuck's going to be demoing shortly. This is a bank balancing demo use to balance an FTP transfer with a processed report. This workflow downloads a file from a FTP provider, uploads to the ifs, then a file event will trigger using Robot Schedule reactivity, and then this event will run an IBM i job to process the ifs file and generate a report. And then Chuck will talk a little bit more about that as he's doing our demo in just a few moments.

Chuck:                 All right, so this was the latest update to Robot Schedule. If you have Robot Schedule Enterprise now, the Automate interface was added on the last iteration, so it's available on our website, and it's part of a built-in function builder functionality if you have Robot Schedule Enterprise. There's two components. There's Robot Schedule and there's an add-on called Robot Schedule Enterprise, so you need the Enterprise add on to be able to interface with Automate, and maybe Richard, you could describe to us what is Automate.

Richard:              Sure, yeah. Let's take a moment to talk about where Automate fits into the landscape for our customers. So often customers are using Robot or Robot Schedule Enterprise to run IBM i jobs that need to also run custom Windows or Linux commands like Chuck was describing. Historically, Robot customers have also used Robot Replay to automate writing those IBM i work loads from Windows by recording and automating playback to simulate an operator running a job from a 5250 session. So with Automate you can certainly automate 5250 sessions if desired because that's in there. But there's also 600 other automation activities you can use to quickly configure and define custom processes like our bank balancing demo that Chuck's going to be showing very shortly.

Chuck:                 All right. So let's jump into our live demo. Okay, so first of all, let's take a look at how Robot Schedule interfaces to Automate. First, let's take a look at the Automate task builder. I've got two Automate scripts created, one called balancing step one, one called balancing step two. Balancing step one is going to take data from another server. In fact, let me show you the blueprint. We do have a job flow diagram. Don't want to get too far ahead of myself. A picture's worth a thousand words, Richard.

Richard:              Absolutely.

Chuck:                 All right. All right, so here's our job flow. First of all, the Automate balance step is a Robot job that's going to run an Automate process, download a CSV file from the web, and then we're going to place that into an ifs directory. Now this step could run via a discrete time. Let's say at 6:00 p.m. every night you want to execute this process. It could run in a reaction to something else. It's all up to you.

Chuck:                 Now when we upload this file to the integrated file system, that's going to trigger a process, a Robot process called Invoices, so that's actually going to create the invoicing spool file, it's going to process the data into our databases, and all that's going to happen automatically. Robot's going to detect that the file is uploaded to the integrated file system, it's going to trigger the invoice create process in Robot, it's going to take that data and it's going to copy the audit report into the ifs directory, and of course we'll also see that in an out queue, and then this job could trigger the next balancing step. We're going to trigger some of this manually just so we can follow along a little bit better during the demo. That's our job flow.

Chuck:                 All right, so first of all, this is Automate and these are our two scripts. Our two balancing scripts as mentioned. Balancing step one's going to do the download and the upload. The report process is going to be triggered automatically in Robot. Then we're going to actually compare the two together using balancing step two.

Chuck:                 As Richard mentioned, a lot of different processes have been pre-automated for the Windows world. For instance, if you wanted to for instance, send an email message, you could just drag that here into your script and it prompts it almost like a cl program. I'm going to go ahead and I'm going to run this just from Automate and let's watch Automate do its thing.

Richard:              Yep. Yeah, Chuck, my favorite term is that it's cl programming for Windows.

Chuck:                 There you go. There you go. Okay, so we just ran the Automate process, and if I bring up our schedule activity monitor ... okay, I'm going to bring up our schedule activity monitor, so this is showing you what's been happening with Robot, and as you can see the invoice create process has executed. So what does that mean? First of all, that means if we look in the out queue bank demo ... oh. Oop. Helps if I get the right system. There we go.

Richard:              I was going to say academy, I think.

Chuck:                 There we go. Here's my report sample. All right, so I have a total value of $63,852.04. So let's take a look now at the spreadsheet that that data came from. It's called Daily Invoices. This was downloaded from a website someplace or some data source, and as you can see, we have the same value, so manually, the ... we definitely balance, but let's run through the balancing step in Automate. And by the way, these jobs do exist. Here under My Applications you can see I have balance step one, balance step two.

Chuck:                 So just for an example to show you the interface of Robots Schedule Enterprise jobs to Automate. I'm going to show you the setup of this balance job. So like I said, this job could be just could be scheduled discreetly. I could have a schedule here on the job that would run the Automate process, and here is my Automate task right there. It's interfacing to Automate. Let me drag that down. So we're interfacing to Automate and we're triggering balance step one. It's right there. All right. Now as I mentioned, we're going to run this step two and we're going to compare the value in that out queue, which has since been copied into the ifs. We're going to compare it to that CSV file, and likewise, I'm going to get email notification. You can see I've got email notification that my file arrived, and here I've got email notification that we had balancing success.

Chuck:                 Okay, so likewise, if I change that file ... let's just change this file by maybe a penny ... all right. Okay, Richard. I have saved it and I'm going to rerun the balancing process, balancing step two, and let's run it and let's see what sort of email we get. All right, we're on air [crosstalk 00:29:19].

Richard:              Pushing the envelope. There you go.

Chuck:                 All right. So likewise, this could be ... I'm ... we're getting an email here that there's an imbalance or that they are imbalanced, but likewise we could just be triggering a Robot job instead of just sending email. All right.

Chuck:                 All right. Let's move on to number three. Our final reason for integrating IBM i with Windows and that's file event-based scheduling. As part of my job flow diagram and my nightly process, I had a couple of file prerequisites, an electronic funds transfer, a POS point of sale file, as well as my daily backup. All those must be completed for my nightly process to run, and then we trigger multiple other processes. File event monitoring in Robot Schedule, you can predefine a file out in the Windows, Linux or AIX world to monitor. In this case I'm monitoring for any file called EFT something in my enterprise directory, and when that file is detected, that will in turn trigger my process, and of course we've got an audit trail behind that. Not only are we capturing when that occurred, but we're also capturing the actual file name. So you can see my file name has changed a little bit depending on when it occurred. So I had a A and a B file, and both those triggered my process.

Chuck:                 All right, so let's jump into our live demo. We're going to go over just a little bit in our timing, but I think this is valuable, so let's do it. Okay. Richard, can you see my screen?

Richard:              Yep. Got it.

Chuck:                 Okay. Okay, so first of all, the file in question is right here. It's an electronic funds transfer. This step is going to trigger both my nightly process, a prerequisite for my nightly process, and for processing the EFT file back into the IBM i. The file event looks like this. Let's take a look at how this is defined. All right, so the object or the agent that we're looking at is listed here, and the object that we're looking at is prefaced with EFT and is going to be in the enterprise directory. So when that file is added, that is a prerequisite. You can also qualify it. You could say if the object is not changed in a certain amount of seconds, you can also say monitor this event every so often, every five seconds in this case, and you can even put a time range for when this event is valid.

Chuck:                 All right. Now when that happens, that's going to trigger this EFT proc job. It's also going to trigger the nightly process. All right, so let's make that happen. Okay, so here's my enterprise directory. There's nothing in it, and here is my file EFT, May 26th, 2017 A. All right, and I'm also going to bring up my schedule activity monitor so we can actually see this occur. All right, so I'm going to drop this into my enterprise directory. Now, one of the steps that's going to occur is not only are we going to FTP this into the integrated file system, we're also going to copy it into the backup directory. You can see how that happened automatically, and you can see even my calculator auto launched. That's because just one of the example steps in my job flow diagram is to launch the calculator. So you can see my nightly process has completed.

Chuck:                 You can see my calculator is launched just to show you how we can execute a Windows executable or bat file using this process. All right, now we've also sent this data into the integrated file system. Let's just do a quick work link, and here's my EFT file from the 26th. All right, so that was part of the job that uploaded this file into the integrated file system so that could trigger other activity. All right, so easy way to coordinate all this activity across multiple schedulers using a single tool.

Chuck:                 All right, so Richard, we've gone about five minutes over. I think we're going to jump directly to our recap and I'm going to ask if there's any questions. Richard, have you been noticing any questions in the chat?

Richard:              Oh, I've got a couple that came in, so I'll hit those real quick since we're running over already.

Richard:              We are a Robot customer and we haven't deployed the new web-based interface. Is it easy to start using? Maybe I'll let you respond to that one real quick, Chuck.

Chuck:                 Yeah, we didn't have time to show the web interface. Obviously we tried to jam a lot in this webinar, but the web-based interface, it can be run on any Windows server and basically you point it back at the IBM i, it would pull data from there, and then you can use mobile technology. You could, for instance, use your iPhone with Safari. The job flow diagram that I showed you for our nightly process, totally visible in the mobile interface. You can work with your Robot jobs, you can look at the schedule activity monitor. A very cool way to go from an operation standpoint and also interfaces with other HelpSystems products like our power tech network security, password self help, and others. Thank you for that question.

Richard:              All right. Yeah, I'll take this next one. So this one says we have some cloud-based fast processes that need to interact with a website because that's the only way to run a report and other processes, and we need to schedule those types of jobs. Can you help? Yeah. If you saw Chuck's bank balancing sample, so if your application has no other way to be automated other than automating the user interface, we can help with that. Our Automate software component can automate interacting with the web applications like we talked about to navigate the site and enter or extract data or upload or download files, and then we can also interact with Windows-based applications or the terminal emulators such as IBM, Mainframe, Linux, and AIX as well. Good question. And then-

Chuck:                 We're really excited about the Automated interface, yep.

Richard:              Yep. Yeah. One final question. So this says, we're thinking about automating our operations, but haven't started an initiative yet. Is your team willing to give us some guidance? Absolutely, yeah. Our teams all over the world are focused on one key thing, making sure our software adds value to our customers when automating their processes. We're always more than happy to schedule a free one-on-one conversation with our technical experts such as Chuck or myself to help determine the best way to begin your automation journey.

Chuck:                 All right. Thanks for those questions. There are a few other questions. We'll follow up with those offline. We really appreciate your time today. If you're already a HelpSystems customer, thank you. Richard, thank you for assisting with this webinar today. I hope everybody has a great day. Thanks. Bye. Bye.

Richard:              Thanks.

Time to Replace Legacy AS/400 Schedulers?

Your business has changed. But has batch processing kept pace? If not, we can help! Download this guide where we help you assess your processing methods and identify the signs that it’s time for a change.

Stay up to date on what matters.