× 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 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.?


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.