Re: Old Hashing Routine
In [EMAIL PROTECTED], on 06/23/2006 at 06:59 PM, Anne Lynn Wheeler [EMAIL PROTECTED] said: tss/360 (the real operating system that was suppose to be for 360/67) had a different mechanism ... moving address constants out of the program image You don't consider a PSECT to be part of the program image? IAC, TSS/360 had to do as much work relocating address constants as OS/360, it just did it a bit more dynamically. note that multics had similar issues and addressed them in similar manner. Multics had the advantage of hardware that supported indirect addressing and traps for unresolved pointers. That allowed for a much cleaner approach to dynamic loading. in any case, tss/360 had a hard time achieving market acceptance ... partially because the code implementation was significantly slowww It got better, but I recall the days when people referred to it as Tape Spinning System. -- 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: Old Hashing Routine
On Fri, 23 Jun 2006 19:26:58 -0300, Shmuel Metz (Seymour J.) shmuel+ibm- [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 06/23/2006 at 10:38 AM, Tom Marchant [EMAIL PROTECTED] said: Amdahl didn't believe in virtual memory. It seems like he would have anticipated the need for it, with the 360/67 already out, but the original design for the 470/6 (IIRC) had to be stopped while they added virtual memory support and changed the name to 470V/6. Didn't they ship one 470/6? It definitely was the machine originally announced. As I recall the first 470V went to Bernie Galler at the University of Michigan. Not that I am aware of. The second one went to U of M, as I recall. IIRC, the first went to NASA. -- 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: Old Hashing Routine
In a message dated 6/26/2006 7:34:24 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Not that I am aware of. The second one went to U of M, as I recall. IIRC, the first went to NASA. So long ago(and far away). My advisor was from Michigan and he always complained that we didn't have this and didn't have that like they did at Michigan. I don't remember them all LaPlume, TSS, Cross Assemblers. He was hardcore nuts and bolts EE and was huge on simulation. Anyway his take from those days was that UM had a huge falling out with IBM and vice versa. They didn't like this and didn't like that and ended up fixing so much that decided to write their own? More friends at Illinois confirmed, but didn't have the details. We did a cost estimate to upgrade the 158 to run TSS and it was over $4M. Nobody bought it and we converted to Sperry! Yuck thooeyCATFUR,FURPUR,MUDFLAPS -- 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: Old Hashing Routine
On Mon, 26 Jun 2006 07:34:10 -0500, Tom Marchant [EMAIL PROTECTED] wrote: On Fri, 23 Jun 2006 19:26:58 -0300, Shmuel Metz (Seymour J.) shmuel+ibm- [EMAIL PROTECTED] wrote: Didn't they ship one 470/6? It definitely was the machine originally announced. As I recall the first 470V went to Bernie Galler at the University of Michigan. Not that I am aware of. The second one went to U of M, as I recall. IIRC, the first went to NASA. At the Goddard Institute of Space Studies initially, and then we moved it down to Maryland and became the Goddard Modelling and Simulation Facility. Just think about it, we used to run multiple global weather models in the 6M of real memory that maxed out the 470/V6. You can't boot windows in that small amount of real memory. /Tom Kern -- 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: Old Hashing Routine
Thomas Kern wrote: At the Goddard Institute of Space Studies initially, and then we moved it down to Maryland and became the Goddard Modelling and Simulation Facility. Just think about it, we used to run multiple global weather models in the 6M of real memory that maxed out the 470/V6. You can't boot windows in that small amount of real memory. When I worked at the Goddard Institute, they had just upgraded to a 7094 mod II, with a whopping 32K (36 bit word) memory. Shortly before I left, they had gotten a 360/65, and build a new computer room for it. It's amazing just how much work we got out of these limited machines. 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
Re: Old Hashing Routine
On Mon, 26 Jun 2006 08:54:22 EDT, Ed Finnell [EMAIL PROTECTED] wrote: So long ago(and far away). My advisor was from Michigan and he always complained that we didn't have this and didn't have that like they did at Michigan. I don't remember them all LaPlume, TSS, snip! ... decided to write their own? More friends at Illinois confirmed, but didn't have the details. As I understand it, U of M tried TSS, but decided to write the Michigan Terminal System. MTS worked quite well. and was used at several other installations, including Wayne Stste University in Detroit, where I worked. I never worked with MTS, but they continued to run it intil the mid to late 1990s. It was the first of the mainframe operating systems that they dumped. For a time, we ran MVT under MTS on the duplex 360/67. Tom Marchant -- 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: Old Hashing Routine
In a message dated 6/26/2006 9:13:56 A.M. Central Standard Time, [EMAIL PROTECTED] writes: worked. I never worked with MTS, but they continued to run it intil the mid to late 1990s. It was the first of the mainframe operating systems that they dumped. For a time, we ran MVT under MTS on the duplex 360/67. Thanks for the update. My 22 yr old niece is a senior at WSU. I don't know what she's majoring in, but makes good grades and works at Mike's Smokehouse for spending change...She's been favorably impressed with the faculty so far. Looks they're running SCT but don't know the specifics. She was living in converted brewery but decided it was time to move when Papa John's wouldn't deliver due to 'high risk neighborhood'. Moved to Berkley with more modern appurtances but misses the hardwood floors... -- 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: Old Hashing Routine
In [EMAIL PROTECTED], on 06/26/2006 at 07:34 AM, Tom Marchant [EMAIL PROTECTED] said: The second one went to U of M, as I recall. IIRC, the first went to NASA. If UofM was 2nd then NASA was definitely first. -- 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: Old Hashing Routine
Jim Mulder wrote: The architecture scavenged two PTE bits to allow for 64mbytes of real storage. I don't think the 3033 ever supported more than 32mbytes, and I am not sure about the 3081, but there were customers running MVS/370 on the 3090 with 64mbytes of real storage. re: http://www.garlic.com/~lynn/2006m.html#27 Old Hashing Routine in past posts i've told the story both ways ... both of the unused bits by architecture allowing PTEs to address up to 2**14 4k real pages (64mbyte) or one unused bit by 3033 to support 2**13 4k real pages. I remember lots of 32mbyte 3081s but don't remember any 64mbyte 3081s. part of this is my scenario about dasd had declined in relative system performance by a factor of ten times over 10-15 yr period i.e. rest of the system resources/thruput increased by 40-50 times while dasd increased by only 4-5 times. at least by the time i release the resource manager ... 11may76, you were starting to see real storage used to compensate for system thruput being constrained by dasd performance. i had done much of the work as an undergraduate in the 60s for cp67 ... which then got dropped in the morph from cp67 to vm370 ... but then was allowed to rerelease it as the resource manager http://www.garlic.com/~lynn/subtopic.html#fairshare http://www.garlic.com/~lynn/subtopic.html#wsclock i had a comparison of cp67 360/67 configuraiton and a vm370 3081 configuration ... and observed if overall system thruput had kept pace with the cpu, the typical number of users would have gone from 80 on 360/67 to over 2000 on 30831 ... but in fact, typical 3081 configurations tended to be more like 300-400 users ... which represented the change in dasd thruput between 360/67 and 3081. this is the story about initially the san jose disk division assigned their performance group to refute the claims ... but they came back a couple weeks later and explained that i had actually understated the problem. the other issue is that ckd dasd from the 60s ... traded off i/o thruput with extended ( multi-track) searches for real memory use ... i.e. more real memory intensive tended to cache indexes to specific disk location ... while vtoc pds multi-track search spun the disk to find location. Some of the IMS ccw programs took this to the extreme with long ccw programs searching and finding fields in disk-based index structures ... which then were read and used for further searching ... all in a single channel program. i've often repeated story about being called into a large national retailer with a large complex of vs2 processor complex ... basically loosely-coupled with processors dedicated to each region. they were experience sever performance degradation. turns out they had a large application program library shared across all processors in the complex with a three (3330) cylinder PDS index. aggregate number of I/Os to (across all processors in the complex) avg. about 6.5/sec ... because they were doing avg 1.5 cylinder search of the PDS index. the multi-track search of the first cylinder at 3600rpm/19cylinders was about .3secs elapsed time (i.e. being limited to approx three application program member loads per second aggregate across all the processors in the complex). http://www.garlic.com/~lynn/subtopic.html#dasd the other place that you saw real memory compensating for dasd performance was with the emergance of rdbms in the 80s. there were arguments between STL (60s physical database) and SJR ... original relational/sql database implementation http://www.garlic.com/~lynn/subtopic.html#systemr the 60s paradigm had direct record pointers imbedded as part of the database infrastructure and exposed to application programmers. this allowed going directly from one record to the next relatively efficiently. however, there was heavy people and skill resource overhead for management of the structure. system/r abstracted away the direct pointers with the relational paradigm ... substituting internal index tree structure managed by the dbms (no longer requiring direct administrative and application support). this significantly decreased the people and skill resources needed to manage the infrastructure. however, it might take 5-6 disk reads of index structure to find the disk record pointer to the actual record needed. the other argument was that the on-disk index structure could double the physical disk space required for relational implementation vis-a-vis a 60s physical dbms implementation. what happened in the 80s was that disk space became increasingly less expensive ($$/mbyte which has now shifted $$/gbyte) and the explosion in real memory sizes allowed much of the relational index to be cached in real memory (eliminating a lot of the additional disk reads to get to the actual record). various past posts discussing the STL/SJR argument over 60s physical databases (with direct record pointers) and relational which created
Re: Old Hashing Routine
Anne Lynn Wheeler wrote: the other issue is that ckd dasd from the 60s ... traded off i/o thruput with extended ( multi-track) searches for real memory use ... i.e. more real memory intensive tended to cache indexes to specific disk location ... while vtoc pds multi-track search spun the disk to find location. Some of the IMS ccw programs took this to the extreme with long ccw programs searching and finding fields in disk-based index structures ... which then were read and used for further searching ... all in a single channel program. This reminds me of a question that you might have the answer to. The 2314 and 3330 controllers (and Memorex 3330 and 3350s) supported a Search Key and Data opcode. I used this out of curiosity to write a small card-format editor doing I/O based on sequence numbers in the data. As expected, it used little CPU time, but tied up the channel. Did anyone ever find a productive use for data search? Considering that IBM dropped it as a standard feature on the 3350, and completely on later models, I doubt it. 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
Re: Old Hashing Routine
In [EMAIL PROTECTED], on 06/22/2006 at 10:16 AM, Charles Mills [EMAIL PROTECTED] said: Was it Gene Amdahl who said the biggest mistake of the 360 architecture was the 24-bit addresses? I don't know, but it certainly shocked me, given that there were already machines with a million words of memory. It didn't take a crystal ball to forsee growing memory demand. I wouldn't call that the biggest mistake, however. When the S/360 came out virtually all of the major players had some sort of hardware address relocation, whether block relocation, paging or segmentation. Even IBM had paging in the laboratory. The use of absolute addresses shocked me more than the address size. -- 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: Old Hashing Routine
On Fri, 23 Jun 2006 11:10:59 -0300, Shmuel Metz (Seymour J.) shmuel+ibm- [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 06/22/2006 at 10:16 AM, Charles Mills [EMAIL PROTECTED] said: Was it Gene Amdahl who said the biggest mistake of the 360 architecture was the 24-bit addresses? snip! I wouldn't call that the biggest mistake, however. When the S/360 came out virtually all of the major players had some sort of hardware address relocation, whether block relocation, paging or segmentation. Even IBM had paging in the laboratory. The use of absolute addresses shocked me more than the address size. Amdahl didn't believe in virtual memory. It seems like he would have anticipated the need for it, with the 360/67 already out, but the original design for the 470/6 (IIRC) had to be stopped while they added virtual memory support and changed the name to 470V/6. -- 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: Old Hashing Routine
I agree it's a shortcoming. FWIW, My impression has always been that the hardware architects thought the base register/displacement scheme was their answer to or version of hardware relocation. Over time, though, link editor/loader relocation has seldom been a problem (except for our VSE friends, where for a long time linkedits were to a fixed address - or it was up to the program to self-relocate). We don't see lots of why don't my program adcons load correctly? questions on IBM-MAIN. That old 24-bit/31-bit continues to be a thorn in our sides - witness, for example, this thread. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.) Sent: Friday, June 23, 2006 7:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Old Hashing Routine I wouldn't call that the biggest mistake, however. When the S/360 came out virtually all of the major players had some sort of hardware address relocation, whether block relocation, paging or segmentation. Even IBM had paging in the laboratory. The use of absolute addresses shocked me more than the address size. -- 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: Old Hashing Routine
Are other people seeing re-posts, as well? This was sent yesterday, and I remember reading it. I thought it was GMAIL, so I went and emptied my inbox. This is still happening. --Original Message-- From: Jack Kelly Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To: Mainframe Discussion List, IBM ReplyTo: Mainframe Discussion List, IBM Sent: Jun 22, 2006 11:42 Subject: Re: Old Hashing Routine just a thought 1. there are numerous callable routines in icsf to (de)encrypt/hash anything, esp pin's, ie the finical services suite. even smp is into icsf hashing and w/ 1.7 you don't even need to start up icsf, i've heard 2. leave the hash routine as a separate callable load module in 24b and don't link it with the other lmod. Jack Kelly LA Systems @ US Courts x 202-502-2390 -- 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 . -teD Marching to the beat of a different flute -- 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: Old Hashing Routine
Shmuel Metz , Seymour J. wrote: I don't know, but it certainly shocked me, given that there were already machines with a million words of memory. It didn't take a crystal ball to forsee growing memory demand. I wouldn't call that the biggest mistake, however. When the S/360 came out virtually all of the major players had some sort of hardware address relocation, whether block relocation, paging or segmentation. Even IBM had paging in the laboratory. The use of absolute addresses shocked me more than the address size. 360/67 shipped with virtual memory supporting both 24-bit addressing and 32-bit addressing options (i.e. you could have 4gbyte virtual address space and used 32bit virtual addressing). 360/67 smp support also had channel director ... where all processors could address all channels. it wasn't until 3081 that you saw greater than 24-bit virtual addressing and provision for all processors in smp configuration to address all channels. 360/67 functional characteristics: http://bitsavers.trailing-edge.com/pdf/ibm/360/funcChar/A27-2719-0_360-67_funcChar.pdf before 3081, there was a real storage scenario with 3033 being approx. 4.5mips and limited to 16mbyte real storage (and 16 channels). having 3033smp (two 4.5mip processors) still limited the configuration to 16mbyte real storage. in comparision you could setup a cluster of six 4341s, approx. 1mip (six mips aggregate), each 16mbytes real storage (96mbytes aggregate), and each six channels (36 channels aggregate) for about the same money as a single 3033 processor configuration. the 16mbyte real limitation was starting represent a real system bottleneck for mvs systems so 3033 came up with a hack for supporting 32mbyte real storage. the 370 page table entry was 16bits with a 12bit page number field (for specifying a real 4k page ... 12+12 gives 24bit addressing or 16mbytes), two defined bits, and two undefined bits. the gimmick scavenged one of the undefined PTE bits to be used in real page numbers. you could now address 2**13 4k real pages ... or 32mbytes. CCW IDAL was 31bits ... show you had bits to read/write pages into/out-of 16mbytes. the problem was that all instructions were still limited to 24bit addressing (both real and virtual). you could stick virtual pages above the 16mbyte line ... but there was periodic requirement that some kernel code running in real mode had to address virtual page contents about the 16mbyte line. So there was this gimmick with a dummy virtual address space ... that you stuffed an real page number below the 16mbyte line and the desired real page number above the 16mbyte line, entered virtual address space mode and copied the virtual page above the line to the virtual page location (that was below the 16mbyte real line). misc. past posts mentioning 4341s in one way or another http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ??? http://www.garlic.com/~lynn/96.html#1 360/370 http://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life http://www.garlic.com/~lynn/99.html#7 IBM S/360 http://www.garlic.com/~lynn/99.html#36 why is there an @ key? http://www.garlic.com/~lynn/99.html#110 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes) http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes) http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element) http://www.garlic.com/~lynn/2000.html#29 Operating systems, guest and actual http://www.garlic.com/~lynn/2000.html#90 Ux's good points. http://www.garlic.com/~lynn/2000b.html#37 How to learn assembler language for OS/390 ? http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe? http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe? http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe? http://www.garlic.com/~lynn/2000d.html#7 4341 was Is a VAX a mainframe? http://www.garlic.com/~lynn/2000d.html#11 4341 was Is a VAX a mainframe? http://www.garlic.com/~lynn/2000d.html#12 4341 was Is a VAX a mainframe? http://www.garlic.com/~lynn/2000d.html#20 S/360 development burnout? http://www.garlic.com/~lynn/2000d.html#82 all-out vs less aggressive designs (was: Re: 36 to 32 bit transition) http://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation? http://www.garlic.com/~lynn/2000e.html#53 Why not an IBM zSeries workstation? http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation? http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems. Disk history...people forget http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems. Disk history...people forget http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic) http://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
Re: Old Hashing Routine
In [EMAIL PROTECTED], on 06/23/2006 at 09:13 AM, Charles Mills [EMAIL PROTECTED] said: I agree it's a shortcoming. FWIW, My impression has always been that the hardware architects thought the base register/displacement scheme was their answer to or version of hardware relocation. Indeed, but they forgot the need to adjust address constants and variables when moving things around. They should have given the software types more say in the design. -- 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: Old Hashing Routine
In [EMAIL PROTECTED], on 06/23/2006 at 10:38 AM, Tom Marchant [EMAIL PROTECTED] said: Amdahl didn't believe in virtual memory. It seems like he would have anticipated the need for it, with the 360/67 already out, but the original design for the 470/6 (IIRC) had to be stopped while they added virtual memory support and changed the name to 470V/6. Didn't they ship one 470/6? It definitely was the machine originally announced. As I recall the first 470V went to Bernie Galler at the University of Michigan. -- 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: Old Hashing Routine
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 06/23/2006 02:11:54 PM: so 3033 came up with a hack for supporting 32mbyte real storage. the 370 page table entry was 16bits with a 12bit page number field (for specifying a real 4k page ... 12+12 gives 24bit addressing or 16mbytes), two defined bits, and two undefined bits. the gimmick scavenged one of the undefined PTE bits to be used in real page numbers. you could now address 2**13 4k real pages ... or 32mbytes. The architecture scavenged two PTE bits to allow for 64mbytes of real storage. I don't think the 3033 ever supported more than 32mbytes, and I am not sure about the 3081, but there were customers running MVS/370 on the 3090 with 64mbytes of real storage. CCW IDAL was 31bits ... show you had bits to read/write pages into/out-of 16mbytes. the problem was that all instructions were still limited to 24bit addressing (both real and virtual). you could stick virtual pages above the 16mbyte line ... but there was periodic requirement that some kernel code running in real mode had to address virtual page contents about the 16mbyte line. So there was this gimmick with a dummy virtual address space ... that you stuffed an real page number below the 16mbyte line and the desired real page number above the 16mbyte line, entered virtual address space mode and copied the virtual page above the line to the virtual page location (that was below the 16mbyte real line). In MVS/370, two virtual pages in common storage were reserved for this purpose. RSM provided a window service, which you called passing one or two real frame numbers, and the address of an exit routine. RSM connected the real frames to the virtual pages, and called the exit routine. When the exit returned, RSM IPTEd the pages, and returned to the caller of the window service. An important user of this service was the DASD ERP. The sense data for a correctable data check provided provided an offset into the transfer block and 3 or 4 bytes of data to exclusive or at that offset in order to correct the error. Since ASM was using 31-bit IDAWs, the DASD ERP needed to use the window service when the real address of the I/O buffer was above 16mbytes. We had been running SP1.3 as a beta test in production on the MVS development system in Poughkeepsie on a 3033 with 32 mbytes of real storage for a few weeks, and had been experiencing some bizarre storage overlays. It turned out that the DASD ERP support had not been installed on that system, so the old DASD ERP was correcting the wrong real storage addresses. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: Old Hashing Routine
Shmuel Metz , Seymour J. wrote: Indeed, but they forgot the need to adjust address constants and variables when moving things around. They should have given the software types more say in the design. os/360 relocatable address constants are a real pain. tss/360 (the real operating system that was suppose to be for 360/67) had a different mechanism ... moving address constants out of the program image ... so they could do memory mapped program execution ... w/o having to preload the program image and run thru all the various address constants (in the image) and swizzling them to the appropriate value (required by the os/360 genre). part of the issue was that the executable paged mapped (out of the filesystem on disk) object could occupy a read-only shared segment ... that might possibly be at different address locations in different virtual address spaces. As a result, it wasn't just having to preload the executable image pages to swizzle the address constants ... but also the executable image was r/o and might not have a constant fixed location in every virtual address space (i.e. there would be no single value for address constants that were acceptable across all possible address spaces). note that multics had similar issues and addressed them in similar manner. recent post with some multics pointers http://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks in any case, tss/360 had a hard time achieving market acceptance ... partially because the code implementation was significantly slowww ... and after i had a couple months as an undergraduate rewritting cp67 kernel code ... cp67 was running rings around tss/360 ... and could offer virtual machine capability (on the same 360/67 hardware). a morph of tss/360 to tss/370 and then to ssup ... did find some deployment inside att. ssup was stripped down to its basic kernel functions with higher level unix functions layered on top of the lower level tss/370 functions. now when i did paged mapped filesystem for cp67/cms ... later ported to vm370/cms ... with similar capability http://www.garlic.com/~lynn/subtopic.html#mmap I was placed in a real bind. cms had picked up a lot of its environment by adapting many os/360 assemblers, compilers, and applications (and therefor inheriting the os/360 address constant convention). i had to play all sorts of games to create page mapped executable objects that could occupy shared segments in multiple different virtual address spaces, potentially simultaneously at different virtual addresses ... a few posts mentioning some of the hoops i had to go thru dealing with os/360 address constants in a virtual address space, paged mapped filesystem paradigm http://www.garlic.com/~lynn/subtopic.html#adcon misc. past posts mentioning tss/360, tss/370 and/or ssup (unix layered on top of tss/370 for att) http://www.garlic.com/~lynn/94.html#46 Rethinking Virtual Memory http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes http://www.garlic.com/~lynn/95.html#1 pathlengths http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party http://www.garlic.com/~lynn/98.html#11 S/360 operating systems geneaology http://www.garlic.com/~lynn/98.html#12 S/360 operating systems geneaology http://www.garlic.com/~lynn/99.html#2 IBM S/360 http://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art http://www.garlic.com/~lynn/99.html#237 I can't believe this newsgroup still exists http://www.garlic.com/~lynn/2000b.html#54 Multics dual-page-size scheme http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort) http://www.garlic.com/~lynn/2000c.html#8 IBM Linux http://www.garlic.com/~lynn/2000c.html#79 Unisys vs IBM mainframe comparisons http://www.garlic.com/~lynn/2000d.html#30 Secure Operating Systems http://www.garlic.com/~lynn/2000f.html#18 OT? http://www.garlic.com/~lynn/2000f.html#56 TSS ancient history, was X86 ultimate CISC? designs) http://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.) http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.) http://www.garlic.com/~lynn/2000f.html#61 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.) http://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86 ultimate CISC? designs) http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...] http://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits http://www.garlic.com/~lynn/2001e.html#19 SIMTICS http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370 http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System Microkernels http://www.garlic.com/~lynn/2001f.html#47 any 70's era supercomputers that ran as slow as today's supercomputers? http://www.garlic.com/~lynn/2001f.html#48 any 70's era
Old Hashing Routine
My client has instructed me to modify some modules so that they run above the line. This was a no brainer until I ran across a call to module BQKDPRS in several of the modules. This is an old (1970's) hashing routine for encrypting and decrypting a pin number. Naturally the client only has the object code and, since it is so old, it can only run below the line. So my questions are: 1. Is there another routine that does the same thing as BQKDPRS but can run above the line? 2. If there isn't, will specifying DATA(31) for the compile options of the Cobol programs calling BQKDPRS and Binder options of Amode(31), Rmode(Any) be enough to satisfy my client's requirements? Thanks. Steve Wiegand -- 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: Old Hashing Routine
will ... be enough to satisfy my client's requirements? Hard to say from this distance. I can tell you that - almost no non-trivial older program ever becomes purely 31-bit. Your client may be happy if your result is mostly 31-bit or as 31-bit as reasonably possible. - I think it's worth a shot to see if it will run 31-bit, either both A R = 31, or just A=31, R=24. Sometimes you win these things on blind luck. There is nothing about an older program that necessarily means it will not run AMODE 31. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Stephen M. Wiegand Sent: Thursday, June 22, 2006 7:01 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Old Hashing Routine My client has instructed me to modify some modules so that they run above the line. This was a no brainer until I ran across a call to module BQKDPRS in several of the modules. This is an old (1970's) hashing routine for encrypting and decrypting a pin number. Naturally the client only has the object code and, since it is so old, it can only run below the line. So my questions are: 1. Is there another routine that does the same thing as BQKDPRS but can run above the line? 2. If there isn't, will specifying DATA(31) for the compile options of the Cobol programs calling BQKDPRS and Binder options of Amode(31), Rmode(Any) be enough to satisfy my client's requirements? Thanks. Steve Wiegand -- 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: Old Hashing Routine
just a thought 1. there are numerous callable routines in icsf to (de)encrypt/hash anything, esp pin's, ie the finical services suite. even smp is into icsf hashing and w/ 1.7 you don't even need to start up icsf, i've heard 2. leave the hash routine as a separate callable load module in 24b and don't link it with the other lmod. Jack Kelly LA Systems @ US Courts x 202-502-2390 -- 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: Old Hashing Routine
Charles Mills wrote: There is nothing about an older program that necessarily means it will not run AMODE 31. A common practice used by older programs is using LA to clear the how order byte, which is a problem if it's a 31-bit address. -- 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: Old Hashing Routine
Depending on what the purpose of the clear is. Sometimes it was done just to make sure a count was not negative, or to get rid of an x'80' call list delimiter, in which case you're okay. My point is that sure, there a thousand reasons why it might not work, but no inherent reason not to give it a try. There's no guarantee that it WON'T work. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Richard Tsujimoto Sent: Thursday, June 22, 2006 8:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Old Hashing Routine Charles Mills wrote: There is nothing about an older program that necessarily means it will not run AMODE 31. A common practice used by older programs is using LA to clear the how order byte, which is a problem if it's a 31-bit address. -- 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: Old Hashing Routine
You might take a look at the HASHWF package on the IBM z/VM Downloads website: HASHWF 2000-01-12 A General HASH function (S/370 and other systems) The hashing code is supplied in Assembler source code. I do not know if it is really capable of running above the line, but the Rexx function included in the package works well. /Tom Kern --- Stephen M. Wiegand [EMAIL PROTECTED] wrote: My client has instructed me to modify some modules so that they run above the line. This was a no brainer until I ran across a call to module BQKDPRS in several of the modules. This is an old (1970's) hashing routine for encrypting and decrypting a pin number. Naturally the client only has the object code and, since it is so old, it can only run below the line. So my questions are: 1. Is there another routine that does the same thing as BQKDPRS but can run above the line? 2. If there isn't, will specifying DATA(31) for the compile options of the Cobol programs calling BQKDPRS and Binder options of Amode(31), Rmode(Any) be enough to satisfy my client's requirements? Thanks. Steve Wiegand -- 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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: Old Hashing Routine
If you can use a 'new fangled' program object instead of a load module as your executable, then RMODE(SPLIT) provides a nice resolution of such problems as you describe: AMODE(24) for a few intractable, difficult to convert routines and RMODE(31) for all the rest. John Gilmore Ashland, MA 01721-1817 USA _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- 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: Old Hashing Routine
AMODE(24) in the below should read RMODE(24), right? Also, some routines won't run AMODE(31), even if they are RMODE(24). Programs with tables with words of the format X'flags',AL3(data) for example, if they load the word into a register and then use the contents of the register as an address. However, you can solve that by front-ending the routine with a stub that goes AMODE(31) to (24) before the call and (24) to (31) on the way back out - assuming of course that the passed parameters are below the line. What a pain! Was it Gene Amdahl who said the biggest mistake of the 360 architecture was the 24-bit addresses? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of john gilmore Sent: Thursday, June 22, 2006 9:47 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Old Hashing Routine If you can use a 'new fangled' program object instead of a load module as your executable, then RMODE(SPLIT) provides a nice resolution of such problems as you describe: AMODE(24) for a few intractable, difficult to convert routines and RMODE(31) for all the rest. -- 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: Old Hashing Routine
I would run one of the dis-assemblers on it and see how complicated it is. It might be extremely easy or impossible. Ed On Jun 22, 2006, at 10:37 AM, Charles Mills wrote: will ... be enough to satisfy my client's requirements? Hard to say from this distance. I can tell you that - almost no non-trivial older program ever becomes purely 31-bit. Your client may be happy if your result is mostly 31-bit or as 31-bit as reasonably possible. - I think it's worth a shot to see if it will run 31-bit, either both A R = 31, or just A=31, R=24. Sometimes you win these things on blind luck. There is nothing about an older program that necessarily means it will not run AMODE 31. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Stephen M. Wiegand Sent: Thursday, June 22, 2006 7:01 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Old Hashing Routine My client has instructed me to modify some modules so that they run above the line. This was a no brainer until I ran across a call to module BQKDPRS in several of the modules. This is an old (1970's) hashing routine for encrypting and decrypting a pin number. Naturally the client only has the object code and, since it is so old, it can only run below the line. So my questions are: 1. Is there another routine that does the same thing as BQKDPRS but can run above the line? 2. If there isn't, will specifying DATA(31) for the compile options of the Cobol programs calling BQKDPRS and Binder options of Amode(31), Rmode(Any) be enough to satisfy my client's requirements? Thanks. Steve Wiegand -- 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 -- 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
