With only a cursory glance, the obvious error is like with the
example last year for QYASPOL API filter. That is, each of the expected
_declared as_ BINARY(4) [four byte binary numeric where the numeric zero
equals 0x00000000] for the last eight numeric fields\variables, does not
match the given _declared as_ CHAR(4) [four bytes of character string
where the padded empty string equals the EBCDIC string 0x40404040].

http://newsgroups.derkeiler.com/Arch.../msg00162.html
http://newsgroups.derkeiler.com/Arch.../msg00166.html
http://groups.google.com/group/comp....c49b4288d003b4

Regards, Chuck

Henrik wrote:
>
> I need some help debugging my program. I call API QtocLstNetCnn out of
> an java pcml (2.0) program with an additional qualifier list.
> Therefore I've defined some structs in my pcml doc. When I run my prog
> with qualifier list I get no results stored in my userspace. Without
> a special qualifier list I get out all connections.
>
> It seems that I haven't got set up the qualifier list properly.
>
>
> > entrypoint="QtocLstNetCnn" >
> > usage="input" init="CHKMQCHAN MOTZKUSH " />
> > usage="input" init="NCNN0100" />
> > usage="input" />
> > usage="input" init="64" />
> > usage="input" init="NCLQ0100" />
> > usage="inputoutput" />
>
>
>
> > init="*ALL" />
> > init="*SUBSET" />
> > init="0" />
> > init="" />
> > init="" />
> > init="" />
> > init="" />
> > init="" />
> > init="" />
> > init="23" />
> > init="0" />
>

Hello Chuck,

thanks, I declared it as type="int" length="4" and getting results
now. When I put a valid Port (i.e. 23) into the port paramter
(portlower) I'am getting results as well.

But putting an internet adress (format "xxx.xxx.xxx.xxx") into the
"rinetlower" is returning an "initial value error". How to declare
this variable? The manual says binary(4).

Regards Henrik



On 19 Mai, 14:35, CRPence wrote:
> * *With only a cursory glance, the obvious error is like with the
> example last year for QYASPOL API filter. *That is, each of the expected
> _declared as_ BINARY(4) [four byte binary numeric where the numeric zero
> equals 0x00000000] for the last eight numeric fields\variables, does not
> match the given _declared as_ CHAR(4) [four bytes of character string
> where the padded empty string equals the EBCDIC string 0x40404040].
>
> http://newsgroups.derkeiler.com/Arch...browse_thread/...
>
> Regards, Chuck
>
>
>
> Henrik wrote:
>
> > I need some help debugging my program. I call API QtocLstNetCnn out of
> > an java pcml (2.0) program with an additional qualifier list.
> > Therefore I've defined some structs in my pcml doc. When I run my prog
> > with qualifier list *I get no results stored in my userspace. Without
> > a special qualifier list I get out all connections.
>
> > It seems that I haven't got set up the qualifier list properly.
>
> > > > entrypoint="QtocLstNetCnn" >
> > * * > > usage="input" *init="CHKMQCHAN MOTZKUSH *" * * />
> > * * > > usage="input" *init="NCNN0100" * * * * * * * * />
> > * * > > usage="input" * * * * * * * * * * * * * * * * */>
> > * * > > usage="input" *init="64" * * * * * * * * * * * />
> > * * > > usage="input" *init="NCLQ0100" * * * * * * * * />
> > * * > > usage="inputoutput" />
> >
>
> >
> > * > > init="*ALL" * * */>
> > * > > init="*SUBSET" />
> > * > > init="0" * * />
> > * > > init="" * * />
> > * > > init="" * * />
> > * > > init="" * * />
> > * > > init="" * * />
> > * > > init="" * */>
> > * > > init="" * * />
> > * > > init="23" * * />
> > * > > init="0" * * />
> > - Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

I am actually not entirely sure what the documentation means to imply
when it suggests using dotted-decimal format, because as I understand
that format, the terminology refers to a text string. However I would
expect that what the documentation probably means to suggest instead, is
that the BINARY(4) field\variable should be used to represent the four
one-byte binary values 0x00 to 0xFF, to represent the decimal values 0
to 255 for each of the components of the dotted decimal format; i.e.
input is a 32-bit representation of the dotted-decimal format. Thus
172.16.50.56 would be the hex string 0xAC103238 which is the unsigned
4-byte binary value to represent the decimal values 2886742584. This
would make sense to me, given that IPv4 is a "32-bit network IP
address". And if so, the documentation should probably direct the
reader to the inet_addr() API:

