re: Management not granting you permission to make a simple change.

Simply send (and record) and email warning them that a statement in the
procedure would make it possible for the daily backup to overwrite some
tape containing important data and that a simple modifocation to it
would prevent this occurance.

If they refuse, you then have the emails to say "I TOLD YOU SO" when the
owner ofthe important data complains to management about loss of his data.

In article <1189996011.648131.314640@19g2000hsx.googlegroups.c om>, AEF writes:
>
>
>On Sep 16, 9:49 pm, "David P. Murphy" wrote:
>> On Sep 15, 11:29 pm, Ron Johnson wrote:
>>
>> > However... why shouldn't I rely on LOGINOUT.EXE to deallocate my
>> > tape drives or free my VM?
>>
>> #1 Why _shouldn't_ you close/deallocate/free/release a resource
>> explicitly? There is no good reason.
>>
>> #2 What if another, less experienced, programmer decides to copy
>> your code? He won't realize that you're relying on LOGINOUT.
>
>(1) Comment your code!!!

People, in my experience anyway, tend to not comment DCL whether it's a
performance issue or otherwise. However, for a small procedure such as
David has posted, the performance excuse is moot.



>(2) Caveat emptor. You can't be expected to save the world. You can't
>be responsible for every possible misuse of your code. If a knife is
>used to murder someone, is the knife manufacturer responsible?

Yes! And the retail establishment which sold the knife too as well as
and the sales person who sold the knife without getting a full and com-
plete personality profile of the buyer. Let's not forget that the em-
ployer of the knife weilding murderer is also responsible because they
hired and paid the buyer so he could buy the knife. Of course, there
is the victim. Don't forget the victim; they're the most liable party.
Why were they in front of the knife blade without wearing a government
bureaucracy approved knife-proof protective garb? The victim was just
asking for it!



>(3) The inexperienced programmer will most likely screw something else
>up that's even worse anyway.

Back to comments, the inexperience programmer will learn more from said
code if comments are included.

One of the things I've heard newbies to DCL often ask: why is the clock
set to 12:00:00.00 at this spot? ($ SET NOON) A little commenting can
go a long way!


--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

"Well my son, life is like a beanstalk, isn't it?"

http://tmesis.com/drat.html

On 09/16/07 20:49, David P. Murphy wrote:
> On Sep 15, 11:29 pm, Ron Johnson wrote:
>
>> However... why shouldn't I rely on LOGINOUT.EXE to deallocate my
>> tape drives or free my VM?
>
> #1 Why _shouldn't_ you close/deallocate/free/release a resource
> explicitly? There is no good reason.

Truthfully?

The vast bulk of my jobs are "backups" that send their data to a
single tape drive (or multiple, for Rdb backups) and then exit.

> #2 What if another, less experienced, programmer decides to copy
> your code? He won't realize that you're relying on LOGINOUT.

Good point.

> #3 My first reason is so good that I'm going to repeat it.
> In fact I'm trying sincerely to think of any justification
> at all for skipping that code, and I cannot.

--
Ron Johnson, Jr.
Jefferson LA USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

In article , VAXman- @SendSpamHere.ORG
wrote:

> In article <1189996011.648131.314640@19g2000hsx.googlegroups.c om>, AEF
> writes:
> >



>
> >(3) The inexperienced programmer will most likely screw something else
> >up that's even worse anyway.
>
> Back to comments, the inexperience programmer will learn more from said
> code if comments are included.
>
> One of the things I've heard newbies to DCL often ask: why is the clock
> set to 12:00:00.00 at this spot? ($ SET NOON) A little commenting can
> go a long way!

The best comment I got about a SET NOON was delivered over my shoulder
as I typed it.

"Visions of Gary Copper here."

--
Paul Sture

Sue's OpenVMS bookmarks:
http://eisner.encompasserve.org/~stu...bookmarks.html

In article , VAXman- @SendSpamHere.ORG
wrote:

> In article <1189996011.648131.314640@19g2000hsx.googlegroups.c om>, AEF
> writes:
> >



>
> >(3) The inexperienced programmer will most likely screw something else
> >up that's even worse anyway.
>
> Back to comments, the inexperience programmer will learn more from said
> code if comments are included.
>
> One of the things I've heard newbies to DCL often ask: why is the clock
> set to 12:00:00.00 at this spot? ($ SET NOON) A little commenting can
> go a long way!

The best comment I got about a SET NOON was delivered over my shoulder
as I typed it.

