Reentrant code and IBM hardware
Craddock, Chris wrote: (after someone else wrote) And a corollary would be why DID IBM make it so darned hard to write reentrant assembler code? Umm... because they really weren't thinking about the problem. Back in the day things were considerably simpler and there was really no need for a more elaborate run time environment, or so they thought. It couldn't have been much longer. It was needed for PL/I, which must have been started pretty early in the OS/360 design. But Fortran G and H generate ordinary non-reentrerable code, with static data in the same CSECT. The Fortran G and H library even uses self modifying code! -- glen -- 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
Reentrant code, Fortran, and learning assembly
Arthur T. [EMAIL PROTECTED] wrote: I still remember learning DOS assembler language well over 20 years ago. I was taught about base and displacement addressing, and told how to code the BALR and USING at the beginning of my programs. What I most remember was, a week or so later, suddenly *really* understanding what the BALR and USING did. I don't remember how long, maybe more than a week... My experience was not unique. All of the students were taught, Put these statements at the beginnings of your programs and eventually you'll understand what they do. Of course, Base Displacement was taught and reiterated, but it takes time to sink in. For some time I was using the LIST option to see the generated code from the Fortran compilers. I also had some other samples of assembly code, and the Fortran GH programmers guide. The Fortran GH programmers guide had the suggested sequence for writing Fortran callable assembly, static save area and all. It was at least until after I had my first assembly program running that I understood the save area and what the base register did. I suppose I believe it is reasonable to learn static save areas for the first few assembly programs until the rest of the ideas have sunk in. As for non-reentrant code being slower, as I understand it on current machines instructions and data should be on separate cache lines. If you aren't worried about wasting a little memory, it isn't that hard to get the data away from instructions, at which point the static save area code is likely faster. Does VS Fortran generate reentrant code? I know Fortran G and H don't. -- glen -- 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: INTERNET Banks (WAS: Resume cover letters.)
I don't know if National Bank does; I know ScotiaBank did not up until two years ago. After I was out-sourced to IGS, I closed everything I could from ScotiaBank. After I was down-sized from IGS (June 2004), I stopped dealing with/following them completely. I moved everything left to a BMO Branch 2 blocks from where I was living at the time. When in doubt. PANIC!! -Original Message- From: james smith [EMAIL PROTECTED] Date: Sun, 22 Oct 2006 12:49:49 To:IBM-MAIN@BAMA.UA.EDU Subject: Re: INTERNET Banks (WAS: Resume cover letters.) My bank TD/Canada Trust does - as does CIBC, Royal Bank of Canada and BMO James F. Smith -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: 22 October 2006 12:31 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: INTERNET Banks (WAS: Resume cover letters.) The major Canadian banks all sell insurance and have done so since, IIRC, the early 90's. NOT the one I used to work at. When in doubt. PANIC!! -- 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
Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?
I meant in theory. I meant had they done this back when. I meant as opposed to 100 things that Chris might wish for and that other OSes do routinely, just these two things would be (would have been) a huge improvement. Chris has done rather more than just wish for it. In a recent former life, I built it and it's fair to say I'm missing it. But I digress. I'm not sure I would ask for stack support in hardware - that tends to be more expensive than you really want. However, it is entirely fair to expect the operating system to materialize a fully-functional runtime for each unit of work. Even (OS) kernel code runs on a runtime in those other OS'. In z/OS you would need to materialize a runtime for each key the unit of work runs under, but in most cases that would just be the moral equivalent of TCB key and key zero. You take the cost of making it on demand and then amortize that cost over the life of the unit of work by reusing the same one over and over. One thing I can tell you from personal experience is that having such an environment that you can count on completely changes the scope of what you can accomplish. Things you would never attempt (because its hard) become simple. Really. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
Craddock, Chris wrote: [snip] It is possible (BTDTGTS) to build coding and run time environments on z/OS where the programmer (even the system's software developer) never has to confront the low level details. In such an environment, reentrancy is natural and in all but the most trivial cases, blows the doors off more traditional programming practices for performance. This is of course, a religious argument to many. I don't expect to change any minds. But I offer the following challenge to assembly language application developers. Even though LE is a demented rats-nest of bad ideas, if you simply use it, you might be pleasantly surprised at how much easier and faster your code can run overall. There's a lot more function available and it is trivially easy to use. A software stack that provides saving of status regs, synchronization with error recovery, and storage for so-called automatic variables is a MUST for any complex system. The one we use is home grown and thoroughly incompatible with LE. Our programs would require massive conversions to use LE services. In particular, it would be close to impossible to free up R12 (as required by LE) in several million lines of code. Like you, I also know how difficult it is to write the kind of infrastructure upon which complex assembler language programs must depend. For anyone starting from scratch, LE sounds like the best way to short cut that process while, at the same time, gaining access to many additional run time functions with almost no effort. Thanks for pointing that out! -- 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
INTERNET Banks (WAS: Resume cover letters.)
http://news.bbc.co.uk/1/hi/business/6066244.stm Internet bank Egg has said it will make a loss this year because people are borrowing less on credit cards and defaulting on personal loans. Perhaps the real reason is that it's not attracting enough new business. And actually never has. And I believe the name to be a causitve factor. The Prudential is a typical basket case - suckers for the chimera of distributed computing (used to be a solid mainframe-based outfit) and rampant airline magazine driven outsourcing. It reversed its policy of off-shoring call centres a while back - perhaps they'll go back to a decent centralised IT model one day? I long for the days of properly thought out business plans and arguments into the night with HP12Cs and a bottle of Metaxa. Their current IT model is really just a symptom of a lask of management vision. -- Phil Payne http://www.isham-research.co.uk +44 7833 654 800 -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
Paul Gilmartin wrote: On Sat, 21 Oct 2006 15:44:00 -0600, Jeffrey D. Smith [EMAIL PROTECTED] wrote: LA R3,FUBAR ST R2,0(0,R3) No way for the assembler to determine that the ST is storing into field FUBAR. The only way to know for sure is to put the program into read-only storage. An unauthorized program can do that by using the IARVSERV or PGSER to page protect the program after it is loaded. The program must be marked page-aligned and the size must be an exact multiple of a page. There has also been discussed on ASSEMBLER-LIST a secret PARMLIB option that when set causes all code, authorized or not, marked RENT to be loaded in a write-protected subpool. There was a URL for an IBM presentation. Write-protected subpools?! No such thing! I mentioned the CsvRentSp252 DIAG trap earlier in this thread.. What that does is put RENT code into subpool 252, which is key zero storage. Therefore, programs running in PSW key zero can modify SP 252 storage. To get complete protection of all RENT modules, you must use the CsvRentProtect DIAG trap. That uses PGSER PROTECT to protect the modules once they're loaded. I don't recommend that setting on systems older than z/OS V1R8 because there are several popular IBM programs, residing in SP 252, that legitimately update themselves and whose module names don't appear in the exception table until that release. [Disclaimer: DIAG traps are not intended for use on production systems.] -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
On Sun, 22 Oct 2006 07:37:46 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Write-protected subpools?! No such thing! Now that I think about it, I suppose that makes sense. I mentioned the CsvRentSp252 DIAG trap earlier in this thread.. What I overlooked that. Several months ago, when you discussed this in ASSEMBLER-LIST, that keyword in Google found me a slide presentation (yours? IBM's? at Share?). It no longer appears. that does is put RENT code into subpool 252, which is key zero storage. Therefore, programs running in PSW key zero can modify SP 252 storage. To get complete protection of all RENT modules, you must use the CsvRentProtect DIAG trap. That uses PGSER PROTECT to protect the modules once they're loaded. I don't recommend that setting on systems older than z/OS V1R8 because there are several popular IBM programs, residing OK. Write-protected pages, not subpool. Is it likely that with evolution the behavior of those two options will become the default, and the list of exceptions will shrink? I suppose the transition will never be complete because of dusty deck concerns. Some non-IBM systems can mark segments as I-fetch only and D-fetch only. Does z/Series have this capability? It instantly traps on wild-branch-into-data. Might also provide a guideline for cache management. The recent discussion here and in links mentioned very small programs, which might load instructions and data into the same cache line. I assume this could happen even in a very large program, wherever instructions abut data. Would use of DS 255C be a good way to avoid the performance impact? Of course this could be ovecome by events if future hardware has a different cache line size. Will CSV and storage management ever allow load modules and data to occupy the same page? If so, a program might need to be protected with neutral zones on both ends. Does EX count as an I-fetch or a D-fetch? (Could even be model- dependent) -- 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: flashcopy
Hello Rex, Few days ago I drop an email with a sample program using the ANTTREXX interface. The interface, which I don't know its future yet, can be used to query on Flashcopy with small changes to my program which one of its features is the pair list. Itschak -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Pommier, Rex R. Sent: Friday, October 20, 2006 10:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: flashcopy Frank, Thanks for the info. The FLASHCPY QUERY gave me what I needed - if I used the RELATIONS parameter with it. I found the ICKDSF manual on the z/OS 1.4 bookshelf doesn't have the FLASHCPY command documented. Fortunately I was able to find the 1.7 collection which does have it documented. I found the TSO commands in the 1.7 bookshelf as well. Wish list time: It would be nice to have either the TSO or the ICKDSF command give me upon request a simple SOURCE--TARGET relationship list so I could at a glance see all the flashcopies in effect. Oh well, maybe someday. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Frank Krueger Sent: Thursday, October 19, 2006 2:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: flashcopy Rex the most powerful command is in ICKDSF the FLASHCPY QUERY command . It shows the relation you are looking for . Unfortunately you have to issue it against every single volume you are interested - you cannot specify a range . Look in ICKDSF Users Guide and Reference - GC35-0033 . Chapter 15 is where you are looking for. The TSO Command FCQUERY is described in DFSMS ADVANCED COPY SERVICES SC35-0428. Chapter 26 is what you need. I never use the GUI cause the ICKDSF or FCQUERY is more accurate and handsome to me - and i am not to much familiar with the DS6800 . Be sure to have the latest microcode of the GUI installed . hope this helps Frank -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
snip--- In C, the main program acquires the stack and heap as part of early initialization. We do something similar in our assembler programs as do (I'm sure) most savvy programmers. ---unsnip I tried to do MOST storage management in the first CSECT of ARCHIVER (CBT File 147) as well. Most of my save areas are stacked in a single area. (Someday I'll get around to determining how deep they're really stacked G) Most of the GETMAIN/FREEMAIN activity after that point is related to I/O buffers and compression/compaction work areas. I even wrote a set of subroutines to emulate QUIKCELL management, 'cuz I didn't have it in my system yet. Didn't use it in ARCHIVER but used it in several other routines. And I agree: I don't like absolutes very much myself. Thay can have a nasty habit of turning around and biting you, right in the posterior, when you least expect it. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Edward Jaffe) writes: Write-protected subpools?! No such thing! I mentioned the CsvRentSp252 DIAG trap earlier in this thread.. What that does is put RENT code into subpool 252, which is key zero storage. Therefore, programs running in PSW key zero can modify SP 252 storage. To get complete protection of all RENT modules, you must use the CsvRentProtect DIAG trap. That uses PGSER PROTECT to protect the modules once they're loaded. I don't recommend that setting on systems older than z/OS V1R8 because there are several popular IBM programs, residing in SP 252, that legitimately update themselves and whose module names don't appear in the exception table until that release. [Disclaimer: DIAG traps are not intended for use on production systems.] the inverse of this is sort of one of the problems left over from 370/165 falling behind schedule with 370 virtual memory hardware ... and picking up six months by dropping a bunch of stuff that was in the original 370 virtual memory architecture (and the mainstream pok operating system people stating they couldn't really see any use for it anyway). this then met that the other 370 models (many that had already had finished 370 virtual memory architecture implementation) had to be retrofitted to conform to what 370/165 was implementing. one of the things that got dropped out of this (read-only) segment protect. one of the nice things about having read-only protection at the segment table level ... was that some address spaces could have protection turned on and other address spaces w/o protection ... for the same area. in cp67, shared pages was offered for cms (and other) virtual address spaces by playing games with the storage protect keys ... and making sure that no virtual address space PSW was really dispatched with key zero. with the appearance of segment protect with 370 virtual memory architecture, cms was restructured (along with appropriate vm370 changes) to align r/o protected areas on segment boundaries. then came the 370/165 bomb shell for 370 virtual memory architecture ... and the whole vm370/cms strategy had to refitted to implement the cp67 storage protect key scheme. I had done a cms paged mapped filesystem originally on cp67 ... and ported it to vm370 ... http://www.garlic.com/~lynn/subtopic.html#mmap i introduced a lot of segment-based operations that could be done across different address spaces. one was that disk resident executables could be mapped directly to segment protected execution shared across multiple different address spaces ... and the segments could appear at arbitrary different virtual addresses in different address spaces. since a lot of cms application code was done based on os/360 derived compilers ... it was heavily loaded with os/360 relocatable address constant convention. now, this is one of the things that tss/360 had done right ... so that execution images on disk could be treated as strictly read-only (the image on disk and the executing image was exact) and still execute at an arbitrary virtual address (executable images contained no embedded address constants that had to be swizzled as part of loading for execution) http://www.garlic.com/~lynn/subtopic.html#adcon this also caused some perturbation in the original relational/sql implementation (all done as a vm370-based implementation). http://www.garlic.com/~lynn/subtopic.html#systemr where there was going to be some (virtual address space/)processes that had r/w access to the data ... but there was design that had application with access to some of the same data ... only unable to change that data. it was ideally designed to take advantage of the original 370 virtual memory architecture segment protection. however, the implemention then required some amount of fiddling for release as sql/ds. for some trivia ... one of the people in the following meeting claimed to have been primary person handling sql/ds technology transfer from endictt back to stl for db2 http://www.garlic.com/~lynn/95.html#13 misc. past posts mentioning 370/165 hardware schedule problems implementing 370 virtual memory http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries http://www.garlic.com/~lynn/2006.html#13 VM maclib reference http://www.garlic.com/~lynn/2006i.html#9 Hadware Support for Protection Bits: what does it really mean? http://www.garlic.com/~lynn/2006j.html#5 virtual memory http://www.garlic.com/~lynn/2006l.html#22 Virtual Virtualizers http://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?
Paul Gilmartin wrote: To get complete protection of all RENT modules, you must use the CsvRentProtect DIAG trap. That uses PGSER PROTECT to protect the modules once they're loaded. I don't recommend that setting on systems older than z/OS V1R8 because there are several popular IBM programs, residing OK. Write-protected pages, not subpool. Is it likely that with evolution the behavior of those two options will become the default, and the list of exceptions will shrink? I suppose the transition will never be complete because of dusty deck concerns. I've never understood why the CsvRentSp252 DIAG trap is necessary. What is the rationale for ignoring the RENT attribute for unauthorized programs? Authorized or not, a RENT program that modifies itself in an unserialized way has a bug that could have serious ramifications for the application. IMHO, by ignoring the RENT option for unauthorized programs, the operating system does their owners a great disservice. Currently, there is a refreshable attribute that the binder understands. That attribute is completely ignored by the operating system. If the distinction between RENT and REFR were surfaced in contents supervisor control blocks (there is a CDRENT flag bit in the CDE but no CDREFR flag bit), then it's conceivable IBM could, without too much effort, make REFR imply page protection. With that, we would not need the CsvRentProtect DIAG trap and its associated exception table! Our platform could do away with module overlays once and for all! It would be tremendous RAS improvement! Some non-IBM systems can mark segments as I-fetch only and D-fetch only. Does z/Series have this capability? It instantly traps on wild-branch-into-data. Might also provide a guideline for cache management. No similar capability. The I- or D- fetching occurs as a result of a reference to storage, either by PSW (or other instruction fetch such as target of EX or TR/TRT translate table) or instruction operand (data). The recent discussion here and in links mentioned very small programs, which might load instructions and data into the same cache line. I assume this could happen even in a very large program, wherever instructions abut data. Data and instructions don't mix, no matter how large or small the program. Some years ago, we found a large, non-RENT program with hundreds of subroutines, each of which performed linkage using a sequence similar to: | DC16F'0' |LabelDC0H | STM R0,R15,Label-64 | . | . (code here) | . | LMR0,R14,Label-64 | BRR14 (Yuck!) It probably performed reasonably well when it was written. But on today's hardware, it was a nightmare. This program was made reentrant and has not been a problem since. .. Would use of DS 255C be a good way to avoid the performance impact? Of course this could be ovecome by events if future hardware has a different cache line size. It would avoid the I-cache D-cache performance issues at the cost of increased module size, which has its own set of issues (slower module fetch, increased cache utilization, increased paging, base register problems for code using based branches, etc.). Reentrancy is almost always the better approach. Will CSV and storage management ever allow load modules and data to occupy the same page? If so, a program might need to be protected with neutral zones on both ends. Programs loaded into SP 252 are loaded into what are usually considered to be program-only pages. No so for programs loaded into SP 251. Programs loaded from a PDSE program object library are (usually) page-aligned and occupy a whole number of pages (default binder options are NOPACK, NOPRIME). Not so for programs loaded from a PDS load library. Does EX count as an I-fetch or a D-fetch? (Could even be model- dependent) This question is so easily answered by reading PoOp, I'm surprised you asked it in this forum. It's already been answered above. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Sunday, October 22, 2006 9:20 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? /snip/ Does EX count as an I-fetch or a D-fetch? (Could even be model- dependent) -- gil /snip/ The target instruction for EX is an I-fetch, because it can trigger a PER program interrupt. OTOH, the in-line parameter list for Resume Program (RP) is a D-fetch in the I-space. Weird. 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Sunday, October 22, 2006 8:38 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? Paul Gilmartin wrote: On Sat, 21 Oct 2006 15:44:00 -0600, Jeffrey D. Smith [EMAIL PROTECTED] wrote: /snip/ The only way to know for sure is to put the program into read-only storage. An unauthorized program can do that by using the IARVSERV or PGSER to page protect the program after it is loaded. The program must be marked page-aligned and the size must be an exact multiple of a page. There has also been discussed on ASSEMBLER-LIST a secret PARMLIB option that when set causes all code, authorized or not, marked RENT to be loaded in a write-protected subpool. There was a URL for an IBM presentation. Write-protected subpools?! No such thing! I mentioned the CsvRentSp252 DIAG trap earlier in this thread.. What that does is put RENT code into subpool 252, which is key zero storage. Therefore, programs running in PSW key zero can modify SP 252 storage. To get complete protection of all RENT modules, you must use the CsvRentProtect DIAG trap. That uses PGSER PROTECT to protect the modules once they're loaded. I don't recommend that setting on systems older than z/OS V1R8 because there are several popular IBM programs, residing in SP 252, that legitimately update themselves and whose module names don't appear in the exception table until that release. [Disclaimer: DIAG traps are not intended for use on production systems.] -- Edward E Jaffe /snip/ I prefer rolling my own IARVSERV or PGSER cover program, because it only affects my job step address space and not the entire system. I guess on a single-user system, like a FLEX-ES (rest in peace), the DIAG stuff would be OK. It doesn't take much work to LOAD the target program, figure out the boundaries and issue PGSER PROTECT (or IARVSERV ACCESS=READONLY). Then on the way out, be sure to unprotect the pages before issuing DELETE. Protected pages are not foolproof, but certainly stronger than relying on key 0 storage to detect self-modifying reentrant programs. 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
I'm not sure I would ask for stack support in hardware - that tends to be more expensive than you really want. I was thinking of hardware support for stack over/underflow detection/diagnosis. A lot easier (in my hardware ignorance g) to have that detection with some sort of fence register in hardware than having to have compare logic at the front of every subroutine, right at the moment when the subroutine is shortest on registers and diagnostic resources. FWIW, when I last implemented the sort of vendor framework that others have referred to, I know I solved the how to diagnose issue by having a stack error at the front of a subroutine branch to some specific odd address in low memory: C stackptr,stackfence BL X'BAD' as I recall. Low overhead, foolproof diagnosis. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Sunday, October 22, 2006 7:04 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? I meant in theory. I meant had they done this back when. I meant as opposed to 100 things that Chris might wish for and that other OSes do routinely, just these two things would be (would have been) a huge improvement. Chris has done rather more than just wish for it. In a recent former life, I built it and it's fair to say I'm missing it. But I digress. I'm not sure I would ask for stack support in hardware - that tends to be more expensive than you really want. However, it is entirely fair to expect the operating system to materialize a fully-functional runtime -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
On Sun, 22 Oct 2006 09:19:36 -0700 Edward Jaffe [EMAIL PROTECTED] wrote: :Programs loaded into SP 252 are loaded into what are usually considered :to be program-only pages. Subpool 252 is also used when a key zero program requests subpool zero. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
On Sun, 22 Oct 2006 09:19:36 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: I've never understood why the CsvRentSp252 DIAG trap is necessary. What is the rationale for ignoring the RENT attribute for unauthorized programs? Authorized or not, a RENT program that modifies itself in an unserialized way has a bug that could have serious ramifications for the application. IMHO, by ignoring the RENT option for unauthorized programs, the operating system does their owners a great disservice. I feel that way about various z/OS features. I assume it was a dusty deck collateral damage. By the time that someone recognized how it should be done right, there was a sufficient residue of self-modifying customer code (mis-)marked RENT that it was too late to change. But that could be fixed by re-linking. In the worst case, NE load modules with the source lost, a utility could be supplied to reset the RENT bit. Currently, there is a refreshable attribute that the binder understands. That attribute is completely ignored by the operating system. If the distinction between RENT and REFR were surfaced in contents supervisor control blocks (there is a CDRENT flag bit in the CDE but no CDREFR flag bit), then it's conceivable IBM could, without too much effort, make REFR imply page protection. With that, we would not need the CsvRentProtect DIAG trap and its associated exception table! Our platform could do away with module overlays once and for all! It would be tremendous RAS improvement! My understanding is that the design motivation was to be able to re-fetch a REFR load module in case of detected physical damage to a page. Either lost in a redesign, or never fully implemented. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
On Sun, 22 Oct 2006 10:28:19 -0600, Jeffrey D. Smith [EMAIL PROTECTED] wrote: It doesn't take much work to LOAD the target program, figure out the boundaries and issue PGSER PROTECT (or IARVSERV ACCESS=READONLY). Then on the way out, be sure to unprotect the pages before issuing DELETE. Yah, but I agree with Ed J. that should be the responsibility of the OS, and not reinvented and redebugged by every programmer. Do those operations require authorization? If so, they're unavailable to the applications programmer writing unauthorized code. Just curious, and probably naive, but how does one figure out the boundaries of a module loaded via an ALIAS or ENTRY not coincident with the beginning of the module? I understand LOAD returns only the entry point and length. In fact, the way Binder can shuffle CSECTS (e.g. as when invoked by SMP/E) there's little certainty that the primary CSECT will be first. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 10/22/2006 12:19:36 PM: I've never understood why the CsvRentSp252 DIAG trap is necessary. What is the rationale for ignoring the RENT attribute for unauthorized programs? Authorized or not, a RENT program that modifies itself in an unserialized way has a bug that could have serious ramifications for the application. IMHO, by ignoring the RENT option for unauthorized programs, the operating system does their owners a great disservice. The reason now is of course compatibility. For example, I have been told that there is a debugger program in the HLASM toolkit which runs unauthorized, and sets breakpoints by modifying the program being debugged. With CsvRentSp252, this debugger cannot set breakpoints in modules which have the RENT attribute. Currently, there is a refreshable attribute that the binder understands. That attribute is completely ignored by the operating system. If the distinction between RENT and REFR were surfaced in contents supervisor control blocks (there is a CDRENT flag bit in the CDE but no CDREFR flag bit), then it's conceivable IBM could, without too much effort, make REFR imply page protection. With that, we would not need the CsvRentProtect DIAG trap and its associated exception table! Our platform could do away with module overlays once and for all! It would be tremendous RAS improvement! And as you know, that is on my list of things I would like to be doing if I had time to be doing things like that. Of course, doesn't hurt to submit a requirement. Will CSV and storage management ever allow load modules and data to occupy the same page? If so, a program might need to be protected with neutral zones on both ends. Programs loaded into SP 252 are loaded into what are usually considered to be program-only pages. CSV does a GETMAIN for the amount of space required by the module (unless you are using the undocumented CSVSP252ROUNDUP trap in DIAGxx). The remaining space in a page could be obtained from subpool 252 by another program for use as data. 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. [EMAIL PROTECTED] (Paul Gilmartin) writes: Some non-IBM systems can mark segments as I-fetch only and D-fetch only. Does z/Series have this capability? It instantly traps on wild-branch-into-data. Might also provide a guideline for cache management. the stack smashing and buffer overflow (highly correlated with numerous c language programming environments) somewhat recently led to d-fetch hardware feature only ... aka countermeasure to various attacks hiding instructions inside incoming data. d-fetch only wouldn't fix programming problems with allowing long data/string structures to overlay things they shouldn't ... but it would at least prevent the execution of any hidden instructions. various flavors i-fetch ( execution) only hardware have been around for somewhat longer (execute-only as opposed to no-execute which is this later countermeasure to various vulnerabilities that have significantly higher occurance in c programming environments) old post discussing 360 key fetch/store protection and emerging d-fetch only (no-execute) ... http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns a few of the other no-execute posts (for stack smashing buffer overrun vulnerabilities) http://www.garlic.com/~lynn/2004q.html#82 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005.html#0 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005.html#1 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns misc. posts with any mention of buffer overflow http://www.garlic.com/~lynn/subintegrity.html#overflow -- 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: Question on the load list
Q.Why is the nuc linked with sctr? A.The nucleus is linked with SCTR in order to provide the flexibility needed to manage CSECTs on an individual basis and have some CSECTs above 16M have some CSECTs below 16M have some CSECTs cache-line-aligned have some CSECTs placed discontiguously (used to be x'1000', as of z/Arch now x'2000') and not even present after IPL completes (IEAVNIP0 and IEAVNIPH for example) Obviously the first two are, to some extent, possible for program objects using RMODE=SPLIT (but that sort of functionality is not available anywhere near early enough to be used for the nucleus. And of course RMODE=SPLIT support was developed long after. Presumably the extra processing needed to load the additional control information and to process this stuff was deemed necessary for the nucleus and not important enough to be accommodated afterwards. Peter Relson z/OS Core Technology Design -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
Charles Mills wrote: I'm not sure I would ask for stack support in hardware - that tends to be more expensive than you really want. I was thinking of hardware support for stack over/underflow detection/diagnosis. A lot easier (in my hardware ignorance g) to have that detection with some sort of fence register in hardware than having to have compare logic at the front of every subroutine, right at the moment when the subroutine is shortest on registers and diagnostic resources. We do this in our infrastructure by page protecting the page(s) before and after the acquired stack area. If you use storage acquired with IARV64 for your stack, you can establish a guard area. FWIW, when I last implemented the sort of vendor framework that others have referred to, I know I solved the how to diagnose issue by having a stack error at the front of a subroutine branch to some specific odd address in low memory: C stackptr,stackfence BL X'BAD' as I recall. Low overhead, foolproof diagnosis. With relative branch, we have converted all such should not occur branches to Jxx *+2. The 0C1 abend PSW points right past the offending branch instruction. Much better than branching into page zero. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
Paul Gilmartin wrote: On Sun, 22 Oct 2006 10:28:19 -0600, Jeffrey D. Smith [EMAIL PROTECTED] wrote: It doesn't take much work to LOAD the target program, figure out the boundaries and issue PGSER PROTECT (or IARVSERV ACCESS=READONLY). Then on the way out, be sure to unprotect the pages before issuing DELETE. Yah, but I agree with Ed J. that should be the responsibility of the OS, and not reinvented and redebugged by every programmer. Do those operations require authorization? If so, they're unavailable to the applications programmer writing unauthorized code. Does not require authorization. Just curious, and probably naive, but how does one figure out the boundaries of a module loaded via an ALIAS or ENTRY not coincident with the beginning of the module? I understand LOAD returns only the entry point and length. CSVQUERY. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Saturday, October 21, 2006 9:59 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? John P Baker wrote: I always -try- to write reentrant code. However, I sometimes find that a non-reentrant coding technique is a more suitable approach. Could you please describe such a situation? -- Edward E Jaffe Writing a application type program which must use a DCB? Why would I take the time and trouble to copy a DCB from my storage to GETMAIN'ed storage, perhaps doing some ADCON changes as well, for an application program. What do I gain? I increase complexity and time to write and debug. Now, for a TSO application, maybe it is worth it. For batch, why bother? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
AFAIR the R12 restriction for LE is gone with z/OS R7 or R8. LE use a PSALAA and ASSB_LAA_CPID instead of R12. Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Sunday, October 22, 2006 4:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? Craddock, Chris wrote: [snip] It is possible (BTDTGTS) to build coding and run time environments on z/OS where the programmer (even the system's software developer) never has to confront the low level details. In such an environment, reentrancy is natural and in all but the most trivial cases, blows the doors off more traditional programming practices for performance. This is of course, a religious argument to many. I don't expect to change any minds. But I offer the following challenge to assembly language application developers. Even though LE is a demented rats-nest of bad ideas, if you simply use it, you might be pleasantly surprised at how much easier and faster your code can run overall. There's a lot more function available and it is trivially easy to use. A software stack that provides saving of status regs, synchronization with error recovery, and storage for so-called automatic variables is a MUST for any complex system. The one we use is home grown and thoroughly incompatible with LE. Our programs would require massive conversions to use LE services. In particular, it would be close to impossible to free up R12 (as required by LE) in several million lines of code. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
Hi Anne, Didn't I see you and Lynn just last week at the Comstock Festival in Brussels? Anyway, I think the trivia you quote below is a bit outdated since it happened on the epoch of a centennial celebration that time when Sting was playing The Royal Albert Hall, remember? Or was it Ozzy Osbourne? I forget. L8R, Lindy -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anne Lynn Wheeler Sent: Sunday, October 22, 2006 6:39 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? for some trivia ... one of the people in the following meeting claimed to have been primary person handling sql/ds technology transfer from endictt back to stl for db2 http://www.garlic.com/~lynn/95.html#13 -- 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: SRM Flash 10526 - Workaround provided until APAR OA18452 closes
Yeswe set it to 2000 last week, and saw a reduction in Uncaptured. (in fact, this APAR was created in part due to some excellent work by our capacity performance guy's, who saw a marked increase in Uncaptured when we recently went to z9's, and wouldn't accept IBM's answer that it was WAD). Cheers...Jason. Richards.Bob [EMAIL PROTECTED] TRUST.COM To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU SRM Flash 10526 - Workaround provided until APAR OA18452 closes 22/10/2006 00:32 Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10526 Anyone else with z9EC boxes catch this flash out on Techdocs and try the workaround yet? For now, it conditionally recommends adding the RMPTTOM keyword with a value of 2000 to the IEAOPTxx member (wherever you have it in your PARMLIB concatenation). See abstract below: Abstract: z/OS Performance on IBM System z9 has reported a drop in z/OS capture ratio after migration to a 2094 EC processor. The impact on capture ratio has been traced to the frequency of SRM timer intervals. This flash describes findings regarding the SRM timer interval and its possible impact on captured time. The flash provides information and recommendations for z/OS tuning. Bob Richards VP, Enterprise Technologist Suntrust Banks, Inc (404) 575-2798 [EMAIL PROTECTED] Seeing beyond money (sm) National Australia Bank Ltd - ABN 12 004 044 937 This email may contain confidential information. If you are not the intended recipient, please immediately notify us at [EMAIL PROTECTED] or by replying to the sender, and then destroy all copies of this email. Except where this email indicates otherwise, views expressed in this email are those of the sender and not of National Australia Bank Ltd. Advice in this email does not take account of your objectives, financial situation, or needs. It is important for you to consider these matters and, if the e-mail refers to a product(s), you should read the relevant Product Disclosure Statement(s)/other disclosure document(s) before making any decisions. If you do not want email marketing from us in future, forward this email with unsubscribe in the subject line to [EMAIL PROTECTED] in order to stop marketing emails from this sender. National Australia Bank Ltd does not represent that this email is free of errors, viruses or interference. -- 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: Question on the load list
Peter, Thanks for the refresh. I did not know about z/Arch change. Ed On Oct 22, 2006, at 12:59 PM, Peter Relson wrote: Q.Why is the nuc linked with sctr? A.The nucleus is linked with SCTR in order to provide the flexibility needed to manage CSECTs on an individual basis and have some CSECTs above 16M have some CSECTs below 16M have some CSECTs cache-line-aligned have some CSECTs placed discontiguously (used to be x'1000', as of z/Arch now x'2000') and not even present after IPL completes (IEAVNIP0 and IEAVNIPH for example) Obviously the first two are, to some extent, possible for program objects using RMODE=SPLIT (but that sort of functionality is not available anywhere near early enough to be used for the nucleus. And of course RMODE=SPLIT support was developed long after. Presumably the extra processing needed to load the additional control information and to process this stuff was deemed necessary for the nucleus and not important enough to be accommodated afterwards. Peter Relson z/OS Core Technology Design -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
When memory moved from tubes or real core it became somewhat more reliable. :) Dave Gibney [EMAIL PROTECTED] System Programmer(509) 335-7359 Information Technology Washington State University Pullman, WA 99164-1222 My understanding is that the design motivation was to be able to re-fetch a REFR load module in case of detected physical damage to a page. Either lost in a redesign, or never fully implemented. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
In [EMAIL PROTECTED], on 10/21/2006 at 10:15 AM, Steve Comstock [EMAIL PROTECTED] said: Interesting. I didn't know that. I joined IBM in 1968 and I seem to recall reentrant being the common tongue then and reenterable used later. Of course, what's really being discussed here is refreshable code. Does your course get around to discussing serialization? -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
In [EMAIL PROTECTED], on 10/21/2006 at 10:19 AM, Jeffrey D. Smith [EMAIL PROTECTED] said: Mainframers tend to use the word reentrant to mean a program that is concurrently executable by multiple units of work and it does not modify itself at all (or may modify itself in a way that is not detectable by the multiple units of work that are concurrently executing the program). That's refreshable. Reentrant means that you get correct results when running concurrent copies, which typically requires some sort of serialization. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
In [EMAIL PROTECTED], on 10/21/2006 at 11:37 AM, John P Baker [EMAIL PROTECTED] said: Reentrant code tends to be larger than non-reentrant code and to run slower in that it generally has to increase the instruction path length due to the need to acquire and release dynamic storage for work areas and to copy model data into that dynamic storage. Not in my experience. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
In [EMAIL PROTECTED], on 10/21/2006 at 11:43 AM, Charles Mills [EMAIL PROTECTED] said: Just TWO things would make life so much simpler: 1. A universal hardware and OS stack. Then all the discussions about reentrance go away. No. It would slightly simplify storage management but would not eliminate the need for serialization. 2. Get the I/O control blocks out of the user's space -- go instead to a handle type approach where the gory details of the I/O control blocks were not the application developer's problem. And bingo, the 24-bit DCB problem disappears. I don't see the need for that, and it would complicate interfaces. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
In [EMAIL PROTECTED], on 10/21/2006 at 04:30 PM, john gilmore [EMAIL PROTECTED] said: More important, it is in logic a universal negative; and it can be proved that no instance of an universal negative can be proved. Not only false but self contradictory. -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
In [EMAIL PROTECTED], on 10/21/2006 at 05:09 PM, Robert A. Rosenberg [EMAIL PROTECTED] said: Use RENT as well as RSECT instead of CSECT and you will get TOLD at assembly time when you're not reentrant. No. You will be told of some possible failures of refreshability. There will be valid statements that get flagged and invalid statements that don't get flagged. -- 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: Question on the load list
In [EMAIL PROTECTED], on 10/21/2006 at 10:16 PM, Ed Gould [EMAIL PROTECTED] said: Why is the nuc linked with sctr? The original reason was to force NIP to loaded where it needed to be, but with MVS/XA there were additional reasons. -- 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: Question on the load list
In [EMAIL PROTECTED], on 10/21/2006 at 10:32 PM, Peter Relson [EMAIL PROTECTED] said: SCTR: This is supported only for nucleus (where it is required) and is ignored everywhere else and thus in those other cases does nothing other than waste space on DASD. I suspect (but don't know for sure) that it was never supported for anything other than the nucleus. It was supported for everything except[1] ERP and SVC code. The translation algorithm for the nucleus was different from the translation algorithm for everything else. BTDTGTS. PLPA modules are required to be refreshable (which is stronger than reentrant) R/O is stronger than refreshable, but neither is stronger than reentrant, since neither implies serialization. [1] The transient area handler was written to load single CSECT modules with nor RLD data. -- 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: Question on the load list
In [EMAIL PROTECTED], on 10/20/2006 at 08:24 AM, McKown, John [EMAIL PROTECTED] said: FSVO reentrant. Actually, being in the LPA usually implies not self modifying, that is the program will not attempt to modify its own storage. But, at least in the past, there were sneaky ways around this. But they are anathema as far as I am concerned. AOL. I always objected vehemently to putting nonrefreshable code in the MLPA. Is it still a PARMLIB option, or is the MLPA now unconditionally page protected? -- 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: Question on the load list
In [EMAIL PROTECTED], on 10/19/2006 at 12:14 PM, Steve Comstock [EMAIL PROTECTED] said: The first time a task dynamically requests a module, the module is either located as already in the LPA or JPA, or it is loaded into my address space and a CDE and XTLST are built. Then an LLE is built and set That depends on whether the module is loaded by a LOAD or by a macro that creates a new PRB, e.g., LINK. Only Load creates or increments an LLE. Here's an another area of confusion. Both you and the docs say that LLEs point to CDEs. But I have a dump I created for testing and I see this (short version and slightly reformatted): It appears likely that you[1] did a LOAD for three different modules in the LPA. Go into IPCS and look at each CDE. Anyway, why are there three LLEs Because they refer to three different load modules. and none of the CDPT values point to the one and only CDE we have in the address space? Hence they must point to the LPA. [1] Probably by doing an OPEN. -- 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: Question on the load list
In [EMAIL PROTECTED], on 10/19/2006 at 06:40 PM, Binyamin Dissen [EMAIL PROTECTED] said: #2 is wrong. No, just incomplete. It does *not* say that only reenterable modules are loaded there. -- 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: Question on the load list
In [EMAIL PROTECTED], on 10/19/2006 at 11:23 AM, Rick Fochtman [EMAIL PROTECTED] said: Why do we need both a LOAD LIST and a CONTENTS DIRECTORY ?? (IIRC, a LOAD for a module in LPA also creates a LLE...Why?) The JPAQ is made up of CDE's for the job step. An LLE represents the use of a load module within a task, and is needed to clean up when the task terminates rather than the entire job step. -- 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: Question on the load list
In [EMAIL PROTECTED], on 10/19/2006 at 09:50 AM, Steve Comstock [EMAIL PROTECTED] said: So I'm comfortable with having the JPA as an area in my address space for holding dynamically called reenterable programs. Dynamically loaded, whether reenterable or not. Those modules marked as RENT and loaded from an APF library go into SP 252 rather than into SP 251, but it's all JPA. suppose I dynamically load a non-reenterable module? Where is that loaded? JPA, SP 251. It can't be the JPA by the above definition. Read it again; there is no above definition. There is a statement about where certain load modules placed, but that statement is nonexclusive. I seem to recall a term like Load List Area or Link List Area but I cannot find these anymore. There is a Load List, which is task related, there is a Link List, which is sytem related and there is a Link Pack Area, which is system related; there is no Load List Area. There is something called LLA, but the A stands for Aside, not for Area. But I am finding old notes that says the load list is only for non-reenterable programs, but no pointer to the docs for that. I have no idea where that came from; it's not true. Any clarification would be appreciated. Look at the mapping for the LLE. -- 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: Multiple FTP Problems
In [EMAIL PROTECTED], on 10/20/2006 at 07:04 AM, Edward Jaffe [EMAIL PROTECTED] said: It seems like there are a couple of options here. The first is to split all transfers up into individual ftp sessions, invoke each ftp session from REXX, interrogate the output, and make conditional decisions based on the results of each invocation. The other option, extremely powerful but not so easy, is to roll your own client code using the REXX Sockets API: Isn't RXFTP available in z/OS? If not, use NET::FTP in Perl. -- 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: From address - was Find the most duplicates
In [EMAIL PROTECTED], on 10/19/2006 at 12:20 PM, Frank Yaeger [EMAIL PROTECTED] said: Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU From: Frank Yaeger [EMAIL PROTECTED] The above are as they should be. Could there be an issue with the envelope From? -- 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.) Sent: Sunday, October 22, 2006 12:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? In [EMAIL PROTECTED], on 10/21/2006 at 10:19 AM, Jeffrey D. Smith [EMAIL PROTECTED] said: Mainframers tend to use the word reentrant to mean a program that is concurrently executable by multiple units of work and it does not modify itself at all (or may modify itself in a way that is not detectable by the multiple units of work that are concurrently executing the program). That's refreshable. No, that's reentrant. Refreshable means the program does not modify itself *ever*. A reentrant program may modify itself in a way that is not detectable by concurrently executing units of work. That's what I wrote. Reentrant means that you get correct results when running concurrent copies, which typically requires some sort of serialization. No, reentrant means what I wrote. Serialization has nothing to do with it, unless the program is self-modifying (which is also what I wrote). -- Shmuel (Seymour J.) Metz, SysProg and JOAT /snip/ 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: Is anyone using Workstation Edit piece of ISPF?
Doh! You need OA17424. As far as the rest of the discussion goes there was always an assumption with this feature that the TN3270 Ipaddr and the target workstation are the same. If your network does interesting things to make this assumption false then you will have to connect in the tried and true fashion. For the technically minded check out the GTTERM macro in the latest TSO pubs. Hank ISPF On Thu, 19 Oct 2006 08:28:33 -0500, Cynthia Davis [EMAIL PROTECTED] wrote: We have implemented the workstation piece on one of our pc's but we are looking to add it to a few more pc's and we need an easier way to implement. I had read in one of the Cheryl Watson news letters that one enhancement to ISPF is The ISPF workstation connect program (WSCON) will be enhanced to automatically discover the IP address of the connected TN3270 workstation and use this address to establish a session. It will no longer be necessary to know your ip address and enter it on the panel to start a session. Does anyone know when this option will come available? or is anyone already using the option? or has anyone already written a clist to do this exact thing? z/OS 1.8. It also removes the need for the SAS/C runtime. From the help pop-up: A value of '*' will be overlayed with system variable ZIPADDR. ZIPADDR is the TCP/IP address of the currently connected TN3270 workstation. I tried it and it didn't work properly. It filled in the IP address with 99. 99. 99. 99 (the numbers were the corrct ones for my connection but the blamks after the periods caused it to fail). When I removed the blanks it worked fine. 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 -- 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
