canopus@amdahl.UUCP (Alpha Carinae) (10/31/85)
> > In article <150@mit-eddie.UUCP> gds@mit-eddie.UUCP (Greg Skinner) writes: > >Unix may have its problems, but I'd rather wander through the man pages, > >documentation and (gasp!) the source code, rather than look through 100 > >IBM manuals trying to find out what IEFBR14 means. > Ian W Moor > How about the system messages manual ? It lists them in order. IEFBR14 is not a system message; it is a dummy utility which does a branch on register 14 (essentially exits once it is called). I would have suggested the OS Utilities manual, but it doesn't seem to be in there, either! Let's face it. All operating systems have their warts. The original article (which I thought quite humorous) could be written about *any* operating system (I've got quite a collection of OS stuff!) -- Frank Dibbell (408-746-6493) ...!{ihnp4,cbosgd,sun}!amdahl!canopus Amdahl Corporation, Sunnyvale CA [This is the obligatory disclaimer..]
scw@ucla-cs.UUCP (11/10/85)
In article <2168@amdahl.UUCP> canopus@amdahl.UUCP (Alpha Carinae) writes: >> >> In article <150@mit-eddie.UUCP> gds@mit-eddie.UUCP (Greg Skinner) writes: >> >Unix may have[...]manual ? It lists them in order. > > IEFBR14 is not a system message; it is a dummy utility which does a > branch on register 14 (essentially exits once it is called). I would > have suggested the OS Utilities manual, but it doesn't seem to be in > there, either! 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 > > Let's face it. All operating systems have their warts. The original > article (which I thought quite humorous) could be written about *any* > operating system (I've got quite a collection of OS stuff!) Ain't it the truth, event the most trivial of operating systems have little warts, knobs and bumps sticking out of their 'black boxes' to trip, bump, mangle and otherwise injure our collective egos. >-- >Frank Dibbell (408-746-6493) ...!{ihnp4,cbosgd,sun}!amdahl!canopus >Amdahl Corporation, Sunnyvale CA [This is the obligatory disclaimer..]
scco@ur-tut.UUCP (Sean Colbath) (11/12/85)
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
herbie@polaris.UUCP (Herb Chong) (11/16/85)
In article <216@ur-tut.UUCP> scco@ur-tut.UUCP (Sean Colbath) writes: >>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. ahhh, but you missed the point. R15 wasn't set to zero to indicate successful completion of the program. it contained the address of the routine called. a one-line assembler program had a bug. OS/JCL used that return code to determine if a previous job step had completed successfully or not. usually IEFBR14 was used to allocate files and stuff like that. a non-zero return code often meant that the step was unsuccessful, so delete the temporary files that you just created. saying more requires that i assume you know OS/JCL so i'll stop here. the design issues i'll ignore. Herb Chong... I'm still user-friendly -- I don't byte, I nybble.... VNET,BITNET,NETNORTH,EARN: HERBIE AT YKTVMH UUCP: {allegra|cbosgd|cmcl2|decvax|ihnp4|seismo}!philabs!polaris!herbie CSNET: herbie.yktvmh@ibm-sj.csnet ARPA: herbie.yktvmh.ibm-sj.csnet@csnet-relay.arpa ======================================================================== DISCLAIMER: what you just read was produced by pouring lukewarm tea for 42 seconds onto 9 people chained to 6 Ouiji boards.
scw@ucla-cs.UUCP (11/22/85)
In article <216@ur-tut.UUCP> scco@ur-tut.UUCP (Sean Colbath) writes: >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 [...] 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). OPPS, I dropped a line while reformatting should have said ')into R15' >> 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. You need to \*ALWAYS*/ have a 0 return code from IEFBR14!!!!!! (Well, you need a predictable return code anyway, and on OS/360 the EPA [Entry Point Address] was anything but predictable.) > 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. My sympathies about your VM affliction. I use as little as I can to keep my U**Xoid happy. > >Frankly, I don't see why many [...] error messages are documented in >a large manual of 'system messages and errors', and follow a certain format: ^^^^^ That's part of the problem, most of us don't have the necessary desk space for 20 linear feet of manuals. > > sssmmmnnnt : message > >where mmm is the module [...] over Unix (in my opinion, no flames >please) in its error handling. All error messages are consistantly formatted, >it is easy to tell [...] issue such a message. Also, each help file for >a command has *every error message that that command could issue* listed at Which means that you need a 3380 ( ~~ .5 Giga Bytes ) to hold the help files. >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..).. Or contact your IBM Field Service Rep. I must say however that IBM does address hardware problems promptly and efficently.