Re: New BDMSCAN version to look at your Broadcast Dataset

2008-12-28 Thread Ted MacNEIL
> 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


Re: New BDMSCAN version to look at your Broadcast Dataset

2008-12-28 Thread Eric Bielefeld
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

2008-12-28 Thread Ted MacNEIL
>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

2008-12-28 Thread Sam Golob

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

2008-12-29 Thread R.S.

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

2008-12-29 Thread Ted MacNEIL
>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

2008-12-30 Thread Hal Merritt
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

2009-01-02 Thread Schwarz, Barry A
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

2009-01-02 Thread Ted MacNEIL
>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