I wrote some code 10 years ago that was 31-bit XPLINK C++ calling the IBM json
parser.
Looking at it now, I agree: the header for hwtjpars is incorrect - parm 3
should be char** instead of char*.
Here's what I had:
/* in JsonParser.h */
..
#include "hwtjic.h"
..
HWTJ_ PARSERHANDLE_TYPE parser;
HWTJ_ DIAGAREA_TYPE diag;
int rc;
char* json_input;
size_t json_input_len;
/* in JsonParser.C */
void JsonParser::parse() {
if (!json_input) {
logAndThrowError("hwtjpars: no JSON to parse.");
}
hwtjpars(&rc, parser, (char*)&json_input, json_input_len, &diag);
if (rc) {
logAndThrowError("hwtjpars failed.");
}
parsed = true;
}
Kirk Wolf
Dovetailed Technologies
https://coztoolkit.com
On Fri, Aug 1, 2025, at 10:48 AM, Charles Mills wrote:
> #1 I must have been suffering from Beaver's Brain Flatulence. There's no
> 64-bit anything in this picture. 64-bit implies XPLINK but XPLINK does not
> imply 64-bit. A review of the compile listing confirms ILP32. Red herring.
>
> #2 Solved. Is anyone using this product? The doc and the supplied C header
> are wrong. The third parameter is *not* as clearly documented "the address of
> the actual buffer storage location of the JSON text to be parsed" and what
> the header declares char* -- it is the address of a word POINTING TO the
> buffer -- char** in C-speak.. The C header is wrong, and the IBM sample
> program overrides the header with a cast! (jeez, guy, why not fix the header
> instead?).
>
> Does anyone care how I found it? I changed my sample text from '{"verbose...'
> to ' {"verbose...' (with a leading blank) which would change the first byte
> from C0 to 40, which would mean that if hwtjpars used it as an address it
> would no longer see it as negative. Bingo! S0C4 rather than 1025, confirming
> my suspicion. I changed my code to (char *)&sanitizedparm, and it works!
> (FWIW, not just this call, but my code ran all the way through my other calls
> too!)
>
> Is anyone actually using z/OS JSON parse from C/C++? Does anyone from IBM
> care that the doc is misleading and the header is wrong? (Serious question --
> if so, drop me a note and I will work with you on fixing the header.)
>
> Charles
>
> On Thu, 31 Jul 2025 17:04:10 -0500, Charles Mills <[email protected]> wrote:
>
> >I am guessing that the problem is that the program is XPLINK and is passing
> >a 64-bit parameter to hwtjpars and the first word is of course zero.
> >
> >What do I have to specify for linkage? I am still learning my way through
> >XPLINK.
> >
> >The JSON functions were declared extern "OS". I just tried extern OS_UPSTACK
> >with no change.
> >
> >Is this impossible to solve easily? Are my local variables likely to be
> >above the bar, and impossible to pass to the JSON services? Does the JSON
> >parse not support 64-bit programs? That seems odd.
> >
> >Help me out here <g>
> >
> >Charles
> >
> >On Thu, 31 Jul 2025 16:30:42 -0500, Charles Mills <[email protected]> wrote:
> >
> >>I am dipping my toe into the z/OS JSON parser (form C++). I am using
> >>SYS1.SIEAHDRV.H(HWTJIC) as a guide. I make it through the hwtjinit() with a
> >>zero return code but my next call, to hwtjpars(), gives me a return code
> >>1025 (Specified JSON string address is less than or equal to zero).
> >>
> >>I thought okay, I am getting bit by a high-order list terminator bit, so I
> >>AND the address with 0x7fffffff and still no joy. Here's the code
> >>
> >>char* sanitizedparm = (char*)((int)parm & 0x7fffffff); // Get rid of any
> >>high-order x'80'
> >>
> >>M::Verbose("Address of JSON text, %08X; Length %d, data '%s'",
> >>sanitizedparm, parmLen, sanitizedparm);
> >>
> >>hwtjpars(&return_code,
> >> parser_instance,
> >> sanitizedparm, /* JSON text string address(input) */
> >> parmLen, /* JSON text string length (input) */
> >> &diag_area);
> >>
> >>That "M::Verbose" puts out a diagnostic message that is exactly as I would
> >>expect:
> >>Address of JSON text, 1B1500D9; Length 17, data '{"verbose": true}'
> >>
> >>Just for a lark I tried passing a static string in the source code and get
> >>the same error.
> >>
> >>Anyone have any experience with this? Anyone have any ideas?
> >>
> >>Charles
> >>
> >>----------------------------------------------------------------------
> >>For IBM-MAIN subscribe / signoff / archive access instructions,
> >>send email to [email protected] with the message: INFO IBM-MAIN
> >
> >----------------------------------------------------------------------
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
