Glad the precision/scale detail helped. Cross-vendor (IBM + MS) documentation isn’t particularly clear in that area.

Note that “stored proc” is more of a thought to how things might be implemented behind-the-scenes rather than how you set things up. I’d be interested in knowing which AS/400 job the COBOL program shows up in. The particular server job sometimes helps in figuring out how bytes get formatted going across the network.

Tom

That is the complete list of Parameters, this is just me trying to get it to work so I made it very simple (or at least I thought).

I am NOT running through any stored procedure, I am calling the program directly. I could set one up if that is the problem, but wouldn’t think I would have to?

I added the precision and scale to the VB.NET code and seems to be working now. Thanks Tom for all your help. Will edit this if come across other issues but seems to be working now.

cmdparm1.Size = 7
cmdparm1.Value = -23456

Consider using:

cmdparm1.Precision = 7
cmdparm1.Scale = 0
cmdparm1.Value = -23456.0

A DECIMAL value should need precision and scale rather than just a size.

Also, many clients like to make their own decisions about how they represent numeric values. When decimal points and digits are supplied, they often behave a little differently. When values are presented without decimal points/digits, many clients assume that an INTEGER data type is okay. Sometimes that leads down a data format conversion code path that isn’t always debugged by developers of the client code.

Without more detail, I’d guess that this is still implemented as a call to a stored proc. You can call your COBOL through stored proc mechanisms even if there has been no stored proc defined to the database as long as you only need ParameterDirection.Input — your iSeries DB2 will handle that okay. It’s only when DB2 is expected to format parameter values to send back that it needs to know definitions. But that’s all only secondary; other code might demonstrate that stored proc concepts aren’t relevant.

Tom

Here is setting of the parameter in Visual Basic 2005………
cmdparm1.ParameterName = “POLNUM”
cmdparm1.OleDbType = OleDb.OleDbType.Decimal
cmdparm1.Direction = ParameterDirection.Input
cmdparm1.Size = 7
cmdparm1.Value = -23456

Here is the COBOL program Linkage section……
LINKAGE SECTION.
01 WS-AMOUNT PIC S9(7) COMP-3.

We are calling the program directly not using a Stored Procedure. From a COBOL side it seems as if the issue is VB.NET can’t add leading zeros and that causes they negative symbol to not be on the last character. I get this message for the field in the DUMP………….

**INVALID DATA ’23456D00′X

Now if I do this and send all 7 digits then it works………………..
Here is setting of the parameter in Visual Basic 2005………
cmdparm1.ParameterName = “POLNUM”
cmdparm1.OleDbType = OleDb.OleDbType.Decimal
cmdparm1.Direction = ParameterDirection.Input
cmdparm1.Size = 7
cmdparm1.Value = -1223456

Cobol value I see…………….1,223,456-

…to send … to a COBOL program?

Especially how does it relate to:

…OLE DB would convert it for them?

Are you trying to invoke a stored procedure? I would normally assume that that is true. If you are, then we need to see both the stored proc definition along with the COBOL LINKAGE SECTION definitions. (And if you’re not trying for a stored proc, we need to know what protocol you want to use.)

Tom