How is the data being replicated to the DR clariion? If you are using SANCopy I believe it will use the Snapview software on the array to create a snapshot prior to replication to ensure that it replicates an consistent image of the data. In that case there is no configuration needed on your part and I don't think you need a Snapview license in RM for that as SANCopy is being used as the replication transport.

Both jobs are incremental SANCopy jobs. However, I was told by the EMC tech that set this up and my EMC rep that we would have to have these licenses to handle the snapshot through RM. They both said the only other option was to script it on the clarion which is supposedly more difficult.

I would get them to clarify this then, because that is counter to what I have read about in the EMC docuement titled EMC CLARiiON SAN Copy: A Detailed Review.

From the document:
A SAN Copy incremental session internally uses SnapView to create a snapshot of the sourc LUN, and actually reads fom the sanpshot during the update, so that there is a consistent point-in-time view of the data being transferred.

This means that you don't need a SnapView license in RM. If they have SanCopy Incremental session setup already, then this is already working using SnapView on the source as documented.

Actually you are correct. However, that isn't my problem. The problem is with the target LUNs not the source LUNs. After the snapshot is taken on the source clarion, a delta set is determined or a list of changes that need to be replicated to the target. Here is my problem. If the delta set is being transmitted and written to the target and the transmission is interrupted, then the target becomes corrupted and unusable. The solution is to take a snapshot of the target LUNs prior to transfer of the delta set. This is what I needed the licenses for.

Sorry for the confusion then, I misunderstood what you were attempting to accomplish.

Then yes, they are right, you will need a RM Snapview license to allow the RM server to take a snapshot of the target LUNs prior to the Incremental SANCopy session. It will be a separate job that you create in RM to run prior to the SANCopy job. I don't know why they said you need two though, you should only need one for the RM server unless you are planning on mounting the snapshot to a host.

With the newest revision of RM you can link the jobs from different data sets. So you can configure the snapshot to run on a schedule and then configure the SANCopy job to start after the snapshot job completes. However if you are trying to schedule your SANCopy jobs to be that close (15 min.) then maybe SANCopy is not the right transport for replication between arrays. How much data changes on the source in 15 minutes? If you want your synchronizations to be so close did you look at MirrorView?

This is the answer I was looking for. However, this raises one additional question. If I have the incremental SANCopy job running every 15 minutes and I schedule the remote snapshot to run prior to this then what happens if my SANCopy job takes more than 15 minutes to run? Would the snapshot job simply fail?

Well, SANCopy is what the EMC rep recommended and 15 minutes has been the goal all along. Normally a replication finishes in 5 minutes. The only exception is the first replication in the morning after we have run a large number of posting jobs. This initial replication can take a couple hours.

Even though the question has been correctly answered I felt that I could try to contribute with a couple of further facts¿

¿ The behaviour noted with SAN Copy and especially the target LUN is correct because SC does not track changes on the destination LUN! Also the reason you should be careful when mounting the replica for testing purposes¿
¿ This is also the reason EMC normally would recommend to have at least two target LUNS that are being rotated so that if one gets corrupted you always got the other one...
¿ AranH did also mention MV/A which I might add would maintain a protective copy (gold copy) of the secondary image to protect against ¿a site failure¿ whilst MV/A update is in progress¿

I hope this helps
Carl