Stonebranch Reviews

We primarily use the solution for our clients.

The installation of the product is very straightforward.

The interface is very user-friendly and easy to navigate.

The solution is very stable.

The product can scale easily.

We've found the pricing to be reasonable.

The product is very new to us still. Therefore, it's difficult to gauge if there's anything missing. We're still learning about the product as we go.

We started using this solution last year. It hasn't been too long.

The stability of the solution is very reasonable. It's reliable. We haven't found that there are bugs or glitches. We haven't dealt with it crashing or freezing. It's been good.

The solution is very easy to scale. If a company needs to scale the solution out, it can do so.

So far, the projects we are working on are for a small company. We haven't tried it for an enterprise-level company just yet. That may come in the future.

Before starting with this solution, we worked with CA.

We've found the initial setup to be quite straightforward. It's not complex at all. It's very easy and this is one of the solution's selling points.

The deployment is quite quick. Within the hour I had everything pretty much up and running.

The pricing is quite reasonable. We found the cost to be surprisingly good.

We are a reseller. We are a software company.

So far, we've had a pretty good experience using the solution. We need a bit more time with it, however, to get more comfortable with everything.

Overall, I would rate it at an eight out of ten, as so far the experience we've had has been positive.

Scheduling Unix and Wintel batches. Full package - finance, backups, transfers. Three environments.  

Our organization could enter the cloud at full speed. 

Triggers separate from tasks contrary to the competitors.  

Lifecycle management.

More than five years.

solution in general stable however last OMS updates are blurring out this opinion.

scalability is good however it is lacking alternative to extend controller cluster's node numer.

reaction time is fair, however it happens that their will of help it not necessary handy, especially when you hardening the solution.

previous scheduler was TWS 8.5.  More expensive, less stable, less capable

a basic setup is straight forward however during setting some more advansed option it could be complex to achive

in-house

for sure unlimited license

control m

Our primary use case is automating the workload for the company. It's used quite extensively. We run over 500,000 jobs a week with it.

The resiliency of the agents helps us to process a lot of workload through them, reducing the latency between jobs.

The solution has saved us money over other potential vendors.

The most valuable feature is the reliability of the agents, because we need them accessible and we need to run stuff. The agent technology and compatibility are top-notch. The agents are wonderful. I've spoken at several of their conferences and always give them high marks. I would put the agents' resiliency at number one in the industry.

We have used the Universal Task a little bit and it seems to be fully functional. It's good.

The Stonebranch Marketplace is decent as well.

The Universal Controller is decent for the money it costs. We host it on-promise - some local virtual servers. It still doesn't have all the features and functionality of our mainframe scheduler, but hopefully it will get there. It needs some work to have full features, compared to other products that are out there, specifically IBM's Workload Scheduler.

Also, regarding the Controller, there should be a much cleaner method of looking at dependencies between workflows. 

I would also like to see, when there is a workflow that's going to kick in at a certain date, the option to pick the time for those dates.

The stability of the agents is wonderful; the Controller, again, needs a little beef.

We have not experienced any limits, so it should be scalable.

I would give tech support 9.827 out of ten. There's always room for improvement.

We are still also using the IBM scheduler. But we completely switched off of the IBM agents to Stonebranch agents. So Stonebranch replaced the existing legacy system as far as the agents go. That went great. It was a very affordable solution, works like a champ, so it's good.

We're still using the mainframe scheduler, but we're looking at phasing that out over this next year.

The setup was straightforward. We did a proof of concept. Stonebranch came in and we had questions. Then, of course, you can always tweak things. But we didn't have any trouble.

It took us two years to migrate all of our stuff from our old agents to our new agents. And we're working on migrating work in the Controller. We got the agents first, because Stonebranch did not have a Controller until several years ago. So when we bought the agents we needed to migrate workload from the old agents to the new and that took two years. So we were done in 2010.

We did not use a third-party.

ROI is tricky because it's really more of an expense item than it is an investment. We all like to say "return on investment," but we are not a profit center. It all works itself out.

There are no costs in addition to the standard licensing fees.

