Aschenbrenner, Poul wrote:
But this does not change the error. !!
I can't see what the different there is from snmpGet and the snmpSet.
There's a fundamental difference between snmpGet and snmpSet!! In one
case, the API sets the values of the data structure, and in the other
case, your program sets the values of the data structure! In other
words, one is INPUT the other is OUTPUT. That's a big difference!
If you write a program that doesn't use the VAR_LEN field of the data
structure, you won't ever know that it's not set properly if you use
snmpGet -- your data structure will contain garbage, but if you don't
read it, you won't know.
On the other hand, with snmpSet, the API will require the data structure
to NOT contain garbage. So that's a very big difference, isn't it?
If we want to be absolutely sure, we can run a little test. Here's an
RPG program that uses your (not-aligned) definition for VARBIND. I named
this program 'VARBINDR4' (for RPG4):
H DFTACTGRP(*NO) BNDDIR('QC2LE')
D VARBIND DS
D NEXT * INZ(*NULL)
D POID * INZ(*null)
D ASNTYPE 1A
D VALLEN 10I 0 INZ(50)
D VALPTR * INZ(*null)
D cvthc PR ExtProc('cvthc')
D target 65534A options(*varsize)
D src_bits 32767A options(*varsize) const
D tgt_length 10I 0 value
C *ENTRY PLIST
C PARM hexdump 129
/free
HEXDUMP = *ALLx'00';
VARBIND = *ALLx'00';
ASNTYPE = 'A';
VALLEN = -1;
cvthc(hexdump: varbind: %size(VARBIND)*2);
*inlr = *on;
/end-free
As you can see, it first sets the entire DS to hex zeroes, then it sets
ASNTYPE to 'A' (x'C1') and VALLEN to -1 (x'FFFFFFFF'). It returns a hex
dump of the data structure in it's parameter.
Then I wrote the following ILE C program that does the same thing.
After it makes it's hex dump, it calls the RPG version of the program.
It then prints both hex dumps so you can see if they match.
#include <stdio.h>
#include <qtomeapi.h>
#include <cvthc.mih>
void varbindr4(char *hexstring);
#pragma map ( varbindr4, "LIBSCK/VARBINDR4" )
#pragma linkage (varbindr4, OS)
int main(int argc, char **argv) {
struct _varBind vb;
char hexdump[129];
char rpgdump[129];
memset(hexdump, 0, sizeof(hexdump));
memset(&vb, 0, sizeof(vb));
vb.asn_type = 'A';
vb.val_len = -1;
cvthc(hexdump, &vb, sizeof(vb)*2);
varbindr4(rpgdump);
printf("%s\n\n", hexdump);
printf("%s\n\n", rpgdump);
return 0;
}
When I run this program, this is what I get:
0000000000000000000000000000000000000000000000000000000000000000
C1000000FFFFFFFF000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
C1FFFFFFFF000000000000000000000000000000000000000000000000000000
Press ENTER to end terminal session.
As you can see, the two strings DO NOT MATCH. In the first string (the
one from the C code) there are 6 zeroes after the x'C1' and before the
x'FFFFFFFF'. In the second string (the RPG string) there are not.
That's because of the alignment issue I explained yesterday.
Then try adding ALIGN to your RPG data structure, and notice that they
DO match. Feel free to try them yourself if you don't believe me.
You have other problems in your program as well:
a) Your RC field is missing the 'S' for standalone on the D-spec. This
will make it part of the SNMPDDU data structure, which will probably
cause a problem.
b) You are using %ADDR() for the HOST and CMTY parameters on the call to
SETSNMP. This is wrong. Those parameters are defined with
options(*STRING) for a reason!! If you use %ADDR() you will disable the
function of options(*String) and that will cause a problem.
c) You are not setting the ASNTYPE field of the VARBIND structure. The
API documentation says that you must set it for the snmpSet() function,
and you're not doing that.
d) The API docs say that the val_len field needs to be set to the amount
of data in the OID when you call snmpSet. This is different from
snmpGet, where it's used to indicate the AMOUNT OF SPACE available. So
for a snmpGet, it should be 50 (the size of your VALUE field, but for
snmpSet it should be the size of the data you're sending (which appears
to be 9.)
That's just what I'm able to see by looking over your code carefully
(which is very time consuming, and this isn't my project!) That's
without actually trying to run it, there may be lots of other problems
as well.
My point is this: I'm not in a good position to find every bug in your
program. I've pointed out the things I noticed, but please don't reply
saying "Scott, you dummy, you didn't solve my problem!" I can't test
everything for you, you're going to have to learn to debug your program
yourself. However, the things I've pointed out are definitely problems
that need to be fixed.
midrange.com
