Unix cmd names obscure?
M. G. Hand
a mainframe for printing:
"... once the tape is done, you can run a standard IBM utility
like IEBGENER to print it on a high speed printer."
And they say Unix command names are obscure...
--
Marcus Hand {ihnp4!}pyuxt!marcus
r...@opus.uucp
> like IEBGENER to print it on a high speed printer."
>
> And they say Unix command names are obscure...
Not half, they aren't! If you think the description above is cryptic,
realize that it's only a glimpse into a bizarre universe...
IEBGENER is the utility you use to copy things. Don't be confused by the
fact that there is an IEBCOPY, which does something else entirely. And to
delete files, you use IEFBR14. This wonderfully mnemonic name is derived
from a magic IBM prefix (IEF) and a branch instruction (Branch Register 14)
which is effectively a do-nothing program, since register 14 is the
standard place for the "return address" of a main program. Huh? Delete a
file...oh yeah, we were talking about that...well, you delete files as a
side-effect of running a program, so IEFBR14 gives you a harmless program
which can be run for its side effect.
[Interesting side-side issue: You may have heard the quip that "Every
program has at least one bug and can be shortened by at least one
instruction"--from which, by induction, one can deduce that every program
can be reduced to one instruction which doesn't work. IEFBR14, if written
as the obvious, single-instruction program " BR 14", does NOT work.
Reason: It fails to set a proper value for its return code, which means
that it may fail mysteriously. An entertaining rumor has it that this bug
actually existed in IEFBR14 once. But don't get too cocky--the same bug
also exists in the UNIX world, since many C programs terminate by falling
out the bottom of the main program and most C startup routines simply take
whatever garbage return value this produces as the exit status of the
program.]
--
Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086
...Are you making this up as you go along?
Mike Taylor
> as the obvious, single-instruction program " BR 14", does NOT work.
> Reason: It fails to set a proper value for its return code, which means
> that it may fail mysteriously. An entertaining rumor has it that this bug
> actually existed in IEFBR14 once. But don't get too cocky--the same bug
> also exists in the UNIX world, since many C programs terminate by falling
> out the bottom of the main program and most C startup routines simply take
> whatever garbage return value this produces as the exit status of the
> program.]
> --
> Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086
> ...Are you making this up as you go along?
It's true. The bug did exist, and was duly APAR'ed (IBM-ese for reported)
and fixed. In fact, I believe there have been three APAR's (problem reports)
against IEFBR14. This was so long ago I don't remember what the others
were ? Does any OS/360/370 trivia buff remember ?
--
Mike Taylor ...!{ihnp4,hplabs,amd,sun}!amdahl!mat
[ This may not reflect my opinion, let alone anyone else's. ]
El lobo solitario
IEWL is the name of the link editor,
IEV90 is the name of the assembler,
IEL0AA is the Pl/1 compiler,
IEFAAB is the Fortran compiler,
IKFCBL00 is the Cobol compiler,
etc............
Very easy to remember right ??
--
Angel Casado
{Las mulas son lentas pero la tierra es paciente.}
... !allegra!princeton!adrvax!angel
Andrew Klossner
"IEFBR14, if written as the obvious, single-instruction program
" BR 14", does NOT work. Reason: It fails to set a proper
value for its return code, which means that it may fail
mysteriously. An entertaining rumor has it that this bug
actually existed in IEFBR14 once. But don't get too cocky--the
same bug also exists in the UNIX world, since many C programs
terminate by falling out the bottom of the main program and
most C startup routines simply take whatever garbage return
value this produces as the exit status of the program.]"
Under OS/360, the location for the exit status is register 15. The
calling convention for all procedures (including the main program) is
that register 15 be loaded with the program's start address. This
helps the procedure get started in finding itself, since a program can
be loaded anywhere in memory and there is no Unix-style relocation
going on. A program cannot use absolute addressing, and so all
addressing is done through an index register. (Some programs use the
supplied value in register 15; otherwise use the instruction "BALR
reg,0" -- Branch And Link Register (subroutine call), but destination 0
means don't branch -- to load the current PC into reg.)
The result was that IEFBR14 returned its start address as its status.
Since a program is never loaded to location 0, the status was never 0,
and so the program never succeeded.
-- Andrew Klossner (decvax!tektronix!orca!andrew) [UUCP]
(orca!andrew.tektronix@csnet-relay) [ARPA]
Basket Case
Now, now... Let's not all bitch at IBM for obscure names...
For every one of those facilities listed in <5...@adrvax.UUCP> there
is also a cataloged procedure (i.e., canned JCL) which is called by
a reasonable name which IBM provides with MVS...
The names that you see (i.e., IEWL, etc.) are generally internal
names. If you insist on doing unusual business that can't be handled
by the cataloged procedures, then you get to deal with these.
--
------------------------------------------------------------------
Henry C. Mensch | User Confuser | Purdue University User Services
{ihnp4|decvax|ucbvax|seismo|purdue|cbosgd|harpo}!pur-ee!pucc-i!ag5
------------------------------------------------------------------
"Never eat more than you can lift!"
-- Miss Piggy
Howard Hull
>[Interesting side-side issue: You may have heard the quip that "Every
>program has at least one bug and can be shortened by at least one
>instruction"--from which, by induction, one can deduce that every program
>can be reduced to one instruction which doesn't work. IEFBR14, if written
>as the obvious, single-instruction program " BR 14", does NOT work.
I really like this! Where did you hear it? Only trouble is, it conflicts
with my experience. Usually, when I find a bug,
1. Both decreases and increases in instruction count are likely
by some number, the average being 2.71828182845904523536
The implication is that to avoid bugs, every program to do a
function must be written in every possible way. To be absolutely
sure that you have the solution in the bag, you must write a
program to do everything there is to do, by writing a set of
programs to do each thing. Then all of these programs must work
together.
The probability that they will do this is given by 1/(n factorial)
in each case, where n is the number of ways to do each particular
task. For some of you, the number of tasks, t, approaches infinity.
The result will inescapably include both of the following:
needed functions unnecessary functions
that have been omitted that have been included
Now then, if all of the above are properly combined, you have:
UNITY (There is in each case, after all, always
t only one *right* way to do everything!)
The Result = Sigma _______________________________________
n=0 (n!)
2. The bug will be in a real-time program running under one of
the Unix clones adapted for the purpose. The change in the
program length will wreck something else, either spatially
or temporally.
3. Because the numeric mentioned under [1.] above is greater than
unity, and is also greater than the binary base, the average
(program, data) length will grow (perhaps stochastically) faster
than its intellegent content - in a very familiar way - the number
of bits of address will crawl over the edge of any imaginable page
size definition in a vernier fashion as the program is developed.
4. As a result of bug fixes, a program has some random probability
of either vanishing completely, or of consuming the entire storage
capacity of the machine. Which way it will go depends mostly on
the rounding algorithm used in the (undocumented) arithmetic
subroutines that came with the software, and the (erroneously
documented) algorithm the mainframe manufacture used for the
determination of which instructions will set, clear, or not
molest the carry bit. :-)
{ucbvax!hplabs | allegra!nbires | harpo!seismo } !hao!hull