Prev: Acucobol Error 98.13
Next: How to talk like a programmer
From: Richard on 25 May 2010 20:43
On May 26, 11:24 am, "Pete Dashwood"
<dashw...(a)removethis.enternet.co.nz> wrote:
> Sorry for blank response... finger trouble.
>
> Some comments below...
>
>
>
> Doug Miller wrote:
> > In article <862ajbF8r...(a)mid.individual.net>, "Pete Dashwood"
> > <dashw...(a)removethis.enternet.co.nz> wrote:
> >> Doug Miller wrote:
> >>> In article <8626ljFfp...(a)mid.individual.net>, "Pete Dashwood"
> >>> <dashw...(a)removethis.enternet.co.nz> wrote:
> >>>> Doug Miller wrote:
> >>>>> In article <86256pF6n...(a)mid.individual.net>, "Pete Dashwood"
> >>>>> <dashw...(a)removethis.enternet.co.nz> wrote:
> >>>>>> jmoore wrote:
> >>>>>>> On May 25, 9:18 am, jmoore <jmoore...(a)gmail.com> wrote:
> >>>>>>>> I have a program that was written in a weird structure. I was
> >>>>>>>> wondering if anyone knew a way to call unix to suppress an
> >>>>>>>> error message if the cobol print file is empty.
>
> >>>>>>>> SEDC Main 9K:noitems $ run pub/
> >>>>>>>> slaudit
> >>>>>>>> 05/25/10 BEGIN SECURITY LIGHT AUDIT 09:19 AM
>
> >>>>>>>> DO YOU WISH TO RUN THIS PROGRAM? Y/N/S/E
> >>>>>>>> Y
> >>>>>>>> NO QUALIFYING RECORDS FOUND
>
> >>>>>>>> coblp: empty output, no spoolfile created for
>
> >>>>>>>> 05/25/10 END SECURITY LIGHT AUDIT 09:19 AM
>
> >>>>>>>> I need to compress the coblp message if the print-file is
> >>>>>>>> empty. Any help would be appreciated. Thank you!
>
> >>>>>>> Sorry I meant suppress
>
> >>>>>> redirect STDERR to the bit bucket... like this:
>
> >>>>>> SEDC Main 9K:noitems $ run pub/slaudit  2> /dev/null
>
> >>>>> That's going to send *all* his error messages to the bit bucket --
> >>>>> probably
> >>>>> undesirable.
>
> >>>> Not if you don't want to see them :-)
>
> >>> He didn't say he didn't want to see any of them, just that he didn't
> >>> want to
> >>> see _one specific_ message.
>
> >>>> He COULD change it to a file name.
>
> >>> More practical to redirect to a shell script that discards the
> >>> message(es) he doesn't want to see, and displays everything else.
>
> >> Er... discarding the messages he doesn't want to see was, I believe,
> >> the nub of his problem.
>
> > Exactly so -- so what is the point of recommending a method that
> > discards *all* messages written to stderr? That's not what he wants.
>
> He stated that he wants an error message (the only one curently produced
> from that particular application) suppressed.
>
> The code I posted would certainly achieve that.

This is _not_ certain. There is no information the the coblp message
was sent to stderr, nor that other messages were not.


> Certainly it would also suppress any other error messages from that
> application, but,as far as we know, there are no other error messages coming
> out of the application.
>
> If this is actually a problem for him, he could easily have the STDERR
> messages written to a file for examination and analysis later.
>
> Now, I would be the first to admit that what I suggested is not a refined or
> elegant solution, but it DOES achieve what was requested.

Whether it does _anything_ is not assured.

> Someone with in
> depth Unix experience could almost certainly suggest a better alternative,
> but there doesn't appear to be anybody here who is prepared to do that.

Which is why Doug has suggested a better group.


> > He wants to
> > suppress or discard _one specific message_.  Redirecting to dev/null
> > is sure
> > to discard that message, but it will also discard _everything else_
> > written to
> > stderr.
>
> Yes. It will. I don't see this as being disastrous, but it is really up to
> the OP. If that IS a problem for him then he must seek a better solution
> elsewhere. Your opinion about it or my opinion about it is not relevant. It
> is what the OP thinks about it that is important.
>
> They guy wants help, not opinions.