We price-lined options including Computer Associates, BMC, IBM's product, etc.

If you're looking at this or a similar solution, get with a company that's done it before. We have consulted with other companies and helped out a number of them to go to this solution.

We've already done digital transformation, so Stonebranch is part of our continuous improvement. I'm not going to say it's transformational, it's just continuous improvement, using our tools to exploit them for the betterment of supporting company goals.

In terms of the solution's users, we have people who build things in order to use it. We have a core of about five people who set up workloads to use them. They perform somewhat traditional scheduling roles. For deployment and maintenance, we do it all with those five.

The agents are a ten out of ten, the Controller is a nine. The agents are top-notch, Controller has some room to grow.

We started off with replacing mainframe batch scheduling for some of our distributed applications, and then it grew into not just batch but workflows and file transfers.

The volumes that we throw at it are in excess of 15 million tasks per month.

Our biggest relief was the file-transfer piece, the way they do it securely and the way they do that handshake and the way they farm out that dependency to give to users - versus admins - the ability to control that little subsection within the environment. We probably would have needed a team of 20 people to centrally admin, manage, create schedules, do file transfers, and support all that stuff. Instead, we have a team of two.

My biggest pain point was the agent. When it comes to the controller, it's one point of failure. You monitor it, it's just another application. You take a look at it. You know what items you need to keep an eye on: memory, log files, entries. You can be proactive because it's one important single point. When you look at all your endpoints, it becomes a management nightmare if you have to monitor every single one of them. Past experience has been that people want to run their batches. They don't want to care about the scheduler. They want to just set it and forget it. They tend to run the machines very hot. When the endpoints are resource-starved, because people's scripts are taking over all the capacity on the box, the agents fail and their workflow gets impacted and you take an SLA hit. We have yet to see that with any of the Stonebranch agents.

Regarding digital transformation, we were already down that road before we even looked at Stonebranch. I wouldn't say that it was the reason why we did it. It does help in the journey, where you're looking at a mainframe scheduler and you think, "Oh my God, I don't think we're going to be able to use this." Going digital, everything is software-defined where you say, "Alright, APIs, plugin, off we go."

This solution replaced an existing legacy system and the benefit was in the area of the support staff supporting those aging systems. We're no longer a bottleneck or a risk. We have a lot of those folks retiring right now, and it is tough to get that expertise on the market nowadays.

Finally, it helped us save money, and that was one of the drivers for getting it in. What I can share with you is it did 90 percent more than whatever solutions we had. We ended up saving a considerable amount every year. We got more for less. It has also saved us a lot of man-hours in support and maintenance. We were able to go down by three FTEs by implementing the solution. We went from less to more with half the staff that we had.

It's very feature-rich, but our focus has been mostly around resolving the file transfer problem: We did not have a standard way of transferring files internally. That was a plus. I don't think anybody in the market does it like they do. When it came down to our standards and compliance and hardening down systems, it was the most secure solution.

We also lean a lot on the multi-tenancy that they offer within the product, the ability to get other people to self-manage their estate, versus having a central team do all the scheduling. That's what we lean on the most.

Regarding the Universal Controller, to give you a bit of history without getting into the details of it, we've tried multiple solutions across the years. The one thing that we wanted to get rid of was the lack of resiliency of all the solutions that we had. What I liked about the agent at the time, before we got into the scheduler, was how robust it was. It just does not go down easily. When we looked at the resiliency of the scheduler, it was on par. It wasn't something that was developed in a basement somewhere. It was top of the class. We throw a lot at it from a resiliency perspective. It stays up. That is a major focus for us. It has reduced the amount of time we have to throw into keeping it up and running, which is translating into a lot of dollars. We host it on-prem.

When it comes to agent technology and compatibility with other vendors, from a platform perspective it was the one vendor that fit all the platforms that we have, from your old platforms - mainframe, NSK, IBM i - to the new ones, going into cloud and containers, etc. It is able to work across the entire suite of technologies, and it works very well with our core, which is the Windows and Unix platforms. It fit what we needed it to do. Other, bigger companies tend to forget one or more of those platforms, because they're in competition with each other, so they do not support some platforms. Stonebranch is very platform-agnostic, so if a customer uses it, they will support it.

