I have today a meeting with a developer and we will look at the certificate issue. Hope to be able to give you more information by the end of the day.

The server should indeed send a message back with status succes. It could be that there is a bug in DVT or that there is an other issue. Can you use the DICOM Network Sniffer and Analyzer to sniff the connection and upload the capture file here on the forum. Then we can take a look at what actually is happening and where the issue might be.

Normally the Sniffer can save the raw data as a capture file that can be used later for analyzing. Either something went wrong in the software or you're college made a mistake. I will check with the DVTk Team here if there is a way to use the PDU files for analyzing after all.

No it is a actual meeting that takes place. The developers and active community users from the DVTk Project will be there as well as a lot of interested people who like to learn more about the products and share knowledge.

You could release the current association after the C-Move and create a new association for the C-Store. Although normally the C-Store occurs within the C-Move it is not possible to create this with DICOM Scripts. You should use Visual Basic .NET scripts for this using the High Level Interface of DVT. Another option is to create two scripts and run the scripts separate from two DVT Application instances.
As a new DVTk user it might be interesting for you to visit the Eye2Eye event.

It seems that you are also missing some braces. I changed the following part of the script from this:

SEND C-STORE-RQ "Secondary Capture Image"(
(0x00080016, UI, "Secondary Capture Image Storage SOP Class")
(0x00000900, 0xFF00)
(0x00080052, "STUDY")
(0x00080054, "EDDA179")
(0x00100010, "Benson11156120*")
(0x00100020, "764240*")
(0x00100030, "19830702")
(0x00100040, "M")
(0x00080061, "CT")
(0x00200010, "264891")
(0x0020000D, "1.2.840.113619.2.55.3.604651394.5523.1165272004.30")
(0x00080050, "091134")
(0x00080020, "20070384")
(0x00280010, US, 512)
(0x00280011, US, 512)


RECEIVE C-STORE-RSP
(0x00000900, US, 0x0000)

into this:

SEND C-STORE-RQ "Secondary Capture Image"(
(0x00080016, UI, "Secondary Capture Image Storage SOP Class")
(0x00000900, 0xFF00)
(0x00080052, "STUDY")
(0x00080054, "EDDA179")
(0x00100010, "Benson11156120*")
(0x00100020, "764240*")
(0x00100030, "19830702")
(0x00100040, "M")
(0x00080061, "CT")
(0x00200010, "264891")
(0x0020000D, "1.2.840.113619.2.55.3.604651394.5523.1165272004.30")
(0x00080050, "091134")
(0x00080020, "20070384")
(0x00280010, US, 512)
(0x00280011, US, 512)
)

RECEIVE C-STORE-RSP (
(0x00000900, US, 0x0000)
)

Somthing else I discovered in the script is that you are doing a C-MOVE and C-STORE in the same association. This is DICOM technical valid if you also agree on this in the association negotiation. However it seems that you are not doing this. It could be that this is the attention of the test case ofcaurse. I just wanted to make you aware of the fact.

It seems you have a parse error in your script. According to the error message you can find the error on line 108 in the file 2.ds.
The command RECIVE should be RECEIVE. If you change that the error should be solved.

Comparing is possible but limited to non binary values. For a real binary compare you can use compare tools like Beyond Compare.
For doing a compare of DICOM files regarding values you can use the DICOM Compare tool that can be found here.

We are having some problem with the generation process. Therefore it may take some more time to create the certificates but we are still working on the issue. As soon as they are available I will post them here in the forum. You may want to use the event notification options of the website to get informed on new posts.

You're script makes an association and then handles a Query. After that you initiate a new association, but you will first need to release the previous association. That is what the other system will be doing and that is what DICOM requires you also to do in your script.
That is the reason the script is failing.