Exactly.

> >> Why not post some code in support of your sugestion and he can pick
> >> whatever solution he wants?
>
> > Why not? Multiple reasons:
> > 1) it's off-topic here; comp.unix.shell is a better place
>
> Oh dear, an off-topic post in CLC?  That would be a dangerous precedent :-)
>
> comp.unix.shell might well be a better place. How hard would it have been to
> simply suggest that?

Look, he did just suggest that.


> > 2) it's been seven years since I've done Unix shell scripting for a
> > living;
> > anything I'd write now is likely to be a bit shaky
>
> And yet your rustiness has not prevented you from criticising someone else's
> attempt to help. There is an old saying: "Any fool can find fault". It takes
> a wise man to find fault wisely. Simply saying that something is not a good
> solution, without providing a means to improve it or a better alternative,
> is just not helpful.

Pot, kettle, something ...

Doug _did_ provide a better approach, that of using a shell script to
filter the unwanted message.

Your 'better alternative' to that is ??


> Having done Unix shell scripting for a living you are certainly better
> placed than I am to provide a solution. Yet you won't because it might not
> be perfect.
>
> If you posted some code and it isn't perfect, might it not point the OP
> towards something that is better? (You could add a disclaimer if you are
> worried about your code being "shaky".)
>
> > 3) without knowing which shell he's using, it's pointless to try
> > anyway
>
> Sure. Might as well give up.
>
> Are Unix shells really so different that redirection doesn't work
> consistently?

Shells are programming languages. Programming languages are different
one from another. While it is usual to expect '>' to redirect, as one
expects '=' to assign, whether '2>' works may depend on the shell.

> >> (BTW, I don't claim Unix/Linux expertise...
>
> > I hadn't guessed.
>
> :-)
>
> At least I tried.
>
> It isn't about who's right, it's about what's right.  You agree that what I
> posted would achieve the requested result.

Whether it does or not depends on whether the coblp message is output
to stderr. What Doug stated is that your solution would send all
stderr to the bit bucket not that your solution would 'work'.

> Your reservation about it is that
> it might also have an unwanted side effect (a very valid observation, but
> arguable in this specific instance). We both agree that there could be a
> better solution, but neither of us can explain it at a level where it is
> helpful to the OP. I can't because  I don't have the knowledge, you won't
> because you are afraid it might not be perfect.

Doug suggested a filter shell script.

Rest of rant ignored.

> So where does that leave him?
>
> Sometimes it is better to have A solution (which can be subsequently refined
> or iterated) than to have NO solution; sometimes a bad solution is worse
> than no solution.
>
> I contend that in this case the former is more applicable than the latter,
> because if he does what I suggested he will be no worse off than if he does
> nothing. In other words, it can "do no harm". If there was another error
> posted and he didn't see it, the application would fail and it would need to
> be re-run with error output either turned on or redirected to a file. No
> harm has been done.
>
> I think you are underestimating your own capacity to help, Doug.
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."

