Re: z/OS 1.7 and "Large Sequential Data Set" Offering
In <[EMAIL PROTECTED]>, on 03/29/2006
at 01:58 PM, "Edward E. Jaffe" <[EMAIL PROTECTED]> said:
>Talk about a digression. Phil is talking about the WRONG bit
>altogether! The VSE bit that wasn't mapped was x'20' in DS1FLAG1 --
>not x'04' in DS4VTOCI. Sheesh!
Also, as I recall the comments used the term ("BOS"|"DOS")
"contaminated" rather than "dirty".
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.7 and "Large Sequential Data Set" Offering
McKown, John wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Thursday, March 30, 2006 6:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: z/OS 1.7 and "Large Sequential Data Set" Offering True, but not all VTOCs have INDEXes Why not in this day and age? Even my non-SMS volumes, few that they may be, have an index. They were out long before SMS was. - -teD My SPOOL volumes do NOT have a VTOCIX on them. The VTOC is cylinder 0 (minus track 0, of course). The rest of the volume is the SPOOL dataset. Absolutely no need for a VTOCIX. The same would be true of any non-SMS volume which is designed to have a minimal number of permenantly allocated datasets. OK, OK, so a 1 cylinder VTOCIX or even a VTOC+VTOCIX taking up cylinder 0 only would work too. I just don't bother. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology ... We found a good reason for having a VTOCIX on our SPOOL volumes during some of our early DR testing: If you do Point-in-Time DR backups using DFDSS with ESS flash Copy to DASD and DFDSS dump of the flash-copy volumes to tape, the volser is not copied to the flash-copy target (so the target can remain online for dump to tape), but at restore time DFDSS "knows" the true volser and plugs the correct volser when restoring at the DR site. One of our JES SPOOL volumes ended up with an incorrect volser at DR testing because it didn't have a VTOCIX. It turned out that DFDSS required either a VTOCIX or a VVDS be present in order to determine the "true" volser during the RESTORE. Not sure whether this is still the case, but ever since we've made a point of having a VTOCIX on every volume. -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
In regards to JES2 SPOOL volumes without VTOC index: On 31 Mar 2006 02:22:05 -0800, in bit.listserv.ibm-main (Message-ID:<[EMAIL PROTECTED]>) [EMAIL PROTECTED] (R.S.) wrote: Vernooy, C.P. - SPLXM wrote: Valid reasons, however our spool and page pack do have indexes, just because of the rule: one size fits all. One initialization procedure for all avoids having to think and possibly make errors. What is a few tracks in a Terabytes Dasd configuration? It does make a sense, however I'd prefer "two sizes" - not to many, not individually assigned for every volume. I don't consider it as error prone, since: 1. It is done by wise admins, not dummy enduser. 2. Vast majority of volumes are under SMS, the only difference is because of volume size (mod3, mod9, mod27). All "special" formats are solely for system volumes, like SPOOL or PAGE. Special format is done under special caution - it isn't done day by day. This brings up a question: Is a one-size-fits-all solution correct if you have a mix of 3390-3 -9 -27 -?? DASD? DASD is (fairly) cheap now, but does it really make sense to put a 3390-27 sized VTOC and index on a 3390-3? Or, does the "one size fits all" philosophy also restrict you to one size of disk? I half-like Vernooy's comment about *one* procedure to avoid errors and having to think. Automating something right means it's done correctly from then on, with no finger checks. I've found very few cases, though, were not thinking when "there's no need to think" hasn't caused trouble, eventually. -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
>Absolutely no need for a VTOCIX. The same would be true of any non-SMS volume which is designed to have a minimal number of permenantly allocated datasets. I came from a shop that was very retentive on DASD. There would be volumes added and removed from various storage groups on a regular basis. So, a database pack one week, could be a SPOOL pack the next, and a Production Batch pack, later. It was easier to give out one policy for initialisation of the pack(s). All had VTOCs a certain size, VTOCIXs a certain size and a VVDS a certain size. All were lined up at the beginning of the pack. Before and after arrays came in. Also, with the dumbing down of the storage administrator, one rule was easier to manage. There were actually three shops like that, that I worked in. The last still even after the price per unit of storage dropped from hundreds of dollars to pennies. So, I have developed a policy to protect us from ourselves. We have met the enemy and they are us! - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL > Sent: Thursday, March 30, 2006 6:00 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: z/OS 1.7 and "Large Sequential Data Set" Offering > > > >True, but not all VTOCs have INDEXes > > Why not in this day and age? > Even my non-SMS volumes, few that they may be, have an index. > > They were out long before SMS was. > - > -teD My SPOOL volumes do NOT have a VTOCIX on them. The VTOC is cylinder 0 (minus track 0, of course). The rest of the volume is the SPOOL dataset. Absolutely no need for a VTOCIX. The same would be true of any non-SMS volume which is designed to have a minimal number of permenantly allocated datasets. OK, OK, so a 1 cylinder VTOCIX or even a VTOC+VTOCIX taking up cylinder 0 only would work too. I just don't bother. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.7 and "Large Sequential Data Set" Offering
In a message dated 3/30/2006 6:54:17 P.M. Central Standard Time, [EMAIL PROTECTED] writes: >True, but not all VTOCs have INDEXes Why not in this day and age? Even my non-SMS volumes, few that they may be, have an index. I didn't mean to imply that I advocated not having a VTOC index. Since creating a VTOC index is still a user option, some users opt not to create one. Maybe some reasons can be solicited by asking this question rhetorically of the list readers. Bill Fairchild -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
Vernooy, C.P. - SPLXM wrote: "Shane" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... On Fri, 2006-03-31 at 09:53 +0200, R.S. wrote: Ted MacNEIL wrote: True, but not all VTOCs have INDEXes Why not in this day and age? Even my non-SMS volumes, few that they may be, have an index. They were out long before SMS was. My SPOOL volumes (or rather JES2 SPOOL volumes) have no index. And small VTOC. I had similar thoughts - not to mention a page pack or two ... Shane ... Valid reasons, however our spool and page pack do have indexes, just because of the rule: one size fits all. One initialization procedure for all avoids having to think and possibly make errors. What is a few tracks in a Terabytes Dasd configuration? It does make a sense, however I'd prefer "two sizes" - not to many, not individually assigned for every volume. I don't consider it as error prone, since: 1. It is done by wise admins, not dummy enduser. 2. Vast majority of volumes are under SMS, the only difference is because of volume size (mod3, mod9, mod27). All "special" formats are solely for system volumes, like SPOOL or PAGE. Special format is done under special caution - it isn't done day by day. BTW: I remain my colleague rant on me: "Stupid! you wasted 2 cylinders! on the volume!". -- Radoslaw Skorupka Lodz, Poland -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
"Shane" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > On Fri, 2006-03-31 at 09:53 +0200, R.S. wrote: > > Ted MacNEIL wrote: > > >>True, but not all VTOCs have INDEXes > > > > > > Why not in this day and age? > > > Even my non-SMS volumes, few that they may be, have an index. > > > > > > They were out long before SMS was. > > > > My SPOOL volumes (or rather JES2 SPOOL volumes) have no index. And small > > VTOC. > > I had similar thoughts - not to mention a page pack or two ... > > Shane ... > Valid reasons, however our spool and page pack do have indexes, just because of the rule: one size fits all. One initialization procedure for all avoids having to think and possibly make errors. What is a few tracks in a Terabytes Dasd configuration? Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
On Fri, 2006-03-31 at 09:53 +0200, R.S. wrote: > Ted MacNEIL wrote: > >>True, but not all VTOCs have INDEXes > > > > Why not in this day and age? > > Even my non-SMS volumes, few that they may be, have an index. > > > > They were out long before SMS was. > > My SPOOL volumes (or rather JES2 SPOOL volumes) have no index. And small > VTOC. I had similar thoughts - not to mention a page pack or two ... 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: z/OS 1.7 and "Large Sequential Data Set" Offering
Ted MacNEIL wrote: True, but not all VTOCs have INDEXes Why not in this day and age? Even my non-SMS volumes, few that they may be, have an index. They were out long before SMS was. My SPOOL volumes (or rather JES2 SPOOL volumes) have no index. And small VTOC. -- Radoslaw Skorupka Lodz, Poland -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
>True, but not all VTOCs have INDEXes Why not in this day and age? Even my non-SMS volumes, few that they may be, have an index. They were out long before SMS was. - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
In a message dated 3/30/2006 5:33:38 P.M. Central Standard Time, [EMAIL PROTECTED] writes: >Aren't they automagically invalid when you have an Index? And, you have to find the >space through it? True, but not all VTOCs have INDEXes. Bill Fairchild -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
>But I think you might have meant the Format-5 (free space) chain >rather than the Format-3 (data set extents) chains. Aren't they automagically invalid when you have an Index? And, you have to find the space through it? Or, has that changed? Or, even simpler, does it matter much, anymore? - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
In a message dated 3/30/2006 7:30:28 A.M. Central Standard Time, [EMAIL PROTECTED] writes: >But I think you might have meant the Format-5 (free space) chain >rather than the Format-3 (data set extents) chains. I sure did. My mistake. Bill Fairchild -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
[EMAIL PROTECTED] wrote: When you wanted to force a cleanup, you would IMASPZAP the bit on, then allocate something - anything - like a one-track data set with DISP=(NEW,DELETE) just to force DASDM to rebuild the F3 chain. Though no longer necessary, I believe this will still work. But I think you might have meant the Format-5 (free space) chain rather than the Format-3 (data set extents) chains. (See topics 1.1.1.4 Format-3 DSCB and 1.1.1.6 Format-5 DSCB in DFSMSdfp Advanced Services.) -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
On Wed, 29 Mar 2006 13:58:00 -0800, Edward E. Jaffe <[EMAIL PROTECTED]> wrote: >... >Talk about a digression. Phil is talking about the WRONG bit altogether! >The VSE bit that wasn't mapped was x'20' in DS1FLAG1 -- not x'04' in >DS4VTOCI. Sheesh! >... Well, ok, but it was a BIT. He got that part right. They're hard to tell apart, especially when they're not mapped. Pat O'Keefe -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
(IBM Mainframe Discussion List) wrote: ... The acronym stands for DASDM Interrupt Recording Facility. The bit is (or was) turned on at the beginning of a long process in which multiple DSCBs had to be updated. When all updates were done, the bit was turned off. If on a new allocate the bit was found to be on, then DADSM knew that the free DSCB chain was not necessarily correct, so DASDM would automatically rebuild the format 3 DSCB chain. It was called the dirty bit because (a) "DIRF" sounds a lot like "dirt" and (b) the F3 DSCB chain was possibly dirty/contaminated/non-kosher/hosed if the bit was on. Talk about a digression. Phil is talking about the WRONG bit altogether! The VSE bit that wasn't mapped was x'20' in DS1FLAG1 -- not x'04' in DS4VTOCI. Sheesh! -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
In a message dated 3/29/2006 12:07:09 P.M. Central Standard Time, [EMAIL PROTECTED] writes: >The DOS footprint bit? It _was_ mapped at one time. DS4DIRF or something like >that. DOS could happily use an OS/360 volume but didn't maintain the Formet 3s. >We used to switch 2311volumes between OS and DOS systems - if OS found the >DIRF bit (also called the "Dirty Bit") on it would recalculate the F3s before starting >allocation. It was a useful feature,and we used to ZAP the bit on every now and then >as part of housekeeping. >In faact I think even OS used to set it on before allocation and clear it afterwards. Correct. The acronym stands for DASDM Interrupt Recording Facility. The bit is (or was) turned on at the beginning of a long process in which multiple DSCBs had to be updated. When all updates were done, the bit was turned off. If on a new allocate the bit was found to be on, then DADSM knew that the free DSCB chain was not necessarily correct, so DASDM would automatically rebuild the format 3 DSCB chain. It was called the dirty bit because (a) "DIRF" sounds a lot like "dirt" and (b) the F3 DSCB chain was possibly dirty/contaminated/non-kosher/hosed if the bit was on. When you wanted to force a cleanup, you would IMASPZAP the bit on, then allocate something - anything - like a one-track data set with DISP=(NEW,DELETE) just to force DASDM to rebuild the F3 chain. Bill Fairchild -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
>In faact I think even OS used to set it on before allocation and clear it >afterwards. Wasn't it used for the indicator as to whether you had a VTOCIX or not on a pack, in the early 1980's? - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
Phil Payne wrote: "Actually, the bit is used by VSE. But it's use was never recorded in any OS mapping of the Format-1 DSCB." The DOS footprint bit? No. You're thinking of a different bit altogether ... in an entirely different control block (Format-4 DSCB)! -- 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
z/OS 1.7 and "Large Sequential Data Set" Offering
"Actually, the bit is used by VSE. But it's use was never recorded in any OS mapping of the Format-1 DSCB." The DOS footprint bit? It _was_ mapped at one time. DS4DIRF or something like that. DOS could happily use an OS/360 volume but didn't maintain the Formet 3s. We used to switch 2311 volumes between OS and DOS systems - if OS found the DIRF bit (also called the "Dirty Bit") on it would recalculate the F3s before starting allocation. It was a useful feature,and we used to ZAP the bit on every now and then as part of housekeeping. In faact I think even OS used to set it on before allocation and clear it afterwards. -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
Skip Robinson wrote: I know that the problem did not affect us. First of all, no VSE. More important, never underestimate the value of procrastination. Well, not today anyway. ;-) Nothing that impacts me ever impacts you, Skip. I wish you would stop reminding me! At least, I now know why. (Procrastination.) :-) The main impact to z/OS ESP and ETP users had nothing whatsoever to do with whether they ran VSE. There was no automatic VTOC conversion program to flip the bits in the DSCBs for existing data sets. When the new driver level came out, you had to manually locate, scratch, and reallocate all of your "large" data sets! Locating and scratching the data sets was best done under the old driver. Reallocation had to occur under the new driver. It was a major PITA! -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
For consideration, I understand that SAS Institute will provide DSNTYPE=LARGE allocation support with SAS V9.2, though there is still no mention of any technical concern on their support web site. Sincerely, Scott Barry SBBWorks, Inc. IBM Mainframe Discussion List <[log in to unmask]> wrote on 03/28/2006 11:49:29 AM: > We are planning our migration from 1.4 to 1.7 and concerned about the > large sequential data set offering. Reasons include: ISV and IBM > Product readiness, environmental impact etc. > > Two Questions: > 1) Are folks planning on exploiting the "large sequential data set" > when they initially migrate to z/OS 1.7? > > 2) If not, what technique are you going to use to prohibit the > exploitation? > > Thanks, > Brian -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
I know that the problem did not affect us. First of all, no VSE. More important, never underestimate the value of procrastination. Well, not today anyway. ;-) IBM Mainframe Discussion List wrote on 03/28/2006 01:59:14 PM: > Skip Robinson wrote: > > Early on in the 1.7 ESP, it was discovered that the large data set > > indicator bit in the VTOC had been used historically by a veteran data > > management product. The indicator bit was moved to another spot before GA > > to avoid lots of customer grief. > > > > Actually, the bit is used by VSE. But it's use was never recorded in any > OS mapping of the Format-1 DSCB. It appeared to be "reserved" to the > DFSMSdfp developers. Due to this unfortunate usage overlap, DS1LARGE had > to be changed from x'20' to x'08' fairly late in the game. (Scary! We > had to reallocate *lots* of data sets and rebuild the spool for both > JESes!) At the same time, the following was added to the IECSDSL1 > mapping macro to ensure the same mistake never happens again: > > DS1EXPBY EQU X'20' ..1. VSE EXP DATE SPEC BY RET PERIOD @08C > > -- > Edward E Jaffe -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
Skip Robinson wrote: Early on in the 1.7 ESP, it was discovered that the large data set indicator bit in the VTOC had been used historically by a veteran data management product. The indicator bit was moved to another spot before GA to avoid lots of customer grief. Actually, the bit is used by VSE. But it's use was never recorded in any OS mapping of the Format-1 DSCB. It appeared to be "reserved" to the DFSMSdfp developers. Due to this unfortunate usage overlap, DS1LARGE had to be changed from x'20' to x'08' fairly late in the game. (Scary! We had to reallocate *lots* of data sets and rebuild the spool for both JESes!) At the same time, the following was added to the IECSDSL1 mapping macro to ensure the same mistake never happens again: DS1EXPBY EQU X'20' ..1. VSE EXP DATE SPEC BY RET PERIOD @08C -- 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: z/OS 1.7 and "Large Sequential Data Set" Offering
Even now large data sets are not fully supported by all IBM products, let alone ISV products. For that reason, it might be premature to jump into them with both feet. Experiment yes, but be cautious about putting them into production. Early on in the 1.7 ESP, it was discovered that the large data set indicator bit in the VTOC had been used historically by a veteran data management product. The indicator bit was moved to another spot before GA to avoid lots of customer grief. . . JO.Skip Robinson Southern California Edison Company SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] IBM Mainframe Discussion List wrote on 03/28/2006 11:49:29 AM: > We are planning our migration from 1.4 to 1.7 and concerned about the > large sequential data set offering. Reasons include: ISV and IBM > Product readiness, environmental impact etc. > > Two Questions: > 1) Are folks planning on exploiting the "large sequential data set" > when they initially migrate to z/OS 1.7? > > 2) If not, what technique are you going to use to prohibit the > exploitation? > > Thanks, > Brian -- 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
z/OS 1.7 and "Large Sequential Data Set" Offering
We are planning our migration from 1.4 to 1.7 and concerned about the large sequential data set offering. Reasons include: ISV and IBM Product readiness, environmental impact etc. Two Questions: 1) Are folks planning on exploiting the "large sequential data set" when they initially migrate to z/OS 1.7? 2) If not, what technique are you going to use to prohibit the exploitation? Thanks, Brian -- 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