There is a component called the OMS, which is the message broker. We rely on infrastructure, resiliency, and availability for that piece. If that could change to be highly available just as a software component, so that we don't have to provide the high-available storage, etc. for it, that would be a plus. It would just be cheaper to run.

The stability has been pretty good. It's been the best out of all the solutions that I've had to deal with.

What I like about it is the configuration that they allow you to get to, how granular it can get. Something that we used to struggle with - because we farm out the work to the applications and say, "You run this, this is just distributed cron for you," - was that people would run their scripts and sometimes do something silly like send their debug to standard out, and standard output is two gigs. Usually, our old tools would go capture that and send it back to the controller. That two-gig amount of data is huge. It's going to break either the agent or the transfer or take the controller down when it gets there. Stonebranch lets you tweak that stuff to say things along the lines of, "How much of the standard output do you want? Do you want 100k, 100 lines, 2k?" You decide. Scalability depends on that. If you want to run 100 million tasks a day, you have to figure out how much data you want to retain, and that's the power of this tool. Other tools don't let you do that.

Stonebranch is one of the best support vendors. They leverage their expertise on the mainframe and IBM i. I could not find that anywhere else in the market. That is something that we really needed. Their Unix knowledge is impeccable. They've always helped us. They're always able to do deep dives easily; same thing with Windows. They're quick to getting to the solution. They're quick in helping us to recover outages if there are any. They're always quick to escalate up the chain on their side of the house if they need to. If the level-one person is looking at a problem and says, "You know what? It's been 30 or 40 minutes. I don't see it," they will get someone from level-two or a developer to take a look.

We have many other solutions. I don't think I can mention those solutions as we do have NDAs with all our vendors on that side of the house.

When we ran our proof of concept, there were two larger companies, three-letter names, that came in and their installs took us a few days just to set them up. When Stonebranch came in, it was 40 minutes. In fact, I had to triple check it when Colin came in and I had to ask, "Are you sure? Did you half-ass it? I need to take a look. Is it running? Can we go through the components?" It took us longer to verify that it was up and running than it took to install.

After getting it installed, implementation is nice and slow because we're a pretty big organization and converting the things that application teams tend to have takes a while. We plan two years in advance. This is technically an infrastructure initiative, where we have to go and get people's time. To get it started, it took us 12 months - just to get started and scheduled. From a migration perspective, it's very cookie-cutter with their Professional Services. They'll come in, look at what you have, and say, "Here's the format we need to convert things to," and they'll do it really quickly.

In terms of an implementation strategy, at that time, we were scheduling application based on their availability. We had 110 apps and we had an excess of 100,000 definitions. We broke it down by application and scheduled them in waves when our resources and our side of the house were available to do the conversion, to throw it in there, and get them to test. We had a whole workflow planned out between the work that we had to do on the infrastructure side, on the application side, and we organized it in a dependent, wave-by-wave approach. The vendor was here. They converted. Then: 

• we threw it into the dev, app tested, made changes
• promoted it to QA, app tested
• promoted it to production, and then we shut down the old stuff in the old schedulers.

On average, it took an application three to four weeks to get to production. That was not that long based on our size. I've seen it take longer with a lot of other tools. The step-by-step approach on the resourcing that we had bottlenecked us so that we could probably only have four of those running in parallel.

We used Stonebranch Professional Services to come in and help us. We did the majority of the design because that's what we do. We depend on the way our business runs, and we schedule with the business. Then we brought Professional Services in and said to them, "Here's how we're going to be able to do this. You guys tell us what the technical capabilities are and help us through it."

The way we run the shop is that Infrastructure has a specific budget. I don't think we did a business case to see how this would improve the business at all. We just looked at what we spend a year and decided, let's spend money on this. It's less work for us, so we went ahead and did it.

Outside of licensing fees, there aren't any other costs.

We did evaluate many other options.