From: Doug Miller on 25 May 2010 22:17
In article <8634i7F64iU1(a)mid.individual.net>, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote:
>Sorry for blank response... finger trouble.
>
>Some comments below...
>
>Doug Miller wrote:
>> In article <862ajbF8rhU1(a)mid.individual.net>, "Pete Dashwood"
>> <dashwood(a)removethis.enternet.co.nz> wrote:
>>> Doug Miller wrote:
>>>> In article <8626ljFfplU1(a)mid.individual.net>, "Pete Dashwood"
>>>> <dashwood(a)removethis.enternet.co.nz> wrote:
>>>>> Doug Miller wrote:
>>>>>> In article <86256pF6niU1(a)mid.individual.net>, "Pete Dashwood"
>>>>>> <dashwood(a)removethis.enternet.co.nz> wrote:
>>>>>>> jmoore wrote:
>>>>>>>> On May 25, 9:18 am, jmoore <jmoore...(a)gmail.com> wrote:
>>>>>>>>> I have a program that was written in a weird structure. I was
>>>>>>>>> wondering if anyone knew a way to call unix to suppress an
>>>>>>>>> error message if the cobol print file is empty.
>>>>>>>>>
>>>>>>>>> SEDC Main 9K:noitems $ run pub/
>>>>>>>>> slaudit
>>>>>>>>> 05/25/10 BEGIN SECURITY LIGHT AUDIT 09:19 AM
>>>>>>>>>
>>>>>>>>> DO YOU WISH TO RUN THIS PROGRAM? Y/N/S/E
>>>>>>>>> Y
>>>>>>>>> NO QUALIFYING RECORDS FOUND
>>>>>>>>>
>>>>>>>>> coblp: empty output, no spoolfile created for
>>>>>>>>>
>>>>>>>>> 05/25/10 END SECURITY LIGHT AUDIT 09:19 AM
>>>>>>>>>
>>>>>>>>> I need to compress the coblp message if the print-file is
>>>>>>>>> empty. Any help would be appreciated. Thank you!
>>>>>>>>
>>>>>>>> Sorry I meant suppress
>>>>>>>
>>>>>>> redirect STDERR to the bit bucket... like this:
>>>>>>>
>>>>>>> SEDC Main 9K:noitems $ run pub/slaudit 2> /dev/null
>>>>>>
>>>>>> That's going to send *all* his error messages to the bit bucket --
>>>>>> probably
>>>>>> undesirable.
>>>>>
>>>>> Not if you don't want to see them :-)
>>>>
>>>> He didn't say he didn't want to see any of them, just that he didn't
>>>> want to
>>>> see _one specific_ message.
>>>>>
>>>>> He COULD change it to a file name.
>>>>
>>>> More practical to redirect to a shell script that discards the
>>>> message(es) he doesn't want to see, and displays everything else.
>>>
>>> Er... discarding the messages he doesn't want to see was, I believe,
>>> the nub of his problem.
>>
>> Exactly so -- so what is the point of recommending a method that
>> discards *all* messages written to stderr? That's not what he wants.
>
>He stated that he wants an error message (the only one curently produced
>from that particular application) suppressed.

Assumption on your part. If he stated that that is the *only* message
produced, I missed it; in any event, even if it is the only message *now*,
it's foolish and naive to assume that there will never be others.
>
>The code I posted would certainly achieve that.

At the cost of suppressing *everything* written to stderr.
>
>Certainly it would also suppress any other error messages from that
>application,

Apparently you don't see a problem with that.

I do.

>but,as far as we know, there are no other error messages coming
>out of the application.

Assumption on your part.
>
>If this is actually a problem for him, he could easily have the STDERR
>messages written to a file for examination and analysis later.

Leaving him with exactly the same problem he has now: a message he doesn't
want, in a place where he doesn't want it.
>
>Now, I would be the first to admit that what I suggested is not a refined or
>elegant solution, but it DOES achieve what was requested. Someone with in
>depth Unix experience could almost certainly suggest a better alternative,
>but there doesn't appear to be anybody here who is prepared to do that.

Which of course is why I suggested that comp.unix.shell is a better place for
the discussion...
>
>
>> He wants to
>> suppress or discard _one specific message_. Redirecting to dev/null is sure
>> to discard that message, but it will also discard _everything else_ written to
>> stderr.
>
>Yes. It will. I don't see this as being disastrous, but it is really up to
>the OP. If that IS a problem for him then he must seek a better solution
>elsewhere. Your opinion about it or my opinion about it is not relevant. It
>is what the OP thinks about it that is important.

