I understand. But I did say " when part of a thought out plan," which it appears (as usual) you did.
Speaking of QSRVAGT, I never thought about saving it. I'll put that on my To Do List. (Done.) As a regular practice, I have only included production libraries and folders in our nightly saves. Looks like I need to re-visit that. Systems vary, of course, but any other system libraries that I should re-visit at the same time for nightly save?
Thanks.
Jerry C. Adams
IBM System i Programmer/Analyst
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, May 16, 2008 9:14 AM
To: Midrange Systems Technical Discussion
Subject: RE: system reply list entries
I am not so sure of even putting it in a backup. Here's an example. We
save library QSRVAGT nightly. It was dying so I thought of doing a save
while active to not blow the whole backup. However, I found out that it
only blew in two examples throughout the years.
1 - QSECOFR password had expired and job was in MSGW.
2 - A particular file in that library was full and needed the message
answered.
Now, if I had a generic error handler for that, the messages might have
gone on unnoticed indefinitely.
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
Jerry Adams <Jerry@xxxxxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/16/2008 10:00 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc
Subject
RE: system reply list entries
I agree, in principle. Default handlers, like CPF0000, can cause more
trouble than problem(s) solved. What really amazes me, even more than
Rob's example, are people who put CPF0000 at the top of the CL so that it
acts on everything.
I do use the system reply list during conversions to respond to messages
that I *know* will occur. For example, if I am dropping a field from a
table, I don't want to have to reply 'I' to every CPA32B2 (File change may
result in data loss) during the conversion. Other than that situation, I
don't have an instance of using CHGJOB INQMSGRPY(*SYSRPYL). However, I
can think of places where one might legitimately use it (unattended
backups come to mind) when part of a thought out plan.
Jerry C. Adams
IBM System i Programmer/Analyst
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, May 16, 2008 7:34 AM
To: Midrange Systems Technical Discussion
Subject: Re: system reply list entries
Chuck,
I've never been a big fan of default handlers. I'd rather the program
halt on the line in error. If the problem is such an obscure error then
often corrective action can be taken elsewhere and an R to retry fits the
bill nicely. Now, a detailed MONMSG on a particular error is completely
acceptable. My detailed I do not mean
DLTF (MYLIB/MYFILE)
MONMSG CPF0000
I mean
DLTF (MYLIB/MYFILE)
MONMSG CPF2105 /* File not found */
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
CRPence <CRPbottle@xxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/15/2008 06:31 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
To
midrange-l@xxxxxxxxxxxx
cc
Subject
Re: system reply list entries
On many systems a user with *JOBCTL would need only perform WRKOUTQ
QEZDEBUG to review what problems had transpired since a prior review had
marked which were already reviewed. This is because the D=Dump
incidents would have produced QPDSPJOB, QPSRVDMP, QPPGMDMP, and possibly
other spools which were directed [per cleanup] into the QEZDEBUG output
queue.
That nobody is informed, is again about properly coded programs. If
the business decides someone needs to be informed because an operator is
not monitoring the system, then the developers need to code a generic
monitor for unexpected errors in the application, for which the handler
effects desired notifications. So instead of allowing the program to
fall into its run-time inquiry handling, either asking the user or the
reply list how to respond, the application makes the decision. Thus
what is in the *SYSRPYL is moot, as the real issue is a programming
problem; a failure to meet the business rule for which someone needs to
be informed of the failing code.
If the entries are removed to prevent the D=Dump action, then the
message handling defers to *RQD processing which means the user\operator
gets the option to reply. As a customization change to the system, the
removal of those reply list entries [RMVRPYLE] should be included in the
system change management script, to be re-run after each upgrade [in
case the OS install blindly resets those defaults].
Note: ADDRPYLE allows the special value *ALL for a message range. I
am not sure why, as it is a bad idea. Primarily because not all
messages will have the same possible allowed replies. Additionally
there is little to no assurance that a program will respond [well; more
likely, unpredictably] to either an invalid reply or an escape from the
message handling component indicating that the reply was invalid.
Regards, Chuck
Jerry Draper wrote:
Issue at this shop is that with the autoreply list set to D)ump all RPG
and CPA messages the developer group never really knows when something
fails unless the user says something. No one actually reviews qsysopr
message queue so all looks fine and dandy.
Hey, if a tree falls in the forest and no one is around to hear it does
it make a sound?
What do others have in their sysrepl?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
midrange.com
