×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 08-Jul-2016 10:34 -0500, Dan wrote:
A long time ago in a galaxy far, far away, you may recall that the
panel for Display Open Files in DSPJOB/WRKJOB defaulted to display
the I/O details. Then, at some point, IBM added the scoping details
as an F11 toggle, and made the scoping details the default panel.
Enough people complained, and IBM graciously "blessed" us with a
request-only PTF to make the I/O details panel the default and that
needs to be applied with every new release. Has this changed? Is it
possible that IBM gave us a hidden data area or some other
user-configurable doo-dad to control the default panel for Display
Open Files?
From the archive, the thread starting with:
[http://archive.midrange.com/midrange-l/200011/msg00026.html]
A link to the most recent discussion thread that I could find
follows; that discussion concludes, apparently, that support for an
additional PTF at each release, and perhaps even any alternative support
for assigning which view is presented [as was alluded in the APAR
sysrouted across various releases], was abandoned on\since v5r1:
[
http://archive.midrange.com/midrange-l/200111/threads.html#02772]
Subject: PTF for viewing open files (WRKJOB/DSPJOB) for V5R1
Sadly, what was originally offered was a /bad idea/; a poor choice,
for a variety of reasons, but most notably, that any future defects in
the code would require a two-pronged chain of PTFs to enable both
versions to persist. Their rationale in such enablement surely was that
in all but one release, the code had never before been changed via a
PTF, and the expectation that would remain so. I do hope that they did
not offer a fix by that implementation, on any release since; per...
Most unfortunate is that the fix-developers apparently failed to
consult other [experienced fix and OS] developers for a recommended
approach to take; hopefully they would have avoided any proponents of
the too commonly offered data-area-implementations, even if that is not
nearly such a poor choice as contrasted with what was done. So I hope
also, that they did not offer a fix by that implementation, on any
release since; per...
The OS has long [always, AFaIK] supported a feature of the
Interactive Profile Entry (IPE) to store last-used values, as effective
/preferences/ for a user. The developers IMNSO should have [learned of
and] used that IPE feature in their first iteration of that support.
Having done so, that implementation could have been [the first and] the
final /fix/ for allowing a user-preference to determine which variant of
the panel was presented, based on the last\previous variant that was
viewed by that user; there would have been no need to suggest the
possibility that a "customizable feature may be created in a future
release.", because that customized effect would be directly available to
every user simply by using the F11=Display [alternate] Details, or they
could have added something along the lines of a F23=Save As Default View
to set a preferred choice instead of solely showing the *PRV view.
Of course even with the use of the IPE, care must have been taken not
to improperly implement functionality with that feature; e.g. as existed
at one time in some generic Work With positioning functions:
[
http://archive.midrange.com/midrange-l/201407/msg00907.html]
midrange.com