"Visions of Gary Cooper here."

--
Paul Sture

Sue's OpenVMS bookmarks:
http://eisner.encompasserve.org/~stu...bookmarks.html

VAXman- @SendSpamHere.ORG wrote:
> One of the things I've heard newbies to DCL often ask: why is the clock
> set to 12:00:00.00 at this spot? ($ SET NOON)


That is simple. At noon, the DCL engine gets really hungry and is
therefore willing to eat any/all DCL commands, and will continue eating
DCL even after having eaten a bad line.

Interesting discussion.

As someone who's been denied the DEC world for about 10 years this
shows the fairly stark difference between "old time DEC philosophy"
and the UNIX/windoze approach to things.

The DEC way of doing things was for applications/libraries to be aware of
everything that is occurring at every level, and dealing with that in a
sensible manner.

This meant that if you had a failure in an application or library you would
be returned an error and the documentation for that component would tell
you exactly what errors would occur under what circumstances. Makes
debugging and fault tracing easy and also means that every process would
behave in a specifically predetermined manner, no matter how it was used.

In the UNIX world, we write code that charges ahead and relies on the
underlying modules to deal with error conditions. This has the result that
often error conditions go unnoticed, have bizare/unexpected side effects,
or when the error is noticed, it's so out of context it's almost impossible
to trace.

The more recent try/except/catch constructs in languages have helped improve
this somewhat, however it's still used so infrequently in libraries that a
lot of "modern" programming is trying to work out what the designer of some
random library was thinking when they wrote the thing.


The first ARPAnet worm illustrates this quite well.

The sin committed in that script wasn't not realizing that node adjacency is
commutative until the enter key was hit, that was just a basic bug in the
algorithm, but rather the first line of the script:
SET NOON
which was employed so that the script wouldn't bomb out when trying to
submit jobs to the many '11s on the net at the time.

The proper "DEC" approach would have been to test for the failed submit
condition and continue at that point. Using SET NOON meant that the script
was close to impossible to stop.

And to continue the theme of scripts not being run by the same person in the
way intended; remember that the worm had a second coming when someone on
one of those '11s found the worm in one of the job spools, wondered what it
did and so submitted to his nearest VAX

Bruce
RIP ~prep


Ron Johnson wrote:

> On 09/13/07 23:26, AEF wrote:
>> On Sep 13, 6:19 pm, "David P. Murphy" wrote:
>>> Real code at the beginning of the "daily backup" batch job:
>>>
>>> $ ON ERROR THEN CONTINUE
>>> $ ALLOCATE 'tape_drive'
>>> $ INIT 'tape_drive' 'label'
>>> $ BACKUP/IMAGE/REWIND/'quals' -
>>> 'disk' -
>>> 'tape_drive'DAILY.BCK/SAVE
>>>
>>> I have lost what little faith in humanity remained in me.
>>>
>>> ok
>>> dpm
>>
>>
>> My questions:
>>
>> Is the same tape in the drive every day?
>>
>> Are there any more BACKUP commands in the rest of the procedure?
>
> Does it matter? Defensive programming says you defend against
> hardware glitches other people's mistakes.
>

On Sep 16, 5:06 pm, "David P. Murphy" wrote:
> On Sep 16, 8:39 am, AEF wrote:
>
>
>
> > On Sep 15, 10:47 pm, "David P. Murphy" wrote:
> >> followed by the inevitable
>
> >> %SYSTEM-F-DEVMOUNT, device is already mounted
>
> >> and immediately thereafter
>
> >> %BACKUP-F-POSITERR, error positioning $1$MUA400:[000000]DAILY.BCK;
> >> -SYSTEM-F-SERIOUSEXCP, serious exception detected by TMSCP
> >> controller
> > AHA!!!!! Withholding evidence!!! Sloppy, sloppy, sloppy! And you
> > complain about the code author!!! ... HAH!
>
> > This is like when Tom and Ray on Car Talk are trying to diagnose a
> > caller's car problems and after struggling for 5 minutes, the caller
> > finally mentions, "Oh, by the way, the engine check light came on" or
> > "It only does it when..."
>
> No, it's much more like getting dozens of errors from a compiler
> when they're all due to a single missing variable declaration.
> They're called "fallout errors", because they don't mean a damn
> and disappear once you fix the actual problem upstream . . .
> just like the BACKUP fatal messages are completely misleading
> and would not have occurred if the command procedure had properly
> handled either the failed ALLOCATE or INITIALIZE commands.
>
> In what way do you consider these messages "evidence"? The warning
> should have been enough for anyone.
>
> ok
> dpm

