QtocLstNetCnn with qualifierlist NCLQ0100 - IBM AS400

This is a discussion on QtocLstNetCnn with qualifierlist NCLQ0100 - IBM AS400 ; Greetings, 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 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: QtocLstNetCnn with qualifierlist NCLQ0100

  1. QtocLstNetCnn with qualifierlist NCLQ0100

    Greetings,

    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" />



    THX in adv.

    Henrik

  2. Re: QtocLstNetCnn with qualifierlist NCLQ0100

    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" />
    >


  3. Re: QtocLstNetCnn with qualifierlist NCLQ0100

    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 -



  4. Re: QtocLstNetCnn with qualifierlist NCLQ0100

    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 -

    >


  5. Re: QtocLstNetCnn with qualifierlist NCLQ0100

    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


  6. Re: QtocLstNetCnn with qualifierlist NCLQ0100

    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.


  7. Re: QtocLstNetCnn with qualifierlist NCLQ0100

    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.
    >


+ Reply to Thread