Re: Assembler Question
Shmuel Metz (Seymour J.) wrote: You know better than that. Actually I don't. I was working on a project that had a ForTran main program with some assembler subroutines, that needed porting from a 7094 to another machine. The only change I recall is having to test for -0, and for some reason I remember the CDC 1604. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
In 45d79eacefba9b428e3d400e924d36b9019d0...@iwdubcormsg007.sci.local, on 02/09/2009 at 09:15 PM, Thompson, Steve steve_thomp...@stercomm.com said: Is there any package - Besides Ada Lovelace's running on Babbage machine - that can run today on a +45 Year old machine :P Yes. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
In 4990bad6.50...@vmfacility.fr, on 02/10/2009 at 12:23 AM, Ivan Warren i...@vmfacility.fr said: Please.. find *ONE* single architecture that's still capable of running programs written 45 years ago ! Would you settle for three? One from column BULL and two from column Unisys. In 4990c212.7040...@vmfacility.fr, on 02/10/2009 at 12:53 AM, Ivan Warren i...@vmfacility.fr said: And I still use 'BALR' because most of my work still involves 24 AMODE/RMODE code ;) That's a non sequitor; BAS and BASR work fine in 24-bit mode. Did you mean that most of your work involves code that relies of the PM and ILC being in the return register? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
In kmi4p4th01jpqif5rqgihtqfdbstvra...@4ax.com, on 02/10/2009 at 11:52 PM, Clark Morris cfmpub...@ns.sympatico.ca said: Thsey are able to run programs for which there is source in one of the higher level languages (the B5000, B5500, B6500, etc. series machines operating system was written in Algol). Various upgrades have required recompiles. The B1700, B2500 and B5000 architectures are dead. I'm not aware of any upgrade within the B6500 architecture that required a recompile. And, yes, Ivan had the correct[1] companies for the BUNCH: Burroughs, UNIVAC, NCR, Control Data, Honeywell. I believe that the other two dwarves[2] were GE and RCA. [1] Other than capitalization. [2] IBM and the seven dwarves were not, however, the only companies making computers. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
In d02.4e62cf50.36c44...@aol.com, on 02/11/2009 at 10:05 AM, (IBM Mainframe Discussion List) dasdbi...@aol.com said: I thought that the C in BUNCH was Compagnie des Machines Bull. No; B.U.L.L. was a minor player at the time. CDC made mainframe-compatible disk drives, though, I think, but not central processors. Sic transit gloria mundi. There was a time when CDC owned the high-end market. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
In 94c476c03bff5e42ac3518fdac9643c4bdcdd49...@hqmail.rocketsoftware.com, on 02/11/2009 at 10:36 AM, Bill Fairchild bi...@mainstar.com said: But there was a connection between BUNCH and the French Bull. From that wiki article: In 1991 Honeywell's computer division was sold to the French computer company Groupe Bull. There was also a connection to the remaining two seven dwarves, sin B.U.L.L. sold both GE[3] and RCA boxen under its own name. [3] Via Honeywell. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
In 499329a7.4050...@valley.net, on 02/11/2009 at 02:40 PM, Gerhard Postpischil gerh...@valley.net said: It depends on your definition of mainframe and compatible. The CDC 1604 was an IBM 7094 look-alike, You know better than that. differing primarily in using 1's complement arithmetic rather than 2's complement (sic) Different instruction set, different number of index registers, different word size, unable to combine index and indirect address, two instructions per word, different interrupt and I/O system. using 1's complement arithmetic rather than 2's complement (patent issues?) Inheritance from UNIVAC. But the 7094 used sign-magnitude. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
In 1234388827.19101.65.ca...@chuck.duda.com, on 02/11/2009 at 04:47 PM, David Andrews d...@lists.duda.com said: Was it KRONOS? That came later. It would have to have been SIPROS or COS. CDC abandoned SIPROS and COS eventually mutated into SCOPE and KRONOS (I'm not sure of the spelling.) -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folkore.computers as well. bi...@mainstar.com (Bill Fairchild) writes: I should have checked Wiki_knows_all first. http://en.wikipedia.org/wiki/BUNCH But there was a connection between BUNCH and the French Bull. From that wiki article: In 1991 Honeywell's computer division was sold to the French computer company Groupe Bull. re: http://www.garlic.com/~lynn/2009c.html#9 Assembler Question http://www.garlic.com/~lynn/2009c.html#12 Assembler Question http://www.garlic.com/~lynn/2009c.html#14 Assembler Question note that in that time-frame, (at least) both Wang and Bull contracted for rs/6000 to sell under their own label. Also the Bull/Honeywell (world) services in Billerica was one of the early HA/CMP installations ... misc. past posts mentioning ha/cmp http://www.garlic.com/~lynn/subtopic.html#hacmp current web site: http://www.bull.us/bull_services/ -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On 16 Feb 2009 14:30:46 -0800, in bit.listserv.ibm-main you wrote: In kmi4p4th01jpqif5rqgihtqfdbstvra...@4ax.com, on 02/10/2009 at 11:52 PM, Clark Morris cfmpub...@ns.sympatico.ca said: Thsey are able to run programs for which there is source in one of the higher level languages (the B5000, B5500, B6500, etc. series machines operating system was written in Algol). Various upgrades have required recompiles. The B1700, B2500 and B5000 architectures are dead. I'm not aware of any upgrade within the B6500 architecture that required a recompile. As I understand it, some operating system upgrades have required recompilations. This is from reading postings on comp.lang.cobol. I THINK that the B5500/6500/etc. series is now the A series and that this is a characteristic of how they do things. And, yes, Ivan had the correct[1] companies for the BUNCH: Burroughs, UNIVAC, NCR, Control Data, Honeywell. I believe that the other two dwarves[2] were GE and RCA. [1] Other than capitalization. [2] IBM and the seven dwarves were not, however, the only companies making computers. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On Mon, 16 Feb 2009 17:52:02 -0500, Anne Lynn Wheeler wrote: note that in that time-frame, (at least) both Wang and Bull contracted for rs/6000 to sell under their own label. Aaah, that fits. At one time we had a small herd of Bulls, running BOS/X, which was represented to me as an AIX variant. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
In ag4kp414kv5gvgdpufgsva0t61f0iq3...@4ax.com, on 02/16/2009 at 09:27 PM, Clark Morris cfmpub...@ns.sympatico.ca said: As I understand it, some operating system upgrades have required recompilations. Possibly, but that's a separate issue from recompilations due to changes in the architecture. I THINK that the B5500/6500/etc. series is now the A series B6500, yes, but the B5500 is part of a different family with a different architecture, and it's been dead for decades. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On Mon, 16 Feb 2009 17:52:02 -0500, Anne Lynn Wheeler wrote: note that in that time-frame, (at least) both Wang and Bull contracted for rs/6000 to sell under their own label. Aaah, that fits. At one time we had a small herd of Bulls, running BOS/X, which was represented to me as an AIX variant. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Notice: The information contained in this email message and any attached files may be confidential information, and may also be the subject of legal professional privilege. If you are not the intended recipient any use, disclosure or copying of this email is unauthorised. If you received this email in error, please notify the DEEWR Service Desk by calling 1300 305 520 and delete all copies of this transmission together with any attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On 16 Feb 2009 14:30:46 -0800, in bit.listserv.ibm-main you wrote: In kmi4p4th01jpqif5rqgihtqfdbstvra...@4ax.com, on 02/10/2009 at 11:52 PM, Clark Morris cfmpub...@ns.sympatico.ca said: Thsey are able to run programs for which there is source in one of the higher level languages (the B5000, B5500, B6500, etc. series machines operating system was written in Algol). Various upgrades have required recompiles. The B1700, B2500 and B5000 architectures are dead. I'm not aware of any upgrade within the B6500 architecture that required a recompile. As I understand it, some operating system upgrades have required recompilations. This is from reading postings on comp.lang.cobol. I THINK that the B5500/6500/etc. series is now the A series and that this is a characteristic of how they do things. And, yes, Ivan had the correct[1] companies for the BUNCH: Burroughs, UNIVAC, NCR, Control Data, Honeywell. I believe that the other two dwarves[2] were GE and RCA. [1] Other than capitalization. [2] IBM and the seven dwarves were not, however, the only companies making computers. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Notice: The information contained in this email message and any attached files may be confidential information, and may also be the subject of legal professional privilege. If you are not the intended recipient any use, disclosure or copying of this email is unauthorised. If you received this email in error, please notify the DEEWR Service Desk by calling 1300 305 520 and delete all copies of this transmission together with any attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question - AMODE=24
I am the started writing Assembler on a 360/20I have seen Gil -- I am the started writing Assembler on a 360/20I have seen BASR and know how it is used but dont use it much at all. Scott J Ford www.identityforge.com From: Gilbert Saint-Flour usenet5...@yahoo.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, February 10, 2009 10:24:21 AM Subject: Re: Assembler Question - AMODE=24 On Tuesday 10 February 2009 15:50, Gilbert Saint-Flour wrote: And, almost always, I code BAL/BALR and rarely BAS/BASR. I started coding assembler on a 360/20 in 1972, so call that an old habit. The 360/20 was a 16-bit machine which had BAS/BASR, which I used a lot at the time. The 360/20 did not have BAL/BALR which I started to use on 370 systems in 1975. IIRC, early 370 systems didn't have BAS/BASR, which were added to XA systems. Sorry for the error. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
In a message dated 2/10/2009 11:25:27 P.M. Central Standard Time, cfmpub...@ns.sympatico.ca writes: (BUNCH - Burroughs Univac Ncr Cdc Honeywell -- if I remember correctly). I thought that the C in BUNCH was Compagnie des Machines Bull. CDC made mainframe-compatible disk drives, though, I think, but not central processors. Bill Fairchild Rocket Software **The year's hottest artists on the red carpet at the Grammy Awards. AOL Music takes you there. (http://music.aol.com/grammys?ncid=emlcntusmusi0002) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
CDC made mainframe-compatible disk drives, though, I think, but not central processors. I thought the C was CDC. They most certainly made processors. Bob Shannon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On Wed, 2009-02-11 at 10:05 -0500, (IBM Mainframe Discussion List) wrote: CDC made mainframe-compatible disk drives, though, I think, but not central processors. Oh m'gosh, yes. Look up Seymour Cray! -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
In a message dated 2/11/2009 9:06:17 A.M. Central Standard Time, dasdbi...@aol.com writes: I thought that the C in BUNCH was Compagnie des Machines Bull. CDC made mainframe-compatible disk drives, though, I think, but not central processors. _http://en.wikipedia.org/wiki/CDC_6000_series_ (http://en.wikipedia.org/wiki/CDC_6000_series) Never laid hands on one, but did lots of Conversions(mostly Fortran) for DOE. **The year's hottest artists on the red carpet at the Grammy Awards. AOL Music takes you there. (http://music.aol.com/grammys?ncid=emlcntusmusi0002) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of (IBM Mainframe Discussion List) Sent: Wednesday, February 11, 2009 10:05 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler Question In a message dated 2/10/2009 11:25:27 P.M. Central Standard Time, cfmpub...@ns.sympatico.ca writes: (BUNCH - Burroughs Univac Ncr Cdc Honeywell -- if I remember correctly). I thought that the C in BUNCH was Compagnie des Machines Bull. CDC made mainframe-compatible disk drives, though, I think, but not central processors. CDC certainly made processors. DOD used CDC 6600's extensively for defense planning in the late 60's and 70's, as they were the fastest numerical/mathematical machines of their era. They had a really crappy OS (if you could even call it that), but they excelled at what they were designed to do. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Finnell Sent: Wednesday, February 11, 2009 10:24 AM _http://en.wikipedia.org/wiki/CDC_6000_series_ (http://en.wikipedia.org/wiki/CDC_6000_series) I should have checked Wiki_knows_all first. http://en.wikipedia.org/wiki/BUNCH But there was a connection between BUNCH and the French Bull. From that wiki article: In 1991 Honeywell's computer division was sold to the French computer company Groupe Bull. Ah, my synapses aren't what they use to be. Bill Fairchild Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
CDC made mainframe-compatible disk drives, though, I think, but not central processors. I believe they stopped after 3350-compatible drives. We were one of the last users in the Greater Toronto Area (Ontario Government) to migrate to 3380's. And, CDC didn't even participate in the RFP. It was just Amdahl, STK (as it was called back then), NAS IBM. I thought the C was CDC. They most certainly made processors. Yes, they made processors; just not IBM-Compatable. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
CDC made mainframe-compatible disk drives, though, I think, but not central processors. Oh m'gosh, yes. Look up Seymour Cray! I think the key was 'mainframe-compatible'. But, back then, everybody was calling their equipment 'mainframes'. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
I thought that the C in BUNCH was Compagnie des Machines Bull. No, back then Honeywell was the H, until Bull bought them in the late 1970's. I was still in University, then. We had a Level 66, runing GCOS8. The reps from Bull came in and changed all the labels on the machine, after the acquisition. I used a Control Data Corporation (CDC), CYBER 6000, in high school taking a night school course run by McMaster University in 1972. It ran FORTRAN in batch, and BASIC online. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
But there was a connection between BUNCH and the French Bull. From that wiki
article: In 1991 Honeywell's computer division was sold to the French
computer company Groupe Bull.
I seem to remember, it was a lot earlier than that (circa 1978).
Of course, I don't know which to trust the least -- my memory, or WIKI. (8-{]}
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. eamacn...@yahoo.ca (Ted MacNEIL) writes: I believe they stopped after 3350-compatible drives. We were one of the last users in the Greater Toronto Area (Ontario Government) to migrate to 3380's. And, CDC didn't even participate in the RFP. It was just Amdahl, STK (as it was called back then), NAS IBM. there is the folklore about 200(?) or so disk engineers leaving San Jose disk division over a period of time ... lots of going to Memorox to do plug-compatible disk drives ... but some number of them going to other places like CDC. in the late 70s I was over in bldg. 28 ... working on various things ... like original relational/sql implementation ... some past posts http://www.garlic.com/~lynn/submain.html#systemr but they would also let me play disk engineer over in bldg. 1415. http://www.garlic.com/~lynn/submain.html#disk I was getting ask to participat in some number of high level discussions ... including conferences with channel engineers in POK. I aksed why and was told that those activities had previously been handled by various senior engineers ... but so many had left over the previous ten yrs. plug-compatible controllers devices has been given as major motivation for the Future System effort in the early 70s. http://www.garlic.com/~lynn/submain.html#futuresys couple old posts with various quotes/reference about FS motivation/activity: http://www.garlic.com/~lynn/2001f.html#33 http://www.garlic.com/~lynn/2008s.html#17 I was somewhat involved in clone controllers as undergraduate in the 60s. I tried to get the 2702 communications controller to do something ... which it could almost, only (i.e. NOT) do. This was some of the motivation behind the university starting a clone controller project using an Interdata/3; reverse engineering the 360 channel interface, building channel interface board for the Interdata/3, and programming the Interdata/3 to emulate 2702 (and do some additional stuff). This was marketed by Interdata ... and then later when Perkin-Elmer bought Interdata, marketed under the Perkin-Elmer name. One of the big issues for 3370s 3380s were new kind of (thin-film) disk head (and possibly drop off in plug-compatible compitition ... although there was also pickup in disk market in other places ... like workstation and PCs). Past posts mentioning air-bearing simulation as part of designing thin-film/floating heads: http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code http://www.garlic.com/~lynn/2005o.html#44 Intel engineer discusses their dual-core design http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer http://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer http://www.garlic.com/~lynn/2006d.html#14 IBM 610 workstation computer http://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2006u.html#18 Why so little parallelism? http://www.garlic.com/~lynn/2006x.html#27 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core? http://www.garlic.com/~lynn/2007e.html#43 FBA rant http://www.garlic.com/~lynn/2007f.html#46 The Perfect Computer - 36 bits? http://www.garlic.com/~lynn/2007j.html#64 Disc Drives http://www.garlic.com/~lynn/2007l.html#52 Drums: Memory or Peripheral? http://www.garlic.com/~lynn/2008k.html#77 Disk drive improvements http://www.garlic.com/~lynn/2008l.html#60 recent mentions of 40+ yr old technology -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Wasn't Bull a service company ? I have been around computer Bill, Wasn't Bull a service company ? I have been around computer service companies since I was a kid, Dad worked and retired from Unisys after 37 yrs, so a lot of these names are familiar. Regards, Scott J Ford www.identityforge.com From: Bill Fairchild bi...@mainstar.com To: IBM-MAIN@bama.ua.edu Sent: Wednesday, February 11, 2009 10:36:49 AM Subject: Re: Assembler Question From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Finnell Sent: Wednesday, February 11, 2009 10:24 AM _http://en.wikipedia.org/wiki/CDC_6000_series_ (http://en.wikipedia.org/wiki/CDC_6000_series) I should have checked Wiki_knows_all first. http://en.wikipedia.org/wiki/BUNCH But there was a connection between BUNCH and the French Bull. From that wiki article: In 1991 Honeywell's computer division was sold to the French computer company Groupe Bull. Ah, my synapses aren't what they use to be. Bill Fairchild Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Ted MacNEIL wrote: Yes, they made processors; just not IBM-Compatable. It depends on your definition of mainframe and compatible. The CDC 1604 was an IBM 7094 look-alike, differing primarily in using 1's complement arithmetic rather than 2's complement (patent issues?). Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Farley, Peter x23353 wrote: They had a really crappy OS (if you could even call it that), but they excelled at what they were designed to do. Which one did you think was crappy? I ran on the CDC 6600 at ESSA, and about halfway through the contract they switched systems. (I remember it as CYPROS, but couldn't find any google or wikipedia references to it). I fondly remember the first version, that crashed whenever the printer ran out of paper. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. peter.far...@broadridge.com (Farley, Peter x23353) writes: CDC certainly made processors. DOD used CDC 6600's extensively for defense planning in the late 60's and 70's, as they were the fastest numerical/mathematical machines of their era. re: http://www.garlic.com/~lynn/2009c.html#9 Assembler Question there are some old references about cray (and thornton) doing cdc 66000 ... and then Cray left and formed Cray computer ... and Thornton left and formed Network Systems Corporation. NSC was eventually bought by STK ... which was subsequently acquired by SUN. some past posts referencing my high-speed data transport (HSDT) project where we used some number of NSC HYPERChannel boxes: http://www.garlic.com/~lynn/subnetwork.html#hsdt some part of 6600 past thread in a.f.c (with some references): http://www.garlic.com/~lynn/2007t.html#73 Remembering the CDC 6600 6600 wiki page http://en.wikipedia.org/wiki/CDC_6600 Parallel operation in the Control Data 6600 (by Thornton) http://research.microsoft.com/en-us/um/people/gbell/Computer_Structures__Readings_and_Examples/0509.htm scan of Thornton's 6600 document on bitsave.org: http://www.bitsavers.org/pdf/cdc/6x00/thornton_6600_paper.pdf some specific posts mentioning Thornton: http://www.garlic.com/~lynn/2002i.html#13 CDC6600 - just how powerful a machine was it? http://www.garlic.com/~lynn/2005k.html#15 3705 http://www.garlic.com/~lynn/2005m.html#49 IBM's mini computers--lack thereof http://www.garlic.com/~lynn/2005r.html#14 Intel strikes back with a parallel x86 design http://www.garlic.com/~lynn/2005u.html#22 Channel Distances http://www.garlic.com/~lynn/2008s.html#37 Is SUN going to become x86'ed ?? http://www.garlic.com/~lynn/2008s.html#38 Welcome to Rain Matrix: The Cloud Computing Network -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On Wed, 11 Feb 2009 10:05:27 EST, IBM Mainframe Discussion List dasdbi...@aol.com wrote: ... I thought that the C in BUNCH was Compagnie des Machines Bull. CDC made mainframe-compatible disk drives, though, I think, but not central processors. ... I don't know what the C was for, but CDC definitely made computers in the 1960s. There was a least a 6000 series. The University of Washington had a CDC 6400 in the late '60s as I recall. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On Wed, 2009-02-11 at 14:50 -0500, Gerhard Postpischil wrote: I remember it as CYPROS Was it KRONOS? Think PLATO used to run on that, too. (But we digress!) -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.foklore.computers as well. patrick.oke...@wamu.net (Patrick O'Keefe) writes: I don't know what the C was for, but CDC definitely made computers in the 1960s. There was a least a 6000 series. The University of Washington had a CDC 6400 in the late '60s as I recall. re: http://www.garlic.com/~lynn/2009c.html#9 Assembler Question http://www.garlic.com/~lynn/2009c.html#12 Assembler Question control data corporation ... there is folklore in the late 60s, about the cdc 6600 at berkeley having a thermal problem a little after 10am tuesday mornings (???) and shutting down. After this happened some number of times ... they basically isolated it to low water pressure to the datacenter cooling system. Eventually identified: 1) tuesday(?) morning was when the grass was being watered and 2) 10am(?) was class break ... with lots of students heading to rest rooms flushing. The combination was enough to drop water pressue to datacenter cooling. recent posts in related thread about liqued cooling: http://www.garlic.com/~lynn/2009b.html#46 Z11 - Water cooling? http://www.garlic.com/~lynn/2009b.html#77 Z11 - Water cooling? note ... one of the litigation settlements was SBC (service bureau corporation) going to CDC (there was also some number of employees that filed legal actions about their change employments) ... also mentioned in CDC wiki page http://en.wikipedia.org/wiki/Control_Data_Corporation from above: In the meantime, IBM announced a new version of the famed System/360, the Model 92, which would be just as fast as CDC's 6600. This machine did not exist, but its nonexistence did not stop sales of the 6600 from drying up, while people waited for the release of the Model 92. Norris did not take this tactic, dubbed as fear, uncertainty and doubt (FUD), lying down, and in an antitrust suit against IBM a year later, he won over 600 million dollars. He also picked up IBM's subsidiary Service Bureau Corporation (SBC), which ran computer processing for other corporations on its own computers. SBC fit nicely into CDC's existing service bureau offerings. ... snip ... during the morph from cp67 to vm370 ... there was first the transition where the cp67 group split off from the science center ... and took over the boston programming center on the 3rd flr of 545 tech sq http://www.garlic.com/~lynn/subtopic.html#545tech as the group outgrew the 3rd flr ... they moved out to the (vacant) SBC bldg. in burlington mall. They were there until a little after future system project being killed http://www.garilc.com/~lynn/submain.html#futuresys during the Future System phase ... lots of 370 product activity was neglected (since FS was targeted as complelely replacing 370 ... in much the same way that 360 had obsoleted previous computer generations). With the death of FS ... there was a mad rush to get stuff back into the 370 product lines ... including a crash program for 370-xa. POK made the business case that in order to make the mvs/xa product schedule ... they needed all the people in the vm370 group ... shutdown burlington mall location, move all the people to POK (and kill off the vm370 product). Endicott eventually made the case to pick up the vm370 product mission (but had to reconstitute a group from scratch). for additional product drift ... the pre-occupation with Future System ... and neglecting 370 products ... contributed to clone processors in getting market foothold ... slightly interesting, since Future System was largely motivated as a countermeasure to clone controllers. -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Control Data Corporation was CDC Scott J Ford Pat, Control Data Corporation was CDC Scott J Ford From: Patrick O'Keefe patrick.oke...@wamu.net To: IBM-MAIN@bama.ua.edu Sent: Wednesday, February 11, 2009 4:32:36 PM Subject: Re: Assembler Question On Wed, 11 Feb 2009 10:05:27 EST, IBM Mainframe Discussion List dasdbi...@aol.com wrote: ... I thought that the C in BUNCH was Compagnie des Machines Bull. CDC made mainframe-compatible disk drives, though, I think, but not central processors. ... I don't know what the C was for, but CDC definitely made computers in the 1960s. There was a least a 6000 series. The University of Washington had a CDC 6400 in the late '60s as I recall. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On Wed, 11 Feb 2009 15:21:16 -0800, Scott Ford scott_j_f...@yahoo.com wrote: ...Control Data Corporation was CDC ... I don't know what the C was for, but CDC ... Uh, I meant the C in BUNCH, not the Cs in CDC, but I can see how that might not have been completely clear. I guess. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Before IBM makes a hardware change that impacts the performance of BAL/BALR, perhaps they should scrape their macros clean of these instructions. I just assembled an exit that uses the RACROUTE macro, and it still uses BALR (z/OS 1.9). Edward Jaffe edja...@phoenixsoftware.com wrote in message news:4990c116.5080...@phoenixsoftware.com... Don Russell wrote: I agree. I'm not advocating that BAL/BALR be dropped from the instruction set. I'm advocating that people stop using them in new/updated code. IBM is scraping the bottom of the barrel looking for ways to improve performance. One way would be to offload processing for older, redundant instructions or functions to millicode. Indeed, there was even some talk a while ago about possibly converting BALR (specifically the parts of it that set the upper byte in 24-bit mode) to millicode in order to save some System z chip real estate. I haven't coded a BALR for program linkage in decades. Up until a few years ago, I still used it on occasion to sense the current AMODE. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Err, they were really very different. The 709x had a 36-bit word, the 1604 a 48-bit word. The instructions sets were totally different. The 1604 packed two 24-bit instructions into each word. I learned computing on a CDC 3600, which was an upwardly compatible successor to the 1604. Gerhard Postpischil gerh...@valley.net wrote in message news:499329a7.4050...@valley.net... Ted MacNEIL wrote: Yes, they made processors; just not IBM-Compatable. It depends on your definition of mainframe and compatible. The CDC 1604 was an IBM 7094 look-alike, differing primarily in using 1's complement arithmetic rather than 2's complement (patent issues?). Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On Wed, 11 Feb 2009 14:40:23 -0500, Gerhard Postpischil wrote: It depends on your definition of mainframe and compatible. The CDC 1604 was an IBM 7094 look-alike, differing primarily in using 1's complement arithmetic rather than 2's complement (patent issues?). Just to clarify (you didn't say either way), the 7094 did not use 2's complement arithmetic. I assumed 1's complement was motivated by the desire to overload boolean complement with arithmetic complement. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Monday, February 09, 2009 6:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler Question Snipped I haven't coded a BALR for program linkage in decades. Up until a few years ago, I still used it on occasion to sense the current AMODE. Indeed, and do you then always use the LINKINST=BASR keyword on the CALL macro to force the macro not to use BALR? What do you do about the WTO macro which always generates a BAL around the message text? Etc., etc., pick your system macro and observe the BAL/R's and other ancient instructions all over the place. smallrant I am occasionally somewhat peeved at IBM for failing to provide different, non-24-bit macro expansions when the programmer goes to the trouble of coding SYSSTATE ARCHLVL=2 (or any other mechanism they might care to invent). Even GET/PUT could use BASR, AFAIK, unless they too are using the BALR to detect AMODE. Which ought to be documented, if true. /smallrant Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
BAS/BASR worked just fine on 360/20 (in 16-bit mode). Who's living in the past? g,d,r Tom Puddicombe Mainframe Performance Capacity Planning CSC 71 Deerfield Rd, Meriden, CT 06450 ITIS | (860) 428-3252 | tpudd...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Don Russell russell@gmail.com Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 02/09/2009 07:02 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu To IBM-MAIN@bama.ua.edu cc Subject Re: Assembler Question On Mon, Feb 9, 2009 at 3:53 PM, Ivan Warren i...@vmfacility.fr wrote: And I still use 'BALR' because most of my work still involves 24 AMODE/RMODE code ;) BAS/BASR work fine in 24 bit mode too. Stop living in the past. ;-) (Just teasing) Do you use the linkage information in the high byte? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question - AMODE=24
LINKINST was added to the CALL macro in 1997 (OS/390 R2). Frankly, I don't remember ever noticing it, let alone using it. What I remember is what I went through when I started to work in XA in 1988/1989 and ESA in 1991. I started to modify programs which were all AMODE=24 to switch to AMODE=31, like I saw the SDSF code do in ISFSRC. A few months later, I realised that it would be better to write AMODE=ANY code which CALLs AMODE=ANY sub-routines which switch to AMODE=24 when they have to (mostly GET/PUT, READ/WRITE), and made appropriate changes in sub-routines for them to work in MVS/370, MVS/XA and MVS/ESA. So, for the last 20 years, I used this type of approach in most of my assembler code and don't care about what's available to switch AMODE in MVS, VM and VSE. In 2003, I realised that it was unlikely that my programs would ever have to work in a system older than DFSMS/MVS, so I removed all the AMODE=24 code from GET/PUT, READ/WRITE sub-routines. I don't think I ever used SYSSTATE or made much difference between BASR and BALR and can't imagine why someone would worry about this in 2009. The only thing I remember is the problem about 24-bit address constants in various control-blocks (DCB, RB, SWA, ...) which many of my programs and sub-routines have to deal with. And, almost always, I code BAL/BALR and rarely BAS/BASR. I started coding assembler on a 360/20 in 1972, so call that an old habit. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ On Tuesday 10 February 2009 14:53, Farley, Peter x23353 wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Monday, February 09, 2009 6:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler Question Snipped I haven't coded a BALR for program linkage in decades. Up until a few years ago, I still used it on occasion to sense the current AMODE. Indeed, and do you then always use the LINKINST=BASR keyword on the CALL macro to force the macro not to use BALR? What do you do about the WTO macro which always generates a BAL around the message text? Etc., etc., pick your system macro and observe the BAL/R's and other ancient instructions all over the place. smallrant I am occasionally somewhat peeved at IBM for failing to provide different, non-24-bit macro expansions when the programmer goes to the trouble of coding SYSSTATE ARCHLVL=2 (or any other mechanism they might care to invent). Even GET/PUT could use BASR, AFAIK, unless they too are using the BALR to detect AMODE. Which ought to be documented, if true. /smallrant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question - AMODE=24
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gilbert Saint-Flour Sent: Tuesday, February 10, 2009 8:49 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler Question - AMODE=24 snippage And, almost always, I code BAL/BALR and rarely BAS/BASR. I started coding assembler on a 360/20 in 1972, so call that an old habit. snippage And BAL/BALR were macros that generated BAS/BASR, at least on the CPS/TPS system I was using. Regards, Steve Thompson -- Opinions expressed by poster may or may not be the opinions of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question - AMODE=24
On Tuesday 10 February 2009 15:50, Gilbert Saint-Flour wrote: And, almost always, I code BAL/BALR and rarely BAS/BASR. I started coding assembler on a 360/20 in 1972, so call that an old habit. The 360/20 was a 16-bit machine which had BAS/BASR, which I used a lot at the time. The 360/20 did not have BAL/BALR which I started to use on 370 systems in 1975. IIRC, early 370 systems didn't have BAS/BASR, which were added to XA systems. Sorry for the error. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Farley, Peter x23353 wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Monday, February 09, 2009 6:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler Question Snipped I haven't coded a BALR for program linkage in decades. Up until a few years ago, I still used it on occasion to sense the current AMODE. Indeed, and do you then always use the LINKINST=BASR keyword on the CALL macro to force the macro not to use BALR? I don't count macro-generated BALRs among the BALRs I've coded. A macro interface is decided by its service provider. My macros use BASR or BASSM. What do you do about the WTO macro which always generates a BAL around the message text? Etc., etc., pick your system macro and observe the BAL/R's and other ancient instructions all over the place. I assemble with SYSSTATE ARCHLVL=1 or SYSSTATE ARCHLVL=2. I do not assemble with SYSSTATE ARCHLVL=0. My programs use base registers only for constants, literals and working storage--not code. I would know right away if a macro generated a B or BAL. FYI, on my system WTO generates this: 34384 WTO 'I am here' 34386+ CNOP 0,4 34387+ BRAS 1,IHB4648A BRANCH AROUND MESSAGE 34388+ DCAL2(13) TEXT LENGTH 34389+ DCB'' MCSFLAGS 34390+ DCC'I am here' MESSAGE TEXT 34391+IHB4648A DS0H 34392+ SVC 35 ISSUE SVC 35 For more ancient macros, I often use IEABRCX PUSH/POP to change B and BAL/BAS to J and JAS just for the problem macro. For example: IEABRCX ENABLEEnable B-to-J conversion PUSH ACONTROLSave ACONTROL status ACONTROL FLAG(NOSUBSTR) Don't flag substring errors CALLTSSR EP=IKJPARS, Invoke TSO/E parse routine MF=(E,PPL) (same) POP ACONTROLRestore ACONTROL status IEABRCX DISABLE Disable B-to-J conversion -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Edward Jaffe wrote: ... My programs use base registers only for constants, literals and working storage--not code. For more information on this topic, see http://ew.share.org/proceedingmod/abstract.cfm?abstract_id=17758 -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question - AMODE=24
360/20 (vintage 1970) didn't have BAL/BALR instructions, it had BAS/BASR. Tom Puddicombe Mainframe Performance Capacity Planning CSC 71 Deerfield Rd, Meriden, CT 06450 ITIS | (860) 428-3252 | tpudd...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Gilbert Saint-Flour usenet5...@yahoo.com Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 02/10/2009 09:49 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu To IBM-MAIN@bama.ua.edu cc Subject Re: Assembler Question - AMODE=24 LINKINST was added to the CALL macro in 1997 (OS/390 R2). Frankly, I don't remember ever noticing it, let alone using it. What I remember is what I went through when I started to work in XA in 1988/1989 and ESA in 1991. I started to modify programs which were all AMODE=24 to switch to AMODE=31, like I saw the SDSF code do in ISFSRC. A few months later, I realised that it would be better to write AMODE=ANY code which CALLs AMODE=ANY sub-routines which switch to AMODE=24 when they have to (mostly GET/PUT, READ/WRITE), and made appropriate changes in sub-routines for them to work in MVS/370, MVS/XA and MVS/ESA. So, for the last 20 years, I used this type of approach in most of my assembler code and don't care about what's available to switch AMODE in MVS, VM and VSE. In 2003, I realised that it was unlikely that my programs would ever have to work in a system older than DFSMS/MVS, so I removed all the AMODE=24 code from GET/PUT, READ/WRITE sub-routines. I don't think I ever used SYSSTATE or made much difference between BASR and BALR and can't imagine why someone would worry about this in 2009. The only thing I remember is the problem about 24-bit address constants in various control-blocks (DCB, RB, SWA, ...) which many of my programs and sub-routines have to deal with. And, almost always, I code BAL/BALR and rarely BAS/BASR. I started coding assembler on a 360/20 in 1972, so call that an old habit. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ On Tuesday 10 February 2009 14:53, Farley, Peter x23353 wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Monday, February 09, 2009 6:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler Question Snipped I haven't coded a BALR for program linkage in decades. Up until a few years ago, I still used it on occasion to sense the current AMODE. Indeed, and do you then always use the LINKINST=BASR keyword on the CALL macro to force the macro not to use BALR? What do you do about the WTO macro which always generates a BAL around the message text? Etc., etc., pick your system macro and observe the BAL/R's and other ancient instructions all over the place. smallrant I am occasionally somewhat peeved at IBM for failing to provide different, non-24-bit macro expansions when the programmer goes to the trouble of coding SYSSTATE ARCHLVL=2 (or any other mechanism they might care to invent). Even GET/PUT could use BASR, AFAIK, unless they too are using the BALR to detect AMODE. Which ought to be documented, if true. /smallrant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Tuesday, February 10, 2009 11:22 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler Question Edward Jaffe wrote: ... My programs use base registers only for constants, literals and working storage--not code. For more information on this topic, see http://ew.share.org/proceedingmod/abstract.cfm?abstract_id=17758 Thanks Ed, that is a very helpful presentation. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On 9 Feb 2009 15:33:19 -0800, in bit.listserv.ibm-main you wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ivan Warren Sent: Monday, February 09, 2009 5:23 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler Question Hopefully.. BAL/BALR will still be around.. It's been around since S/360 and it's here to stay. That's the power of the architecture.. Please.. find *ONE* single architecture that's still capable of running programs written 45 years ago ! SNIP Discussed this very thing with a person who used to work on Burroughs systems. Seems that UNISYS systems that are patterned after the Burroughs machines are able to run programs that old. Not sure about the UNIVAC side of the house. Seems that the BUNCH had a common idea at some point of protecting the investment that their clients made in software. Thsey are able to run programs for which there is source in one of the higher level languages (the B5000, B5500, B6500, etc. series machines operating system was written in Algol). Various upgrades have required recompiles. On the other hand, COBOL 74 is still supported for that series of machines which I believe is now the A series. (BUNCH - Burroughs Univac Ncr Cdc Honeywell -- if I remember correctly). Regards, Steve Thompson PS. BAS and BASR were implemented on the S/360-20. Because it only had 16 bit registers, not the full 32 of its bigger siblings. -- Opinions posted by this poster may not be those of poster's employer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On Mon, 9 Feb 2009 12:19:53 -0800, Don Russell russell@gmail.com wrote: BAL was pretty much obsolete when IPM came into existance. Unless of course your code had to run on an old box. I have not come across an instance yet when I needed BAL, and often use OPSYN to map BAL/R to BAS/R. If I REALLY need BAL/R, I'll code a DC X'45' or DC X'05' and add a comment saying I really, really need BAL/R here... I have a very vague memory of one subroutine which was written to be sensitive to whether it was invoked via a BAL or a BALR instruction. It looked at the ILC in the link register and set a flag depending on whether the ILC was 1 (BALR) or 2 (BAL). Of course, it only worked in AMODE(24), so it not really very useful anymore. -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
BAL was pretty much obsolete when IPM came into existance. Unless of course your code had to run on an old box. I have not come across an instance yet when I needed BAL, and often use OPSYN to map BAL/R to BAS/R. If I REALLY need BAL/R, I'll code a DC X'45' or DC X'05' and add a comment saying I really, really need BAL/R here... I would also opt for the immiediate-type instructions instead of referencing separate storage locations... i.e. LHI R5,L'BUFFER or LHI R6,-2 They're faster because they don't require additional memory fetches... and they're nicer because if you look at a dump or object code, you can see the operand right in the instruction. In many cases their use eliminates literals. I favor the branch-relative instructions (Jxxx mnemonics) where possible to reduce base register needs (sometimes) and, I suppose they're faster because they simply add the displacement to the currect PSW without all that adding, checking if index or base reg are zero etc. Don On Fri, Feb 6, 2009 at 9:43 AM, Ward, Mike S mw...@ssfcu.org wrote: Hello, all I have a question. I was just looking through the principle of ops guide on an instruction I had a question on and noticed a BAS instruction. I started reading about it and noticed that it said we should use the BAS, BASR type of instructions instead of the BAL and BALR types. I won't bore you with the details. My question is: Is there a list of recommended instructions that we should be using instead of the old instructions we had been using? == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On Mon, Feb 9, 2009 at 12:38 PM, John McKown joa...@swbell.net wrote: On Mon, 9 Feb 2009 12:19:53 -0800, Don Russell russell@gmail.com wrote: BAL was pretty much obsolete when IPM came into existance. Unless of course your code had to run on an old box. I have not come across an instance yet when I needed BAL, and often use OPSYN to map BAL/R to BAS/R. If I REALLY need BAL/R, I'll code a DC X'45' or DC X'05' and add a comment saying I really, really need BAL/R here... I have a very vague memory of one subroutine which was written to be sensitive to whether it was invoked via a BAL or a BALR instruction. It looked at the ILC in the link register and set a flag depending on whether the ILC was 1 (BALR) or 2 (BAL). Of course, it only worked in AMODE(24), so it not really very useful anymore. That sounds like the subroutine was trying to be bi-modal, and probably used BSM to return. If it were called via BAL, the addressing mode bit in the return register is not reliable for determining address mode when the caller is in 24 bit mode. BAL sets the two high order bits of the regsiter to B'10', an ILC of 2. However, if the caller were in 24 bit mode, a BSM Rx would then incorrectly set the amode to 31 because the high-order bit is on. i.e. BSM may be used to return from calls via BAS, BASR, BASSM and BALR when the caller is in either 24 or 31 bit mode, but from BAL only if the caller is in 31 bit mode. BAL and BALR still work in 31 bit mode, they just behave differently than in 24 bit mode. (which is one of the reasons to stop using it). If all you care about is the address following BAL/BALR, AMODE doesn't matter. If you care about the linkage information BAL sets in 24 bit mode, then yes, you need to update your code to use IPM if you want it to work in 31 (or 64) bit mode. Don -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Hopefully.. BAL/BALR will still be around.. It's been around since S/360 and it's here to stay. That's the power of the architecture.. Please.. find *ONE* single architecture that's still capable of running programs written 45 years ago ! --Ivan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ivan Warren Sent: Monday, February 09, 2009 5:23 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler Question Hopefully.. BAL/BALR will still be around.. It's been around since S/360 and it's here to stay. That's the power of the architecture.. Please.. find *ONE* single architecture that's still capable of running programs written 45 years ago ! SNIP Discussed this very thing with a person who used to work on Burroughs systems. Seems that UNISYS systems that are patterned after the Burroughs machines are able to run programs that old. Not sure about the UNIVAC side of the house. Seems that the BUNCH had a common idea at some point of protecting the investment that their clients made in software. (BUNCH - Burroughs Univac Ncr Cdc Honeywell -- if I remember correctly). Regards, Steve Thompson PS. BAS and BASR were implemented on the S/360-20. Because it only had 16 bit registers, not the full 32 of its bigger siblings. -- Opinions posted by this poster may not be those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On Mon, Feb 9, 2009 at 3:23 PM, Ivan Warren i...@vmfacility.fr wrote: Hopefully.. BAL/BALR will still be around.. It's been around since S/360 and it's here to stay. That's the power of the architecture.. Please.. find *ONE* single architecture that's still capable of running programs written 45 years ago ! I agree. I'm not advocating that BAL/BALR be dropped from the instruction set. I'm advocating that people stop using them in new/updated code. BC mode PSWs are no longer supported, so if you are still running ACP 9 or TPF 1.0 you have some old hardware indeed. ;-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Don Russell wrote: BC mode PSWs are no longer supported, so if you are still running ACP 9 or TPF 1.0 you have some old hardware indeed. ;-) The fact is.. A z/Arch PSW is a BC mode PSW ;) (E bit is 0 !) --Ivan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Don Russell wrote: I agree. I'm not advocating that BAL/BALR be dropped from the instruction set. I'm advocating that people stop using them in new/updated code. IBM is scraping the bottom of the barrel looking for ways to improve performance. One way would be to offload processing for older, redundant instructions or functions to millicode. Indeed, there was even some talk a while ago about possibly converting BALR (specifically the parts of it that set the upper byte in 24-bit mode) to millicode in order to save some System z chip real estate. I haven't coded a BALR for program linkage in decades. Up until a few years ago, I still used it on occasion to sense the current AMODE. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Edward Jaffe wrote: I haven't coded a BALR for program linkage in decades. Up until a few years ago, I still used it on occasion to sense the current AMODE. And I still use 'BALR' because most of my work still involves 24 AMODE/RMODE code ;) --Ivan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On Mon, Feb 9, 2009 at 3:40 PM, Ivan Warren i...@vmfacility.fr wrote: Don Russell wrote: BC mode PSWs are no longer supported, so if you are still running ACP 9 or TPF 1.0 you have some old hardware indeed. ;-) The fact is.. A z/Arch PSW is a BC mode PSW ;) (E bit is 0 !) Well, good luck with your SIO instructions there. ;-) I think your argument is what might be called a straw man. Pre-ESA the BC/EC mode was used to change between 360 and 370 mode. 360 mode is gone now, though I suppose some 360 applications would continue to run. But not programs that depend on the architecture. SIO vs SSCH for example. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Don Russell wrote: Well, good luck with your SIO instructions there. ;-) I said BC mode.. Never said Pre-XA ! (all I said is that a z/Arch PSW is no longer an EC mode PSW since the E bit in the PSW is 0 in z/Arch (lest you want an early Specification Exception to occur)) (However, some virtualization solutions with 370ACCOM will allow SIOs !) --Ivan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On Mon, Feb 9, 2009 at 3:53 PM, Ivan Warren i...@vmfacility.fr wrote: And I still use 'BALR' because most of my work still involves 24 AMODE/RMODE code ;) BAS/BASR work fine in 24 bit mode too. Stop living in the past. ;-) (Just teasing) Do you use the linkage information in the high byte? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Don Russell wrote: BAS/BASR work fine in 24 bit mode too. Stop living in the past. ;-) (Just teasing) Do you use the linkage information in the high byte? I *HAVE* to live in the past.. S/370 to us is the only option. The powers that be leave us no choice ! --Ivan (If you're wondering about the cryptic message above, do not hesitate to ask me) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Ivan Warren wrote: Please.. find *ONE* single architecture that's still capable of running programs written 45 years ago ! Babbage's Analytical Engine? G Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Ivan Warren wrote: Edward Jaffe wrote: I haven't coded a BALR for program linkage in decades. Up until a few years ago, I still used it on occasion to sense the current AMODE. And I still use 'BALR' because most of my work still involves 24 AMODE/RMODE code ;) Why not BASR? You mean you actually *want* to worry about the ILC, condition code and program mask in the upper byte? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Gerhard Postpischil wrote: Babbage's Analytical Engine? G ok.. lemme rephrase this ! Is there any package - Besides Ada Lovelace's running on Babbage machine - that can run today on a +45 Year old machine :P --Ivan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
On Mon, 9 Feb 2009 14:24:12 -0800, Don Russell wrote: That sounds like the subroutine was trying to be bi-modal, and probably used BSM to return. If it were called via BAL, the addressing mode bit in the return register is not reliable for determining address mode when the caller is in 24 bit mode. BAL sets the two high order bits of the regsiter to B'10', an ILC of 2. However, if the caller were in 24 bit mode, a BSM Rx would then incorrectly set the amode to 31 because the high-order bit is on. i.e. BSM may be used to return from calls via BAS, BASR, BASSM and BALR when the caller is in either 24 or 31 bit mode, but from BAL only if the caller is in 31 bit mode. I did something like that in the Bad Old Days when access methods needed to be called in 24-bit mode. IIRC (vaguely): Entry Code: STM BALR 0,0 LTR 0,0 * if entered in 31-bit mode, BSM to enter 24-bit mode. * if entered in 24-bit mode, clear the top bit of R14 * in the RSA. Exit code: LM LTR R14,R14 BNMR R14 BSMR R14 ... runs in 24 bit mode on either architecture; never issues a BSM to cause an instruction exception on 370. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
Ivan Warren wrote: Don Russell wrote: BAS/BASR work fine in 24 bit mode too. Stop living in the past. ;-) (Just teasing) Do you use the linkage information in the high byte? I *HAVE* to live in the past.. S/370 to us is the only option. The powers that be leave us no choice ! --Ivan (If you're wondering about the cryptic message above, do not hesitate to ask me) Well, I'm curious. Tell me. Off-list if you prefer. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler Question
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ivan Warren Sent: Monday, February 09, 2009 6:30 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler Question Gerhard Postpischil wrote: Babbage's Analytical Engine? G ok.. lemme rephrase this ! Is there any package - Besides Ada Lovelace's running on Babbage machine - that can run today on a +45 Year old machine :P SNIP That would possibly be MVS 3.8J. I'm not sure if DOS/360 is still available. The Hercules crowd would know about that. I think someone still has a S/370 Basic copy of WYLBUR, but I'm not sure about that either. The IESRPG for OS/MVT is still available (RPG not RPGII). Or did I miss what you are getting at still? Regards, Steve Thompson -- Opinions expressed by poster may not reflect poster's employer's opinions. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
In a recent note, Shmuel Metz (Seymour J.) said: Date: Tue, 19 Dec 2006 19:36:40 -0500 I've written programs where the lower bound was negative. Yes, the code was clearer that way than it would have otherwise been. Heck, I've written programs in Rexx and awk (others might use perl) where the subscripts aren't even numeric. And the code was much clearer that way than it would have otherwise been. (Except to programmers who have never before encountered the construct.) -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: [SPAM] Re: assembler question (strong typing)
In [EMAIL PROTECTED], on 12/08/2006 at 10:30 AM, Howard Brazee [EMAIL PROTECTED] said: Sure for non-programmers indices start off with 1 - most of the time. But sometimes they start off with 1001. I've written programs where the lower bound was negative. Yes, the code was clearer that way than it would have otherwise been. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
[SPAM] Re: assembler question (strong typing)
In [EMAIL PROTECTED], on 11/22/2006 at 08:30 AM, John R. Ehrman (408-463-3543 T/543-) said: I vaguely remember a QUAL or HEAD pseudo-op. Shmuel, do you have any references? C28-6392-4 IBM 7090/7094 IBSYS Operating System Version 13 Macro Assembler (MAP) Language Or know of any web sites that might have scanned the manual(s)? I'd suggest that John Ehrman must have a copy, except that you *are* John Ehrman ;-) Gerhard? Could you scan your copy? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
[SPAM] Re: assembler question (strong typing)
In [EMAIL PROTECTED], on 11/21/2006 at 08:35 AM, Paul Gilmartin said: PL/I? PL/I defaults to a lower bound of 1 but allows the lower bound to be negative. Yes, that is useful. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
[SPAM] Re: assembler question (strong typing)
In [EMAIL PROTECTED], on 11/21/2006 at 12:01 AM, Joel C. Ewing said: CDC6000 Assembler (COMPASS?) CDC used the name COMPASS for each of its assemblers, including the one for the 6600. Similarly it recycled the name SCOPE for its operating systems. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
At 08:55 -0700 on 11/21/2006, Paul Gilmartin wrote about Re: assembler question (strong typing): I yield to your expertise. Could it assume values other than 0 or 1? Could you mix arrays with different bases in the same program? I have a vague impression that PL/I goes one step further. When you define an array, you define the lower and upper bounds (l:h) with only upper (ie: number of elements) required. Thus you could define a 10 element array that goes from element 5 to 14. In addition it does bounds checking (this might be optional) with an error being raised if, for example, index5 or index14 gets used to access the above array. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
Charles Mills wrote: Where did John Ehrman write that? I didn't receive the e-mail and it's not in the archives (that I find). I'd like to read the entire note. Over on the IBM Assembler-list. Kind regards, -Steve Comstock Imposing one's perhaps parochial episteme is a lovely turn of phrase but it's a straw man. No one has proposed an imposition; I have proposed an option. It's no more an imposition than any other option that someone may choose not to use. Nor for that matter have I called its lack a deficiency. Saying it would be nice if my wife cooked a steak for dinner is not to say that she is deficient until or unless she does so. I disagree that macros are the answer. Macros are wonderful things and I have written many of them. However: - It is hard for me to picture a macro that would solve the problem of giving a warning if a halfword instruction referenced a field defined as a fullword -- unless you suppose writing an entire language with the macros (which can be done, and might be a good thing, but it's not the same thing). - Macros introduce another whole layer of possible errors. A programmer looking for an error must consider not only whether the source code as written is in error, but also whether the macro might be in error. (This is especially true for home-grown macros.) - Most importantly, macros -- if the program is to be maintained -- must be enhanced, supported, and documented. Any competent assembler programmer who may pick up my code knows what an LH does. Will s/he know what MILLSMAC FUNC=GETSTOR does? Will s/he know how to maintain it or modify it? Far better to have an optional (and usually silent) enhancement to the assembler's processing of LH. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of john gilmore Sent: Tuesday, November 21, 2006 5:51 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: assembler question (strong typing) John Ehrman writes (of strong typing): I know of no HLL that can do this. With macros, it's easy. and this of course is the point. Less time spent lamenting putative, and always controversial, deficiencies of the HLASM and more time spent writing macros that embody and implement their writer's views of how it should behave differently would be highly desirable. One's own macros may do what one wants them to do witrhout imposing one's own perhaps parochial episteme on others. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
IBM's and STSC's APL had a system variable called quadIO (cannot display a quad on this keyboard) which could be assigned a 0 or 1 to dynamically switch from 0-based to 1-based addressing. Note this didn't actually change the array, it just changed the coordinate system. A wonderful language! Could it assume values other than 0 or 1? No. As the name suggested, it simply changed the interpretation of the origin used for indexing expressions. The only valid values are 0 and 1. I think []IO was defined to be a Boolean scalar, which would have limited the assignment values to 0 or 1 anyway. I've long since forgotten, but I suspect you'd get a domain error if you tried to assign any other value. Could you mix arrays with different bases in the same program? It had nothing to do with the arrays themselves. They stayed the same. All that []IO did was change the interpretation of the index expression. Basically it boiled down to whether you considered the first element in the array to be index zero or index one. For any subscripted access to an array, the system would subtract the value of []IO from each subscript and multiply the result by the element size to obtain the offset of the element within the array - logically anyway. You could switch between 0 and 1 on a statement by statement basis according to the needs of the application, but that would probably be considered bad form. Changing []IO could have astonishing results downstream and upstream, so in most cases where you would want to use a different value you would either specify []IO as a local variable within that function, or save/restore its value before/after using a different index base. APL is a language where typing was implicit, but could be changed on the fly and where all variables had names and the names had either global scope (same value anywhere in the workspace) or local scope (within a function and anything called by that function.) Once a locally scoped name was encountered, that definition took precedence until either another local scope was encountered, or the original function that declared it to be local, ended. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
John Ehrman writes (of strong typing): I know of no HLL that can do this. With macros, it's easy. and this of course is the point. Less time spent lamenting putative, and always controversial, deficiencies of the HLASM and more time spent writing macros that embody and implement their writer's views of how it should behave differently would be highly desirable. One's own macros may do what one wants them to do witrhout imposing one's own perhaps parochial episteme on others. John Gilmore Ashland, MA 01721-1817 USA _ View Athletes Collections with Live Search http://sportmaps.live.com/index.html?source=hmemailtaglinenov06FORM=MGAC01 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
Where did John Ehrman write that? I didn't receive the e-mail and it's not in the archives (that I find). I'd like to read the entire note. Imposing one's perhaps parochial episteme is a lovely turn of phrase but it's a straw man. No one has proposed an imposition; I have proposed an option. It's no more an imposition than any other option that someone may choose not to use. Nor for that matter have I called its lack a deficiency. Saying it would be nice if my wife cooked a steak for dinner is not to say that she is deficient until or unless she does so. I disagree that macros are the answer. Macros are wonderful things and I have written many of them. However: - It is hard for me to picture a macro that would solve the problem of giving a warning if a halfword instruction referenced a field defined as a fullword -- unless you suppose writing an entire language with the macros (which can be done, and might be a good thing, but it's not the same thing). - Macros introduce another whole layer of possible errors. A programmer looking for an error must consider not only whether the source code as written is in error, but also whether the macro might be in error. (This is especially true for home-grown macros.) - Most importantly, macros -- if the program is to be maintained -- must be enhanced, supported, and documented. Any competent assembler programmer who may pick up my code knows what an LH does. Will s/he know what MILLSMAC FUNC=GETSTOR does? Will s/he know how to maintain it or modify it? Far better to have an optional (and usually silent) enhancement to the assembler's processing of LH. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of john gilmore Sent: Tuesday, November 21, 2006 5:51 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: assembler question (strong typing) John Ehrman writes (of strong typing): I know of no HLL that can do this. With macros, it's easy. and this of course is the point. Less time spent lamenting putative, and always controversial, deficiencies of the HLASM and more time spent writing macros that embody and implement their writer's views of how it should behave differently would be highly desirable. One's own macros may do what one wants them to do witrhout imposing one's own perhaps parochial episteme on others. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
On Sun, 19 Nov 2006 02:47:32 -0500 Gerhard Postpischil [EMAIL PROTECTED] wrote: :Charles Mills wrote: : You could do some of that with labeled USINGs. :Perhaps, but not enough to handle the requirement. When you are :combining two (or more) programs, frequently the labels will :have duplications, not just the variables. :Back in the MVT days, SVCs had to be chopped up so that each :load would fit into a transient area. With later systems, the :requirement for built-in TTRs to subsequent loads has been :removed, but except for the ones completely rewritten, there are :still multiple modules that could and probably should be :combined into single modules. For these, the variable names in :the overlays generally refer to the same fields in control :blocks, but the labels conflict. While there are some SVCs that :should not be combined (SVC 34 comes to mind), some such as :19/22 might yield enough performance improvements to justify the :work. I wonder how much performance improvement can be done by reducing the code path for OPEN. OPEN has to access the media to read labels, after all. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
In response to my strictures against strong typing Clark Morris wrote: As someone who has made great use of the COBOL REDEFINES option, I don't think that strong typing would necessarily be an impediment to writing operating system code. I wanted optional flagging because of people with your point of view. Coming from a COBOL background where changes in the data definition are automatically accommodated, I believe that flagging can reduce inadvertent errors. Also making the operation match the data definition can reduce confusion for the person who inherits the assembler code. I am not sure just how to react to this, except to acknowledge that we are all creatures of our experience, which is often very different and in consequence of which we often see the world very differently too. There are, I suppose, two polar programming postures. The first is move-orient[at]ed, compile-time bound, and synchronous. The second is list- and pointer-orient[at]ed, execution-time bound, and asychronous. I have often marvelled at the---in my view entirely misplaced or, better, mistimed---radical ingenuity embodied in COBOL REDEFINES and analogous constructs in other SLPLs. (Both C and PL/I can be and now often are written as a species of COBOL with semicolons.) COBOL now supports what it calls address modifications and the rest of us call substring operations, and the availability of execution-time substring operations entirely eliminates the need for compile-time REDEFINES operations. Predictably, however, REDEFINES continue to be used heavily; and the use of address modification is still exiguous. At my advanced age I have lost any messianic zeal I may once have had to convert experienced programmers who think in and write move-orient[at]ed idioms to the use of list- and pointer-orient[at]ed ones instead, not least because such conversions are anyway all but impossible; but I do find attempts to introduce COBOL-like assembly-time constraints into the HLASM very disagreeable. John Gilmore Ashland, MA 01721-1817 USA _ All-in-one security and maintenance for your PC. Get a free 90-day trial! http://clk.atdmt.com/MSN/go/msnnkwlo005002msn/direct/01/?href=http://clk.atdmt.com/MSN/go/msnnkwlo005001msn/direct/01/?href=http://www.windowsonecare.com/?sc_cid=msn_hotmail -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Saturday, November 18, 2006 8:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: assembler question (strong typing) /snip/ I pretty much agree, though I'm somewhat uncomfortable with further overloading USING. It's bursting at the seams with labelled and dependent USINGs. And how would this work with the new-fangled baseless code, particularly in the case discussed recently where code from two different sources is merged with an editor or with COPY? /snip/ -- gil I had a subroutine with ranged USING to prevent based references beyond the bounds of the subroutine. I converted the subroutine from based branch to relative branch. Then I copy-pasted the subroutine to another location in the same CSECT, and manually changed the branch target labels. The new subroutine also had a ranged USING. Everything assembled RC=0. Upon perusal of the assembly listing, I noticed that some of the relative branches in the new subroutine were referring to labels in the old subroutine outside of the ranged USING. The relative branches were ignored by the ranged USING, because there were no base registers to test in the relative branch instructions. Rather than try to dig around in the assembler documentation to find a way to generate a warning/error message for this situation, I just converted the routines back to RX-type branches. Problem solved. I doubt there is any significantly measurable difference in the performance between RX-type and relative branch instructions. Jeffrey D. Smith Principal Product Architect Farsight Systems Corporation 700 KEN PRATT BLVD. #204-159 LONGMONT, CO 80501-6452 303-774-9381 direct 303-484-6170 FAX http://www.farsight-systems.com/ comments are invited on my encryption project -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
Jeffrey D. Smith wrote: I doubt there is any significantly measurable difference in the performance between RX-type and relative branch instructions. There are some now. There will be more. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
John, I'm a pointer guy, not an MVC guy. I'm not advocating MVCing fullwords to halfwords before LHing them. I'm saying if a 32-bit field is really a structure the first 16 bits of which are a 16-bit integer, then I ought to define it that way, not as a 32-bit integer. If it's both depending on the circumstances, then I ought to define it both ways. And it would be nice if the assembler had an option to warn those of us who would appreciate being warned if we violated the above. Not a constraint, but an option. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of john gilmore Sent: Sunday, November 19, 2006 6:37 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: assembler question (strong typing) ... There are, I suppose, two polar programming postures. The first is move-orient[at]ed, compile-time bound, and synchronous. The second is list- and pointer-orient[at]ed, execution-time bound, and asychronous. ... because such conversions are anyway all but impossible; but I do find attempts to introduce COBOL-like assembly-time constraints into the HLASM very disagreeable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
On Sun, 19 Nov 2006 09:02:47 -0700, Jeffrey D. Smith [EMAIL PROTECTED] wrote: I had a subroutine with ranged USING to prevent based references beyond the bounds of the subroutine. By experiment a while back, a ranged using properly prohibited references above the top of the range, but allowed references below the bottom of the range. Is this still true, or has it been fixed? -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
On Sat, 18 Nov 2006 20:12:23 +, john gilmore [EMAIL PROTECTED] wrote: Moreover, it must be conceded that analogues of such PL/I constructs as declare phantom_cs character(32767) based(pcsp) ; pcsp = addr(whatever) ; and addr(whatever)-phantom_cs . . . ; which permit any sequence of [here at most 32767] storage locations to be viewed as a character string, are now grudgingly available in C too; but the much more commonly used C asterisk notation declares a pointer to an instance of a particular scalar or structure. C is more much strongly typed than PL/I; and Dennis Ritchie, its designer, has said more than once that he views this as desirable. Unfamiliar with PL/I as I am, I see little practical difference between the above and the equivalent (as far as I understand the PL/I): typedef char[32767] phantom_cs; ... ... (phantom_cs) whatever ...; That said, I loathe C's reliance on null-terminated strings. (Some claim, with some validity, that this is more a feature of the Standard Function Library than of the language proper. But, practically, the two are inseparable.) This makes it impossible to abstract a substring from a static string without allocating storage, diminishing the usefulness of the constructs in the example. The null-termination convention has cross-infected the programming interfaces to most C kernels. In contrast, the BPX1* callable interfaces have boldly and laudably eschewed null-terminated strings. So, in answer to Bob Shannon's question: Linkname: IBM-MAIN archives -- August 2006 (#278) http://bama.ua.edu/cgi-bin/wa?A2=ind0608L=ibm-mainD=1amp;O=DP=32264 ... you may add one to the count. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler question
At 11:39 -0300 on 10/27/2006, Shmuel Metz (Seymour J.) wrote about Re: Assembler question: 2. You you can shorten that by offsetting the translate table, e.g., STR0,IN UNPK OUT(9),IN(5) TROUT(8),TRTAB-C'0' TRTAB DCC'0123456789ABCDEF' taking care to prevent TRTAB from being within the first 240 bytes of the csect. Jumping into thread late - Making the code STR0,IN UNPK OUT(9),IN(5) NCOUT(8),=8X'0F' --- Alter Fx...Fx to 0x...0x TROUT(8),TRTAB TRTAB DCC'0123456789ABCDEF' fixes the offset issue for the TRTAB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
Gee, in my impression, and in my expectations, a USING range check is just that: a check to make sure that the displacement in within the limits specified. I would not expect it to have any effect on relative jumps. Yes, local-scope labels would be a wonderful thing, but that's a *big* enhancement, and in any event, not what the displacement range check does (although it could be used in limited circumstances to provide a limited amount of locality checking). I use the range check for an uh-oh, you're in danger of running out of your 4096 bytes of addressability check. Does anyone know of another intended use? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Sunday, November 19, 2006 12:52 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: assembler question (strong typing) On Sun, 19 Nov 2006 09:02:47 -0700, Jeffrey D. Smith [EMAIL PROTECTED] wrote: I had a subroutine with ranged USING to prevent based references beyond the bounds of the subroutine. By experiment a while back, a ranged using properly prohibited references above the top of the range, but allowed references below the bottom of the range. Is this still true, or has it been fixed? -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
On Sun, 19 Nov 2006 13:39:06 -0800, Charles Mills [EMAIL PROTECTED] wrote: Gee, in my impression, and in my expectations, a USING range check is just that: a check to make sure that the displacement in within the limits specified. Yes. I encountered a problem when I built a template for a control block in reentrant storage and copied it into part of a work area in acquired storage. I used a relative using with an upper bound to map the proper part of the acquired storage, and put an upper bound on the CSECT base register to exclude tne template. But HLASM warned (incorrectly, IMO) that part of the CSECT could be addressed by both the CSECT base register and the DSECT base register. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
FWIW I solve this problem by using a separate CSECT for a GETMAIN storage template. Wastes a load to address the CSECT, but you only need to do it once. Then you can use the CSECT definition as though it were a DSECT for addressing the GETMAIN storage. Real neat and clean. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Sunday, November 19, 2006 1:58 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: assembler question (strong typing) On Sun, 19 Nov 2006 13:39:06 -0800, Charles Mills [EMAIL PROTECTED] wrote: Gee, in my impression, and in my expectations, a USING range check is just that: a check to make sure that the displacement in within the limits specified. Yes. I encountered a problem when I built a template for a control block in reentrant storage and copied it into part of a work area in acquired storage. I used a relative using with an upper bound to map the proper part of the acquired storage, and put an upper bound on the CSECT base register to exclude tne template. But HLASM warned (incorrectly, IMO) that part of the CSECT could be addressed by both the CSECT base register and the DSECT base register. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Sunday, November 19, 2006 2:39 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: assembler question (strong typing) Gee, in my impression, and in my expectations, a USING range check is just that: a check to make sure that the displacement in within the limits specified. I would not expect it to have any effect on relative jumps. Yes, local-scope labels would be a wonderful thing, but that's a *big* enhancement, and in any event, not what the displacement range check does (although it could be used in limited circumstances to provide a limited amount of locality checking). I use the range check for an uh-oh, you're in danger of running out of your 4096 bytes of addressability check. Does anyone know of another intended use? Charles /snip/ My ranged USING is for position-independent subroutines that I copy into common storage. I don't want my subroutine code looking past its own boundary into foreign storage. Jeffrey D. Smith Principal Product Architect Farsight Systems Corporation 700 KEN PRATT BLVD. #204-159 LONGMONT, CO 80501-6452 303-774-9381 direct 303-484-6170 FAX http://www.farsight-systems.com/ comments are invited on my encryption project -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler question
On 13 Nov 2006 06:48:39 -0800, in bit.listserv.ibm-main you wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Clark Morris Sent: Friday, November 10, 2006 4:47 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Assembler question On 7 Nov 2006 10:34:33 -0800, in bit.listserv.ibm-main you wrote: snip Back in the 1980's or early 1990's, with the help of John Ehrman I submitted a number of requirements at SHARE, on of which was for optional flagging of all operand mismatches including length matches, LH of a fullword, etc. Even though they were all rejected at the time, many of them later made it into what became HLASM. Maybe it is my COBOL background but the idea that the operation and the data definition should match in most cases is one that the assembler should encourage. In regard to another thread, the awkwardness of coding reentrant code and the mediocre support for it means that for main programs, I don't bother. I do for exits and subroutines. snip I think what you are (or were) suggesting is strong typing for ALC (OK, I can hear it coming now, that's why we always did it in UPPER CASE and the like) and enforcement thereof. However, some of us have written code that makes use of nuances that would cease to (1) assemble correctly, and more importantly (2) not execute correctly. These nuances are not wrong or illegal, but made use of generation capability of the assembler and/or documented side effects of instructions. As an example, the idea of a LH against a fullword may be done because in some case it is known that only the high order nibbles of a fullword are valid for certain operations (logical or arithmetic). While you and I might say that this should have been done with ICM, or the fullword should have a secondary definition (using ORG perhaps), the code works correctly using LH (perhaps it even required the high-order bit propagation for negativity). This is why I made the flagging optional based on a PARM. While some may have taken advantage of the nuances, I believe that making sure the operation and the data description match. The lack of IBM supplied macros that would automatically take into account the data description is in my opinion one of the shortcomings of the way IBM has provided Assembler. If you were to add strong typing to the assembler with enforcement of typing, then that code will not assemble, or the assembler will presume that a Load was meant -- look-out! We could continue this with various instructions. And yes, I've made the rookie error of L instead of LA (and vice versa), MVC instead of MVI, etc. But you learn and you think in ALC -- COBOL code that I have written at times looked like someone trying to strangle the compiler to get what they wanted. But as I said in a prior posting, ALC is a low level language. So perhaps those of us that have programmed in it for years just think quite differently (I started on S/360 machines). Don't get me wrong, I am not interested in GATE/TEST coding -- Macrocode at Amdahl was close enough to the bare metal. It may be low level, but does it also have to be brain-dead? Later, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
Clark Morris writes of the HLASM: It may be low level, but does it also have to be brain-dead? Characterizing the HLASM as brain-dead because it does not do strong typing gives polemical expression to one point view. Other, different views are possible; they are indeed entertained by experienced people. I, for one, loathe strong typing. In my own code I do data-type punning routinely, and I should not wish to see the HLASM converted into as C-lilke language that made this gratuitously difficult. The whole question whether the HLASM or any assembly language is now a suitable vehicle for use by novices is, I think, an open one. Let them write C or Pascal! Devoting any of the very limited resources available for maintaining and enhancing the HLASM to childproofing it would come far down on my personal wish list for it. John Gilmore Ashland, MA 01721-1817 USA _ Talk now to your Hotmail contacts with Windows Live Messenger. http://clk.atdmt.com/MSN/go/msnnkwme002001msn/direct/01/?href=http://get.live.com/messenger/overview -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of john gilmore
Sent: Saturday, November 18, 2006 8:10 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: assembler question (strong typing)
Clark Morris writes of the HLASM:
It may be low level, but does it also have to be brain-dead?
Characterizing the HLASM as brain-dead because it does not do strong
typing
gives polemical expression to one point view. Other, different views are
possible; they are indeed entertained by experienced people.
I, for one, loathe strong typing. In my own code I do data-type punning
routinely, and I should not wish to see the HLASM converted into as C-
lilke
language that made this gratuitously difficult.
The whole question whether the HLASM or any assembly language is now a
suitable vehicle for use by novices is, I think, an open one. Let them
write C or Pascal! Devoting any of the very limited resources available
for
maintaining and enhancing the HLASM to childproofing it would come far
down
on my personal wish list for it.
John Gilmore
Greetings,
Systems/C by www.dignus.com generates HLASM output, which is subsequently
processed with an HLASM-compatible assembler. At any point, the C source
code can drop down to assembler using the __asm {} block. There are other
features for controlling register usage, using 64-bit addresses and
ALET-qualified pointers, reentrant and non-reentrant. Systems/C programs can
be designed to run in task mode, SRB mode, cross memory code.
Such a compiler is a very educational tool for showing C programmers how
the C language idioms are translated directly into assembler source code.
The shortage of good assembler programmers can be mitigated by hiring good
C programmers and using Systems/C as a development and educational tool. As
the C programmers become educated in mainframe assembler by looking at the
generated assembler, they can write assembler-only subroutines and easily
call those routines directly from their Systems/C programs. It's a great way
to ease into mainframe assembler programming from a higher level language.
Also, a good set of debugging tools is vital for understanding the
difference between what you thought you wrote compared to what you
actually wrote. Go to www.colesoft.com for state of the art debugging
tools.
2 cents worth. Your mileage may vary.
Jeffrey D. Smith
Principal Product Architect
Farsight Systems Corporation
700 KEN PRATT BLVD. #204-159
LONGMONT, CO 80501-6452
303-774-9381 direct
303-484-6170 FAX
http://www.farsight-systems.com/
comments are invited on my encryption project
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
In a recent note, john gilmore said: Date: Sat, 18 Nov 2006 15:10:14 + I, for one, loathe strong typing. In my own code I do data-type punning routinely, and I should not wish to see the HLASM converted into as C-lilke language that made this gratuitously difficult. Certainly data-type punning is possible in C; entire oerating systems have been written in C, which would be impossible otherwise. (What prevalent operating systems are written in PL/I?). And one programmer's gratuitously difficult might be another progammer's merely explicit? I know practically no PL/I. How is data-type punning achieved in PL/I? If it's anything less than explicit, I can't imagine that ambiguities could be avoided. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
Isn't DB2 written in PL/I? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Saturday, November 18, 2006 8:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: assembler question (strong typing) In a recent note, john gilmore said: Date: Sat, 18 Nov 2006 15:10:14 + I, for one, loathe strong typing. In my own code I do data-type punning routinely, and I should not wish to see the HLASM converted into as C-lilke language that made this gratuitously difficult. Certainly data-type punning is possible in C; entire oerating systems have been written in C, which would be impossible otherwise. (What prevalent operating systems are written in PL/I?). And one programmer's gratuitously difficult might be another progammer's merely explicit? I know practically no PL/I. How is data-type punning achieved in PL/I? If it's anything less than explicit, I can't imagine that ambiguities could be avoided. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
Paul Gilmartin wrote: In a recent note, john gilmore said: Date: Sat, 18 Nov 2006 15:10:14 + I, for one, loathe strong typing. In my own code I do data-type punning routinely, and I should not wish to see the HLASM converted into as C-lilke language that made this gratuitously difficult. Certainly data-type punning is possible in C; entire oerating systems have been written in C, which would be impossible otherwise. (What prevalent operating systems are written in PL/I?). Multics was written in PL/I Henry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
I don't find controversy with Paul Gilmartin productive, and I foreswear it from time to time, but my point here was that strong typing was inappropriate to the HLASM. In making it I chose, ill-advisedly, to cite C as strongly typed. I did not mention PL/I. Now it is true, as Paul knows, that I prefer PL/I and its dialects to C. I use it heavily for routines, often but not always throwaway ones, that I alone will use; reserving assembly language for routines that others will use, table-generation macro definitions, and the like.) Moreover, it must be conceded that analogues of such PL/I constructs as declare phantom_cs character(32767) based(pcsp) ; pcsp = addr(whatever) ; and addr(whatever)-phantom_cs . . . ; which permit any sequence of [here at most 32767] storage locations to be viewed as a character string, are now grudgingly available in C too; but the much more commonly used C asterisk notation declares a pointer to an instance of a particular scalar or structure. C is more much strongly typed than PL/I; and Dennis Ritchie, its designer, has said more than once that he views this as desirable. My reference to C was thus not inappropriate, but I regret it because it triggered Paul's here otiose reference to PL/I. John Gilmore Ashland, MA 01721-1817 USA _ Get free, personalized commercial-free online radio with MSN Radio powered by Pandora http://radio.msn.com/?icid=T002MSN03A07001 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
On 18 Nov 2006 07:10:24 -0800, in bit.listserv.ibm-main you wrote: Clark Morris writes of the HLASM: It may be low level, but does it also have to be brain-dead? Characterizing the HLASM as brain-dead because it does not do strong typing gives polemical expression to one point view. Other, different views are possible; they are indeed entertained by experienced people. I, for one, loathe strong typing. In my own code I do data-type punning routinely, and I should not wish to see the HLASM converted into as C-lilke language that made this gratuitously difficult. The whole question whether the HLASM or any assembly language is now a suitable vehicle for use by novices is, I think, an open one. Let them write C or Pascal! Devoting any of the very limited resources available for maintaining and enhancing the HLASM to childproofing it would come far down on my personal wish list for it. As someone who has made great use of the COBOL REDEFINES option, I don't think that strong typing would necessarily be an impediment to writing operating system code. I wanted optional flagging because of people with your point of view. Coming from a COBOL background where changes in the data definition are automatically accommodated, I believe that flagging can reduce inadvertent errors. Also making the operation match the data definition can reduce confusion for the person who inherits the assembler code. John Gilmore Ashland, MA 01721-1817 USA _ Talk now to your Hotmail contacts with Windows Live Messenger. http://clk.atdmt.com/MSN/go/msnnkwme002001msn/direct/01/?href=http://get.live.com/messenger/overview -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
I have written many tens if not hundreds of thousands of lines of assembler, 390, x86, and others (mostly 390). I've been giving this topic some thought ever since it came up here. I thing stronger typing, such as a warning if an LH referenced a fullword, would be a plus in the assembler. I am assuming here that it could be turned on and off, preferably with something like PUSH TYPING. I for one would turn it on. I would welcome a warning if I did an LH on a fullword, particularly in the situation where I changed a halfword to a fullword and missed making the corresponding change to one or more instructions. It would be fairly trivial (IMHO) to redefine a fullword with a halfword (in any of the at least three ways that the assembler now permits this) in situations where the LH was legitimate and intended. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
I have written many tens if not hundreds of thousands of lines of assembler, 390, x86, and others (mostly 390). May I impose on your time with a digression? The absolute WORST assembler of the lot was IV-Phase. (Anyone remember IV-Phase? Combination minicomputer and plug-compatible 3270 controller? Bunch of Fairchild refuges, AFAIR. The 3270 display buffer was in main memory, so to display something on a screen, you just had to do a move. 8-bit bytes, 24-bit words, addressable by the rightmost byte. But I digress.) The world's worst assembler: - Symbols were only 5 characters long. - But only the first three characters were significant, so STORE and STOP were the same symbol. - There was no possibility of a duplicate symbol: the assembler just did a redefinition of the symbol. So not only were STORE and STOP the same symbol, defining both did not generate an error: References to STOxx just went from referring to the field defined as STORE to the field defined as STOP. - There was no possibility of an undefined symbol. Anything you forgot to define, the assembler just made it into an EXTRN, postponing the error (hopefully!) to linkedit time. Thank you. I'm done now. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: assembler question (strong typing)
Charles Mills wrote: - There was no possibility of an undefined symbol. Anything you forgot to define, the assembler just made it into an EXTRN, postponing the error (hopefully!) to linkedit time. I always considered that to be a weakness of the 360+ assemblers. I started programming on the 704/7090/7904, and SAP, FAP, and MAP all treated undefined names as external references, which made it much easier to make internal into external subroutines, and v.v.. If John E. is lurking, there is one feature I'd really love to see - qualifiers. Suppose you wish to combine two programs that have duplicate variables - prefix each code section with a qualifying name, and the assembler correctly resolves the local references. In a way this was a precursor to the way unexposed variable names are handled in REXX (and others) procedures. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
