Software pricing
10 July 1996: The federal government and IBM agreed today to end a 40-year-old decree against the computer giant. The 1956 consent decree between the Department of Justice and IBM, of Armonk, N.Y., resulted in several restrictions on the company that were designed to prevent it from becoming a monopoly in the computer industry. Some of the restrictions on IBM's AS/400 line will be terminated within six months of a judge's approval, and the rest four years later. The restrictions on the S/390 line will be phased out in five years. While we continue to believe the consent decree should be terminated immediately, this settlement allows us to move ahead without spending further time and money in litigation, said IBM General Counsel Lawrence Ricciardi. We have been under restrictions 40 years already, and it's time to move on. There are currently no Consent Decree or similar restrictions on IBM. The last was the 1984 EC Undertaking that mainly concerned the timely availability of interface information. Interestingly, the Amdahl corporate lawyer who helped DG IV put the 1984 Undertaking together is now with Platform Solutions. It may be that DG IV will get interested again. Perhaps about 64-bit commercials, too. -- 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: questions on the load list . . .
john gilmore wrote: Chris Craddock wrote: In practice those limitations are trivially defeated, which is one of the many reasons I maintain that non-reentrant modules are just a bad idea and ought to be avoided, especially by privileged code. My view is less charitable. There are now few if any---I can in fact think of no---circumstances in which it is excusable to write non-reentrant code. Well, when you are learning Assembler, the work to write reentrant (I, too, prefer that term to the relatively new-fangled reenterable) can get in the way of focusing on simply how the instructions work and how to string together series of instructions to accomplish specific tasks. Our intro Assembler class does not mention reentrant. We introduce reentrant techniques at the end of our second course in the series, Assembler Basic Interfaces. Kind regards, -Steve Comstock The Trainer's Friend, Inc. http://www.trainersfriend.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
Is the teaching of non-reentrant HLASM coding practices ever defensible?
Steve Comstock[EMAIL PROTECTED] writes: Well, when you are learning Assembler, the work to write reentrant (I, too, prefer that term to the relatively new-fangled reenterable) can get in the way of focusing on simply how the instructions work and how to string together series of instructions to accomplish specific tasks. This pedagogic argument is a hoary one that cannot be dismissed out of hand. Complexities must sometimes be deferred. Newtonian mechanics, which has its own legitimate and useful purview, is for example taught first, before relativistic mechanics, in physics curricula. Deference to what Sir Thomas Browne politely called 'junior understanding' is, however, too frequent. To teach techniques that have no legitimate non-pedagogic uses is, I think, indefensible. Browne also said that . . . to produce a clear and warrantable body of truth we must forget and part with much we know; and too many of the notions that we must jettison have been inflicted upon us by our teachers. Today assembly language is a putatively 'advanced' topic; it is not usually learned first; and students who are already familiar with storage classes (with the differences among static, LIFO automatic, and non-LIFO heap storage) can and should be introduced to reentrant assembly-language methods at the outset of their training. John Gilmore Ashland, MA 01721-1817 USA _ Get today's hot entertainment gossip http://movies.msn.com/movies/hotgossip?icid=T002MSN03A07001 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?
Today assembly language is a putatively 'advanced' topic; it is not usually learned first; and Semi-Colon and AND (or BUT) are redundant. The ';' replaces AND or BUT! students who are already familiar with storage classes (with the differences among static, LIFO automatic, and non-LIFO heap storage can and should be introduced to reentrant assembly-language methods at the outset of their training. Who's the professional instructor here? You or Steve. Who has the experience of what works and what doesn't? I have seen students so burdened with the complexities of the advanced topics that they never pick up the basics well. Besides, I don't see graduates of ASM101 writing exits or LPA-destined code. All in good time! 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
Re: Is the teaching of non-reentrant HLASM coding practices ever defensible?
== john gilmore == wrote2006-10-21 14:54: Steve Comstock[EMAIL PROTECTED] writes: Well, when you are learning Assembler, the work to write reentrant (I, too, prefer that term to the relatively new-fangled reenterable) can get in the way of focusing on simply how the instructions work and how to string together series of instructions to accomplish specific tasks. This pedagogic argument is a hoary one that cannot be dismissed out of hand. Complexities must sometimes be deferred. ... But most of the time is the problem to get the students get a gripe about the very basic at all ! Learning advanced topics without mastering the basics is nearly worthless. Either they learn the basics fast and can get to the advanced parts soon. Or they have no chance at all to understand advanced techniques and methods. Thomas Berg -- __ Mundus Vult Decipi __ They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin Military justice is to justice what military music is to music. - Groucho Marx -- 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?
john gilmore wrote: Steve Comstock[EMAIL PROTECTED] writes: Well, when you are learning Assembler, the work to write reentrant (I, too, prefer that term to the relatively new-fangled reenterable) can get in the way of focusing on simply how the instructions work and how to string together series of instructions to accomplish specific tasks. This pedagogic argument is a hoary one that cannot be dismissed out of hand. Complexities must sometimes be deferred. Agreed. Newtonian mechanics, which has its own legitimate and useful purview, is for example taught first, before relativistic mechanics, in physics curricula. True Deference to what Sir Thomas Browne politely called 'junior understanding' is, however, too frequent. To teach techniques that have no legitimate non-pedagogic uses is, I think, indefensible. Well, I agree. In our programming courses, we _never_ use a Hello World program as an example: how often do you need that in the real world? Never. We always begin with how to describe fields, records, and files and how to use the appropriate file I/O verbs. Never write a line of code to be thrown away. Browne also said that . . . to produce a clear and warrantable body of truth we must forget and part with much we know; and too many of the notions that we must jettison have been inflicted upon us by our teachers. And much that has proven valuable in our lives has also been inflicted upon us by our teachers. It is true we must often let go of, or unlearn, what we once thought was truth. Or at least continually re-examine our assumptions, biases and beliefs. As a Unitarian, we are constantly challenged: To question is the answer. But, I digress... Today assembly language is a putatively 'advanced' topic; it is not usually learned first; and students who are already familiar with storage classes (with the differences among static, LIFO automatic, and non-LIFO heap storage) can and should be introduced to reentrant assembly-language methods at the outset of their training. Most often the audience for my Assembler classes are either new to programming or their experience is with COBOL; in neither case are they familiar with storage classes and their differences. So we defer reentrant coding until their 8th day of training. By then they are ready to focus on this. That's just my real world experience talking. Kind regards, -Steve Comstock -- 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?
Reentrancy may be preferred, but it is not always reasonable or even possible. Each situation must be evaluated on its own merits. I always -try- to write reentrant code. However, I sometimes find that a non-reentrant coding technique is a more suitable approach. Programmers must have both the -training- and -experience- to be able to select the best approach in each situation. John P Baker Software Engineer -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of john gilmore Sent: Saturday, October 21, 2006 08:54 To: IBM-MAIN@BAMA.UA.EDU Subject: Is the teaching of non-reentrant HLASM coding practices ever defensible? This pedagogic argument is a hoary one that cannot be dismissed out of hand. Complexities must sometimes be deferred. Newtonian mechanics, which has its own legitimate and useful purview, is for example taught first, before relativistic mechanics, in physics curricula. Deference to what Sir Thomas Browne politely called 'junior understanding' is, however, too frequent. To teach techniques that have no legitimate non-pedagogic uses is, I think, indefensible. Browne also said that . . . to produce a clear and warrantable body of truth we must forget and part with much we know; and too many of the notions that we must jettison have been inflicted upon us by our teachers. Today assembly language is a putatively 'advanced' topic; it is not usually learned first; and students who are already familiar with storage classes (with the differences among static, LIFO automatic, and non-LIFO heap storage) can and should be introduced to reentrant assembly-language methods at the outset of their training. John Gilmore Ashland, MA 01721-1817 USA -- 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
No idea. UNIX certainly has a *similar* exit value (as they call return codes) culture: 0 = success, etc. They tend to use 1, 2, 3, ... not 4, 8, 12, 16, and I don't think there is any equivalent to the MVS culture of 4 = warning, 16 = disaster. BTW, another how come question would be how come MVS has always used return codes of 4, 8, 12, ... and not 1, 2, 3, ...? I have this vague notion it was so the caller could use the return code to index into a branch table, but I may be imagining that. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Friday, October 20, 2006 8:08 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Multiple FTP Problems Charles, Just curious as to why that is. I know the IBM unix people don't play (all the time) by the MVS world, would it be a good thing to try and create a SHARE requirement to do so (play be the rules)? -- 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?
Ted MacNEIL wrote: I have seen students so burdened with the complexities of the advanced topics that they never pick up the basics well. At issue is not whether advanced topics should be taught to beginners -- most would agree that's folly -- but whether the concepts of storage acquisition, DSECTs and ordinary USINGs should be considered advanced assembler language topics in the first place. Assembler language can be complex and there are many things to learn. IMHO if your ASM101 class doesn't teach you about DSECTs and ordinary USINGs, you're in deep trouble as an assembler programmer. And, if the class will teach you about invoking system services via macros, such as OPEN, CLOSE, GET, and PUT, there's no reason it can't teach STORAGE OBTAIN as well. A discussion of the reasons why reentrant code tends to run faster than non-reentrant code would take longer and be a far more advanced than simply teaching new programmers to always acquire working storage. In a lab setting on a test machine running z/OS, I would also enable the CsvRentSp252 DIAG trap to ensure that reentrant programs loaded from _unauthorized_ libraries reside in subpool 252. Abend0C4 can be an extremely useful debugging aid! ;-) [That last bit is for Ed Jaffe's class. Not Steve Comstock's class, Mike Stack's class, or even John Gilmore's class, though I suspect John might agree with me on this point.] Besides, I don't see graduates of ASM101 writing exits or LPA-destined code. Are you kidding?! We see them every day! (We refer to them as customers!) Certainly, there are many system programmers who are proficient with assembler language. But, there are quite a few others that could benefit from a class like Steve offers. Exits and other code within an existing reentrant framework can usually be modified without a full understanding of reentrancy. The assembler RENT option can help prevent mistakes in simple programs. Abend0C4 is a useful debugging aid as well. (See above.) As with most complex undertakings, a full understanding is ideal. And, a partial understanding is better than none at all. From my point of view, any teaching of assembler language is a good thing. I won't quibble over what should be taught in the first week of class. -- 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?
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 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?
Charles Mills wrote: And then there is no way to test that the code really is reentrant (that I know of -- am I missing something?) without running it APF-authorized. Now there's a winner: testing brand new code in anything goes mode! Enable the CsvRentSp252 DIAG trap on your development systems. Abend0C4 is an extremely useful debugging tool, even for unauthorized code! 8-) -- 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
Open Text Acquires Hummingbird
See http://www.opentext.com/news/pr.html?id=1767 Hopefully, this will mean good news for the troubled HostExplorer emulator and related products. -- 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?
Sure. True quick-and-dirties. My product supports DD overrides using the typical second parameter convention. I have an assembler program to exercise that feature. It consists of a LINK macro and a few DCs. Reentrance would be overkill. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Saturday, October 21, 2006 7: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? -- 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?
Consider that I have a program running in private storage which issues a GETMAIN to acquire working storage. The GETMAIN is unsuccessful. I now wish to issue a WTO to the console to inform the system operator of the condition and to supply diagnostic information (return code, reason code). In a reentrant situation, I would copy the WTO PLIST to working storage, insert the substitution data, and then issue a WTO MF=(E,plist). However, I have no working storage. In this case, I am left with no choice but to modify the real PLIST, which is not a problem since I am running in private storage, and the CSECT has no requirement to be reentrant. John P Baker Software Engineer -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Saturday, October 21, 2006 10:59 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 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?
The following message is a courtesy copy of an article that has been posted to alt.folklore.computers as well. [EMAIL PROTECTED] (John P Baker) writes: Reentrancy may be preferred, but it is not always reasonable or even possible. Each situation must be evaluated on its own merits. so possibly not just simple reentrancy ... but also thread/multitasking *safe* ... including use of compareswap semantics slightly related posts from a.f.c. http://www.garlic.com/~lynn/2006s.html#21 Very slow booting and running and brain-dead OS's? http://www.garlic.com/~lynn/2006s.html#40 Ranking of non-IBM mainframe builders? including needing new programming paradigm to leverage parallel thruput on the increasingly multiprocessor machines. http://www.garlic.com/~lynn/2006s.html#19 Very slow booting and running and brain-dead OS's? as i've mentioned before, charlie had been doing a lot of work on multiprocessor fine-grain locking on cp67 kernel at the science center http://www.garlic.com/~lynn/subtopic.html#545tech and invented the compareswap instruction (original mnemonic chosen because CAS are charlie's initials). initial attempt at getting compareswap into 370 architecture was rebuffed by the (370 architecture) redbook owners. they effectively said that the mainstream operating system (i.e. os/360 derivatives) were doing just fine in their multiprocessor support carrying over the testset instruction from 360 (and extremely course-grain locking). the challenge was that to get compareswap instruction into 370 ... it needed to have uses that were non-multiprocessor specific. thus was born the compareswap description for multitreaded/multitasking ... originally including in the programming notes for compareswap ... since moved to the appendix of principles of operation A.6 Multiprogramming and Multiprocessing Examples http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6?SHELF=DZ9ZBK03DT=20040504121320 from above: When two or more programs sharing common storage locations are being executed concurrently in a multiprogramming or multiprocessing environment, one program may, for example, set a flag bit in the common-storage area for testing by another program. It should be noted that the instructions AND (NI or NC), EXCLUSIVE OR (XI or XC), and OR (OI or OC) could be used to set flag bits in a multiprogramming environment; but the same instructions may cause program logic errors in a multiprocessing configuration where two or more CPUs can fetch, modify, and store data in the same storage locations simultaneously. Subtopics: * A.6.1 Example of a Program Failure Using OR Immediate * A.6.2 Conditional Swapping Instructions (CS, CDS) * A.6.3 Bypassing Post and Wait * A.6.4 Lock/Unlock * A.6.5 Free-Pool Manipulation * A.6.6 PERFORM LOCKED OPERATION (PLO) ... snip ... misc. collected posts related to multiprocessor support http://www.garlic.com/~lynn/subtopic.html#smp and some other recent threads touching on programming techniques (including mention of PLI program that I had written in the early 70s that analyzed 360 assembler listings ... control flow, register useage, etc ... and then attempted to generate higher level program representation) http://www.garlic.com/~lynn/2006e.html#32 transputers again was: The demise of Commodore http://www.garlic.com/~lynn/2006p.html#1 Greatest Software Ever Written? http://www.garlic.com/~lynn/2006p.html#4 Greatest Software Ever Written? http://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks) http://www.garlic.com/~lynn/2006s.html#27 Why these original FORTRAN quirks? -- 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 have problems with this assertion. 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. It is true that you can share copies of a reentrant module across address spaces, which can eliminate the need for repeated LOAD requests, and can save memory. However, an evaluation of how and where the module is to be used is needed in order to determine whether writing the module to be reentrant is justifiable. A flat assertion of better performance is not supportable. John P Baker Software Engineer -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Saturday, October 21, 2006 11:24 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? reentrant code tends to run faster than non-reentrant code Could you elaborate on that? I understand that there is a savings if reentrant code can be reused without reloading (such as if it is resident in the LPA) but why would reentrant code be inherently faster than non-reentrant? There is certainly an additional overhead for GETMAIN, storage initialization, often an extra level of indirection, etc. Reentrant design often burns one more register, which may in turn lead to additional register save and restore operations. Reentrant code is typically more scattered in its storage references, which increases paging overhead (at least in theory). It's an academic question, I admit. 99% of all assembler code is so fast it does not matter, and the 1% that matters can always be optimized despite any considerations for reentrance. I'm just curious about your assertion. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Dan Ponta
Could someone please remove Dan Ponta [EMAIL PROTECTED] from the mailing list? He is no longer at that address and I am receiving a message to that effect with every post. John P Baker Software Engineer -- 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 A program that is re-entrant according to the strict definition is one that spontaneously re-enters itself. We call such behavior a loop. -unsnip--- Sometimes we call it recursion. G -- 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- I have problems with this assertion. 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. It is true that you can share copies of a reentrant module across address spaces, which can eliminate the need for repeated LOAD requests, and can save memory. However, an evaluation of how and where the module is to be used is needed in order to determine whether writing the module to be reentrant is justifiable. A flat assertion of better performance is not supportable. --unsnip John, it's a function of the internal cache usage; z900 and later processors have a separate caches for instruction fetch and data fetch; usage DOES have a significant effect on performance. While the factors you cite can have an effect, experimentation has born out the fact that the basic assertion is valid. -- 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 writes: Reentrant code is typically more scattered in its storage references, which increases paging overhead (at least in theory). Properly qualified, this once good theory can be rescued. Locality of data reference is good, and locality of instruction reference is good. Global locality of reference, intermixing data and instructions, is very, very bad. z/Architecture processors have been optimized for (mostly) compiler-generated reentrant code, and they are very bad at executing non-reentrant code. This is not really an issue for compromise or for statesmanlike fatuities of the form 'Reentrant code has important uses; on the other hand there is scope for non-reentrant constructions'. As I indicated in my OP, there is no longer any rationale or excuse for writing non-reentrant code. En passant 1, I am familiar with the quondam geometric use of the word 'reentrant'. It is no longer current, and in any case it is not a bar to another use in another place. In his treatise on the astrolabe Chaucer described himself as a mere lewd compilator; but his use of the term 'lewd' to mean that he was a layman, not in holy orders, is not a bar to its modern uses. En passant 2, in English 'a and b and c' and 'a; b; c' are indeed equivalent. Moreover, the semicolon is mandatory when the conjunction is omitted. The converse notion that a semicolon may not be used when a conjunction is used is, however, ridiculous (and ridiculed memorably by Fowler). The other major use of semicolons (outside of ALGOL-like statement-level procedural languages) is as separators for independent clauses (linked by conjunctions) that themselves contain commas. John Gilmore Ashland, MA 01721-1817 USA _ Stay in touch with old friends and meet new ones with Windows Live Spaces http://clk.atdmt.com/MSN/go/msnnkwsp007001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us -- 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?
Steve Samson wrote: Um, Steve, reenterable was the original word circa 1964. 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. -Steve Comstock Some IBM dockie circa 1970 thought that that looked too complex and found the word reentrant in a dictionary. Unfortunately, he or she did not read the definition. Reentrant meant a closed curve that had at least one concave segment, i.e. it re-entered itself. Reenterable means a program that is capable of being re-entered without compromising data integrity. The -able suffix is the essence of the word. A program that is re-entrant according to the strict definition is one that spontaneously re-enters itself. We call such behavior a loop. /rant Steve Comstock[EMAIL PROTECTED] writes: Well, when you are learning Assembler, the work to write reentrant (I, too, prefer that term to the relatively new-fangled reenterable) can get in the way of focusing on simply how the instructions work and how to string together series of instructions to accomplish specific tasks. -- 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?
If the reentrant program must acquire and release storage (via GETMAIN/FREMAIN or STORAGE ACQUIRE/RELEASE) during each invocation, I can not see how the operation of the internal cache is going to make a difference of sufficient significance to support the performance assertion. If the reentrant program does not have to invoke these or other system services, it may be a different matter. In fact, I would expect the performance characteristics to be quite different. My experience is that the assertion that reentrant programs ALWAYS perform better than non-reentrant programs can not be justified. There are simply too many variables involved. John P Baker Software Engineer -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Saturday, October 21, 2006 12:02 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? John, it's a function of the internal cache usage; z900 and later processors have a separate caches for instruction fetch and data fetch; usage DOES have a significant effect on performance. While the factors you cite can have an effect, experimentation has born out the fact that the basic assertion is valid. -- 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?
Non-mainframers tend to use the word reentrant to mean what we mainframers would call recursive. 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). btw: I would offer the definition of non-reentrant to be a program designed either to modify itself or a program that may misbehave when executed concurrently by multiple units of work. Mainframers tend to use the word refreshable to mean a program that does not modify itself at all, so that it could be refreshed from external storage medium at any time *and* any concurrently executing units of work would not detect the refresh. A refreshable program is also specifically designed for correct behavior during concurrent execution by multiple units of work. btw: I always write my reentrant programs as though they are refreshable. I always design my programs to be reentrant *unless* there is a specific reason that requires the program to be non-reentrant. Personal convenience alone is not sufficient justification to design a program as non-reentrant, other than for a throw away program that I expect to use only once. 2 cents worth. Your mileage may vary. Jeffrey D. Smith Principal Product Architect Farsight Systems Corporation 700 KEN PRATT BLVD. #204-159 LONGMONT, CO 80501-6452 303-774-9381 direct 303-484-6170 FAX http://www.farsight-systems.com/ comments are invited on my encryption project -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Saturday, October 21, 2006 9:53 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? snip A program that is re-entrant according to the strict definition is one that spontaneously re-enters itself. We call such behavior a loop. -unsnip--- Sometimes we call it recursion. G -- 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?
A reentrant program need not use GETMAIN/FREEMAIN/STORAGE. I've written zillions of reentrant routines that rely on the caller to provide a work area or that rely on pre-allocated storage areas (usually PC routines). Using pre-allocated or caller-specified work areas is extremely fast. If a caller provides a work area that is allocated within itself, then the caller is non-reentrant, but the called routine is still reentrant. 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 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John P Baker Sent: Saturday, October 21, 2006 10:17 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? If the reentrant program must acquire and release storage (via GETMAIN/FREMAIN or STORAGE ACQUIRE/RELEASE) during each invocation, I can not see how the operation of the internal cache is going to make a difference of sufficient significance to support the performance assertion. If the reentrant program does not have to invoke these or other system services, it may be a different matter. In fact, I would expect the performance characteristics to be quite different. My experience is that the assertion that reentrant programs ALWAYS perform better than non-reentrant programs can not be justified. There are simply too many variables involved. John P Baker /snip/ -- 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: And a corollary would be why DID IBM make it so darned hard to write reentrant assembler code? Some IBM macros can be used in standard form without a problem. Some simply require MF=E with MF=L in the DSECT. Some require MF=L in the DSECT and a model in CSECT storage that you move to the DSECT (or home-built initialization code that defeats the purpose of standard macros). Some have internal address constants that must be relocated after a move to a DSECT. Some executable forms generate standard address constants that are incompatible with DSECTs. Often it depends on which operands you code, so a simple change to a macro may create a totally unexpected problem. And the documentation does not usually bother to tell you which is which. You cannot use a single IBM executable macro in a reentrant environment without examining the assembled code to make certain it will not have a problem (unless you are already very familiar with the particular macro). A symptom of a mature operating system. The now decades-old services allowed parameters to be set along with MF=L and attempted to merge options in their MF=E expansions. The new services merely reserve space and declare symbols in their MF=L expansions and their MF=E expansions zero the parameter list before updating it. Upward compatibility concerns make it impossible to go back and change the older services to use the newer approach. The only option is to replace them the way the new ISG services have replaced ENQ/DEQ and GQSCAN. Don't expect such replacements to be commonplace. -- 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?
John P Baker writes: My experience is that the assertion that reentrant programs ALWAYS perform better than non-reentrant programs can not be justified. There are simply too many variables involved. This is, at best, a straw man, constructed to facilitate dismemberment. The textbook proposition There are no black swans. has an empirical defect: real blank swans have been found to exist. More important, it is in logic a universal negative; and it can be proved that no instance of an universal negative can be proved. The existence of some non-reentrant block of code that is faster than the corresponding reentrant one is no argument for writing non-reentrant code. In the light of the character of the defenses of doing so set out here after my post, I must, however, conclude that this issue is for some an emotional and not an intellectual one. So be it! John Gilmore Ashland, MA 01721-1817 USA _ Add a Yahoo! contact to Windows Live Messenger for a chance to win a free trip! http://www.imagine-windowslive.com/minisites/yahoo/default.aspx?locale=en-ushmtagline -- 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?
You are correct in that an optimal situation exists when necessary dynamic storage can be supplied to a reentrant program by the caller. However, that is not ALWAYS the case. My objection is to the use of the term ALWAYS. To paraphrase something read years ago, THE ONLY ABSOLUTE IS THAT THERE ARE NO ABSOLUTES. John P Baker Software Engineer -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey D Smith Sent: Saturday, October 21, 2006 12:24 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? A reentrant program need not use GETMAIN/FREEMAIN/STORAGE. I've written zillions of reentrant routines that rely on the caller to provide a work area or that rely on pre-allocated storage areas (usually PC routines). Using pre-allocated or caller-specified work areas is extremely fast. If a caller provides a work area that is allocated within itself, then the caller is non-reentrant, but the called routine is still reentrant. 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?
Charles Mills wrote: Sure. True quick-and-dirties. My product supports DD overrides using the typical second parameter convention. I have an assembler program to exercise that feature. It consists of a LINK macro and a few DCs. Reentrance would be overkill. You've hit a sore spot with me. In my experience, anything (not just a program) that starts out as a One Off or Quick Dirty implementation often has a way of eventually being used for daily, production use. There's always time to do something over but never enough time to do it right the first time. Like others on this list, I write 99% reentrant code and believe that non-reentrant programs and programming techniques should generally be discouraged, _especially_ when working with less experienced programmers. Of course, there are always exceptional cases in which reentrancy can/should not be used. But focusing on such exceptions gives the false impression that they are more numerous than they actually are. Bad habits are harder to unlearn than to never learn in the first place. I think everyone reading this can agree that adding something like what's shown below to a program skeleton is trivial: | STORAGE OBTAIN,LENGTH=MyWkLen | LRRx,R1 | USING MyWk,Rx | . | . (program here) | . |MyWk DSECT , | . | . (data here) | . |MyWkLenEQU *-MyWk In my code, the DSECT usually precedes the code, but that's a topic for another thread ... on ASSEMBLER-LIST. -- 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?
z900 and later processors have a separate caches for instruction fetch and data fetch; usage DOES have a significant effect on performance 9672's and later. I remember SAS having issues with this long before z. Optimisation of ASM is an art that has long lost its need. You can take the savings toss in $5 and buy a beer. Now, optimisation of I/O is where you will find your benefits. 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
Re: Multiple FTP Problems
Charles, I guess I always thought that it was easier to to use shift left to get the desired return code. In any case now for 20+ years its worked fine why change it? Ed On Oct 21, 2006, at 9:41 AM, Charles Mills wrote: No idea. UNIX certainly has a *similar* exit value (as they call return codes) culture: 0 = success, etc. They tend to use 1, 2, 3, ... not 4, 8, 12, 16, and I don't think there is any equivalent to the MVS culture of 4 = warning, 16 = disaster. BTW, another how come question would be how come MVS has always used return codes of 4, 8, 12, ... and not 1, 2, 3, ...? I have this vague notion it was so the caller could use the return code to index into a branch table, but I may be imagining that. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Friday, October 20, 2006 8:08 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Multiple FTP Problems Charles, Just curious as to why that is. I know the IBM unix people don't play (all the time) by the MVS world, would it be a good thing to try and create a SHARE requirement to do so (play be the rules)? -- 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
Open Text Acquires Hummingbird
Hopefully, this will mean good news for ... On the basis of the bounce I keep getting, I'd say the RIF has started already. -- 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?
It seems I've touched off another little fire-storm :-) 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. As time passed, things became more complex (of course) but by then the horse had already bolted with respect to the classic techniques (list form macro expansions etc.) used by assembly language programmers. As Ed Jaffe pointed out it would be impossible to go and change all of those dependencies so the only alternative would be to deliver new functions that don't fall prey to the same problems. And of course, as long as the old style of programming is what is taught by default, nothing will ever significantly change. On other platforms, the run time environment is embedded in the fabric of the system. Reentrancy (or whichever similar term floats your boat) is the only way that exists and so people don't even give it a moment's thought. It just works that way. Your working storage is allocated automatically from the stack and for data that needs to have a separate lifetime than your function, malloc() is a fast sub-allocation from the heap. GETMAIN is conservatively 4 orders of magnitude slower, so it is trivial for compiled code running on a runtime to blow the doors off assembler code. In z/OS and ancestors, the run time environment has always been this grafted on chunk of mindless gooberware (LE) that has more controls than a nuclear reactor. To this day it is treated as a separate thing that exists to serve those HLL weenies, rather than just being taken for granted by everyone. But even with all of its faults, it is better than the nothing that assembler developers assume. 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. And if you did it on another platform, you wouldn't even be having this discussion at all. This is one of those areas where z/OS is truly a stone-age operating system. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 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 alt.folklore.computers,bit.listserv.ibm-man as well. Anne Lynn Wheeler [EMAIL PROTECTED] writes: A.6 Multiprogramming and Multiprocessing Examples http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/A.6?SHELF=DZ9ZBK03DT=20040504121320 from above: When two or more programs sharing common storage locations are being executed concurrently in a multiprogramming or multiprocessing environment, one program may, for example, set a flag bit in the common-storage area for testing by another program. It should be noted that the instructions AND (NI or NC), EXCLUSIVE OR (XI or XC), and OR (OI or OC) could be used to set flag bits in a multiprogramming environment; but the same instructions may cause program logic errors in a multiprocessing configuration where two or more CPUs can fetch, modify, and store data in the same storage locations simultaneously. Subtopics: * A.6.1 Example of a Program Failure Using OR Immediate * A.6.2 Conditional Swapping Instructions (CS, CDS) * A.6.3 Bypassing Post and Wait * A.6.4 Lock/Unlock * A.6.5 Free-Pool Manipulation * A.6.6 PERFORM LOCKED OPERATION (PLO) ... snip ... re: http://www.garlic.com/~lynn/2006s.html#53 Is the teaching of non-reentrant HLASM coding practices ever defensible? ... as to having people well versed with A.6.1 problems ... there was a rumor in the late 70s that the hardware engineers were approached by MVS group to make the immediate instructions atomic on multiprocessor machines. MVS was moving kernel from the old-style os/360 single global kernel/supervisor lock to higher degrees of kernel parallelism and were having a devil of a time converting all the non-atomic immediate instruction coding for parallel operation. ... having re-entrant programming supporting multiple concurrent operation ... including supporting multiple concurrent operation in same address space (aka threading/multitasking) ... for highly parallel operation. -- 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?
Two necessary steps you left out of your example are moving the model MF=Ls and similar structures to the DSECT, and the relocation of address constants in those structures. More complexity = more places for an error to occur. Further, I am working as a contractor, and most readers of this list are working for hourly wages, or are at least limited in what they can accomplish for their employers by the number of hours they work. I cannot justify putting more time into a program than is appropriate to its intended function, on the theory that making it reentrant would be more elegant. Obviously, I am not talking about cases where reentrancy has a tangible benefit to my employer. You ARE right that temporary programs and temporary taxes have a way of sticking around forever. But it's hard to see how my load the product with a bunch of stupid, hard-coded DD overrides ever makes it into daily production. I think one has to be willing to trust the good judgment of an experienced developer -- which is another way of saying what John Baker has said on this thread: there are few absolutes. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Saturday, October 21, 2006 9:34 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? You've hit a sore spot with me. In my experience, anything (not just a program) that starts out as a One Off or Quick Dirty implementation often has a way of eventually being used for daily, production use. There's always time to do something over but never enough time to do it right the first time. Like others on this list, I write 99% reentrant code and believe that non-reentrant programs and programming techniques should generally be discouraged, _especially_ when working with less experienced programmers. Of course, there are always exceptional cases in which reentrancy can/should not be used. But focusing on such exceptions gives the false impression that they are more numerous than they actually are. Bad habits are harder to unlearn than to never learn in the first place. I think everyone reading this can agree that adding something like what's shown below to a program skeleton is trivial: | STORAGE OBTAIN,LENGTH=MyWkLen | LRRx,R1 | USING MyWk,Rx | . | . (program here) | . |MyWk DSECT , | . | . (data here) | . |MyWkLenEQU *-MyWk -- 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?
Chris Craddock writes: 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. Yes indeed! My first exposure to the LE came when I had to write some things to be used by COBOL programmers, and I found that I could use the LE-supplied prologue and epilogue (stack-management) macros to preserve the COBOL environment without adding measurably to the burden these COBOL applications were already carrying. I was then agreeably surprised to learn that this was the case for heap storage too. Some of us who write a lot of assembly-language routines for other people to use have also developed our own stack- and heap-management macros and code. This is a viable alternative to use of the LE routines in situations in which the environment is not perforce an LE (because SLPL) one. Its limited use reflects the fact that the HLASM macro language is radically underused and under appreciated. (People of course code macro instructions, but they don't often write their own macro definitions.) But that is a topic for another thread in another place . . . John Gilmore Ashland, MA 01721-1817 USA _ Try Search Survival Kits: Fix up your home and better handle your cash with Live Search! http://imagine-windowslive.com/search/kits/default.aspx?kit=improvelocale=en-USsource=hmtagline -- 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 21 Oct 2006 05:54:37 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (john gilmore) wrote: Steve Comstock[EMAIL PROTECTED] writes: Well, when you are learning Assembler, the work to write reentrant (I, too, prefer that term to the relatively new-fangled reenterable) can get in the way of focusing on simply how the instructions work and how to string together series of instructions to accomplish specific tasks. 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. 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. (OS Assembler doesn't have this built-in AHA moment because we are taught to get our addressability from R15.) Until base and displacement addressing is fully internalized, you can't understand or appreciate RENT coding. Trying to teach it before that simpler understanding is, IMO, counterproductive. On the practical (as opposed to pedagogical) side: When I write a utility program that reads, manipulates, and writes data, I see no good reason to make it RENT. It's designed to be a single program running as a batch step. What is the advantage of copying DCBs and other control blocks into getmained storage? That adds unneeded complexity to the code, which therefore makes the program easier to miscode and harder to maintain. (Why write it in Assembler?, you ask. Because it's one of my two best languages.) -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot 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?
Just TWO things would make life so much simpler: 1. A universal hardware and OS stack. Then all the discussions about reentrance go away. 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. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Saturday, October 21, 2006 11:09 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? 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. snip And if you did it on another platform, you wouldn't even be having this discussion at all. This is one of those areas where z/OS is truly a stone-age operating system. -- 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?
Good link. Thanks Ed (and Cheryl). I was not aware specifically of the 256-byte I-cache. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Saturday, October 21, 2006 10:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? http://www.watsonwalker.com/PR010302.PDF -- 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 Sat, 21 Oct 2006 11:43:17 -0700 Charles Mills [EMAIL PROTECTED] wrote: :Just TWO things would make life so much simpler: :1. A universal hardware and OS stack. Then all the discussions about :reentrance go away. LE will sort of give you that (on the software side). :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. Only if all programs are changed. And, from the assembler side, it is good to be able to play with the control blocks. HLL's will sort of give you what you want. -- 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?
Edward Jaffe wrote: A symptom of a mature operating system. The now decades-old services allowed parameters to be set along with MF=L and attempted to merge options in their MF=E expansions. The new services merely reserve space and declare symbols in their MF=L expansions and their MF=E expansions zero the parameter list before updating it. While it would not be efficient for frequently executed macros, for which the MF=E/static, copied MF=L/dynamic MF=L forms are preferable, it would be nice to have an MF=(R,workarea) form where the code will expand to do whatever is necessary in a single macro invocation. For a number of macros, this would be no more onerous than adding a few AIFs. But many of IBM's macros could do with a complete rewrite, perhaps using inner macros to handle standard situations (load a register, place a value in a list, set a flag, etc.). 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
john gilmore wrote: Chris Craddock writes: 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. Yes indeed! My first exposure to the LE came when I had to write some things to be used by COBOL programmers, and I found that I could use the LE-supplied prologue and epilogue (stack-management) macros to preserve the COBOL environment without adding measurably to the burden these COBOL applications were already carrying. I was then agreeably surprised to learn that this was the case for heap storage too. For a few years, we were teaching our course Using LE Services in z/OS (and its OS/390 predecessor equivalent) frequently. This is a multi-lingual course (COBOL, PL/I, C, and Assembler) and we discuss how to use all the callable services in the language(s) of interest to the students. In the discussion of LE-enabled Assembler, we also demonstrate how to use the LE macros to generate reentrant code. But we haven't been asked to teach that course in over six years. [Even so, I keep it current, just having finished the z/OS 1.8 version which, by the way, added some significant new callable services.] Some of us who write a lot of assembly-language routines for other people to use have also developed our own stack- and heap-management macros and code. This is a viable alternative to use of the LE routines in situations in which the environment is not perforce an LE (because SLPL) one. Its limited use reflects the fact that the HLASM macro language is radically underused and under appreciated. (People of course code macro instructions, but they don't often write their own macro definitions.) But that is a topic for another thread in another place . . . Indeed. Mainframers just don't seem to have as much fun as we used too. Kind regards, -Steve Comstock -- 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: Software pricing
Phil Payne wrote: The 1956 consent decree between the Department of Justice and IBM, of Armonk, N.Y., resulted in several restrictions on the company that were designed to prevent it from becoming a monopoly in the computer industry. There are currently no Consent Decree or similar restrictions on IBM. The last was the 1984 EC Undertaking that mainly concerned the timely availability of interface information. I'm not sure you're correct about that. The 1956 consent decree required IBM to make hardware available for purchase; prior to that all hardware was available on lease only. In 1968 or 1969, I worked for Applied Data Research, when Marty Goetz decided to sue IBM for giving away free software, to the purported detriment of ISVs (my experience was otherwise - you look at IBM's code, and come up with better, cheaper, and faster solutions). ADR at the time was peddling Roscoe. As part of the consent decree, IBM was forced to start charging for software. They also agreed to have their sales staff market Roscoe as well as CRBE, but to my knowledge nothing ever came of that. 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: Is the teaching of non-reentrant HLASM coding practices ever defensible?
And doing this while keeping true to compatability allowances unique to the platform? If customers discover that they will be required to, in a fell swoop, replace all installed hardware, software, interfaces, etc. how many would stick with this platform? Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Saturday, October 21, 2006 1:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? Just TWO things would make life so much simpler: 1. A universal hardware and OS stack. Then all the discussions about reentrance go away. 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. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Saturday, October 21, 2006 11:09 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? 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. snip And if you did it on another platform, you wouldn't even be having this discussion at all. This is one of those areas where z/OS is truly a stone-age operating system. -- 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?
On Sat, 21 Oct 2006 16:30:59 +, john gilmore [EMAIL PROTECTED] wrote: More important, it is in logic a universal negative; and it can be proved that no instance of an universal negative can be proved. Hmmm. So there is a proof that no proof of a universal negative can exist. This appears to verge on self-contradiction. But I'll readily accept that axiomatic proofs of universal negatives can exist, but not empirical proofs. Or, are you dealing in something similar to FOPC, where proofs themselves are not elements of the universe of discourse? -- 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?
At 07:58 -0700 on 10/21/2006, Charles Mills wrote about Re: Is the teaching of non-reentrant HLASM coding practices: And then there is no way to test that the code really is reentrant (that I know of -- am I missing something?) without running it APF-authorized. Use RENT as well as RSECT instead of CSECT and you will get TOLD at assembly time when you're not reentrant. -- 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 Robert A. Rosenberg Sent: Saturday, October 21, 2006 3:09 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? At 07:58 -0700 on 10/21/2006, Charles Mills wrote about Re: Is the teaching of non-reentrant HLASM coding practices: And then there is no way to test that the code really is reentrant (that I know of -- am I missing something?) without running it APF-authorized. Use RENT as well as RSECT instead of CSECT and you will get TOLD at assembly time when you're not reentrant. Not every time. 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. 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?
Cobol was really easy, because I was fresh out of second semester assembler. 1st semester was PDP 11, second was os370. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Comstock Sent: Saturday, October 21, 2006 6:43 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? john gilmore wrote: Steve Comstock[EMAIL PROTECTED] writes: Well, when you are learning Assembler, the work to write reentrant (I, too, prefer that term to the relatively new-fangled reenterable) can get in the way of focusing on simply how the instructions work and how to string together series of instructions to accomplish specific tasks. This pedagogic argument is a hoary one that cannot be dismissed out of hand. Complexities must sometimes be deferred. Agreed. Newtonian mechanics, which has its own legitimate and useful purview, is for example taught first, before relativistic mechanics, in physics curricula. True Deference to what Sir Thomas Browne politely called 'junior understanding' is, however, too frequent. To teach techniques that have no legitimate non-pedagogic uses is, I think, indefensible. Well, I agree. In our programming courses, we _never_ use a Hello World program as an example: how often do you need that in the real world? Never. We always begin with how to describe fields, records, and files and how to use the appropriate file I/O verbs. Never write a line of code to be thrown away. Browne also said that . . . to produce a clear and warrantable body of truth we must forget and part with much we know; and too many of the notions that we must jettison have been inflicted upon us by our teachers. And much that has proven valuable in our lives has also been inflicted upon us by our teachers. It is true we must often let go of, or unlearn, what we once thought was truth. Or at least continually re-examine our assumptions, biases and beliefs. As a Unitarian, we are constantly challenged: To question is the answer. But, I digress... Today assembly language is a putatively 'advanced' topic; it is not usually learned first; and students who are already familiar with storage classes (with the differences among static, LIFO automatic, and non-LIFO heap storage) can and should be introduced to reentrant assembly-language methods at the outset of their training. Most often the audience for my Assembler classes are either new to programming or their experience is with COBOL; in neither case are they familiar with storage classes and their differences. So we defer reentrant coding until their 8th day of training. By then they are ready to focus on this. That's just my real world experience talking. Kind regards, -Steve Comstock -- 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?
Which is EXACTLY what LOTS of the IBM macros do! OPEN ((R4)),MODE=31 + CNOP 0,4 ALIGN LIST TO HALFWOR + BAS 1,*+12 LOAD REG1 W/LIST ADDR + DCA(0) OPTION BYTE + DCA(0) DCB ADDRESS + STR4,4(1,0)STORE INTO LIST + MVI 0(1),128 MOVE IN OPTION BYTE + LR0,1 POINT REG0 TO PLIST + SR1,1 CLEAR REGISTER 1 + SVC 19 ISSUE OPEN SVC No error there if RENT or RSECT. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey D. Smith Sent: Saturday, October 21, 2006 2:44 PM To: IBM-MAIN@BAMA.UA.EDU Subject: 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 Robert A. Rosenberg Sent: Saturday, October 21, 2006 3:09 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? At 07:58 -0700 on 10/21/2006, Charles Mills wrote about Re: Is the teaching of non-reentrant HLASM coding practices: And then there is no way to test that the code really is reentrant (that I know of -- am I missing something?) without running it APF-authorized. Use RENT as well as RSECT instead of CSECT and you will get TOLD at assembly time when you're not reentrant. Not every time. LA R3,FUBAR ST R2,0(0,R3) No way for the assembler to determine that the ST is storing into field FUBAR. -- 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. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Wayne Driscoll Sent: Saturday, October 21, 2006 12:50 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? And doing this while keeping true to compatability allowances unique to the platform? If customers discover that they will be required to, in a fell swoop, replace all installed hardware, software, interfaces, etc. how many would stick with this platform? Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Saturday, October 21, 2006 1:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? Just TWO things would make life so much simpler: 1. A universal hardware and OS stack. Then all the discussions about reentrance go away. 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. -- 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?
Whoa !!! In all this, maybe the most interesting facet is that we managed to drag Steve Samson away from the bridge table. Guess his partner must have been declarer at the time ... ;-) Shane ... -- 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: Software pricing
That's my recollection also. I know it was around 1969 -- the second (software) consent decree, because that is the one year I worked for what would become Kraft Corporation, and my boss had me order every Type 3 (remember those -- free, unsupported, SE-written software?) program that he thought they could ever use, on the mistaken understanding that formerly free software was going to go to a charge basis. Somewhere in there also was the settlement with Control Data Corp., in which IBM agreed to foreswear the service bureau (hourly machine rental, for you young fellers) business, and gave Service Bureau Corporation to CDC as part of the settlement. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gerhard Postpischil Sent: Saturday, October 21, 2006 12:29 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Software pricing Phil Payne wrote: The 1956 consent decree between the Department of Justice and IBM, of Armonk, N.Y., resulted in several restrictions on the company that were designed to prevent it from becoming a monopoly in the computer industry. There are currently no Consent Decree or similar restrictions on IBM. The last was the 1984 EC Undertaking that mainly concerned the timely availability of interface information. I'm not sure you're correct about that. The 1956 consent decree required IBM to make hardware available for purchase; prior to that all hardware was available on lease only. In 1968 or 1969, I worked for Applied Data Research, when Marty Goetz decided to sue IBM for giving away free software, to the -- 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?
If a prog modify some part of the hardware I-cache it will run slower because the hardware cache becomes invalid. Reentrant coding avoid this. Well also the getmain/freemain for reentrant code require some cylce. I don't know what is better in terms of CPU for a quick and dirty pgm. Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Saturday, October 21, 2006 5:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? reentrant code tends to run faster than non-reentrant code Could you elaborate on that? -- 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.)
Ted The major Canadian banks all sell insurance and have done so since, IIRC, the early 90's. However I don't believe they can as yet use their branch networks to market insurance -- you can certainly buy direct from their Internet sites. James F. Smith -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: 21 October 2006 04:29 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: INTERNET Banks (WAS: Resume cover letters.) UK banks are highly diversified - they sell all sorts of financial packages; mortgages, insurance, etc. Canadian Banks aren't allowed to sell insurance (yet); they are otherwise as diversified. But, the INTERNET is more to help existing (mostly retail) retail. This is to reduce costs more than improve customer service. 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
Re: Question on the load list
Minor things (many folks provided great answering appends) JPA: Job Pack Area. It is not CDEs. It is modules each of which is represented by a CDE JPQ: Job Pack Queue. This is the queue of CDEs 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. Contents Supervision was rewritten by Bob Rogers for MVS/XA. PLPA modules are required to be refreshable (which is stronger than reentrant) LLE's point either to CDEs (on the JPQ or in active LPA) or to LPDEs. An LLE is the validation for DELETE. If there is no LLE, you cannot DELETE. 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: Question on the load list
Peter: Thanks for the definitions. I guess my memory is partially paged out. Why is the nuc linked with sctr? Ed On Oct 21, 2006, at 9:32 PM, Peter Relson wrote: -- 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: Software pricing
On Sat, 21 Oct 2006 16:40:01 -0700, Charles Mills [EMAIL PROTECTED] wrote: Somewhere in there also was the settlement with Control Data Corp., in which IBM agreed to foreswear the service bureau (hourly machine rental, for you young fellers) business, and gave Service Bureau Corporation to CDC as part of the settlement. And, I understand, in return CDC had to agree to dismantle the data base of evidence it had used to press the suit. -- 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 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. -- 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: 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
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