http://publib.boulder.ibm.com/infoce...pis/unix8b.htm
inet_addr() (Translate the full address from dotted decimal format to a
32-bit Internet address) is used to translate an Internet address from
dotted decimal format to a 32-bit IP address.

FWiW the following documentation seems to suggest what I would expect
for the "dotted-decimal format". There that terminology is used to
describe what is declared as a CHAR(15), as noted for "Local binding
network address". That field has a corresponding "Local binding network
address binary" which is a BINARY(4) as the "Binary representation of...
address":
http://publib.boulder.ibm.com/infoce...clstnetrte.htm

Regards, Chuck

Henrik wrote:
> Hello Chuck,
>
> thanks, I declared it as type="int" length="4" and getting results
> now. When I put a valid Port (i.e. 23) into the port parameter
> (portlower) I'm getting results as well.
>
> But putting an internet address (format "xxx.xxx.xxx.xxx") into the
> "rinetlower" is returning an "initial value error". How to declare
> this variable? The manual says binary(4).
>
> Regards Henrik
>
>
>
> On 19 Mai, 14:35, CRPence wrote:
>> With only a cursory glance, the obvious error is like with the
>> example last year for QYASPOL API filter. That is, each of the expected
>> _declared as_ BINARY(4) [four byte binary numeric where the numeric zero
>> equals 0x00000000] for the last eight numeric fields\variables, does not
>> match the given _declared as_ CHAR(4) [four bytes of character string
>> where the padded empty string equals the EBCDIC string 0x40404040].
>>
>> http://newsgroups.derkeiler.com/Arch...browse_thread/...
>>
>> Regards, Chuck
>>
>>
>> Henrik wrote:
>>
>>> I need some help debugging my program. I call API QtocLstNetCnn out of
>>> an java pcml (2.0) program with an additional qualifier list.
>>> Therefore I've defined some structs in my pcml doc. When I run my prog
>>> with qualifier list I get no results stored in my userspace. Without
>>> a special qualifier list I get out all connections.
>>> It seems that I haven't got set up the qualifier list properly.
>>> >>> entrypoint="QtocLstNetCnn" >
>>> >>> usage="input" init="CHKMQCHAN MOTZKUSH " />
>>> >>> usage="input" init="NCNN0100" />
>>> >>> usage="input" />
>>> >>> usage="input" init="64" />
>>> >>> usage="input" init="NCLQ0100" />
>>> >>> usage="inputoutput" />
>>>
>>>
>>> >>> init="*ALL" />
>>> >>> init="*SUBSET" />
>>> >>> init="0" />
>>> >>> init="" />
>>> >>> init="" />
>>> >>> init="" />
>>> >>> init="" />
>>> >>> init="" />
>>> >>> init="" />
>>> >>> init="23" />
>>> >>> init="0" />
>>> - Zitierten Text ausblenden -
>> - Zitierten Text anzeigen -
>

Thanks Chuck, it is still not working properly. I tried out your
recommendation and got into another issue:

I put this into my pcml doc:

init="AC14424C" />

and getting this out of the programm trace :

Di Mai 20 08:39:27:562 CEST 2008 Writing data -- Offset: 30 Length: 4
Name: "netstat.listqual.rinetlower" Byte data: ACACACAC Thread[main,
5,main]

It seems that my hex string isn't transfered properly to the service
program.

Regards Henrik



