On 30-Jul-2014 13:42 -0500, Buck Calabro wrote:
On 7/30/2014 2:22 PM, CRPence wrote:
I am shocked that I only just now noticed this bizarre effect: If
I use a F17=Position-to request and use either of the special
values *TOP or *BOT within a job, the next Work With panel *might*
position with the /previous/ positioning preference; apparently any
WRKxxx feature that /shares/ the same Interactive Profile Entry
(IPE) position-to data. <<SNIP>>
Confirmed, 7.1 TR7. To re-create:
WRKOBJ OBJ(QGPL/*ALL)
F17, *BOT, Enter - now positioned at the bottom.
Now, on the WRKOBJ command line:
WRKDTAARA DTAARA(QSYS/*ALL)
Positioned at the bottom, despite not having pressed F17 on
WRKDTAARA.
Any opinion(s) on whether the effect is "clearly a defect, or what
possible value is there in the effect [across _disparate WRKxxx_
requests]?" Or with regard to the latent effects of past positioning
across new invocations even of the _same WRKxxx_ command but invoked
with a different set of object(s) to list due to completely different
inputs for the specified generic* or special-value qualified object naming?
Test-case:
WRKDTAARA QSYS/*ALL /* F17, *BOT, Enter to confirm position */
WRKDTAARA QSYS/Q* /* why would this be positioned-to *BOT? */
WRKF QSYS2/SYS* /* why would this be positioned-to *BOT? */
If I F3/F12 out of WRKOBJ, the panel 'forgets' my previous choice of
*BOT.
Huh. Seems then, that the dev must have become aware of the effect,
for the [negative] impact to disparate WRKxxx requests. Presumably
however, only being aware of the effect at the same call level, they
eventually /fixed/ what they noticed as the issue, but not /fixing/ the
wider effects. That is, on the older release v5r3, the effect is there
from any prior WRKxxx work, irrespective of the means to exit the prior
WRKxxx panel, and irrespective of call level; obviously the behavior was
changed eventually, to eliminate the effect of latent positioning from
prior WRKxxx work that had since been exited, but also obvious, the
effect of latent positioning from a prior WRKxxx work that remains on
the stack still impacts newer WRKxxx requests in the same way.
When I first noticed the effect, my call-levels had not been nearly
so direct; i.e. rather than WRKDTAARA issued directly from the WRKOBJ
command\parameter-input area, I had issued requests to activate various
interactive utilities, attention programs, CALL requests, etc., before
finally arriving at some much higher call level where I eventually
noticed the oddity. The /further away from/ the prior position-to
request, I suppose, the less likely the effect of latent positioning was
to get noticed. And then that the F16=Repeat-position-to being
non-functional despite the new WRKxxx had apparently remembered and
therefore implicitly activated a _prior_ position-to; a horribly
incongruous result IMO, making any choice to apply that positioning
extremely puzzling.
I suspect the /problem/ was viewed [by dev] only with the narrow
scope of WRKxx->exit->WRKyy, rather than as a wider issue, and thus that
the /easy fix/ that was implemented for that specific test-case was
deemed complete; i.e. upon F3=Exit\F12=Return such that the panel was
exited, the stored choice for top\bot positioning was cleared [from the
IPE], thus the next invocation of WRKxxx was not influenced by the prior
positioning.
FWiW: I expect that dumping the contents of the IPE, which I believe
to be the x/0EC4 object with the same name as the [current] user profile
for the job, would show the difference; the first dump from when WRKOBJ
was still active after positioning to *BOT, and the second dump from
after WRKOBJ was exited. Possibly even, the data is stored as the
visible text *BOT versus being an encoded [numeric] value.
I suspect, as having gone unnoticed, the wider /problem/ remained for
effectively /the same/ activity, but limited only to when the newer
WRKxxx activity has been initiated at higher invocation levels; i.e. new
WRKxxx while a prior WRKxxx invocation remains in the stack per that
request not yet exited\completed with a F3|F12. So just as the original
issue went unnoticed [for some release(s)] for WRKxxx requests being
performed at the same invocation level, so too will the wider problem
:-( Though I suspect nobody [else\here] will report the issue, and even
if reported I doubt any resources would be put forth to /correct/ the
behavior; they would be more likely to say the effect is a /feature/ of
those WRKxxx panels :-(
The help does not mention *BOT or *TOP.
Too bad the dev did not also notice that lack of help text when the
slightly changed behavior was instituted :-( as they could have had that
help text corrected too. And if they were aware that they were leaving
the side-effects for different call levels, then they could have
documented the bizarre behavior as a .feeture. of some subset of WRKxxx
panels that apparently share the same processor [CPP QMNWRKXX ¿and IPE
data?] ;-)
And FWiW, while the effect may seem rather innocuous at first
glance... With an _assumption_ that the WRKxxx requests will always
start at *TOP irrespective of past work-with activity, some rather
drastically incorrect conclusions can be drawn, with possibly highly
negative consequences. In my specific case, the lack of the expected
file being presented in the output of my request to WRKF QTEMP/*ALL
FILEATR(*ALL) had me falsely inferring that a control file was missing;
the non-existence of my control file [in a list of *ALL files of *ALL
possible attributes] was an indication to me that DLTF QTEMP/MXT7* was
desirable. Seeing the only file listed was named VL100, something used
to test a VARCHAR scenario and as some testing that I had since
completed, it was only dumb luck that I then decided to delete that sole
file; thus the /magical/ appearance of another file caused me to realize
that the positioning was askew, and resulted in my closer inspection to
find that the control file remained -- which meant that my Delete File
activity was *not* desirable at the time.
Of course if these WRKxxx commands had a *parameter* for POSITIONTO()
with a default value of *SHRPRV [shared previous; a *PRV value common to
the Menu feature's WRKXX], then I *might* be open to a suggestion that
the result is expected. Lacking such a parameter, I can infer only that
the behavior is accidental rather than planned; and given the
modification to avoid impacting invocations at the same [or lower] call
levels, the dev apparently recognized the behavior as undesirable. If
such a parameter had been or were made available, then my System Change
Management would include effecting a change in the default behavior to
POSTO(*TOP) to avoid any confusion, except when I explicitly chose to
confuse myself ;-)
midrange.com
