Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ur-tut.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!rochester!ur-tut!scco
From: scco@ur-tut.UUCP (Sean Colbath)
Newsgroups: net.followup
Subject: Re: Unix, Unixpeople, Usenix (really IBM Utilities)
Message-ID: <216@ur-tut.UUCP>
Date: Tue, 12-Nov-85 13:41:00 EST
Article-I.D.: ur-tut.216
Posted: Tue Nov 12 13:41:00 1985
Date-Received: Fri, 15-Nov-85 06:49:29 EST
References: <96@tekadg.UUCP> <9700101@uiucdcs> <150@mit-eddie.UUCP> <256@ivax.icdoc.UUCP> <2168@amdahl.UUCP> <7524@ucla-cs.ARPA>
Reply-To: scco@ur-tut.UUCP (Sean Colbath)
Organization: Univ. of Rochester Computing Center
Lines: 62
Keywords: IBM, Error Messages, etc

In article <7524@ucla-cs.ARPA> scw@ucla-cs.UUCP (Stephen C. Woods) writes:
>Interestingly enough IEFBR14 had a bug in the first release.  System
>360 (now called 370) had a calling sequence as follows:
>(1) R15 -> entry
>(2) R14 -> return
>(3) [all kinds of stuff about save areas]
>    and a return sequence as follows
>(1) restore all registers (except R0-R1 which may contain function return
>    values)
>(2) Put the condition code (a number indicating the severity of any errors
>    that occured durring execution 0=none, 2= very minor, 4=warning,
>    ... 32 terminal errors (hardware failures etc).
>    then 
>    br	14		branch to where r14 points
>The problem with IEFBR14 was that it didn't clear R15 before it returned
>	bad			good
>	BR	14		XR	15,15
>				BR	14

AAAhhh, finally a discussion about a *real* operating system! (:-)...  The
linkage conventions that are described above are standard linkage conventions,
but I don't see any advantage the second 'good' implementation of IEFBR14 has
over the first.  I have programmed on VM (one of the major operating systems
that run on IBM's System/370 line) for several years, and the only thing that
R15 is used for is a return code, in which case you wouldn't want to have 
your return call zero it out.

Frankly, I don't see why many people complain that IBM's error messages are
cryptic and hard to understand - I find that they are one of the strong 
points of their operating systems.  All error messages are documented in
a large manual of 'system messages and errors', and follow a certain format:

         sssmmmnnnt : message

where mmm is the module that issued the message, sss is the system that module
is running under, nnn is the error message number, and t is the severity - 
R for request, I for informational, E for error, W for warning, T for terminal,
etc...  For instance, if I tried to erase a file under CMS, and that file was
not found, I would get the message

         DMSERA024E FILE 'filename' NOT FOUND

CMS, for example, has many advantages over Unix (in my opinion, no flames
please) in its error handling.  All error messages are consistantly formatted,
it is easy to tell where the error came from, and errors are consistant across
modules.  For instance, a '024' error will mean FILE NOT FOUND in every module
that would have an occasion to issue such a message.  Also, each help file for
a command has *every error message that that command could issue* listed at
the bottom.  And, if I find a message I don't understand, I could say
 
         HELP DMS024E

and get a short description of the error, what could cause it to occur,
and how I could rectify the problem (of course, IBM's solution for many of
the more serious error messages is 'contact your operations staff' or
'contact your systems staff' which I'm sure they love..)..

-Sean Colbath

"Dave, why don't you take a stress pill and lie down for a while?"
UUCP:    {allegra,decvax,ihnp4}!seismo!rochester!ur-tut!scco
BITNET:  SCCO@UORVM