I didn't say it would be disastrous -- but I did point out there is a problem
with that approach, a problem to which you seem blind.
>
>They guy wants help, not opinions.
>
>>>
>>> Why not post some code in support of your sugestion and he can pick
>>> whatever solution he wants?
>>
>> Why not? Multiple reasons:
>> 1) it's off-topic here; comp.unix.shell is a better place
>
>Oh dear, an off-topic post in CLC? That would be a dangerous precedent :-)
>
>comp.unix.shell might well be a better place. How hard would it have been to
>simply suggest that?
>
>> 2) it's been seven years since I've done Unix shell scripting for a
>> living;
>> anything I'd write now is likely to be a bit shaky
>
>And yet your rustiness has not prevented you from criticising someone else's
>attempt to help.

Your attempt to help is clearly broken. I described the basis of an entirely
workable solution, that does exactly what the OP wants _and no more_.

>There is an old saying: "Any fool can find fault". It takes
>a wise man to find fault wisely. Simply saying that something is not a good
>solution, without providing a means to improve it or a better alternative,
>is just not helpful.

I *did* provide the means, at least to the extent of describing what needs to
be done. The specifics of the implementation are up to the OP.
>
>Having done Unix shell scripting for a living you are certainly better
>placed than I am to provide a solution. Yet you won't because it might not
>be perfect.
>
>If you posted some code and it isn't perfect, might it not point the OP
>towards something that is better? (You could add a disclaimer if you are
>worried about your code being "shaky".)
>
>
>> 3) without knowing which shell he's using, it's pointless to try
>> anyway
>
>Sure. Might as well give up.
>
>Are Unix shells really so different that redirection doesn't work
>consistently?

You missed the point (again). Some of the shells are different enough that the
code required to discard only the undesired message(s) may work in one shell
and not in another. The Bourne and Korn shells, for instance, are sufficiently
similar that small non-complex scripts written in one will likely work just
fine when run under the other; the C shell, OTOH, is syntactically very
different, and most C shell scripts won't run under Korn and vice versa.
>
>
>>
>>> (BTW, I don't claim Unix/Linux expertise...
>>
>> I hadn't guessed.
>
>:-)
>
>At least I tried.
>
>It isn't about who's right, it's about what's right. You agree that what I
>posted would achieve the requested result.

Untrue. Don't put words in my mouth. I do not agree that what you posted would
achieve the desired result: the desired result is to discard *one* message.
What you posted will discard *all* messages. That is not the desired result.

>Your reservation about it is that
>it might also have an unwanted side effect (a very valid observation, but
>arguable in this specific instance).

Untrue. Not "might", but "is guaranteed to".

> We both agree that there could be a
>better solution, but neither of us can explain it at a level where it is
>helpful to the OP. I can't because I don't have the knowledge, you won't
>because you are afraid it might not be perfect.

Untrue again. I can, and I did. I gave him a general description of what to
do.
>
>So where does that leave him?

Headed over to comp.unix.shell, I hope.
>
>Sometimes it is better to have A solution (which can be subsequently refined
>or iterated) than to have NO solution; sometimes a bad solution is worse
>than no solution.

Thank you for making my point for me: your bad solution *is* worse than no
solution.

Glad we agree on something finally.
>
>I contend that in this case the former is more applicable than the latter,
>because if he does what I suggested he will be no worse off than if he does
>nothing. In other words, it can "do no harm".

Please explain why you believe that suppressing all diagnostic output from a
running program "does no harm".

> If there was another error
>posted and he didn't see it, the application would fail and it would need to
>be re-run with error output either turned on or redirected to a file. No
>harm has been done.

Sorry, but that's just flat wrong. If all errors are suppressed, there is no
indication that anything failed. Failure is externally indistinguishable from
success. Other jobs may be run, based on the mistaken belief that this one
succeeded. *Much* harm can result.
>
>I think you are underestimating your own capacity to help, Doug.

