On 26-Oct-2015 15:10 -0500, rob wrote:
I took another look at this message:
<snip>
WRKLNK '/qntc/gdl164/qtemp/*.TXT'
SAV DEV('/QSYS.LIB/ROB.LIB/ROB.FILE') OBJ(('/qntc/gdl164/qtemp/*.TXT'))
CPD37C4 -
Message . . . . : 14 objects not saved.
Cause . . . . . : 0 objects were not saved due to the ALWSAV
attribute set to *NO. A CPD37C3 message was sent for each of those
objects. 14 objects were not saved because the system has indicated
they should not be saved.
</snip>
They were right. There were zero objects not saved due to someone
setting the ALWSAV attribute therefore there would be zero CPD37C3
messages.
Of little concern to me, but I offer [that the PMR could have addressed]:
While indeed correct, the lack of a similar addendum to the second
set of "not saved", as is provided with the first, leaves the user
somewhat uninformed. And more easily susceptible to misread the text;
such that the reader may incorrectly be expecting to find the CPD373C
messages being logged for the 14 objects mentioned in the first-level
text, _despite the clarification_ of the messaging intending to refer
only to the subset mentioned immediately prior in the second-level text.
As I wondered in a followup reply [essentially pointing out my also
having /missed/ the same point being made by that 2nd level message
text], why are there not for that second category of unsaved objects,
both a similar function of loggin a message for each [if not already
there... or is there?] and to have the respective text stating "A
YYY#### message was sent for each of those objects"? And would that be
CPD3775?
See my two variations of the CPD37C4, the original and my suggested
improvement, included as quoted text under the words "perhaps the text
for msg CPD37C4 could be less confusing" in the message
[
http://archive.midrange.com/midrange-l/201510/msg00733.html]
Or if per-object messaging is absolutely _not going to happen_ for
that second subset of unsaved objects, then still I wonder, why not
include a corresponding addendum that says instead, "No messages were
sent for each of those objects"? And if applicable, then maybe also
reveal in that addendum that "nor will there be any record of those
objects not being saved included on any OUTPUT()"?
There were 14 objects not saved because the system indicated that
they should not be saved.
On that part you're on your own to determine why the system indicated
why they should not be saved.
<<SNIP>>
The "on your own to determine" part is the kicker. The second level
text could probably just list the reasons? Or perhaps just refer to a
different message identifier that explains what are the reasons for the
second subset of unsaved objects [even if that message is not sent for
each unsaved object like the other message supposedly is].?
Essentially, if they are going to aggregate the count in the first
level text yet reveal using message(s) why just one [the first] subset
of that aggregate is unsaved, again I wonder why not also do the same or
similar with the other subset? And if /just because/, then why not
clarify instead, within the message itself, the lack of any intention to
be similarly informative of the second subset; e.g. an addendum that
suggests "You can't handle the truth; as such we are withholding any
explanation as to why those objects [of the second subset] were not
saved." The present wording I think leads the reader to too easily to
misinterpret, with an expectation of messaging applying to both subsets;
i.e. they can more easily misconstrue the "message was sent for each" to
apply to the count seen in the first level text rather than applying
solely to the count seen just prior in the second level text.
The problem is QNTC does not support SAV.
AFaiK, as a statement standing alone, that is an inaccurate
implication, because file-level saves apparently *are supported*, but
only when both the share for /QNTC is on IXA or IXS, and the proper
pre-requisite actions have been taken to allow that file-level SAV
feature to operate against the Integrated X accessible via the /QNTC.?
midrange.com