Look at also having the database solution be HA as well, because the product is highly available and you can stretch it to also be your BCP where you just fail over from one data center to the other. We suffer because our database solution is not. I would urge everybody to go down that path and set it and forget it. If you lose a part of your data center, this thing will stay up.

The universal task is something that we started dabbling with. We haven't used it fully yet.

We don't rely on the Stonebranch Marketplace a lot. It was something that we discussed with Stonebranch over a period of time. It's something that we, as a culture, need to look into internally as a company. We tend to trust the things that we write, versus looking into things like a marketplace where we can extract thoughts or automation or universal tasks that other people have put out there. If it breaks, we need to be able to call somebody when it does.

At last count we had around 650 defined users, and around 50 logged in at once.

Right now, to do the scheduling and maintain the environment, it's two bodies, and we have one to help support the file-transfer piece. Those three bodies are responsible for administrating the environment. If somebody needs to be onboarded, that's all automated. You come in, AD groups are created, the security stuff is in, it's all automated via ServiceNow. All that those three guys do, from an admin perspective, is troubleshoot production issues. If something breaks, the app goes, they sit down with the application and explain why it broke. The other roles that we have are operators, schedulers, and the read-only users. The applications are broken into dev and production teams. Dev teams usually have access to schedule and promote to production. Operators only have access to production, and they do the operations role. The scheduler basically has read, write, delete, update access to everything. The operator only has that access on the tasks so operators are able to rerun, stop, that type of role. Those are the four roles that we have defined.

I would estimate that ten percent of the business uses this product. Are we going to expand it? Anybody is welcome to use it. It's slowly growing by itself. As soon as you mention the file transfer solution to people, they say, "Okay, I'm on board. Let's go." Are we going to make it a strategic tool that everybody has to use? It's just one of the many tools that we have in the toolbox. I think within our organization, we probably have in excess of 500 tools.

I would rate Stonebranch at nine out of ten. I would never give anybody a perfect ten. I always want people to work harder. I'd give them a nine because, if you deal with all the other vendors, you're used to a sales guy coming in with an agenda - that he needs to maximize the sale. I didn't get that from this vendor. It was very weird dealing with them because all the other vendors act a certain way, except them. They show up, very transparent, very honest, and they're always willing to negotiate.

It handles all of our scheduling. All our batch workload runs through it. We use MOVEit for our file process transfers, so we don't use Stonebranch for that. 

We have MOVEit integrated with our scheduling, so we run commands to MOVEit from scheduling.

We're running about 46,000 tasks per day.

Stonebranch enhanced the digital transformation at our company, through the dashboard. We run a customized dashboard for our operations team, where we can quickly see the issues. We can see running task. We use a lot of started and finished, late finished, late started. We also have some gauges where we can see jobs that exceed their average runtime or estimated end-time. It's helped our operations team see issues ahead of time, instead of four hours later when we've already gone past the point of no return.

In terms of our system operators, we're bringing guys off the street that pick this stuff up within two weeks, and they're flying with it. It just seems like it's so easy, once they get the baseline down. Then it's just boom, and they're off and running. There's some work to get that initial understanding, where to go to find what you want, and then these guys are flying with it. Our older people that have been here for a few years were the ones that struggled with the new technology.

Their agents are the simplest. They're easy to install, they're easy to get up and running. We do a particular kind of access on our servers for ubroker and then I have the directory created by my Unix admin. After that, I don't have to get them involved anymore. I can install, upgrade, I can name the aliases on the agent, so if we need a passive environment for an agent, that's one of the nice features. If our primary goes down, I can bring up the passive one and I don't have to change anything in the scheduling world. It will start running from that new server.

The agents have treated me very well. I have found the agents to be so much simpler, when compared to ESP. I haven't been exposed to the other tools, how they run their agents, but Stonebranch's agents are by far the simplest I've seen to download, install. I'm up and running within a half hour on it.