I meant the fact that you didn't tell us that there was a problem.
IOW, I was referring to all the error messages, not just the last few
error messages.

It seems to me that it was mostly the result of someone having used
the tape drive he shouldn't have, which, because even if the procedure
were written correctly the backup still would not have been done,
suggests that this ON ERROR THEN CONTINUE is not the biggest problem
at your site!

What does it matter?

If your housekeeper or housemate or whoever left the door unlocked
when he or she left, does it matter if someone robbed your house or
apt. as a result? I say, YES! Does it matter if you live in a high
crime neighborhood or not? I say, YES!

If you live in The Plains, OH, you don't need to put a club on your
steering wheel. This is not true in a big city! So don't complain
about the lack of a club if you live in The Plains. You didn't tell us
where you lived, so to speak. Yes, it's still bad programming and
should be fixed. How bad a disaster it was depends on what happened to
the tape, what was on the tape, what was missed in the thwarted backup
operation, and whether any backups ever succeeded at this site!

AEF

On Sep 18, 8:28 am, AEF wrote:

> I meant the fact that you didn't tell us that there was a problem.
> IOW, I was referring to all the error messages, not just the last few
> error messages.

Surely an experienced person such as yourself saw them coming.

> It seems to me that it was mostly the result of someone having used
> the tape drive he shouldn't have, which, because even if the procedure
> were written correctly the backup still would not have been done,
> suggests that this ON ERROR THEN CONTINUE is not the biggest problem
> at your site!
>
> What does it matter?

$ ON WARNING THEN GOTO ABORT
$ ALLOCATE ...
$ INIT ...
$ BACKUP ...
$ DEALLOCATE ...
$ LOGOUT
$!
$ ABORT:
$ MAIL /SUBJECT="URGENT! BACKUP FAILED!" NL: OPERATOR
$ LOGOUT

That's why. If the procedure is written correctly, then a human
is notified of the inevitable problem.

> If your housekeeper or housemate or whoever left the door unlocked
> when he or she left, does it matter if someone robbed your house or
> apt. as a result? I say, YES! Does it matter if you live in a high
> crime neighborhood or not? I say, YES!

I can only interpret that paragraph to mean that you need a reason
to write code correctly, as otherwise it's not worth your time.
Therefore I stand by my earlier statement of not wanting to work with
you.

> If you live in The Plains, OH, you don't need to put a club on your
> steering wheel. This is not true in a big city! So don't complain
> about the lack of a club if you live in The Plains. You didn't tell us
> where you lived, so to speak. Yes, it's still bad programming and
> should be fixed. How bad a disaster it was depends on what happened to
> the tape, what was on the tape, what was missed in the thwarted backup
> operation, and whether any backups ever succeeded at this site!

"I didn't bother adding error handling to that code because
I realized that it would only be a *small* disaster if it failed."

ok
dpm

On Sep 18, 8:28 am, AEF wrote:

> If you live in The Plains, OH, you don't need to put a club on
> your steering wheel.

2004 Crime Statistics
Athens County, OH
% population affected
Motor Vehicle Theft = 0.08%

Given a population of 64,000 I conclude that 51 cars were
stolen during 2004. I guess the trick is knowing whether
or not you are one of the 63,949 people who *didn't* need
to put a club on their steering wheel!

Another way to look at it is if you're running that batch job
every night on three nodes, your tolerance is having it fail
once per year. It's good to know your limits.

ok
dpm

On Sep 18, 8:28 am, AEF wrote:

> If you live in The Plains, OH, you don't need to put a club on
> your steering wheel.

2004 Crime Statistics
Athens County, OH
% population affected
Motor Vehicle Theft = 0.08%

Given a population of 64,000 I conclude that 51 cars were
stolen during 2004. I guess the trick is knowing whether
or not you are one of the 63,949 people who *didn't* need
to put a club on their steering wheel!

Another way to look at it is if you're running that batch job
every night on three nodes, your tolerance is having it fail
once per year. It's good to know your limits.

ok
dpm

On Sep 18, 9:19 am, "David P. Murphy" wrote:
> On Sep 18, 8:28 am, AEF wrote:
>
> > I meant the fact that you didn't tell us that there was a problem.
> > IOW, I was referring to all the error messages, not just the last few
> > error messages.
>
> Surely an experienced person such as yourself saw them coming.

Yes, but what actually happens matters.

