We used AutoSys before. I'm familiar with that tool as well. The big factor in switching was the license model being just a lot more predictable. Then, as a result of that, it was for the number of features that Tidal had. It was significantly more powerful at a lower cost. It wasn't just the cheapest. They were pretty close in cost when we got it all down to it. It was still less expensive, however, also had the more advanced features, in particular REST API, which was super duper expensive with AutoSys. It was a license model that made it very hard to predict the growing cost, versus Tidal. With Tidal, at least in the model that we had, it was very, very stable. We just renewed for another couple of years recently.

It was quite a while ago, but we did not use another scheduler at the time. We used cron and Windows Scheduler, depending on the platform. They were embedded in the OS, as opposed to some type of fully-featured scheduling tool.

The reason we switched was that we were consolidating processing centers. We were going from 69 processing centers down to one, with one more for redundancy. We were taking all of our external spoke locations and bringing them in-house to one location. We couldn't manage 69 operators. We decided that this made more sense than going with some giant room with a whole bunch of operators in it.

There was the JD Edwards scheduler itself and we've also used Control-M. We've used Circular Edge's scheduler. I've even written a DOS command using a Windows scheduler to do all of my job processing. 

At the previous company where I first implemented Tidal, I was like, "Well, I have this free scheduler that does all of this." So, whatever I'm paying for has to be able to duplicate that. I have to be able to justify the cost. If it is going to cost X, what am I getting for X? With Tidal on that particular comparison, it came down to the fact that I would get the ability to report on things and the ability to easily recover from errors. As soon as the business was willing to say that recoverability and error reporting justify the cost, I was able to get them to pay for it.

Another scheduler that we were using was Robot. One of the things that Tidal has is a true JD Edwards adapter and I can schedule jobs into JD Edwards. With the JD Edwards tool, you can submit a JD Edwards job, but you can't really monitor it. I would submit a job and I cross my fingers and hope that it was really running. With Tidal, if there is an error, Tidal will respond back with the error and with the logs of why it failed. The integration is much tighter with Tidal and is probably the reason why I went with Tidal as opposed to any other scheduler. Every solution can schedule a job, so that's not a differentiator. Having an actual JD Edwards adapter is what differentiated them. Smart Scheduler is built into JD Edwards, but because it can only do one instance of JD Edwards. I have a bunch of instances of JD Edwards and didn't want to be tied to a Smart Scheduler for each JD Edwards instance. I wanted one Tidal scheduler that can do everything, and that's what we have right now. So, instead of my guy going to 11 different places to see if a job ran, he can go to one.

We had two mainframes running all of our applications. We were using CA products. Our health application was ClaimFacts, from TriZetto, but they were dropping support for the mainframe product and everybody had to switch to Facets. We were running both products at the same time while we were transitioning to Facets. We had to run ClaimFacts, the mainframe version, for about a year or so because, if somebody has a claim they have a year to report that claim and another six months to make adjustments on their claim. So our old mainframe product had to be kept until all that faded away. 

Then everything went into PC, server-oriented applications. We got Tidal because the company, TriZetto, used Tidal to run their stuff. So we brought it in and we started setting up our whole batch schedule.

This is my first scheduler. I used to send jobs to the Control-M team, but that was with my previous organization.

When I started working for my current organization, Tidal was already available. My team was supposed to support Tidal too.

I have used a lot of different solutions such as Autosys, Windows Tasks Scheduler, Microsoft SQL Server Management Studio, CA7, CA11, Control-M, and Maestro. In all cases, we've had all these different companies that we moved to Tidal. It was definitely the right thing to do. We switched because of a lot of better features. Tidal is easier to use, easier to integrate, and definitely easier to administer. It's also versatile. It has a lot of features that some of the other ones didn't have.

I think we had a variety of solutions that were sort of stitched together.

We were using a home-grown solution. It was a cron job manager. It didn't do file events very well; it had monitor CIS logs. It was tough to schedule tasks. It was purpose-built so it didn't have a SQL adapter. It didn't have the ability to run on Netezza and things like that.

We switched because to programmatically create the enhancements for the things that came out-of-the-box with Tidal was just too costly. It would have taken too much time.

We had a different scheduler before we started using Tidal but that was 12 years ago. We are very happy with the results of our switch. The product we used previously was Open Scheduler and we switched for two reasons. One was the cost of ownership of that product and the other was the set of requirements around our JD Edwards ERP solution.

There were no automation tools used before.

We only had crontab on a bunch of Unix systems. We looked into Tidal because we were having so many missed processes. Our environment is so much bigger and more complicated now compared to 15 years ago. But even back then it was almost like having things in crontab made it easier for there to be issues because they were all arbitrarily set to run at different times, different users, different systems. If there was some sort of conflict or collision, there was really no way to even regulate the fact that there were too many processes running at given time. 

It actually helped prevent some issues then, and now we have so many things cranking through Tidal. Getting all this to work in crontab would be impossible.

In my past job, I have used HelpSystems Robot. At the time, HelpSystems only ran on an AS/400 or iSeries while the Tidal solution runs on various platforms. They are pretty comparable though for functionality.

I have worked with other workload automation solutions before, but nothing that is still around. 

Even though we have been a Tidal user for quite awhile, there was still stuff being run with Windows Scheduler or cron. We have been able to pull that stuff in and reduce the workload on teams.

I did not use a different solution previously. I was on this project for six months and later shifted to a different project.

We went from AutoSys (formerly CA) to Tidal. We switched because of CA's expensive licensing. They were also behind the curve.

As I mentioned, we came off of Maestro. Back in 2004 or 2005, when we were looking at schedulers, Tidal was one of the solutions we demoed. Universally, we all decided that Tidal seemed to be the better candidate.

We used local solutions, like scheduling for each platform, such as SAP Scheduler, SnapLogic scheduler, and cron jobs. We didn't have a centralized place.

In my previous company we used the Lawson ERP's internal job scheduler. There were Windows tasks that we had to check on. They were running a lot of VB6 stuff. In my current company, I came onboard years after they had already cut over to Tidal. I know they had some mainframe stuff in the past, but I don't think they converted from something like CA to Tidal. Tidal was their first choice.

We were using SAP native schedule, which was fairly primitive.

We did not use another similar solution prior to Tidal.