Task monitors work extremely well. We haven't had any issues with them: jobs monitoring another job to finish. We do have some that look into the future, but most of ours look backward. We have some that look back two days. The job running on a Friday looks for something that ran on that Wednesday and knows it ran successfully, and the schedule keeps right on going.

They brought in a web service task, which saves you running an agent on a server. I can send http commands directly to servers, which can start processes on that server itself, based on a file coming in. There is an agent cost, but there's a certificate that you have to put on. There's a little more background work for myself, because I have to keep the certificates up to date.

One hiccup we've had is due to the fact that we have other internal scheduling tools. We're able to talk to them, but we have trouble with some of the networking between them, so we're still trying to work out the kinks there.

Also, there's the z/OS agent. We've had troubles with GDGs, with recovery. Say we have a job that fails on a Saturday and there are other jobs that update that generation. If they go to fix the one from Friday, it picks up right where it left off. It doesn't know about the future generations that were created. We've been trying to have Stonebranch correct that for us, and that's probably the biggest open issue. And they're the hardest ones to install and upgrade. Mainframe, in general, seems to be a hurdle, in my opinion.

In terms of resiliency, we run the high-availability, so I have two controllers, one in passive and one primary-active. We switch every month for patching, and the passive one takes over without an issue. 

With our database patching, we can see when that stops and when the controller goes into a pause. But less than 15 seconds later, we're back up and running again. There are no job failures associated. It takes off right away. In the patching world, we've seen a significant improvement.

It has high scalability. It's easy to use, it's easy to run with, it's easy to get it turned on and going.

I found tech support to be very knowledgeable. They seemed to go above and beyond. I will admit, my former copilot here actually started working for Stonebranch. She went beyond expectations but she's no longer working with support. She moved on to a storage administrative role. But overall, they seem to be very knowledgeable. Within hours, they're getting back to you on a fix. Most of the time, they will provide the fix right upfront or tell you what you need or how to do it. I'm very comfortable with their expertise.

The Universal Controller is what I'm running. I like it for web interface. There were four or five products we were reviewing. We came from an ESP shop but we didn't like their web interface. We were leaning toward a web interface and this was the only tool that had it. I believe a couple of them are close, but we didn't like their features. We liked this one better. We have the Controller on our own server, inside the company. I have read some of the cloud stuff and we have other products going in that direction, but I haven't been asked to go that way.

We had an elective in 2013 to get off the mainframe, so we jumped to get going with a different scheduling tool but, guess what, we're still on the mainframe.

I wasn't very Unix-savvy when I started, but Stonebranch came in and showed me how to do it. One of the hurdles we had was that we went with their 5.1 version, and then they had to completely change their mapping, and I ended up doing that all by myself. I ended up copying everything over into a new version, I promoted everything we had over into the new one, and it took me less than an hour to do it. So the conversion to an entirely new server was very easy.

We were 97 percent effective when we converted, but they converted most of it for us, upfront. They were onsite to help us with the conversion. We had a couple of kinks with them. ESP had some inherited dependencies that we overlooked and that was the biggest hurdle we had. We had to break some of the connections for predecessors and successors, but they built all that the same night we went live. We were able to get that going and fixed. There was an AIX agent we had some issues with, but an hour later I had the new version installed and up and running and we were on track.

Our initial deployment took us a little over a year. Stonebranch was onsite. They started converting. We ended up identifying some 50 schedules that were stand-alones, where they didn't impact anything. In the space of seven months we turned them on, and then our peak window hit and we couldn't do any changes from November 1st to January 1st. We waited until after our peak window and I believe it was during the first week in February that we went with everything else. We got a taste of what was happening, and then we put everybody else in.

Our implementation strategy was to get everything converted. We did that first seven months by ourselves, we just turned things on and let them run. We had three people from Stonebranch onsite for our go-live night. They worked eight-hour shifts. My co-compliancer and I ended up pulling two 12-hour shifts, and then we had a third person who helped us out in between them, so we could at least get a bite to eat, or walk away, or unload some of the issues that we were seeing. But most of them were pretty minor. We met our SLA opening morning for our batch processing. We were not behind.