> > It seems to me that it was mostly the result of someone having used
> > the tape drive he shouldn't have, which, because even if the procedure
> > were written correctly the backup still would not have been done,
> > suggests that this ON ERROR THEN CONTINUE is not the biggest problem
> > at your site!
>
> > What does it matter?
>
> $ ON WARNING THEN GOTO ABORT
> $ ALLOCATE ...
> $ INIT ...
> $ BACKUP ...
> $ DEALLOCATE ...
> $ LOGOUT
> $!
> $ ABORT:
> $ MAIL /SUBJECT="URGENT! BACKUP FAILED!" NL: OPERATOR
> $ LOGOUT
>
> That's why. If the procedure is written correctly, then a human
> is notified of the inevitable problem.

Based on what we know about your site, no one would have ever read the
mail. The problem at your site is primarily something that is not
curable by even the best code. And even if an operator did read it, at
this site he or she probably would ignore it.

> > If your housekeeper or housemate or whoever left the door unlocked
> > when he or she left, does it matter if someone robbed your house or
> > apt. as a result? I say, YES! Does it matter if you live in a high
> > crime neighborhood or not? I say, YES!
>
> I can only interpret that paragraph to mean that you need a reason
> to write code correctly, as otherwise it's not worth your time.

You don't get it.

> Therefore I stand by my earlier statement of not wanting to work with
> you.

I'm puzzled by this statement. It is not a logical conclusion based on
our discussion.

Regardless, you need to take an economics course. You do what it's
worth to do. Would you spend thousands of dollars in protection and
insurance to safeguard a thirty-dollar blender? I think not!

>
> > If you live in The Plains, OH, you don't need to put a club on your
> > steering wheel. This is not true in a big city! So don't complain
> > about the lack of a club if you live in The Plains. You didn't tell us
> > where you lived, so to speak. Yes, it's still bad programming and
> > should be fixed. How bad a disaster it was depends on what happened to
> > the tape, what was on the tape, what was missed in the thwarted backup
> > operation, and whether any backups ever succeeded at this site!
>
> "I didn't bother adding error handling to that code because
> I realized that it would only be a *small* disaster if it failed."

You missed the point, you still don't get it, and you'll never get
it.

Let me know how it goes when you put that bank-safe-door-lock on your
bathroom, and its effect on your net worth!

>
> ok
> dpm

AEF

On Sep 18, 9:51 am, AEF wrote:

>> Surely an experienced person such as yourself saw them coming.

> Yes, but what actually happens matters.

No, actually, it does not. What matters _when you're coding_
is the *potential* of what *might* happen. A good programmer
assumes that problems will occur. Whether or not they ever do
is completely beside the point.

> Regardless, you need to take an economics course. You do what it's
> worth to do. Would you spend thousands of dollars in protection and
> insurance to safeguard a thirty-dollar blender? I think not!

You are saying that a backup procedure might not be worth
the time it takes to add a few lines of code for error handling.
I'm saying the question should never even arise.

Why you are valuing a backup at $30 while valuing a few lines
of code at > $2000 is beyond me.

ok
dpm

On Sep 18, 10:12 am, "David P. Murphy" wrote:
> On Sep 18, 9:51 am, AEF wrote:
>
> >> Surely an experienced person such as yourself saw them coming.
> > Yes, but what actually happens matters.
>
> No, actually, it does not. What matters _when you're coding_
> is the *potential* of what *might* happen. A good programmer
> assumes that problems will occur. Whether or not they ever do
> is completely beside the point.

How upset you get about it, is.

And when no one reads the mail, what good has it done? This is the
second time I've had to make this point.

>
> > Regardless, you need to take an economics course. You do what it's
> > worth to do. Would you spend thousands of dollars in protection and
> > insurance to safeguard a thirty-dollar blender? I think not!
>
> You are saying that a backup procedure might not be worth
> the time it takes to add a few lines of code for error handling.
> I'm saying the question should never even arise.

I said it was bad code. I said to fix the bloody code. What more do
you want?

And something _did_ go wrong and it's not the end of the world. So
relax already. No one really seems to care at your site.

> Why you are valuing a backup at $30 while valuing a few lines
> of code at > $2000 is beyond me.

I was giving a hypothetical example for the general case because it
seemed to me you were arguing to actually do silly things like that,
in general.

> ok
> dpm

Not ok. :-)
AEF

