Re: IBM Preview of z/OS V1.10
From the Share session what's new in DFSMS under z/OS V1.9 Statement of Direction VSAM KEYRANGE Attribute • Support for the VSAM KEYRANGE attribute will not be withdrawn as previously stated • No supported release of z/OS allows you to define new VSAM data sets with the KEYRANGE attribute • On modern storage devices, KEYRANGE is generally detrimental to performance. For this reason, IBM recommends that you minimize or eliminate your use of KEYRANGE. • Striped data sets are expected to provide better performance than KEYRANGE, and can be viewed as a good replacement for KEYRANGE data sets. • To detect the KEYRANGE attribute on existing data sets, refer to INFO APAR II13894. • Use the DFSMShsm ARCTOOLS (FINDKRDS) to detect this attribute for data sets migrated with DFSMShsm. Details on how to use this tool are in the DFSMShsm Implementation and Customization Guide (SC35-0418). and VSAM IMBED and REPLICATE Attributes • In a future release of z/OS, when DFSMShsm or DFSMSdss recalls or restores a VSAM data set with either IMBED or REPLICATE attribute or both, the attributes will be removed. • Once recalled or restored, the data sets would no longer have these attributes. Until this enhancement is made available, support for IMBED and REPLICATE will not be withdrawn. • No supported release of z/OS allows you to define new VSAM data sets or catalogs with the IMBED or REPLICATE attributes • Using them for existing data sets can waste DASD space and can often degrade performance, and for this reason, IBM recommends that you stop using these attributes. • For information about how to detect IMBED and REPLICATE attributes on existing data sets and catalogs, refer to INFO APAR II13894. • Tivolitm Advanced Catalog Management for z/OS also has the ability to remove these attributes Regards, Chris Taylor -- 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: IBM Preview of z/OS V1.10
Well I've just seen my first one (actually 2) as they were being delivered. Don't look much different to the previous versions. Personally I'm waiting for the plethora of postings asking if OS/390 can run on it... Seb. -- 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: IBM Preview of z/OS V1.10
Mark Zelden wrote: [...] On another preview note: I (still) don't see anything about the removal of support for opening VSAM data sets with IMBED or REPLICATE. The only mention is how VSAM data sets with IMBED (and KEYRANGE) relate to Extended Address Volumes (EAVs).I really wish IBM would at least commit to a date / release already so I can get the dasd geeks to really take some action on this issue. It seems to me this is a proof that KEYRANGE and IMBED are still supported. No such proof for REPLICATE ...but who cares ? It's obsloteted for years (I mean REPLICATE and IMBED as well). Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- 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: IBM Preview of z/OS V1.10
On Wed, 27 Feb 2008 11:59:02 +0100, R.S. [EMAIL PROTECTED] wrote: Mark Zelden wrote: [...] On another preview note: I (still) don't see anything about the removal of support for opening VSAM data sets with IMBED or REPLICATE. The only mention is how VSAM data sets with IMBED (and KEYRANGE) relate to Extended Address Volumes (EAVs).I really wish IBM would at least commit to a date / release already so I can get the dasd geeks to really take some action on this issue. It seems to me this is a proof that KEYRANGE and IMBED are still supported. No such proof for REPLICATE ...but who cares ? It's obsloteted for years (I mean REPLICATE and IMBED as well). Yes, they are still supported until they aren't. But, since I don't see any change in the SOD I have to assume that removal of that support is still planned: http://www-03.ibm.com/servers/eserver/zseries/zos/zos_sods.html I wonder if the delay is related to this other SOD: In a future release of z/OS, when DFSMShsm or DFSMSdss recalls or restores a VSAM data set with either IMBED or REPLICATE attribute or both, the attributes will be removed. This is a must have in order to remove the OPEN support. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: IBM Preview of z/OS V1.10
A new virtual storage area, the High Common Storage Area (HCSA), is defined. Did they really call it that? Or, did they mean to say, High Common *Service* Area? Date: Tue, 26 Feb 2008 11:53:36 -0600 From: [EMAIL PROTECTED] Subject: IBM Preview of z/OS V1.10 To: IBM-MAIN@BAMA.UA.EDU HCSA - because 510T of shared storage is not enough. :-) -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html _ Do more with your photos with Windows Live Photo Gallery. http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_photos_022008 -- 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: IBM Preview of z/OS V1.10
On Tue, 26 Feb 2008 13:25:13 -0500, J R wrote: A new virtual storage area, the High Common Storage Area (HCSA), is defined. Did they really call it that? Or, did they mean to say, High Common *Service* Area? Date: Tue, 26 Feb 2008 11:53:36 -0600 From: mark.zelden HCSA - because 510T of shared storage is not enough. :-) Yeahbut... what happened to 'Grande' in the naming scheme? -- Tom Schmidt -- 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: IBM Preview of z/OS V1.10
On Tue, 26 Feb 2008 12:44:22 -0600, Tom Schmidt [EMAIL PROTECTED] wrote: On Tue, 26 Feb 2008 13:25:13 -0500, J R wrote: A new virtual storage area, the High Common Storage Area (HCSA), is defined. Did they really call it that? Or, did they mean to say, High Common *Service* Area? I know I've heard many people refer to the S in CSA as storage. So I think using storage makes more sense now. Date: Tue, 26 Feb 2008 11:53:36 -0600 From: mark.zelden HCSA - because 510T of shared storage is not enough. :-) Yeahbut... what happened to 'Grande' in the naming scheme? The Grande scheme is for 64-bit instructions. The H in HVSHARE also stands for High. Oh... b4 the pedantry starts: yes, I know HVSHARE can go up to 1 exabyte. 510 terabytes is just the default. On another preview note: I (still) don't see anything about the removal of support for opening VSAM data sets with IMBED or REPLICATE. The only mention is how VSAM data sets with IMBED (and KEYRANGE) relate to Extended Address Volumes (EAVs).I really wish IBM would at least commit to a date / release already so I can get the dasd geeks to really take some action on this issue. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: IBM Preview of z/OS V1.10
I know I've heard many people refer to the S in CSA as storage. So I think using storage makes more sense now. I've seen the 'S' stand for service, storage, system, over the last 28 years, so I have given up. The 'S' stands for 's'. - Too busy driving to stop for gas! -- 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: IBM Preview of z/OS V1.10
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Ted MacNEIL) writes: I've seen the 'S' stand for service, storage, system, over the last 28 years, so I have given up. The 'S' stands for 's'. it started out as common segment area ... when it originally was a single segment. this was the transition from svs to mvs and required some place for applications to pass parameters to subsystems (running in different virtual address space) using pointer passing paradigm. however, it quickly got out of hand ... and became multiple common segments. recent posts with discussion of evoluation of mvs, common segments, dual-address space feature on 3081, and access registers http://www.garlic.com/~lynn/2008c.html#35 New Opcodes http://www.garlic.com/~lynn/2008d.html#69 Regarding the virtual machines http://www.garlic.com/~lynn/2008e.html#14 Kernels here is posting with MVS APAR/PTF 0267587 from 1983 ... for running MVS Guest under VM ... when there was a problem with common segments bit on 3090 ... http://www.garlic.com/~lynn/2002m.html#0 common segment bit was added to virtual memory hardware table segment table entry definition. i have done a qd html conversion of the old gcard ios3270 (green card with additional info done in ios3270 format): http://www.garlic.com/~lynn/gcard.html#13 370 table look aside buffer (TLB) implementations were STO-associative ... i.e. every hardware translation entry was associated with specific virtual address space (determine by its segment table origin address). if you did a special case operation for an installation running a (single) MVS operating system ... it was possible to imagine customizing improved hardware thruput ... even if it didn't conform to official 370 architecture ... but tailoring the hardware operation for exactly how MVS happened to be using the hardware. In the case of the common segment(s) ... the identical same segments appeared in every virtual address space (at least if you were only running a single MVS operating system on the bare hardware). That resulted in huge number of duplicate TLB entries ... since there were huge number of different applications (from their virtual address spaces) referencing locations in the common segment(s). Even if they were the same exact location ... since they origianted from different virtual address spaces ... they would have different (duplicate) entries in the TLB (associated with the specific STO/virtual address space that the operation occured in). The 370 segment table entry hardware table (see gcard DAT reference) was updated to define a bit meaning common segment. If TLB was processing a virtual address associated with a segment having the C bit turned on ... rather than associating the TLB entry with a specific virtual address space ... the TLB entry would be flagged as associated with the Common Segment(s). The straight-forward implementation only works if there is one and only one set of common segments across the whole infrastructure. current principles of operation reference for segment-table entries: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/3.11.2.2?DT=20040504121320 from above: Common-Segment Bit (C): Bit 59 controls the use of the translation-lookaside-buffer (TLB) copies of the segment-table entry and of the page table which it designates. A zero identifies a private segment; in this case, the segment-table entry and the page table it designates may be used only in association with the segment-table origin that designates the segment table in which the segment-table entry resides. A one identifies a common segment; in this case, the segment-table entry and the page table it designates may continue to be used for translating addresses corresponding to the segment index, even though a different segment table is specified. However, TLB copies of the segment-table entry and page table for a common segment are not usable if the private-space control, bit 55, is one in the address-space-control element used in the translation or if that address-space-control element is a real-space designation. The common-segment bit must be zero if the segment-table entry is fetched from storage during a translation when the private-space control is one in the address-space-control element being used; otherwise, a translation-specification exception is recognized. ... 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
