Sending -/+ Number from VB.NET to COBOL

220 pts.
Tags:
COBOL
OLE DB
VB.NET
Visual Basic
Visual Basic .NET
Is it possible for someone on the VB.NET side to send a -120 to a COBOL program? The COBOL program LINKAGE SECTION is WS-AMOUNT PIC S9(3). The only way I got it to work is having the VB.NET person to send "12}" in char field. Just figured there was a way they could send like they normally would like -120 and OLE DB would convert it for them?

Software/Hardware used:
V5R4

Answer Wiki

Thanks. We'll let you know when a new response is added.

You are missing the understanding of what S9(3) means. The sign (positive or negative) is carried in the last byte of the field along with the numeric value.

If you want “send like they normally would like -120″ then you are looking at a 4 byte field and it will not be a numeric field. Your program will have to try to figure out what to do with the hyphen (or the + or the absence of both).

Discuss This Question: 5  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    Please define what you mean by: ...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
    125,585 pointsBadges:
    report
  • BeanBaggs
    Here is the connection string in VB.NET............ Dim dbconn As New OleDb.OleDbConnection("Provider=IBMDA400; OLE DB Services=-2; Data Source=S106****; User Id=*****; Password=*******") 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-
    220 pointsBadges:
    report
  • TomLiotta
    Just to be certain, is that the complete list of parameters? Also, is it ILE COBOL or COBOL/400? 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
    125,585 pointsBadges:
    report
  • BeanBaggs
    It is OPM COBOL, but I compiled it in ILE and get the same results so problem isn't specific to one or the other. 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.
    220 pointsBadges:
    report
  • TomLiotta
    There could be some minor differences between OPM and ILE handling of parameters if there were others, particularly when single-byte (e.g., a boolean indicator value) parameters are involved. It was a "just in case" question that might be relevant in later programs but wasn't relevant here. 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
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following