And I think you're overestimating yours.
From: jmoore on 26 May 2010 07:14
On May 25, 10:17 pm, spamb...(a)milmac.com (Doug Miller) wrote:
> In article <8634i7F64...(a)mid.individual.net>, "Pete Dashwood" <dashw...(a)removethis.enternet.co.nz> wrote:
>
>
>
>
>
> >Sorry for blank response... finger trouble.
>
> >Some comments below...
>
> >Doug Miller wrote:
> >> In article <862ajbF8r...(a)mid.individual.net>, "Pete Dashwood"
> >> <dashw...(a)removethis.enternet.co.nz> wrote:
> >>> Doug Miller wrote:
> >>>> In article <8626ljFfp...(a)mid.individual.net>, "Pete Dashwood"
> >>>> <dashw...(a)removethis.enternet.co.nz> wrote:
> >>>>> Doug Miller wrote:
> >>>>>> In article <86256pF6n...(a)mid.individual.net>, "Pete Dashwood"
> >>>>>> <dashw...(a)removethis.enternet.co.nz> wrote:
> >>>>>>> jmoore wrote:
> >>>>>>>> On May 25, 9:18 am, jmoore <jmoore...(a)gmail.com> wrote:
> >>>>>>>>> I have a program that was written in a weird structure. I was
> >>>>>>>>> wondering if anyone knew a way to call unix to suppress an
> >>>>>>>>> error message if the cobol print file is empty.
>
> >>>>>>>>> SEDC Main 9K:noitems $ run pub/
> >>>>>>>>> slaudit
> >>>>>>>>> 05/25/10 BEGIN SECURITY LIGHT AUDIT 09:19 AM
>
> >>>>>>>>> DO YOU WISH TO RUN THIS PROGRAM? Y/N/S/E
> >>>>>>>>> Y
> >>>>>>>>> NO QUALIFYING RECORDS FOUND
>
> >>>>>>>>> coblp: empty output, no spoolfile created for
>
> >>>>>>>>> 05/25/10 END SECURITY LIGHT AUDIT 09:19 AM
>
> >>>>>>>>> I need to compress the coblp message if the print-file is
> >>>>>>>>> empty. Any help would be appreciated. Thank you!
>
> >>>>>>>> Sorry I meant suppress
>
> >>>>>>> redirect STDERR to the bit bucket... like this:
>
> >>>>>>> SEDC Main 9K:noitems $ run pub/slaudit  2> /dev/null
>
> >>>>>> That's going to send *all* his error messages to the bit bucket --
> >>>>>> probably
> >>>>>> undesirable.
>
> >>>>> Not if you don't want to see them :-)
>
> >>>> He didn't say he didn't want to see any of them, just that he didn't
> >>>> want to
> >>>> see _one specific_ message.
>
> >>>>> He COULD change it to a file name.
>
> >>>> More practical to redirect to a shell script that discards the
> >>>> message(es) he doesn't want to see, and displays everything else.
>
> >>> Er... discarding the messages he doesn't want to see was, I believe,
> >>> the nub of his problem.
>
> >> Exactly so -- so what is the point of recommending a method that
> >> discards *all* messages written to stderr? That's not what he wants.
>
> >He stated that he wants an error message (the only one curently produced
> >from that particular application) suppressed.
>
> Assumption on your part. If he stated that that is the *only* message
> produced, I missed it; in any event, even if it is the only message *now*,
> it's foolish and naive to assume that there will never be others.
>
>
>
> >The code I posted would certainly achieve that.
>
> At the cost of suppressing *everything* written to stderr.
>
>
>
> >Certainly it would also suppress any other error messages from that
> >application,
>
> Apparently you don't see a problem with that.
>
> I do.
>
> >but,as far as we know, there are no other error messages coming
> >out of the application.
>
> Assumption on your part.
>
>
>
> >If this is actually a problem for him, he could easily have the STDERR
> >messages written to a file for examination and analysis later.
>
> Leaving him with exactly the same problem he has now: a message he doesn't
> want, in a place where he doesn't want it.
>
>
>
> >Now, I would be the first to admit that what I suggested is not a refined or
> >elegant solution, but it DOES achieve what was requested. Someone with in
> >depth Unix experience could almost certainly suggest a better alternative,
> >but there doesn't appear to be anybody here who is prepared to do that.
>
> Which of course is why I suggested that comp.unix.shell is a better place for
> the discussion...
>
>
>
> >> He wants to
> >> suppress or discard _one specific message_.  Redirecting to dev/null is sure
> >> to discard that message, but it will also discard _everything else_ written to
> >> stderr.
>
> >Yes. It will. I don't see this as being disastrous, but it is really up to
> >the OP. If that IS a problem for him then he must seek a better solution
> >elsewhere. Your opinion about it or my opinion about it is not relevant. It
> >is what the OP thinks about it that is important.
>
> I didn't say it would be disastrous -- but I did point out there is a problem
> with that approach, a problem to which you seem blind.
>
>
>
>
>
>
>
> >They guy wants help, not opinions.
>
> >>> Why not post some code in support of your sugestion and he can pick
> >>> whatever solution he wants?
>
> >> Why not? Multiple reasons:
> >> 1) it's off-topic here; comp.unix.shell is a better place
>
> >Oh dear, an off-topic post in CLC?  That would be a dangerous precedent :-)
>
> >comp.unix.shell might well be a better place. How hard would it have been to
> >simply suggest that?
>
> >> 2) it's been seven years since I've done Unix shell scripting for a
> >> living;
> >> anything I'd write now is likely to be a bit shaky
>
> >And yet your rustiness has not prevented you from criticising someone else's
> >attempt to help.
>
> Your attempt to help is clearly broken. I described the basis of an entirely
> workable solution, that does exactly what the OP wants _and no more_.
>
> >There is an old saying: "Any fool can find fault". It takes
> >a wise man to find fault wisely. Simply saying that something is not a good
> >solution, without providing a means to improve it or a better alternative,
> >is just not helpful.
>
> I *did* provide the means, at least to the extent of describing what needs to
> be done. The specifics of the implementation are up to the OP.
>
>
>
>
>
>
>
> >Having done Unix shell scripting for a living you are certainly better
> >placed than I am to provide a solution. Yet you won't because it might not
> >be perfect.
>
> >If you posted some code and it isn't perfect, might it not point the OP
> >towards something that is better? (You could add a disclaimer if you are
> >worried about your code being "shaky".)
>
> >> 3) without knowing which shell he's using, it's pointless to try
> >> anyway
>
> >Sure. Might as well give up.
>
> >Are Unix shells really so different that redirection doesn't work
> >consistently?
>
> You missed the point (again). Some of the shells are different enough that the
> code required to discard only the undesired message(s) may work in one shell
> and not in another. The Bourne and Korn shells, for instance, are sufficiently
> similar that small non-complex scripts written in one will likely work just
> fine when run under the other; the C shell, OTOH, is syntactically very
> different, and most C shell scripts won't run under Korn and vice versa.
>
>
>
> >>> (BTW, I don't claim Unix/Linux expertise...
>
> >> I hadn't guessed.
>
> >:-)
>
> >At least I tried.
>
> >It isn't about who's right, it's about what's right.  You agree that what I
> >posted would achieve the requested result.
>
> Untrue. Don't put words in my mouth. I do not agree that what you posted would
> achieve the desired result: the desired result is to discard *one* message.
> What you posted will discard *all* messages. That is not the desired result.
>
> >Your reservation about it is that
> >it might also have an unwanted side effect (a very valid observation, but
> >arguable in this specific instance).
>
> Untrue. Not "might", but "is guaranteed to".
>
> > We both agree that there could be a
> >better solution, but neither of us can explain it at a level where it is
> >helpful to the OP. I can't because  I don't have the knowledge, you won't
> >because you are afraid it might not be perfect.
>
> Untrue again. I can, and I did. I gave him a general description of what to
> do.
>
>
>
> >So where does that leave him?
>
> Headed over to comp.unix.shell, I hope.
>
>
>
> >Sometimes it is better to have A solution (which can be subsequently refined
> >or iterated) than to have NO solution; sometimes a bad solution is worse
> >than no solution.
>
> Thank you for making my point for me: your bad solution *is* worse than no
> solution.
>
> Glad we agree on something finally.
>
>
>
> >I contend that in this case the former is more applicable than the latter,
> >because if he does what I suggested he will be no worse off than if he does
> >nothing. In other words, it can "do no harm".
>
> Please explain why you believe that suppressing all diagnostic output from a
> running program "does no harm".
>
> > If there was another error
> >posted and he didn't see it, the application would fail and it would need to
> >be re-run with error output either turned on or redirected to a file. No
> >harm has been done.
>
> Sorry, but that's just flat wrong. If all errors are suppressed, there is no
> indication that anything failed. Failure is externally indistinguishable from
> success. Other jobs may be run, based on the mistaken belief that this one
> succeeded. *Much* harm can result.
>
>
>
> >I think you are underestimating your own capacity to help, Doug.
>
> And I think you're overestimating yours.- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Thanks for all the ideas!! I did go back and fix the opens and closes
From: Pete Dashwood on 26 May 2010 10:50
jmoore wrote:
> On May 25, 10:17 pm, spamb...(a)milmac.com (Doug Miller) wrote:
>> In article <8634i7F64...(a)mid.individual.net>, "Pete Dashwood"
>> <dashw...(a)removethis.enternet.co.nz> wrote:
>>
>>
>>
>>
>>
<snip>>
> Thanks for all the ideas!! I did go back and fix the opens and closes

