C$SOCKET to control Verifone Credit Card Reader on USB port ?

Has anyone been able to control a Verifone Crdit/Debit Card Reader.

The device can communicate either on the network or USB.  I assumed that C$Socket could to the trick.  Can anyone offer advise or help on how to hook this thing up and does C$SOCKET talk to a COM port ?    Randy --- HELP --- I'm drowning in technology that is poorly documented.

I took a look for Verifone documentation, and all I found was user documentation, nothing technical. I suspect that you would need to actually contact the company for such doc.

However, I suspect that there is an ActiveX control or a .NET control that does the communication for you. And that you need to utilize that software, not try to talk to the device yourself. Does the device come with software to install?

Randy …. thanks for getting back to my submission.  Hope you had a good holiday in NZ.   Yes, their documentation needs an overhaul.

I have three options that I need to code for  (using AcuGT 9.1.2).

1. To talk directly to a Verifone V400c debit/credit card reader.  It is hooked up to my network and I am trying to get C$SOCKET to talk to it.  When I make the C$SOCKET call to "AGS-CREATE-CLIENT, the return code is always ZERO.  I have the IP address of the device, but am unsure as to what socket # to assign.  I use the one defined by the reader specs, but still does not work.  I'm wondering if C$SOCKET actually works.  So I am stuck and need help.  

2. I also have an interface that will talk directly to Moneris to do credit card validation, payments and credits. using their supplied .NET API library.  I have coded everything needed, but it does not work either.  I have executed the NetDefGen utility and that seems to work OK giving my the required definitions.  However the Acu documentation suggests it is supposed to generate an Event DLL.  But no such library gets created.  When I execute my test routine the CREATE...….statement returns a HANDLE = 1.   I have spent hours reading through the documentation and the sample programs.  So I am stuck and need help.

3. I also have coded that ability to do batched multi-payment requests. I generate and XML file that gets Ftp'd to Moneris for processing.   I am happy to say that it works just fine.

It's frustrating trying to get the first two scenarios working.  I have a relatively simple test file for option 2 that I can supply along with the API library.

Thanks

Randy …. thanks for getting back to my submission.  Hope you had a good holiday in NZ.   Yes, their documentation needs an overhaul.

I have three options that I need to code for  (using AcuGT 9.1.2).

1. To talk directly to a Verifone V400c debit/credit card reader.  It is hooked up to my network and I am trying to get C$SOCKET to talk to it.  When I make the C$SOCKET call to "AGS-CREATE-CLIENT, the return code is always ZERO.  I have the IP address of the device, but am unsure as to what socket # to assign.  I use the one defined by the reader specs, but still does not work.  I'm wondering if C$SOCKET actually works.  So I am stuck and need help.  

2. I also have an interface that will talk directly to Moneris to do credit card validation, payments and credits. using their supplied .NET API library.  I have coded everything needed, but it does not work either.  I have executed the NetDefGen utility and that seems to work OK giving my the required definitions.  However the Acu documentation suggests it is supposed to generate an Event DLL.  But no such library gets created.  When I execute my test routine the CREATE...….statement returns a HANDLE = 1.   I have spent hours reading through the documentation and the sample programs.  So I am stuck and need help.

3. I also have coded that ability to do batched multi-payment requests. I generate and XML file that gets Ftp'd to Moneris for processing.   I am happy to say that it works just fine.

It's frustrating trying to get the first two scenarios working.  I have a relatively simple test file for option 2 that I can supply along with the API library.

Thanks

Sorry, but I won't be able to help with this specific hardware.

We have people using C$SOCKET successfully, and we have people using .NET successfully. So chances are good that this is something specific to this hardware. And without having the hardware and all the necessary software, there is little I can do.

This sounds like a case for hiring Micro Focus professional services.

First, I use the @! command regularly when debugging, and have never had trouble with it. I just tested it again, and it worked as I expected it to. I'm not sure why it is not working for you.

As an aside, the phrase "doesn't work" is so nondescript. There are so many ways something can not work. In this case, does the execution point jump to a random point? Does it not move at all? Does it crash the runtime? Something else? Note that you need to ensure that the new line you want to move to actually has a verb.

To go back to C$SOCKET - note that when issuing AGS-READ, using a length parameter that is negative tells the runtime to leave the data on the socket. I assume you are not doing this, but I really hate making assumptions.

When you talk about the buffer keeping the original data, I assume you are referring to the COBOL variable that you are passing to C$SOCKET to hold the data being read. (See above about assumptions.) Are you sure that the data is actually being read? Do you move spaces to that variable before issuing the new AGS-READ? Are you checking the return value of C$SOCKET to see how much data was actually read? One possibility here is that the read that is returning the same data is really not returning anything, but is keeping the old data.

The AGS-FLUSH command is intended to throw away bytes that came from the socket. After you have read the data, that data won't be thrown away. The purpose is to do something like the following:

Check how much data is available. Determine that 20 bytes are ready. Read 10 bytes. You know you can ignore the rest, so you can issue AGS-FLUSH with a length of 10 to get rid of the other 10 bytes, so that the next READ (once you know there is relevant data to be read) will not get the 10 bytes you want to ignore.

Since I don't have the hardware, perhaps the best thing to do would be to show me code, with the values of the variables before and after each call to C$SOCKET, along with the return-code after each call. The more detail you give, the better chance I have of being able to help.