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:

F17, *BOT, Enter - now positioned at the bottom.
Now, on the WRKOBJ command line:

Positioned at the bottom, despite not having pressed F17 on

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?

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

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 ;-)

This thread ...

Return to Archive home page | Return to MIDRANGE.COM home page