RE: Pointer Reset operation?

Chris,

Thanks for the reply.

The if pstdin = *null; was just for testing and debugging in order to
understand what was going on.
The problem is really one of implementing ILE programs in a totally non
ILE.

This is an extract from the callstack of the job :

----Groupe d'activation-----
Programme Nom Numéro
QP0ZPCP2 QSYS *DFTACTGRP 0000000000000001
QZSRCGI QHTTPSVR *NEW 0000000000000011
MyWebPgm MyLib * DFTACTGRP 0000000000000002

I seem to remember from years ago when I worked a lot in an ILE, that INLR
had no effect on an ILE RPG if it was running in the DFTACTGRP.
It seems I have three choices :

Compile my program with ACTGRP *CALLER but make sure all intermediate
programs (for example a CLP that sets the library list) are not in the
DFTACTGRP;
This could be problematic as there is no infrastructure for compiling and
it only needs another programmer to come along and enter option 14.

Let my program run in the DFTACTGRP and manage file opening (seems costly
to me)

Compile with ACTGRP *NEW

date: Mon, 26 Jul 2021 17:50:33 +0000
from: "Hiebert, Chris" <chris.hiebert@xxxxxxxxxxxxxx>
subject: RE: Pointer Reset operation?

Since you've conditioned the call to LOAD TREE based on the pointer being
null, then there may not be anything that is initializing the value of
$MSGERR to blanks.

To correct the error on the $MSGERR field you would need to INZ or clear
the value prior to the call.
Here shows both:

Dcl-s $MSGERR Varchar(500) Inz;
Clear $MSGERR;
if pstdin = *null;
pSTDIN = YAJL_STDIN_LOAD_TREE( *ON : $MSGERR);
endif;
If $MSGERR <> *Blanks;
...
Endif;



We would have to understand the entire process to know why you are
conditionally running the Load Tree based on if pstdin is null.

I'd wonder why each run wasn't complete, from start to end.

The RPGLE program should run, then turn on *INLR and return. This closes
the program down.
If you are not doing that then you could be using a Linear Main program.

If you are using a Linear Main program then you may need to account for
the values of some fields yourself. I usually suggest an Initialize
procedure to set default values on each call.
Linear main use this H-Spec CTL-OPT:
ctl-opt Main(ProcedureName);


I would think that the default RPG method for most is to have a Cycle
program where you need to turn on *INLR and exit to close the program and
release the resources.
If that was the case then the pointer pSTDIN would be null, by default,
for each call to the program.
If you are trying to use a MAIN(proc) program, then you probably want to
make sure to set the values of your pointers yourself.


I'd expect the program to start.
Then call YAJL_STDIN_LOAD_TREE for the first time (not conditioned based
on the prior value of a pointer).
Then do other things with Yajl.
Then end with a call to yajl_tree_free to free up the Tree Pointer.

So each run would get a new pointer out of YAJL_STDIN_LOAD_TREE.



After yajl_tree_free is run you can assume that the memory is unallocated.
You shouldn't assume that the pointer has been set to NULL.

If you want to compare the pointer to null, then you should specifically
set pSTDIN to null after you run yajl_tree_free.

Otherwise you are trying to assume that the internal process flow of YAJL
works in a specific manner.
And you should never assume something like that, because the internal code
of YAJL could change on the next patch (if there ever is one required).
But the concept goes for most 3rd party libraries being used.

All my variables are staying initialised between calls as they are all
global (I'm writing for a team with no ILE or RPG4 experience!).

Based on this I'd wonder if someone is running a cycle program and forgot
to turn *INLR=*on; before the return from the program.

At the moment I'm simply making the program run in *new actgrp which

solves moste of these problems.

Properly closing the program would be a better idea. You may be
inadvertently leaving the program and memory allocated to the call stack.
I'm not talking about the memory for the Yajl Tree. I'm talking about the
memory for every RPG variable you have. Like the 16 bytes for each pointer.
These could add up if this program is run a lot.

Most of the time I only need to use a *NEW activation group to deal with
an SQL cursor not closing properly. Which doesn't sound like the issue here.

Using a *NEW activation group is expensive for programs that are run
multiple times.
Especially if you are accessing service programs that are set to *CALLER,
as each new activation would activate another copy of the service program.

If you want your program to run outside of the default activation group,
then using a named activation group would be a better solution. At least
then there is a chance that somethings don't have to waste time loading
again and again and again.


Chris Hiebert
Senior Programmer/Analyst
Disclaimer: Any views or opinions presented are solely those of the author
and do not necessarily represent those of the company.

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Dave
Sent: Monday, July 26, 2021 3:35 AM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Pointer Reset operation?

Thanks to all for the great replies.

Chris, in the example you give, Nodepointer (in my case) is remaining

with

the same address after yajl_tree_free(nodepointer).
I'm thinking that the problem is a misunderstanding of pointer usage on

my

part.
noticed that the pointer to stdin is remaining with the same address even
if I change the JSON data submitted.

I tested this :
if pstdin = *null;
pSTDIN = YAJL_STDIN_LOAD_TREE( *ON : $MSGERR);
endif;

IF $MSGERR <> *BLANK provokes error RNQ0115 on a second call
because of the length of $MSGERR not being set.

So I'm deducing that YAJL_STDIN_LOAD_TREE frees the memory making my
pointer point to this freed up memory.

It's easy to miss a control which could lead to the program crashin- I
wouldn't have thought of testing the value and the length of $MSGERR.
Other problems I've had were a pointer not initialised because of an
expected JSON object not present and the fact that of course my files

are

staying locked by the job.

At the moment I'm simply making the program run in *new actgrp which
solves
moste of these problems