Glad you got it solved :-)

Pete.

--
"I used to write COBOL...now I can do anything."


From: Pete Dashwood on 26 May 2010 11:18
<snip>
>> I contend that in this case the former is more applicable than the
>> latter, because if he does what I suggested he will be no worse off
>> than if he does nothing. In other words, it can "do no harm".
>
> Please explain why you believe that suppressing all diagnostic output
> from a
> running program "does no harm".

OK. I don't think that to be the case in every situation, but I do in this
one.

My opinion is based on the transcript of his program run, which he posted in
the original post. Here it is again:

========================================================
SEDC Main 9K:noitems $ run pub/
slaudit
05/25/10 BEGIN SECURITY LIGHT AUDIT 09:19 AM

DO YOU WISH TO RUN THIS PROGRAM? Y/N/S/E
Y
NO QUALIFYING RECORDS FOUND

coblp: empty output, no spoolfile created for

05/25/10 END SECURITY LIGHT AUDIT 09:19 AM

================================================

As you can see, there is ONE system error message and I assumed this would
be written to STDERR, the other messages, being generated by COBOL ACCEPT
and DISPLAY, would be written to STDOUT.

(Yes, I knew there could be other system messages but in the instance given,
there aren't.)

If he ran the program and it failed on some other error, he wouldn't get the
terminating message and would have to re-run to confirm what was wrong. At
this point, I would expect STDERR to be either turned on or redirected to a
file.

While this is not an elegant solution, it IS a solution. If nothing else, it
stimulated yourself and Richard to post.
>
>> If there was another error
>> posted and he didn't see it, the application would fail and it would
>> need to be re-run with error output either turned on or redirected
>> to a file. No harm has been done.

Hence the above.
>
> Sorry, but that's just flat wrong. If all errors are suppressed,
> there is no
> indication that anything failed.

Generally that may be true. In this case, it isn't.


> Failure is externally
> indistinguishable from
> success. Other jobs may be run, based on the mistaken belief that
> this one
> succeeded. *Much* harm can result.

Not when the application says it has ended, and cannot say that unless it
has run to completion.

All of my response was based on what he posted, not on things in general.


>>
>> I think you are underestimating your own capacity to help, Doug.
>
> And I think you're overestimating yours.

Hardly. I made very clear my own limitations in this arena and I still
believe you could have provided a better solution.

Perhaps we can agree that the BEST course was to go to the Unix forum.
Unfortunately, that wasn't suggested until AFTER I had posted my attempt,
and then only in response to it. I confess, I never thought of that because
I didn't know the forum existed. Like I said, I claim no expertise in Unix.

Nevertheless, if I hadn't posted anything, you wouldn't have posted
anything, and there would have been no solution, good, bad, or
indifferent... :-)

Pete.
--
"I used to write COBOL...now I can do anything."


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Acucobol Error 98.13
Next: How to talk like a programmer