On Sep 18, 9:33 am, "David P. Murphy" wrote:
> On Sep 18, 8:28 am, AEF wrote:
>
> > If you live in The Plains, OH, you don't need to put a club on
> > your steering wheel.
>
> 2004 Crime Statistics
> Athens County, OH
> % population affected
> Motor Vehicle Theft = 0.08%
>
> Given a population of 64,000 I conclude that 51 cars were
> stolen during 2004. I guess the trick is knowing whether
> or not you are one of the 63,949 people who *didn't* need
> to put a club on their steering wheel!

And how many of these stolen cars were in The Plains? Is your car even
something worth stealing? Etc., etc.

At these odds I'd rather not bother with the Club.

Do you carry a gun around to protect yourself from being mugged? How
do you know you're one of the lucky people who won't get mugged? Are
you protecting yourself from Al Qaeda? Did you write some code for
that? ;-)

Etc.

There is such a thing as cost-benefit analysis. With the odds you gave
for Athens county, I'd pass on the Club.

There is always risk, and you do what's reasonable given the case. In
your case, I'd tell mgmt. that the code needs to be fixed and, perhaps
more importantly, some data center rules need to be rewritten or
enforced or whatever it takes to stop people from loading their
personal tapes into the drive used for system backups.

> Another way to look at it is if you're running that batch job
> every night on three nodes, your tolerance is having it fail
> once per year. It's good to know your limits.

And one failed backup a year is a disaster? It in part depends on what
you're backing up. Apparently, at your place, a nightly failure is
acceptable. If a once-a-year backup failure is a disaster at your
site, you need to do a hell of a lot more than what you did in your
posted fixed-up example!!! Could it be, like at my site, that the most
critical files are separately copied to another system far away in
case of backup failure or disaster so that the tape backup is partly
just a precaution?

At your place, fixing the code will still not fix the problem. You
should be more concerned about that. You're being penny-wise and pound-
foolish.

> ok
> dpm

AEF

On Sep 18, 9:19 am, "David P. Murphy" wrote:
> On Sep 18, 8:28 am, AEF wrote:
>
> > I meant the fact that you didn't tell us that there was a problem.
> > IOW, I was referring to all the error messages, not just the last few
> > error messages.
>
> Surely an experienced person such as yourself saw them coming.
>
> > It seems to me that it was mostly the result of someone having used
> > the tape drive he shouldn't have, which, because even if the procedure
> > were written correctly the backup still would not have been done,
> > suggests that this ON ERROR THEN CONTINUE is not the biggest problem
> > at your site!
>
> > What does it matter?
>
> $ ON WARNING THEN GOTO ABORT
> $ ALLOCATE ...
> $ INIT ...
> $ BACKUP ...
> $ DEALLOCATE ...
> $ LOGOUT
> $!
> $ ABORT:
> $ MAIL /SUBJECT="URGENT! BACKUP FAILED!" NL: OPERATOR
> $ LOGOUT
>
> That's why. If the procedure is written correctly, then a human
> is notified of the inevitable problem.

This code doesn't even meet your own standards. Suppose MAIL fails.
Then it will go to the ABORT label and run MAIL again. In that case,
you'll be depending on the default error handler, ON ERROR THEN EXIT,
which will finally end it, and you'll be depending on LOGINOUT.EXE to
deallocate your drive.

And where is your cleanup! You didn't check if the drive is allocated
in the ABORT section, so again(!) you're depending on LOGOUT to
deallocate your drive. Horrors!

[...]

> I didn't bother adding error handling to that code because
> I realized that it would only be a *small* disaster if it failed."

If the result with correct programming is the same as with bad
programming, what does it matter? You should still fix the code and
fix the operations staff. Both need to be fixed in your case.

I SAID TO FIX THE BLOODY CODE. HOW MANY TIMES DO I HAVE TO SAY THIS.
AND WARNING, I'VE GOT A LOT MORE UPPER CASE LETTERS IN MY ARSENEL.
ALMOST UNLIMITED, IN FACT! AND FIXING THE CODE STILL DOESN'T GET YOUR
BACKUP DONE IF SOME FOOL IS USING THE DRIVE TO BACKUP HIS STUPID VIDEO
GAMES OR WHAT NOT DURING SYSTEM-BACKUP TIME.

Besides, he did have error handling code: ON ERROR THEN CONTINUE. Yes,
it's bad, but it's still error handling. And I suspect that whoever
put it there thought it would act more like SET NOON.

[...]

> ok
> dpm

