(fwd) Re: amode rmode problem
On 21 Mar 2006 17:46:17 -0800, in bit.listserv.ibm-main [EMAIL PROTECTED] (Edward E. Jaffe) wrote: Tom Savor wrote: Ed wrote: Tom Savor wrote: Thanks to some enlightenment from Mr Rutledge, all my Assembler programs run AMODE(31), RMODE(ANY). 1). GETMAIN storage location as ANY. 2). Copy DCB to GETMAINed area 3). Open file as example: OPEN (FILE,(INPUT)),MODE=31 4). Get File as example: GET FILE,AREA 5). Close file as example: CLOSE (FILE),MODE=31 #1 above GETMAIN location should be BELOW or 24 -- not 31 or ANY. Sorry Ed, but the GETMAIN location is set to ANY. If the DSORG is PO, then I use BELOW for READ and WRITE processing of PDS. But for normal QSAM processing and my example, program is set to ANY. Then I must be confused about what it is you're doing with this GETMAIN. DCBs must (MUST!) be below 16MB in all cases because, among other things, the pointer to the DCB from the DEB is only three bytes long! LOC=ANY implies 31-bit storage (though it *could* actually be satisfied from 24-bit storage if 31-bit storage is exhausted -- very unlikely). We _are_ talking about the *first* (or only) LOC= subparameter, right? The second subparameter controls only the location of the real storage when the page is fixed. Why the unprintable hasn't IBM extended the ACB to handle at least QSAM (and parenthetically allowed concatenation of ESDS and QSAM data sets)? To have to go through the aggravation of getting 24 bit storage in 2006 is one minor symptom for the mainframe not have good long term prospects. Naturally, the above has nothing whatsoever to do with the location of your program. Your program can reside anywhere. -- 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 -- 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: (fwd) Re: amode rmode problem
I think z/OS has very good long term prospects just because of what you think is a symptom. Because of downward compatibility, a program written 30+ years ago can still work today. Things introduced post 31-bit addressing use it. The problem I see for z/OS is what people use it for. Its role has changed from just a batch job machine to a giant server. In terms of capacity to handle a tremendous number of online queries, it can not be beat. Which is why UPS, FedEx and most all large companies rely on the z/Series machines to support their critical workloads. Christopher Y. Blaicher BMC Software, Inc. Austin Development Labs (512) 340-6154 The comments made are my personal opinions. BMC Software, Inc. makes no representations or promises regarding the reliability, completeness, or accuracy of the information provided in this discussion; all readers agree not to rely on this information or take any action against BMC Software in response to this information. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Clark Morris Sent: Wednesday, March 22, 2006 10:34 AM To: IBM-MAIN@BAMA.UA.EDU Subject: (fwd) Re: amode rmode problem Why the unprintable hasn't IBM extended the ACB to handle at least QSAM (and parenthetically allowed concatenation of ESDS and QSAM data sets)? To have to go through the aggravation of getting 24 bit storage in 2006 is one minor symptom for the mainframe not have good long term prospects. -- 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: (fwd) Re: amode rmode problem
To have to go through the aggravation of getting 24 bit storage in 2006 is one minor symptom for the mainframe not have good long term prospects. You're joking right? We're talking about a minor and pretty insignificant piece of coding to basically maintain downward compatibility with code that is several decades old. It is only of concern for Assembler language programmers who aren't exactly the most abundant element in I/T. So, why should this play into the mainframe's long-term prospects? Adam -- 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
(fwd) RE: (fwd) Re: amode rmode problem
On 22 Mar 2006 09:47:12 -0800, in bit.listserv.ibm-main [EMAIL PROTECTED] (Blaicher, Chris) wrote: I think z/OS has very good long term prospects just because of what you think is a symptom. Because of downward compatibility, a program written 30+ years ago can still work today. Things introduced post 31-bit addressing use it. I have no problem with IBM functionally stabilizing the DCB to protect existing programs. I have a major problem with them not coming up with a clean way to access those data set organizations which were not functionally stabilized without having to get 24 bit storage. Indeed we have a major shift coming with 64 bit. IBM COBOL already seems to be steadfastly ignoring it and XPLINK as well. We have the ludicrous situation where instead of implementing the 2002 COBOL standard floating point usages and declaring them to be IEEE floating point leaving COMP-1 and COMP-2 to remain hex floating point, IBM has a glue routine when interfacing with JAVA. I have a major problem with IBM not handling FBA devices despite the fact that all of the strategic access methods (VSAM, PDSE, databases) are FBA. There are still 24 bit modules in TSO and TSO is functionally stabilized despite there still not being a follow-on. The problem I see for z/OS is what people use it for. Its role has changed from just a batch job machine to a giant server. In terms of capacity to handle a tremendous number of online queries, it can not be beat. Which is why UPS, FedEx and most all large companies rely on the z/Series machines to support their critical workloads. Christopher Y. Blaicher BMC Software, Inc. Austin Development Labs (512) 340-6154 The comments made are my personal opinions. BMC Software, Inc. makes no representations or promises regarding the reliability, completeness, or accuracy of the information provided in this discussion; all readers agree not to rely on this information or take any action against BMC Software in response to this information. rest snipped -- 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
