Re: New BDMSCAN version to look at your Broadcast Dataset
>A year or so ago when IBM sent me a z/OS 1.7 driver system for my new z9, it >consisted of three 3380 pack dumps. Did you have 3380's available? Did you complain to IBM? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New BDMSCAN version to look at your Broadcast Dataset
A year or so ago when IBM sent me a z/OS 1.7 driver system for my new z9, it consisted of three 3380 pack dumps. -Original Message- From: Ted MacNEIL Sent: Sunday, December 28, 2008 1:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: New BDMSCAN version to look at your Broadcast Dataset > Suppose you use FDR, for example, to copy a Broadcast Dataset from a 3380 to a 3390. Does anybody still have 3380's? I haven't seen one since 1990! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New BDMSCAN version to look at your Broadcast Dataset
I seem to recall that one old COBOL compiler required 3380's for work datasets. Since COBOL compliers tend to live forever and that solutions tend to outlive their problems .. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Eric Bielefeld Sent: Sunday, December 28, 2008 3:42 PM To: IBM-MAIN@bama.ua.edu Subject: Re: New BDMSCAN version to look at your Broadcast Dataset We still have a couple hundred addresses defined on our new Shark as 3380's. I'm not sure exactly why, but they are there. I think we had some software that required 3380s at one time, but I don't think we have any now. I'm curious - what would be the benefit of getting off of the 3380s? I think that the larger track size might allow a little more data per track, but other than that, why would having 3380s be a problem? Eric Ted MacNEIL wrote: > > Suppose you use FDR, for example, to copy a Broadcast Dataset from a 3380 > > to a 3390. > > Does anybody still have 3380's? > > I haven't seen one since 1990! > - -- Eric Bielefeld Systems Programmer Washington University St Louis, Missouri 314-935-3418 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New BDMSCAN version to look at your Broadcast Dataset
>AFAIK the largest 3380 model is approx 1GB. 3380-K: 1.89 GB - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New BDMSCAN version to look at your Broadcast Dataset
Eric Bielefeld wrote: We still have a couple hundred addresses defined on our new Shark as 3380's. I'm not sure exactly why, but they are there. I think we had some software that required 3380s at one time, but I don't think we have any now. I'm curious - what would be the benefit of getting off of the 3380s? I think that the larger track size might allow a little more data per track, but other than that, why would having 3380s be a problem? The benefits of getting off 3380s: - adressablility. Nowadays disk adresses occupy vast majority of addressing space. I know datacenters where mod-27 and even mod-54 was the only ay to address all the dasd box space. - consistency. Life is much easier when having only one geometry, isn't it? - convenience. AFAIK the largest 3380 model is approx 1GB. So, relatively average size datasets have to be multi-volume. - limits. Large datasets can reach 59-vol limit. Of course the above does not apply to datacenter with 6MIPS CPC, OS/390 2.6, 3480 drives for backup and 330GB of dasd. We call such datacenters as palliative: you can't cure them, but you can buoy them up. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2008 r. kapitał zakładowy BRE Banku SA wynosi 118.642.672 złote i został w całości wpłacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New BDMSCAN version to look at your Broadcast Dataset
Hi Folks, The device type doesn't even matter here, and we shouldn't get sidetracked by 3380's or whatever. I'll explain. The fact is that a free Broadcast Dataset record, with key X'FF' has to have the absolute record number, starting with X'01', in the first data byte of the record. If a (candidate for a) Broadcast Dataset does not have this value hard-coded in the first data byte of the X'FF' records, and the system tries to use that dataset as a Broadcast Dataset, all mayhem breaks loose. My (commercial) program BDMDSFIX will solve the situation by resetting the first data bytes of all X'FF' records to the relative record number on the track. The same result can be accomplished with my free package from File 247 of the CBT Tape (Updates page, please), by running BCMDUMP followed by BCMREST, and after the dump/restore, the resulting Broadcast Dataset will have the same data as before, but all these hard-coded data bytes (containing the record position) will be fixed up. ALL THIS HAS NOTHING TO DO WITH DEVICE TYPES, at least so far! An easy way of CREATING THE PROBLEM is by copying a Broadcast Dataset that was formatted on a 3380, to a 3390, which actually holds FEWER RECORDS PER TRACK, of the unblocked and keyed Broadcast Dataset records. The resulting (copied) dataset then has the problem, because the first data bytes of the X'FF' records are out of sync with the record number of the track that they are on. That's why IBM says you can't move a Broadcast Dataset between different device types (but I can do it with my tool packages). The idea is that the device type situation came in peripherally, and it wasn't the real problem here. So if it's 3380's or something else (3375's?), it doesn't matter for our discussion. Anyway, even though most of the world now seems to have standardized on DASD images and devices that have 3390 geometry, 3390's are by no means entirely universal, even nowadays. And I've just tried to make people aware of the weird situation in the Broadcast Dataset, where the X'FF' records have to contain hard-coded record positions within their data. THAT is the actual issue here. All the best of everything to all of you. Sincerely,Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New BDMSCAN version to look at your Broadcast Dataset
>I'm curious - what would be the benefit of getting off of the 3380s? >I think that the larger track size might allow a little more data per track, >but other than that, why would having 3380s be a problem? I never said it was a problem. I just said that I wasn't aware that people were still using them. Most (if not all) shops in Canada converted to 3390's before RAID came out. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New BDMSCAN version to look at your Broadcast Dataset
We still have a couple hundred addresses defined on our new Shark as 3380's. I'm not sure exactly why, but they are there. I think we had some software that required 3380s at one time, but I don't think we have any now. I'm curious - what would be the benefit of getting off of the 3380s? I think that the larger track size might allow a little more data per track, but other than that, why would having 3380s be a problem? Eric Ted MacNEIL wrote: > > Suppose you use FDR, for example, to copy a Broadcast Dataset from a 3380 > > to a 3390. > > Does anybody still have 3380's? > > I haven't seen one since 1990! > - -- Eric Bielefeld Systems Programmer Washington University St Louis, Missouri 314-935-3418 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New BDMSCAN version to look at your Broadcast Dataset
> Suppose you use FDR, for example, to copy a Broadcast Dataset from a 3380 to > a 3390. Does anybody still have 3380's? I haven't seen one since 1990! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
New BDMSCAN version to look at your Broadcast Dataset
Hi Folks, Please download File 247 from the Updates page of www.cbttape.org to get a fresh load module of my new commercial version of the old "BRODSCAN" program to analyze your Broadcast Dataset (SYS1.BRODCAST or a copy thereof). The BDMSCAN member, and the sample JCL member BDMSCAN$ will guide you through the process of analyzing your Broadcast Dataset (i.e. SYS1.BRODCAST). I give permission for anybody to use this program anywhere, no strings attached, subject only to the conditions and disclaimer rules of the CBT Tape collection. See www.cbttape.org for them. Please have a look at my website, www.brodmstr.com , which talks about my commercial Broadcast Dataset product. If you are interested in my commercial product or you want to find out more about it, please email me at sbgo...@cbttape.org . It will be VERY inexpensive. This new version of the BDMSCAN program will tell you how many Notices records are active, and it will also reveal an error condition which can result when you copy a Broadcast Dataset from one device type to another (something IBM says you shouldn't do, but it might happen accidentally). The reason for the error condition is as follows: Empty message records on the Broadcast Dataset (records with Key X'FF') have to have as their first data byte, the exact record number on the track (the R of the CCHHR of the record). If even one of the X'FF' records doesn't have the R of the CCHHR as its first data byte, then the Broadcast Dataset (despite any good data it may contain) is not usable by the system. How can this happen? I'll give an example. Suppose you use FDR, for example, to copy a Broadcast Dataset from a 3380 to a 3390. (I think ADRDSSU will stop you.) On a 3380, there can be 53 records in a track for the Broadcast Dataset. On a 3390, there can be only 50 records on a track. All X'FF' records have the record number for that record, hard coded into the first data byte. Some of these records might have X'33' thru X'35' in there, if the dataset was formatted (by ACCOUNT SYNC) on a 3380. This cannot occur for a 3390 (where the record numbers only go up to X'32'). So the X'FF' records of the copied dataset will have to be wrong, and a serious system error will result if you try to use the copied Broadcast Dataset as your SYS1.BRODCAST dataset, or if you try to switch to it using PARMLIB UPDATE(xx). BDMSCAN will now detect these Broadcast Dataset errors. You'll now see the following messages on a bad dataset: Count of BRODCAST Header Record (Should be 1) 1 Number of BRODCAST "Notices" Directory Records10 Number of BRODCAST "Notices" Message Records 250 Number of USER "Mail" Directory Records 116 Number of USER "Mail" Message Records 0 Count of Free Search Record (Should be 1) 1 Number of Empty USER "Mail" Record Slots9003 Number of Bad empty "Mail" Record Slots8853 >> (BRODCAST DATASET UNUSABLE! Fix with BDMDSFIX pgm.) << On the other hand, a "corrected" Broadcast Dataset will show the following messages: Count of BRODCAST Header Record (Should be 1) 1 Number of BRODCAST "Notices" Directory Records10 Number of BRODCAST "Notices" Message Records 250 Number of USER "Mail" Directory Records 116 Number of USER "Mail" Message Records 0 Count of Free Search Record (Should be 1) 1 Number of Empty USER "Mail" Record Slots9003 Number of Bad empty "Mail" Record Slots 0 and no error message will follow. My BDMDSFIX program (which is part of my commercial product) will fix the errant Broadcast Dataset directly. However, without my commercial package, you can indirectly fix the problem, without losing any data, by running (from CBT Tape File 247) the BCMDUMP and BCMREST programs. After the dump and restore, the restored dataset will have all the X'FF' records fixed with the proper data in the first data byte, and the new dataset will then be usable by the system. I hope this shows you some valuable information about the Broadcast Dataset, which most of us take for granted, and maybe this information will help get you out of a pinch someday. This might happen if you're switching your DASD to a device of different geometry. All the best of everything to all of you. Sincerely,Sam Golob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.e
