Re: Oddity with QUSRTVUI

I think ENQ/DEQ are for queues. The MI instruction I compared to was
FNDINXEN (and INSINXEN and so forth) but I couldn't remember it when I sent
the post.

Anyhow, I may be accustomed to MI instructions and such but others are not,
so for the sake of maintainability I stick with "easily understandable"
APIs. That, and I am using *SYSTEM domain indexes so "On a system with the
QSECURITY system value set to 40 or greater, you must use system APIs to
access system-domain user indexes." pertains here.

I just wondered what that object might be. All I did was create a perfectly
normal fixed-length user index and put entries in it and read them back
out. Been doing it for a long time, but only just now noticed the odd space
left behind. It struck me as odd that IBM would leave a persistent space
behind.

Another guy at work here has seen them there (in QTEMP) for years but never
knew where exactly they originated.

Stu





On Mon, Aug 23, 2010 at 09:18, Dennis Lovelady <iseries@xxxxxxxxxxxx> wrote:

It's quiet out there. Too quiet. :)

Well, I can say that I have not seen this effect on any release
before/including V5R3. We haven't moved beyond that. I will say that I
suspect this is caused by something other than standard, IBM-supplied
QUSRTVUI functionality.

But if you're accustomed to ENQ/DEQ, why would you use QUSRTVUI? Just
curious.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"A diplomat is a man who always remembers a woman's birthday but never
remembers her age."
-- Robert Frost

Just today noticed a weird thing that happens whenever I use QUSRTVUI
(Retrieve User Index Entries). I'm running v5r4.

Every time QUSRTVUI runs, a user space gets created in QTEMP. The
user
space, always named (for me anyway) QUS + 7 hex chars (like QUS000007B),
is
always the same size (8192 bytes) and always filled with nulls. In
different jobs it has different names but still in QTEMP always. It
happens
for all indexes, both fixed- and variable-length.


Using comparable MI instructions to access the index does not cause
this.


Ever seen such a thing? Maybe it's normal and I just never noticed it
before.


Dump of user space:


DMPOBJ
PARAMETERS


OBJ- QUS000007B CONTEXT-
QTEMP

OBJTYPE-
*USRSPC


OBJECT TYPE- SPACE
*USRSPC

NAME- QUS000007B TYPE- 19
SUBTYPE- 34

LIBRARY- QTEMP 0144930C1863A7EA8000 TYPE- 04
SUBTYPE- C1

CREATION- 08/20/10 07:45:48 SIZE-
0000002000

OWNER- SROWE TYPE- 08
SUBTYPE- 01

ATTRIBUTES- 0800 ADDRESS- 37D761182A
000000

SPACE ATTRIBUTES-


000000 00FFF000 00000074 1934D8E4 E2F0F0F0 F0F0F7C2 40404040
40404040
40404040 * 0 È QUS000007B *

000020 40404040 40404040 E0060000 00000000 00001000 00100000
00000000
00000000 * \ *

000040 00000000 00000000 259C60E7 6C000400 00000000 00000000
00000000
00000000 * æ-X% *

000060 00000000 00000000 00000000 00000000 00FFF000
* 0 *

SPACE-


000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
00000000 * *

LINES 000020 TO 000FFF SAME AS
ABOVE

.POINTERS-



NONE


OIR DATA-



NONE


END OF
DUMP


* * * * * E N D O F L I S
T I N
G * * * * *



Stu
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.