It went very smoothly. There are always going to be some hurdles you have to figure out, but we were expecting bigger hurdles, and we didn't see those really big hurdles.

The Stonebranch reps were extremely knowledgeable. It didn't take much for them to figure out what we wanted, how to do it. Danny Provo was one of the primary guys for us. We had some unique things that we had to have converted, and they came up with a solution for every one of them.

When we reviewed this solution against other vendors, Stonebranch blew everybody out of the water in terms of cost.

There is a maintenance cost that is required every year.

We evaluated BMC and we looked at CA's products - we already had CA in house. Tivoli was another we looked at. There were four or five on the list, and we dropped it down to three pretty quickly.

BMC would have been in the running, but they were... "arrogant" is the word I want to say. They just brushed us the wrong way. I think they have a great tool but the sales pitch that they sent to us did more chopping of other products instead of selling their own.

If I were to go to another company, this would probably be the tool I would push for. It's a very sound product. I feel Stonebranch is on the technical edge. I've been to a couple of their conferences. They are going into areas and blowing my mind with where they're going with some of this stuff. They're trying to stay on top of the cutting edge.

When you go to their conferences, you hear how other people are utilizing the tools. Something might spark a concept, where I say, "Maybe I can do that."

We use ServiceNow as our problem management tool, so I'm trying to automate tickets to go into that, but we haven't made it that far yet. We send an email on every task failure over to a public folder, and that's what our operations team copies and pastes. Then they update another gauge in our dashboard so they know that somebody's working on that. Then we have some warning issues. We have things that go into define states, because they could be a sub-apple of a main workflow. Or we have workflows that stack up behind each other because they're the same name. We use resources to control everything. If we do have a maintenance window, I'm using a resource to set it to zero, so any workload coming in after that is waiting for our operations team to release or get the okay after a maintenance window has been performed.

I'm the primary for the maintenance. I have a backup, but he's more my MQ guy. I support MQ as well. I do all the maintenance and controller, so it's one person primarily doing it all. We have three production-control people who do batch scheduling, for new schedules, obsoletions. They reverse their procedures every week. One's doing scheduling, we have one doing user-requests, ad-hoc requests that are coming in on a daily basis to insert into the schedules to run. We have a schedule that we call Production Control and that's where all our user requests go; users who want to run this or that today, that's where they would insert it and run it.

We have about 120 users. They include our DevOps team. We used some business services to lock down some of their pseudo test schedules. We run a production internet environment, and the data that comes out of that actually goes into our development environment, for their testing. We use business services to lock that down. They have eight people who can update tasks, create tasks, etc. That's the only place we're using business services.

We have seven groups. The Administrative group and the "Everything" group comes with the tool. But then we created seven more groups. We strayed away from the default groups and made our own. We have ops-wise-admin, which is the administrative group. We have an ops-wise-all group, which is just readability. Somebody can get into that group and they can see ops-wise, they just can't make changes. Developers is our biggest group. In production, they only have read access, but in our development areas they have full-blown access. We manipulated the permissions to help control production over development. Ops-wise-IT is another group similar to ops-wise-all. I don't know why we had to have that one to give IT some extra abilities, but that's what we did. And we have an operations group for our system operators. They have capabilities to restart workload based on a programmer's request, a plan of failure. They can make modifications to the active instance, but they can't make modifications to the definition. That's how our change control comes into play. Product control has the same access as ops-wise-admin, but they just can't do upgrades.

In terms of the prospect of increasing our usage of the solution, we're looking into the cloud situations, but I haven't been asked how to go that route. Doing it would be a matter of putting an agent out there in the cloud world. Security is the biggest hurdle for me, sometimes; trying to get access. Some of our servers are behind firewalls. It's usually a matter of talking to the right people to get the job done, but I probably have seven agents that are behind firewalls and working just fine.

