What is a Mainframe? When might you want one? What endears them to programmers? [with interspersed editorial commentary by your archiver ...RSS] <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: alt.folklore.computers,alt.sys.pdp10 Path: utkcs2!stc06.ctd.ornl.gov!fnnews.fnal.gov!news.eng.convex.com!news.ecn.uoknor.edu!feed1.news.erols.com!howland.erols.net!newsfeed.internetmci.com!in2.uu.net!uucp1.uu.net!world!bzs In-Reply-To: peter@taronga.com's message of 8 Jul 1997 07:48:35 -0500 Message-ID: Organization: The World @ Software Tool & Die References: <01bc8523$84da9b80$e12185c2@rashid1> <5pkj08$b2c@ss1.digex.net> <0q4ta6r06p.fsf@rorschach.hks.net> <5ptcv3$6tf@bonkers.taronga.com> Date: Tue, 8 Jul 1997 16:58:43 GMT From: bzs@world.std.com (Barry Shein) Subject: Re: Why Mainframes? A mainframe was/is typically a machine with separate I/O processors (in IBM parlance, "channels") which normally had independant paths to memory (no single bus.) For example, to perform disk I/O on an IBM 370, you created a channel program in memory which the IOP executed directly (think of it as another CPU living off the main system's memory.) Besides all the obvious stuff ("get me this block") the IOP could do things such as search a range of tracks for a particular data key (match, high, low, etc.) Large 370 mainframes had 16 then later 256 separate channels (well, you bought as many as you could afford, but "up to...") These allowed true I/O parallelism, you could have a disk farm all lit up doing operations simultaneously, including transferring data to/from memory without contention (i.e., no serialization over a single bus.) In some sense all the other terms, mini/micro/PC, refer to just a progression of making a simple computer (single I/O bus) smaller and cheaper. I suppose the important distinction is that PCs center around a motherboard, whereas minis were typically a rack of boards (CPU board, memory board, serial I/O board) on a common backplane such as a Unibus. Anyhow, in this world of fascination with prices and CPU clock speeds it's not surprising that people have trouble understanding that mainframes were defined by their I/O speed and generally only required to have adequate ("balanced") CPU speed so that wasn't a choke point for the I/O. For example, I remember being awed at watching a 3090 (big IBM 370 architecture mainframe) simultaneously reading and/or writing 8 tape drives at what looked like fast rewind speed, 250ips, when my supposedly high-end minis would stop/start and stutter, maybe on a good day stream for short bursts, trying to turn one tape drive. I remember that mainframe could read or write a tape in about 2 minutes, several of them simultaneously, where the minis could easily take an hour, even with high-end tape drives (eg, TU78s.) -- -Barry Shein Software Tool & Die | bzs@world.std.com | http://www.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: bit.listserv.ibm-main Path: utkcs2!stc06.ctd.ornl.gov!news.he.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!paladin.american.edu!auvm!CIBOLA.NET!victoria Message-ID: <199707120338.VAA24118@cibola.net> Date: Fri, 11 Jul 1997 21:38:35 -0600 Sender: IBM Mainframe Discussion List From: Victoria Morrison Subject: Re: Mainframes are back! order form My 3 cents: Have you experienced that the people who choose to get off the mainframe come from application backgrounds? Managers that fall in love with the GUI (pretty screens), and forget about the everyday operations of a business. I work for a utility company and guess what! The application manager has given the IS department the goal to get rid of the mainframe. We have 4 UNIX servers, but we do not have any type of security, tape management system, operational procedures, no tape drives, no monitors for OS or Database, no type of batch...etc etc....... But, gee, we are getting off the mainframe. Our lease expires in 1998. _____________________________ V ---- V | . . | | 0 | | \ / |\ # | | | |# 000 000 Victoria Gemoets Morrison El Paso, Texas _____________0O0_____________ [In fairness to Unix, these capabilities are available for most Unix variants, if you understand that you should get them. And now, similar arguments are being presented to GUI-infatuated managers who want to convert from Unix to Windows NT. ...RSS ] <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: bit.listserv.ibm-main Path: utkcs2!stc06.ctd.ornl.gov!utk.edu!news.cis.uab.edu!gatech!howland.erols.net!paladin.american.edu!auvm!WEPCO.COM!judy.runt References: <199707120338.VAA24118@cibola.net> Message-ID: <33C7BFAB.6730@wepco.com> Date: Sat, 12 Jul 1997 12:32:27 -0500 Sender: IBM Mainframe Discussion List From: Judy Runt Subject: Re: Mainframes are back! - Victoria (and everyone else)... You sound exactly like us 2 years ago. I also work with a utility. In fact we went so far as to outsource the remainder of our Mainframe processing because of "cost savings." The machine never left the floor and was just operated and supported by another company. Well this year it has been determined that now the cost savings can be occurred if we bring it all back IN HOUSE again (a major task since that is still running MVS 3.1.3). We will be making it a viable platform alternative to our UNIX client/server environment and expect hopefully to see it grow in use with our upgrades to OS/390 and all associated functions. Hang in there, what goes around comes around...I went from an MVS Systems programmer to Unix System Admin back to MVS system programmer. I'm back in the environment I enjoy and looking forward to the challenges all the upgrades are bringing. Judy Runt Wisconsin Electric Power Co. <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: bit.listserv.ibm-main From wumpus@IX.NETCOM.COM Tue Jul 15 12:22:27 1997 Path: utkcs2!stc06.ctd.ornl.gov!utk.edu!news.cis.uab.edu!gatech!howland.erols.net!paladin.american.edu!auvm!IX.NETCOM.COM!wumpus Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU References: <199707120338.VAA24118@cibola.net> Message-ID: <33C7AF1A.FBB031DF@ix.netcom.com> Sender: IBM Mainframe Discussion List Date: Sat, 12 Jul 1997 09:21:46 -0700 From: Bob Halpern Subject: Re: Mainframes are back! order form I know of a site (which shall remain nameless) that went through a conversion of an application to client/server. They did a complete post mortem when the project was done. It worked exactly as they had planned it. However, the $$$$ were now much MORE--when PCs, maintenance, handholding, etc., have been factored in. They now have a new motto: "If you mention client/server again, you had better have your resume in hand." <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> [ When choosing the platform for a computer application, there is no substitute for rational analysis of the problem. ...RSS ] From rwh@cci.com Tue Jul 15 12:20:49 1997 Newsgroups: bit.listserv.ibm-main,comp.software.year-2000 Path: utkcs2!stc06.ctd.ornl.gov!novia!newsfeed.nacamar.de!howland.erols.net!psinntp!sunsrvr6!rwh Message-ID: Sender: root@sunsrvr6.cci.com (Operator) Organization: Northern Telecom, Network Application Systems References: <867524527.13508@dejanews.com> <33C1C9C0.5B83@acm.org> Date: Tue, 15 Jul 1997 03:35:44 GMT From: rwh@cci.com (Robert Hellmann) Subject: Re: Mainframe computers vs. Minicomputers In article <33C1C9C0.5B83@acm.org>, wrote: >rashid1@qatar.net.qa wrote: >> >> I am about to make a decision on whether to buy an IBM Mainframe or >> minicomputers with PC servers. >> >> I need your help in pointing out to me the major points which will make >> to choose mainframe over minicomputers with PC servers or the other way >> around. >> >> In other words, if you would please provide me with key points which make >> me prefer one over the other. > >(newsgroups adjusted: redirected to ibm-main newsgroup for IBM mainframe >perspective. There are probably PC-oriented groups that would be better >advocates for that approach) > >Size and availability considerations are two major factors that come to >mind. Other factors include third party software and/or tools availability, what your programmers are familiar with, how much you have available to spend, etc. You would be amazed at what a super-mini can do today. The mainframe/mini decision really depends on the transaction volume and design decisions such as database schema. How many indices and how well do they match the queries? >Assuming you at least have an application which lends itself to division >among multiple PC servers, when the load exceeds that of a single >server, at some point as the number of servers increases the overhead of >management/maintenance of such a system will exceed the cost of running >the application on a mainframe. The personnel costs associated with >maintaining and running a mainframe tend to be much more fixed if you >run the same transaction mix, just more transactions, so scaling up a >mainframe system to support a growing load may involve a hardware >upgrade, but shouldn't increase staff requirements as long as additional >functionality isn't added as well. If your applications can be >supported for the foreseeable future on a few PC servers, then this may >be the cheaper route. If long-term growth is expected, and especially >if any of the PC server applications are contrained by the maximum >capacity of a single server, this could make a PC solution cheaper >initially, but much more expensive at the point that capacity limit is >reached (worst-case scenario: total hardware/software replacement >required). One of the amazing things about PCs is how fast the hardware has improved. In the past 10 years, disk drives have increased in size 100 times, memory about 64 times, etc. If you outgrow the PCs in a couple of years, donate them to an educational institution (they're virtually worthless on the open market) and buy new ones. >Mainframes have traditionally been better at 24x7 availability than >other platforms, with more robust hardware, operating systems, and >related subsystems than in minicomputer or PC environments. Your odds >of nondisruptive recovery from hardware/software glitches should be >better on a mainframe. Transitioning to a new maintenance level of >software on a mainframe can be done with only minutes of downtime (or >possibly with no downtime in an MVS sysplex). Transitioning a PC to a >new operating system maintenance level typically involves hours of >downtime for each PC (if you're lucky). [Although "minicomputers" designed for fault-tolerance can beat even the mainframes at this game. ...RSS] I don't have much mainframe experience, so I can't compare mainframe/mini reliability, but if you really need 24x7 availability, fault-tolerant minis are always an option. >The level of expertise and training required to install, customized, >tune, and maintain IBM mainframe software will be higher than for PC or >minicomputer environments, but this can be largely independent of the >size of the mainframe platform and becomes less of a factor as system >size increases. >-- >Joel C. Ewing, Fort Smith, AR jcewing@acm.org Just playing devil's advocate. IMHO, the hardware decision should be left to your system architect. Personnally, I think there are much more important decisions to be made, such as how do I make sure that I have all of the source code and build environment stored just in case I need it changed. The example that jumps to mind is Y2K bugs, but as you use your new system, you may want it to interface to other systems in your company, etc. Do you have access to the source code and build environment or does it belong to the contract house that built the system for you? <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: bit.listserv.ibm-main Date: Fri, 11 Jul 1997 21:16:23 -0400 From: Jim Keohane Subject: Re: MVS batch FTP In article <5q6g5u$qv0@chronicle.concentric.net>, cityboy@cris.com wrote: >All, > >I've been all through the MVS TCP/IP manual and I cannot figure out >how to do this one simple little dumb thing. > >I've a number of files I need to FTP from MVS to a server type >machine. The MVS dataset names are about 35 to 40 characters and the >receiving files have multi levels of directories. So the PUT >statement can't fit both the sending and receiving file names on one >80-byte record. I've already tried creating a longer record and >reading the control statements in as a DSN. Doesn't work, the manual >is clear that the control statements have to be on a fixed length >80-byte record. > >The question is: How do you continue an FTP PUT/GET statement onto >a second line when everything won't fit on one line? Ron, You have a few options: if this can't fit: PUT LONG.LOCAL.FILE.NAME /long/remote/file/name try: PUT LONG.LOCAL.FILE.NAME + /long/remote/file/name or: LCD 'LONG.LOCAL.FILE' CD /long/remote/file PUT NAME name or allocate DDNAME INPUT to file containing FTP subcommands with large enough LRECL. Up to 200 or better should do it. -- - Jim Keohane <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: comp.unix.large,comp.arch.storage,comp.sys.dec Message-ID: <2gkpvq$otv@bushwire.apana.org.au> References: <2ghmla$mad@organpipe.uug.arizona.edu> <2gj9ep$ljo@bushwire.apana.org.au> Organization: APANA regional feed site - Melbourne, Australia. NNTP-Posting-Host: bushwire.apana.org.au Date: 8 Jan 1994 10:07:38 +1100 From: markd@bushwire.apana.org.au (Mark Delany) Subject: Re: What is a mainframe (was Re: Big I/O or Kicking the Mainframe..) [Not quite sure why comp.sys.dec is here...] In psilva@cid.aes.doe.CA (Peter Silva) writes: >Criteria set 2: >|> Mainframe: Something you have no chance of looking over the top >|> of with anything less than a step ladder. >|> >|> [Super]mini: Something you can look over the top of without >|> resorting to tippy-toes. >|> >|> Micro: Something you can look over the top of when sitting >|> down. >Super computers have been forgotten here... >These definitions are less relevant than the architecture oriented ones. Weelll, I'm going to persist with yet another set non-architectural definitions not because architectural definitions are wrong, but because there are other dimensions. Criteria set 3: Job perception if you work on a mainframe in the year.... 1960 Leading edge scientist 1970 Wizard 1980 Secure 1990 Nervous (Note I use the word perception) Criteria set 4: Perception of an organization if it buys a mainframe in the year ... 1960 Bet the future of the company on it 1970 Keep up with the competition 1980 No one gets fired for buying a mainframe 1990 Behind the times (Note I use the word perception) Criteria set 5: Perception of the word "mainframe" in the year ... 1960 Oh, is that something Computer Scientists work on? 1970 We wish we could afford one 1980 The company computer 1990 Dirty word (Note I use the word perception) Oh, did I mention that I use the word 'perception'? M. <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: alt.folklore.computers,alt.os.multics Message-ID: <39lcdj$72@ceylon.gte.com> References: <199410311519.AA02237@world.std.com> <1994Nov5.125905.5907@wizvax.wizvax.com> Reply-To: pkarger@gte.com NNTP-Posting-Host: pkarger.gte.com Organization: GTE Laboratories, Inc Date: 7 Nov 1994 14:08:50 GMT From: pak0@gte.com (Paul A. Karger) Subject: Re: YKYBHTL when... In article <1994Nov5.125905.5907@wizvax.wizvax.com>, multics@wizvax.wizvax.com (Richard Shetron) writes: |> |> In article <199410311519.AA02237@world.std.com>, |> wrote: |> >Tavares responded: |> > |> >~ > but I did have that experience. It is, also a sign of age. |> >~ |> >~ I hope not. I wasn't even 21 at the time. |> > |> >OK, not age, but programming in the 60's. You had to have been used to |> >thinking Octal and not this newfangled hex stuff. |> |> What new fangled hex stuff, the IBM 360 (same vintage as the GE/HIS-600 |> of the early/mid 60's) was programmed in hex. My biggest problem in |> working on both multics and an IBM mainframe at the same time was |> remembering if I was working in hex or octal. |> Two corrections: 1. The IBM 360 was announced in 1964, so early 60's really doesn't apply. 2. Hex computers significantly predate the IBM 360. For example, the Bendix G-15 from the late 50s (vacuum tubes!) was programmed in hex, although the hex digits were 0123456789uvwxyz. I doubt that the G-15 is even the earliest example, although it is the earliest that I know of personally. (I first learned to program on a G-15 that had been donated to a school.) <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: alt.os.multics,alt.folklore.computers Path: cs.utk.edu!willis.cis.uab.edu!gatech!howland.reston.ans.net !news2.near.net!das-news2.harvard.edu!spdcc!iecc!mailgateway Message-ID: <199411071539.AA22486@world.std.com> Sender: postmaster@iecc.com From-Uucp: frankston.com!Bob_Frankston Organization: I.E.C.C., Cambridge, Mass. Date: Mon, 7 Nov 1994 14:36:00 GMT From: Bob_Frankston@frankston.com Subject: Re: YKYBHTL when... Yes, I know hex didn't suddenly displace octal on Jan 1, 1970 and lots of people also learned on decimal machines like the IBM-1620 and even the IBM-650 as well as BCD machines like the IBM-1401. But major systems like the IBM-7094 and the GE-6xx were likely to be handled in octal. 18 bit fields encouraged this behavior and one could still use one's fingers. <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: alt.folklore.computers,alt.os.multics Message-ID: <199501160222.AA01929@world.std.com> Sender: postmaster@iecc.com Organization: I.E.C.C., Cambridge, Mass. Date: Mon, 16 Jan 1995 01:20:00 GMT From: Bob_Frankston@frankston.com Subject: Re: old mainframes & text processing Maybe it's time for either alt.os.vm (aliased as alt.os.cp67) or, better, alt.os.545TechSq.cp (along with .multics and .its under 545TechSq). In addition to my Multics experience, I also spent time in the VM world at Interactive Data Corporation. There are obviously a number of VM readers of this discussion and, I think, other IDCers still read it. Even present day ones! There were distinct variants of CMS. In particular, at IDC, we modified and eventually rewrote much of it. It is possible that my experience is biased towards the modified version. Command completion was a "feature" of the early CMS though not unique to it. The problem is that the matches were accidental properties of the file search. But you could usually depend on E being the editor and not erase (though once I did type misspelled EDIT as ERASE so typing the whole word doesn't necessarily help). I was glad to see this mechanism replaced with deterministic command names. I don't know the history of this feature in the mainstream CMS implementations. VM (or CP in those days) has (I think) retained abbrevations which is why Q is a way to type "QUERY". If CMS failed to find the command name it passed it on to CP, thus there were abbrevations on some commands. Oh yeah, tutorial time. CP (Control Program) created virtual IBM 360's (360/47's, but that's another story). So we are really talking about two independent operating systems with both getting a shot at the command line but with utterly different rules. <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: alt.os.multics,alt.folklore.computers Path: cs.utk.edu!news.msfc.nasa.gov!sol.ctr.columbia.edu!howland.reston.ans.net !news.sprintlink.net!emerald.oz.net!Sequoia.picosof.com!nic.scruz.net !garlic.com!garlic!lynn Message-ID: In-reply-to: richgr@netcom.com's message of Sun, 15 Jan 1995 19:34:06 GMT Organization: Wheeler&Wheeler References: <199501151752.AA17192@world.std.com> Date: 15 Jan 1995 23:48:11 GMT From: lynn@garlic.garlic.com (Anne & Lynn Wheeler) Subject: Re: old mainframes & text processing The original method for CMS handling commands was/is sorta funky. Everything was tokenized into 8 character units concatenated together and then a system call was made. It turns out that this was the procedure for kernal system calls or commands ... or just about anything. The kernel would then attempt to resolve the first 8character unit as an exec (aka shell script) in search path, binary executable in search path, or kernel functions. standard system has a standard command abbreviation table ... but users could augement it with their own specification. there was some tricks regarding invoking kernel calls directly from command line (or exec/shell-scripts) by typing appropriate binary data. early on cms ran into some scaleup issues and started doing sorts on file directories and leaving around a status bit indicating whether the directory was sorted or "dirty". If sorted ... simple filename search was performed with binary search (rather than linear). Also in the early '70s, (for performance) cms added a 2nd type of kernel call api ... which would only resolve to kernel functions (actually a kernel function branch table) ... instead of alwas doing the generalized search mechanism. lots of applications then got rebuilt using macros mapped to the new performance implementation (this somewhat reduced the requirement for the file directory sort). The original exec(-1) (shell script) processor was somewhat more sophisticated than dos command processing ... but was augmented in the early '70s with "exec-2" and in the late '70s with rex (which turned into rexx in the early '80s). -- +-+-+-+ Anne & Lynn Wheeler | lynn@garlic.com, lynn@netcom.com <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: alt.sys.pdp10,alt.folklore.computers,alt.os.multics Message-ID: Sender: bzs@world.std.com (Barry Shein) References: <3mcqbi$nnm@ionews.io.org> <3mhkuj$kfa@Starbase.NeoSoft.COM> Organization: The World Date: Thu, 13 Apr 1995 07:52:16 GMT From: bzs@world.std.com (Barry Shein) Subject: Re: Dumb Command Names (was Re: Retro-Computing!) In-Reply-To: peter@Starbase.NeoSoft.COM's message of 12 Apr 1995 Xref: cs.utk.edu alt.folklore.computers:104820 alt.os.multics:2098 From: peter@Starbase.NeoSoft.COM (Peter da Silva) > >Charles Bennett wrote: >> >>Especially when 'dd' does such a good job ;-). > > Yeh, it has that loverly old-fashioned IBM-JCL-70s-DEC kinda feel, > like PIP TI:=file.ext;v... Well, that was the whole point, it was a joke (you probably knew that, but for clarity.) The name was lifted from the OS/370 DD (data definition) card, as in: //NAME DD LRECL=80,BLOCK=800,RECFM=F,DISP=(KEEP,KEEP,DELETE) That should look familiar to dd users the world over. It basically defined a file you were going to use in IBM/JCL. Logical record length is 80 bytes, blocks are 800 bytes (ie, 10 LRECLs), record format is fixed (all records the same length), file disposition at end of job is (um, er) keep if the job succeeds, keep if the job exits non-zero (register 15), delete if the job abends??? Memory fails. There were about 200 different parameters you could stick on a DD card. It was pretty much the origin of the wisecrack about OS/370 being a land where everything is either mandatory or forbidden. Every parameter had a default, invariably not what you wanted, if they related at all. If you were talking about a disk file you could *usually* ignore the parameters that controlled line printer output, tho not always since it might be a disk file formatted for a line printer (like when you sent the output listing of a compiler to a disk file), did you mean the first character to be Fortran carriage control? Say so fast or repent!!! Anyhow, that's where dd comes from in unix. -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: alt.sys.pdp10,alt.folklore.computers,alt.os.multics Message-ID: <3mm2jf$s3l@reuters2.mitre.org> References: <3mcqbi$nnm@ionews.io.org> <3mhkuj$kfa@Starbase.NeoSoft.COM> NNTP-Posting-Host: mwunix.mitre.org Organization: The MITRE Corporation Date: 14 Apr 1995 14:58:55 GMT From: jcmorris@mwunix.mitre.org (Joe Morris) Subject: Re: Dumb Command Names (was Re: Retro-Computing!) bzs@world.std.com (Barry Shein) writes: >The name was lifted from the OS/370 DD (data definition) card, as in: > //NAME DD LRECL=80,BLOCK=800,RECFM=F,DISP=(KEEP,KEEP,DELETE) >That should look familiar to dd users the world over. It basically >defined a file you were going to use in IBM/JCL. Logical record length >is 80 bytes, blocks are 800 bytes (ie, 10 LRECLs), record format is >fixed (all records the same length), file disposition at end of job is >(um, er) keep if the job succeeds, keep if the job exits non-zero >(register 15), delete if the job abends??? Memory fails. ^^^^^^^^^^^^ So does the syntax of the sample you gave . You specified unblocked records, blocked 10:1; the first DISP parameter is invalid; and you never told the system what device was to receive the output. Also, you're confusing an abend (Windows users: think of a GPF) and a non-zero return code (ERRORLEVEL). For all of its sometimes idiotic complexity, the DD card and the way programs did I/O had a very useful characteristic in that the binding of an I/O operation to a specific file was done by the DD card and thus was outside the control of the application. The application performed its I/O to a program-specified DDname; the user (more commonly, the sysprog who built the "cataloged procedures" (batch files) ) used DD statements to map the DDname to a specific external resource. File characteristics such as blocksize, record format, carriage control, etc. could be specified by the application, the DD card, or (for disk- or tape-resident files) the control information previously stored with the file. For example, the FORTRAN subroutine library could be used with the linker program by coding the DDcard: //SYSLIB DD SYS1.FORTLIB,DISP=SHR (sigh. the DISP (disposition) parm defaults weren't appropriate). The easiest DD card to write was the one to define card in the input deck itself as the data stream: //SYSIN DD * /* (marks end of input stream) and close behind it was the printer or punch: //SYSPRINT DD SYSOUT=A (or =B for punch) but the user could redirect the program's use of the logical names SYSIN and SYSPRINT to any other sequential device, including a flat file on disk. While I don't miss some of the more complex "feechurs" of DD cards (such as so-called "referbacks" which were necessary evils) I sometimes wish that current desktop systems had easier redirection capabilities, especially when some silly program has hardcoded directory names that collide with other applications' hardcoded names. Joe Morris / MITRE / this material *will* be on the final exam. <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: alt.sys.pdp10,alt.folklore.computers,alt.os.multics In-Reply-To: jcmorris@mwunix.mitre.org's message of 14 Apr 1995 14:58:55 GMT Message-ID: Sender: bzs@world.std.com (Barry Shein) Organization: The World References: <3mcqbi$nnm@ionews.io.org> <3mhkuj$kfa@Starbase.NeoSoft.COM> <3mm2jf$s3l@reuters2.mitre.org> Date: Sat, 15 Apr 1995 02:31:20 GMT From: bzs@world.std.com (Barry Shein) Subject: Re: Dumb Command Names (was Re: Retro-Computing!) From: jcmorris@mwunix.mitre.org (Joe Morris) >bzs@world.std.com (Barry Shein) writes: > >>The name was lifted from the OS/370 DD (data definition) card, as in: > >> //NAME DD LRECL=80,BLOCK=800,RECFM=F,DISP=(KEEP,KEEP,DELETE) > >>That should look familiar to dd users the world over. It basically >>defined a file you were going to use in IBM/JCL. Logical record length >>is 80 bytes, blocks are 800 bytes (ie, 10 LRECLs), record format is >>fixed (all records the same length), file disposition at end of job is >>(um, er) keep if the job succeeds, keep if the job exits non-zero >>(register 15), delete if the job abends??? Memory fails. > ^^^^^^^^^^^^ >So does the syntax of the sample you gave . You specified unblocked >records, blocked 10:1; the first DISP parameter is invalid; and >you never told the system what device was to receive the output. Well, heck, if you were going to correct me you might've started with its being BLKSIZ= not BLOCK= as I wrote! But you're right, it should be RECFM=FB, fixed+blocked. >For all of its sometimes idiotic complexity, the DD card and the way >programs did I/O had a very useful characteristic in that the binding of >an I/O operation to a specific file was done by the DD card and thus >was outside the control of the application. I'm sure that's true but the motivation was that the only way the writers of OS/360 could figure out how to prevent deadly embrace was by forcing you to pre-allocate all potentially share-able resources thru an external JCL. That's why for such a "great idea" it wasn't optional (yes I know about bumming OPEN macros but by and large the concept of something as simple as an application prompting someone for a file to work with didn't exist, we often faked that by writing programs that wrote out JCL and then invoked that.) So some of that is 20/20 hindsight. There was also this hideous feature of OS/3x0 that if you somehow forgot how a file was written (ie, the details like the above example that created a file) it was very difficult to discover what they were because attempting to open with anything else would just fail, there was no real idea of a generic open and you often needed a super-user's assistance. In many cases, if possible, it was easier to remove the file and start again. And sometimes that was non-trivial but at least it was sure and mechanical (I mean like bringing 25,000 cards back down to the card reader on a hand lorry and reading it all back in, and running whatever jobs stepped from there to some final data set you needed, recreating formats as need be, etc.) Yech. It seemed to happen all the time where I worked, perhaps due to slovenliness (more often because the person who created some data set had left), but still it was quite frustrating. >While I don't miss some of the more complex "feechurs" of DD cards (such >as so-called "referbacks" which were necessary evils) I sometimes wish >that current desktop systems had easier redirection capabilities, >especially when some silly program has hardcoded directory names >that collide with other applications' hardcoded names. I'd say that's just the weakness of the app writers. For example, I can't think of a reason why it would be difficult (other than all the details) to re-implement IBM/JCL on any OS I've ever used or currently use. My guess is that no one wants it, but hey, perhaps you've found a vast, untapped market opportunity! -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: alt.os.multics Date: Wed, 19 Apr 1995 20:09 EDT Message-ID: <950420000959.911296@MULTICS-A.PMS.FORD.COM> From: Vince Scarafino Subject: Re: Retro-Computing! Date: 15 April 1995 12:39 edt From: ig25 at FG70.RZ.UNI-KARLSRUHE.DE (Thomas Koenig) Subject: Re: Retro-Computing! Peter da Silva (peter@bonkers.taronga.com) wrote in alt.folklore.computers, article : >I guess the program should have been called "punch". Well, at least IBM gave their printing utility for OS/360 the right name - IEBPTPCH (IEB for dataset utilities, PTPCH, as everybody can easily see, stands for PrinT and PunCH). Thomas "What does IEF stand for again?" Koenig -- Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet. The joy of engineering is to find a straight line on a double logarithmic diagram. I remember IEFBR14, which was a program that branched to register 14. This, by convention was a return to the caller (i.e. the operating system). This was used by people who wanted to do nothing more than execute their jcl DD statements. Oh, and the IEF (and IEB, etc.) was chosen because it was unlikely users would want to name their own programs starting with such silly letters, and there was this eight-character total namespace they had to deal with. (A rudimentary file system with some kind of directory structure would have been great, but they (at IBM) couldn't understand why there would be a need for it.) <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: alt.os.multics Date: 23 Oct 1996 05:00:01 GMT Organization: University of California, Santa Cruz Message-ID: <54k8oh$976@darkstar.ucsc.edu> NNTP-Posting-Host: hobbes.ucsc.edu From: haynes@cats.ucsc.edu (James H. Haynes) Subject: New Book "King of the Seven Dwarfs" by Homer R. Oldfield, IEEE Computer Society Press, P.O. Box 3014, Los Alamitos, CA 90720-1264. Order number BP07383, ISBN 0-8186-7383-4 The history of the GE Computer effort from ERMA to Honeywell. <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: alt.comp.sys.palmtops.pilot Organisation: CADvision, Calgary, Alberta, Canada From: Ray Barham The landing computer used on the Apollo 11 Lunar Module in 1969 did the equivalent of a Windows GPF several times during the critical descent phase of the moon landing. This was caused because the computer, during peak calculation load, couldn't handle all the telemetry (real-time data input) channels. The crew forgot to turn off several unneeded telemetry channels and the computer detected overruns and restarted (reinitialized) itself several times. If you listen carefully to the crew voices during the landing in the full version you can hear the crew refer to this. The computer was working again in time for the final landing sequence, which would have been very tough without the computer stabilization. I heard this in a lecture on real time systems given by one of the LEM computer system designers in 1974. This guy said the LEM landing computer's CPU was built entirely out of triple-input NOR-gate chips that were of middle 1960's vintage. This was so they could control the reliability of the computer. That same year I was programming real time assembler code for the control system for what is now the M1 Abrams tank. The CDC469 computer used in the tank prototype had all of 8K (that's K not M) of 16 bit memory. We had to simulate and time all critical instruction sequences down to the microsecond and hand optimize the code to shorten calculation and control sequences. Compared to all that, a USR PalmPilot is an incredibly powerful computer--but, at the same time, ALL computers today have bloated operating systems. Hey, I ain't complaining, just putting in perspective the progress that's been made! <>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<>:::<> Newsgroups: comp.sys.hp.hpux Message-ID: <854rbq$djh$1@magnum.mmm.com> References: <387362D6.A11B60A6@cornell.edu> <3874C953.FB7C0BB@netquotient.com> <3874D388.CA3BC20D@cornell.edu> <947197288.15175.0.nnrp-04.c1ed6dcb@news.demon.co.uk> Date: 7 Jan 2000 13:57:14 GMT Organization: 3M Company From: Dan Mercer Subject: Re: RTF viewer for HP-UX 10.20 In article <947197288.15175.0.nnrp-04.c1ed6dcb@news.demon.co.uk>, "Simon Waters" writes: > Its a long time since I knew this for certain but I think there are two > similar but different RTF standards. > > Standards may have moved since but I think the basic standard is DCA RTF, > and then there is Microsoft's variant. I think you are confusing IBM's DCA/RFT (Document Control Architecture/Revisable-Format-Text) with Microsoft's RTF (Rich Text Format). DCA/RFT was based on an IBM Selectric Typewriter paradigm - you could, for instance, compose letters like +/- using backspaces and half-linefeeds. The RTF standard has been a moving one, however, as it has striven to maintain capabilities with Microsoft Word. -- Dan Mercer damercer@uswest.net > Jonathan Joseph wrote in message > news:3874D388.CA3BC20D@cornell.edu... > I installed rtf2latex, and got the following same errors when I ran it on > two different > .rtf files (from two different sources) ////////////////////////////////////////////////////////////////////////////// [February A.D. 2003] Of possible interest: Hercules (IBM mainframe) emulator http://www.conmicro.cx/hercules/ also see discussion group http://groups.yahoo.com/group/hercules-390/ (see Links section for other Hercules groups). //////////////////////////////////////////////////////////////////////////////