> GLOBAL (zone)
> SYSMOD (entry)
> ENAME,SOURCEID,SMODTYPE (sub entry)
> SOURCEID='PUT2312' (filter)
In the grand scheme of things, the results of that query shouldn't use much
storage at all. And if you didn't get an error message from GIMAPI then it
obtained all the storage it needed.
Sure. The Interface to GIMAPU is an assembler program called by a rexx
program. The assembler program creates stem variables with the results from
the call. The Query is for:
MVS.GLOBAL.CSI
GLOBAL (zone)
SYSMOD (entry)
ENAME,SOURCEID,SMODTYPE (sub entry)
SOURCEID='PUT2312' (filter)
*|
> Does GIMAPI have a storage limitation, and if so, can it be controlled by the
> program?
GIMAPI does not have a storage limit which can be easily controlled by the
caller. It will gobble up as much 31-bit storage as it needs to return the
requested information, limited only by REGION size
Hi
I noticed the same, but the codition filter is related with zones and global
and entries. The results are different for example if you are using just tzones
or dzones or a mix of tzones, dzones and global.Of course, I do not know your
scenary, but it almost like that.
RegardsDan
Sent from
We are using the GIMAPU (SMP) to retrieve data from SMP. We noticed that
not all of the data conform with the conditions specified are returned. At
the end of the query command, we perform a FREE command to free the storage
occupied by the QUERY call.
The problem is easy to identify when querying