On 19 Mai, 17:33, CRPence wrote:
> * *I am actually not entirely sure what the documentation means to imply
> when it suggests using dotted-decimal format, because as I understand
> that format, the terminology refers to a text string. *However I would
> expect that what the documentation probably means to suggest instead, is
> that the BINARY(4) field\variable should be used to represent the four
> one-byte binary values 0x00 to 0xFF, to represent the decimal values 0
> to 255 for each of the components of the dotted decimal format; i.e.
> input is a 32-bit representation of the dotted-decimal format. *Thus
> 172.16.50.56 would be the hex string 0xAC103238 which is the unsigned
> 4-byte binary value to represent the decimal values 2886742584. *This
> would make sense to me, given that IPv4 is a "32-bit network IP
> address". *And if so, the documentation should probably direct the
> reader to the inet_addr() API:
>
> http://publib.boulder.ibm.com/infoce...opic/apis/unix...
> inet_addr() (Translate the full address from dotted decimal format to a
> 32-bit Internet address) is used to translate an Internet address from
> dotted decimal format to a 32-bit IP address.
>
> * *FWiW the following documentation seems to suggest what I would expect
> for the "dotted-decimal format". *There that terminology is used to
> describe what is declared as a CHAR(15), as noted for "Local binding
> network address". *That field has a corresponding "Local binding network
> address binary" which is a BINARY(4) as the "Binary representation of...
> address":http://publib.boulder.ibm.com/infoce...opic/apis/qtoc...
>
> Regards, Chuck

I would suggesting using INT-4 precision 32; i.e. to match the 32-bit
internet address, treated as an unsigned long value, as noted from
inet_addr():
http://publib.boulder.ibm.com/infoce...pis/inaddr.htm

In review of type="byte", it appears that the type /byte/ is
literally that; i.e. one byte of data. Thus the first byte in the
/init/ is being assigned for all four byte in the type="byte"
length="4". A bit more complicated than that; it is implicitly an array:

The doc for type="byte", suggests that declaration defines a "/byte/
where byte is a byte value. No conversion is performed on the data. A
byte data value is returned as an array of byte values (byte[])"
http://publib.boulder.ibm.com/infoce...h/pcmldttg.htm
And as an array, I infer the init="string" is problematic for the
given declaration, due to the comment in the documentation suggesting
"the initial value specified is used to initialize scalar values. If the
element is defined as an array or is contained within a structure
defined as an array, the initial value specified is used as an initial
value for all entries in the array.". That is, I infer the attempt to
init="AC14424C" is actually assigning 0xAC into each of the four
one-byte array elements; at least that would explain seeing 0xAC four
times in the debug data.

Declared instead as a structure of four separate "byte" values with
length="1", I would expect it to work; each initialized to the separate
hex representing each 1-byte binary number of the dotted-decimal format.
That declaration may seem a bit odd, but may be preferable, if using a
4-byte unsigned binary is even more difficult or less intuitive to the
reader.

And to further confuse [me, at least]:

The earlier text quoted from the docs for /byte/ suggests "For more
information, see the byte values for length."
http://publib.boulder.ibm.com/infoce...onrelative.htm
And there for type="byte" it suggests its /length=/ will define "The
number of bytes of data for this element. You must specify either a
literal number or data-name." That seems to conflict the implication
that the length is the number of elements in the byte[] array.? I would
expect it to say its /length=/ would define 'the number of one-byte
elements'. I am not sure what to think... Sorry. One last note... The
type="byte" was mentioned in the length= documentation [in the first
link given above; pcml tags], commenting on data-name "where data-name
defines the name of a element within the PCML document that will
contain, at runtime, the length. A data-name can be specified only for
elements with type="char" or type="byte"."

Regards, Chuck

Henrik wrote:
> Thanks Chuck, it is still not working properly. I tried out your
> recommendation and got into another issue:
>
> I put this into my pcml doc:
>
>
>
> and getting this out of the program trace :
>
> Di Mai 20 08:39:27:562 CEST 2008
> Writing data -- Offset: 30 Length: 4
> Name: "netstat.listqual.rinetlower" Byte data: ACACACAC
> Thread[main,5,main]
>
> It seems that my hex string isn't transfered properly to the service
> program.

Hello Chuck,
this was the key to success. The additional struct you mentioned must
look like this.


init="0xAC" />
init="0x14" />
init="0x42" />
init="0x4C" />


Now I get right results back from the api.

Thanks a lot for your efforts.

Regards Henrik




>
> * *Declared instead as a structure of four separate "byte" values with
> length="1", I would expect it to work; each initialized to the separate
> hex representing each 1-byte binary number of the dotted-decimal format.
> * That declaration may seem a bit odd, but may be preferable, if using a
> 4-byte unsigned binary is even more difficult or less intuitive to the
> reader.
>