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.