I run four controllers, but I have six in place. I have two that are high-availability. We were struggling and this is probably an issue with Stonebranch. We had developers who were making changes in our test and development areas, and then we would promote them up to production, but we started having conflicts with sysids. What would happen was that a developer would make a copy of what he wanted to change, and he would go back and rename the original task to "old" or something like that, and then rename the new one to the originally named task. The sysids were now out of sync. Sometimes they would bundle up okay, but once we started seeing a larger volume of them, we started having bundling issues and failures. We elected to go with what we call our change-control environment. It's almost a mimic of our production environment, but now our production control team actually updates the original task upon request. They make the changes in their development and then they submit a change request to have this copied into production or updated into our change-control environment, so we can keep the sysids from getting out of sync. Sysids were probably one of our bigger hurdles, after the fact.

There are no agents running on our product-control system. We variable-ized all our agent definitions and we variable-ized all our credentials. With scheduling, if you hard-code the agent name or the credential, it will actually bundle it up like that, but if you variable-ize them, you can keep them unique between the two systems. In production, this is a production credential, but in test they use an LE-dev credential name. When we go to move that up, it still thinks it's just LE, because we variable-zed it.

Especially when going to a new server - if they want to rebuild a whole new server - all I do is install a new agent as "_new," and the alias name will be whatever, and then, go-live, I just swap the names and scheduling isn't impacted at all. It's pretty sweet the way that works, using the aliases.

I can remember with ESP, we had to have tons of schedule changes and agent name changes to the new one, whereas ops-wise took a lot of that away with the use of variables.

We had no enterprise solution in place for our application. This was meant to support Linux and Windows.

The organization supports an application which impacts multiple platforms. This has helped a great deal with the initial setup and ongoing maintenance, in terms of being able to do so in one place.

• The layout of the UI is solid.  
• It has really helped scale automation efforts.
• I also like the existing templates.
  

• FTP tasks have been an issue. 
• It has also been challenging to support PGP encryption which is a fairly standard encryption method.
  

No issues with the stability of UAC, it has really never been a problem for us.

The tool is consistently executing large batch jobs. Issues that we attempt to correct are more often than not within the application itself and not UAC.

Not much interaction personally.

At other organizations, I have used CA Unicenter. It was OK, but on working with UAC, I prefer this tool.

There were some complexities, but that was our own doing in terms of our application and the platforms we support.

We used Stonebranch, they were solid.

We have far fewer folks running jobs manually from a command prompt. We have visibility into our job streams. ROI continues to grow.

Found it to be reasonable and worth the investment.

Yes, CA Unicenter was considered.

• We are using Stonebranch to automate our MDM solution with all inbound and outbound systems. 
• We also use it for scheduling jobs or process to extract data from our business app to data warehouse solutions.
  

It really helped with the heavy lifting of the integration and scheduling gaps within our MDM solution and other systems. We have ETL solutions with native scheduling feature, but with Stonebranch we have improved our scheduling making it so autonomous and easy.

• Ready-to-use standard API or interfaces available, and flexible scheduling. 
• The beautiful part of scheduling is you can do weekdays or business days or custom business days. 
• The template format is very helpful when you have 100s of jobs to be scheduled every day.
• Email feature can be customized based on the variables and parameters.

For me, Stonebranch can do more than integration and scheduling, like real-time interfacing services and point-to-point to integration. With this, we don't want to invest money on multiple tools for different purposes.

We didn't have one enterprise scheduling to automation tool before Stonebranch. With Stonebranch, we are able to bring all enterprise automation to once place.

I'm very much pleased with the setup process or installation process, and licensing. 

We are a SAP shop, we have evaluated Redwood, WorkFusion, and Stonebranch.

No.

I am a part of a production support team, and we automate most of our work using this. It reduces all the manual work.

Earlier, it used to take us a lot of time for file transfers and creating a backup, but after this automation, the pain and time have been reduced a lot.

It is very user-friendly, and it is quite easy to use. Moreover, you can integrate a lot of applications by using this simple tool, and it holds all the details in a very simplified manner.

More number of FAQs should be provided because I found it hard to configure when I started using this tool.

I see it as a stable tool so far.

Customer support is really helpful.

No, I did not.

It was a bit complex for me.

In-house.

Pricing is very comparable to other tools in the market.

No.