I wasn't involved in the initial setup although I am still working with someone who was maybe 20 years ago. It's grown with us and it'd be difficult to switch.

I was involved in the setup process not at this shop but at a different shop in the past. The process was complex.

I was not involved in the initial setup but I have been involved in an upgrade. It was complex. It wasn't a major upgrade. It was just an application version maintenance-level upgrade.

It was complex because of the integrations. It was complex because of the availability of the system. It's at 32 distribution centers, so you have to work with one distribution, or a few, at a time. Like I talked about scaling. You had to do 32 distinct upgrades, and they all had their own little engagement, and they had their own little nuances, depending on the location.

Initial setup and upgrades are pretty much straightforward. Now that we've had it for so long, pretty much, we're just adding on at this point. They're pretty much stable, as far as the initial setup and also upgrades.

Once you're familiar with the product, it’s easy to use. The documentation is very good – coding some rules for console ‘message suppression’ is a good way to start.

Our initial setup was probably a little complex, but that was a long time ago in 1988. The new releases are reasonably good and do not require a lot of effort on our part. It's a pretty stable process.

We have another team perform the install and we do some customization or test new features. From what I understand, there are no complaints about set-up.

OPSMVS also uses REXX, albeit its own flavour. Some code could be converted virtually unchanged.

Converting from the MAT to rules was a much longer process, more time-consuming than difficult.

As many MAT entries had no message-ids coded, we had to determine what the actual message-ids were before we could convert them (another reason for dropping AO NetView). We initially tried coding each of these entires as ")MSG *" and then capturing the text in each rule, but that almost killed JES2 as we had more than double figures of such rules. It was a bad idea, so avoid having more than one such rule.

We had to run both products concurrently for about two years during cutover, being careful not to have them fight each other.

It's relatively straightforward. It's not so complex. Of course, if you are a newbie, it will be more complex than for someone who has done it before.

I was not involved in the initial setup, but I know it was straightforward. The documentation is simple, easy to follow, and use. A limited, first-time systems programmer can do it, in that it is out-of-the-box almost functional.

There are some things that are different, but that is true for pretty much all products. Overall, it is very easy - time consuming because of the code having to be rewritten - to convert to OPS/MVS.

I was not involved in the initial setup, though I have created and brought in new releases and stuff. The upgrades are pretty easy. When I do have questions, they usually walk me through it.

I was not a part of the initial setup.

Initial setup was pretty straightforward. It's very easy to install. The documentation they give you and also the product, the way they had it set up to install, make it easy.

Initial setup was very straightforward.

Initial setup was straightforward, used CA-supplied migration tools.

The setup was straightforward. We received on-site assistance from CA, and they not only helped us set up the system properly, they also made sure to transfer the knowledge to us.

Our initial setup was not overly difficult, but support was sent out to help us with our initial install.

We actually had CA, one of their experts, come in and help us set it up. Now it seems simple, but I have to train folks on it and it's complex, but it does a lot for us. It's complex because it does everything.

I was not involved.

It was a complex setup in the mainframe environment. The product is feature rich, so you don’t know if you have it implemented correctly most of the time.