Re: despair

On Sep 14, 9:57 pm, "David P. Murphy" <dpm_goo...@xxxxxxxxx> wrote:
On Sep 14, 1:40 pm, AEF <spamsink2...@xxxxxxxxx> wrote:

So the author of this bad code was apparently only worried about show-
stoppers.

I beg to differ. Anytime you code

$ ON ERROR THEN CONTINUE

in front of a ALLOCATE command, that is just plain wrong. No debate.

Please forgive me if I'm being obtuse on this. That said...

Please tell me what error from the ALLOCATE command would screw things
up and how.

Your arguments seem to hold water only as far as error trapping the
outcome of the BACKUP command, but this lies before the INITIALIZE
and ALLOCATE as well as the BACKUP. Guilty, guilty, guilty.

What error from INIT would screw things up? My experience is that when
INIT fails, it's an F error.

Relax, dude! The world is not going to end because of this command
procedure. Besides, that's only two "guilty"s. :-)

I'm not recommending this way of doing things; I'm just
trying to explain what I think the motivating factors were.
Of course incompetence and not-giving-a-s%%% are other possible
reasons!

I'm going with "stupidity" here. Truly, a little knowledge can be
a very dangerous thing.

Maybe it was written by a BOFH!

Nah, the *** always knows exactly what he's doing.

Sorry, I disagree or missed your point (about BOFH).


ok
dpm

All right. First: Never say never! OK. Next...

Only once did I ever have a problem from "misuse" (actually, in this
case, non-use) of ALLOCATE. It was in 1988 when I was a (rather
inexperienced -- well let's say, non-expert -- certainly not system
manager level) user at IUCF. I was in the terminal room where the TU77
(or TU78 or similar tall vacuum) drives were located. I mounted a tape
and was unable to MOUNT it. After trying some things, someone came
down and said he had ALLOCATED the drive I had my tape on. I was only
visiting there for a week or so to do an experiment, and back at my U.
of Md. physics group (much smaller) we never had people ALLOCATE
drives and then come down to mount a tape. But this was a bigger place
and I didn't know that that's how they do things there. The guy was
nice and let me do my tape job.

OK. Something went wrong with misuse (non-used) of ALLOCATE. The world
didn't come to an end! What's the big deal? (If they're going to have
this ALLOCATE policy, they should have told me!)

I find it interesting that you get all upset over this code snippet
yet you can't even tell me if the tape is changed daily! You appear to
know nothing at all about this environment except this code snippet.
How did you come across this code in the first place? What is your
role at this place that you have access to this code but still don't
know if the tape is ever changed?

At my current job no one but me loads tapes. No one but me uses DCL on
the system. The tape drives are in the data center which is locked.
Only people who need access to the room are allowed in. So a command
procedure that would be okay at my site would not be okay at others.

For example, you complained that the code didn't have a DEALLOCATE
command. Why is this a big problem? Could it not be, maybe, that no
one else ever uses this tape drive, in which case the lack of a
DEALLOCATE command is not a problem? (OK, if the process hangs, the
drive will stay allocated, but isn't there someone checking the system
at least daily to take care of any problems that may arise? And if it
does hang, someone will have to take care of it anyway.)

AEF

.