In article <1190128284.178297.247170@e34g2000pro.googlegroups. com>,
AEF writes:
> On Sep 18, 9:19 am, "David P. Murphy" wrote:
>> On Sep 18, 8:28 am, AEF wrote:
>>
>> > I meant the fact that you didn't tell us that there was a problem.
>> > IOW, I was referring to all the error messages, not just the last few
>> > error messages.
>>
>> Surely an experienced person such as yourself saw them coming.
>>
>> > It seems to me that it was mostly the result of someone having used
>> > the tape drive he shouldn't have, which, because even if the procedure
>> > were written correctly the backup still would not have been done,
>> > suggests that this ON ERROR THEN CONTINUE is not the biggest problem
>> > at your site!
>>
>> > What does it matter?
>>
>> $ ON WARNING THEN GOTO ABORT
>> $ ALLOCATE ...
>> $ INIT ...
>> $ BACKUP ...
>> $ DEALLOCATE ...
>> $ LOGOUT
>> $!
>> $ ABORT:
>> $ MAIL /SUBJECT="URGENT! BACKUP FAILED!" NL: OPERATOR
>> $ LOGOUT
>>
>> That's why. If the procedure is written correctly, then a human
>> is notified of the inevitable problem.
>
> This code doesn't even meet your own standards. Suppose MAIL fails.
> Then it will go to the ABORT label and run MAIL again. In that case,
> you'll be depending on the default error handler, ON ERROR THEN EXIT,
> which will finally end it, and you'll be depending on LOGINOUT.EXE to
> deallocate your drive.
>
> And where is your cleanup! You didn't check if the drive is allocated
> in the ABORT section, so again(!) you're depending on LOGOUT to
> deallocate your drive. Horrors!
>
> [...]
>
>> I didn't bother adding error handling to that code because
>> I realized that it would only be a *small* disaster if it failed."
>
> If the result with correct programming is the same as with bad
> programming, what does it matter? You should still fix the code and
> fix the operations staff. Both need to be fixed in your case.
>
> I SAID TO FIX THE BLOODY CODE. HOW MANY TIMES DO I HAVE TO SAY THIS.
> AND WARNING, I'VE GOT A LOT MORE UPPER CASE LETTERS IN MY ARSENEL.
> ALMOST UNLIMITED, IN FACT! AND FIXING THE CODE STILL DOESN'T GET YOUR
> BACKUP DONE IF SOME FOOL IS USING THE DRIVE TO BACKUP HIS STUPID VIDEO
> GAMES OR WHAT NOT DURING SYSTEM-BACKUP TIME.
>
> Besides, he did have error handling code: ON ERROR THEN CONTINUE. Yes,
> it's bad, but it's still error handling. And I suspect that whoever
> put it there thought it would act more like SET NOON.
>

Grampa, tell me again about how bad all Unix programmers were and how
great all VMS programmers were. :-)


bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include

In article <1190128284.178297.247170@e34g2000pro.googlegroups. com>, AEF writes:
>
> This code doesn't even meet your own standards. Suppose MAIL fails.
> Then it will go to the ABORT label and run MAIL again. In that case,
> you'll be depending on the default error handler, ON ERROR THEN EXIT,
> which will finally end it, and you'll be depending on LOGINOUT.EXE to
> deallocate your drive.

No it won't. The "ON" statement is good once, after which a failure
of MAIL would follow default behaviour. Since he isn't showing any
other path to the MAIL statement there can be no loop in the code
he's shown.

On Sep 18, 1:14 pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> In article <1190128284.178297.247...@e34g2000pro.googlegroups. com>, AEF writes:
>
>
>
> > This code doesn't even meet your own standards. Suppose MAIL fails.
> > Then it will go to the ABORT label and run MAIL again. In that case,
> > you'll be depending on the default error handler, ON ERROR THEN EXIT,
> > which will finally end it, and you'll be depending on LOGINOUT.EXE to
> > deallocate your drive.
>
> No it won't. The "ON" statement is good once, after which a failure
> of MAIL would follow default behaviour. Since he isn't showing any
> other path to the MAIL statement there can be no loop in the code
> he's shown.

Yeah, you're right. I posted in haste and waste. (Thanks for the
catch!)

But it still won't deallocate or dismount his tape if needed. And he
made a BIG FUSS over not depending on LOGOUT to deallocate your drive.
And he has no DISMOUNT command whatsoever. And he's depending on
BACKUP to MOUNT the tape, most or all of which are big no-no's
according to Mr. Murphy.

AEF