Re: Why can't the track format be changed? (was: Physical record size query)

[Ron Hawkins]

Mike,

I think that is only true for Iceberg, RVA and SVA. For HDS the VTOC is seen
as your data, secure from the storage controllers operating system and the
VTOC cannot be opened.

EMC, IBM and HDS thin provisioning methods allocate in pages (HDS parlance),
so if you write one block on one track the whole page is allocated. For HDS
the page is 672 tracks (approx 38MB) striped across the HDD/SSD in one
Parity Group.

For the IBM and HDS implementations, RAID Rank Striping and Hitachi Dynamic
Provisioning, the wide striping that comes with this method is probably more
attractive than thin provisioning with over-commitment. It has all the
load-leveling advantages of RAID-0 while maintaining RAID-6 or RAID-5
protection.

In the HDS case you can achieve thin provisioning by adding real Array
Groups to the pool, creating more virtual volumes within the pool, and then
adding them to the Storage Group. I'm not sure about the IBM or EMC
implementation - perhaps someone can enlighten. Those that have embraced
volume pooling automation like DFSMS, SAMS-Vantage, or even ACC will start
to use the new capacity on the new virtual volumes immediately and without
disruption. You can also use DVE, or the old Iceberg/RVA methodology of
over-commitment and empty placeholder datasets (everything old is new
again).

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of
> Mike Schwab
> Sent: Tuesday, February 07, 2012 11:45 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Why can't the track format be changed? (was:
Physical
> record size query)
> 
> Behind the scenes, some controllers only store the active amount of data
for a
> track, and monitor the VTOC for datasets being deleted.
> This is called Thin Provisioning and allows a small amount of
overcommitting.
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed?

[Anne & Lynn Wheeler]

r.skoru...@bremultibank.com.pl (R.S.) writes:
> Yes and no.
> It depends on definition of "real CKD device".
> Actually 3390 and 3380 were FBA under the cover. The "data cells" (32
> or 34 bytes) were the fixed size sectors. Indeed, the device was not
> emulated - physical disc was presented as single I/O device, but the
> elecronics hidden the cells from MVS view.
>
> AFAIK the last "fully real" CKD device was 3350 (1975 GA).

re:
http://www.garlic.com/~lynn/2012b.html#58 Why can't the track format be changed?

3380/3390 were the low-level emulation on kind of FBA.

One of the things was that 3380 was the high-end datacenter disks and
the only mid-range disks were FBA.

In the 3380/3370 time-frame there was huge explosion in new 4300 sales
going into non-datacenter environments ... which MVS was precluded from
because of lack of FBA support. Eventually, trying to provide MVS with
an entry into that market ... 3375 was created ... that was a 3370 under
the covers. The other problem was that many of these environments were
getting close to set-it and forget it ... requiring very little
care&feeding ... which tended to also preclude MVS.

misc. past posts mentioning CKD, multi-track seek, FBA, etc
http://www.garlic.com/~lynn/submain.html#dasd

misc. old email mentioning 4300s ... some of which involve 3380/3370
http://www.garlic.com/~lynn/lhwemail.html#43xx

past posts about them letting me play disk engineer in bldgs. 14&15
http://www.garlic.com/~lynn/subtopic.html#disk

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed?

[Shmuel Metz (Seymour J.)]

In
,
on 02/08/2012
   at 10:03 AM, John Gilmore  said:

>Minimally, modus ponens yields the result that the production of real
>CKD devices did not end before the production of real 3390s--which
>were/are real CKD devices--ended.

AFAIK the 3350 was the last real CKD device; everything since
simulated CKD on a sectored disk.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Paul Gilmartin]

On Tue, 7 Feb 2012 22:41:34 -0500, Shmuel Metz (Seymour J.) wrote:

>In , on 02/07/2012
>   at 09:03 PM, Clark Morris said:
>
>>4.  Restrict the FBA devices to FBA data architectures (VSAM, PDSE,
>>HFS, zFS, any other FBA architecture.  Thus no QSAM, no BSAM, no PDS,
>>no BDAM, no traditional Spool.
>
>How do you plan to access the PDSE if not BSAM and QSAM? It might be
>desirable to have ACB/RPL access, but a DCB compatability facility is
>needed for existing code.
> 
BSAM and QSAM can read and write UNIX files and BPAM can read
them (and write shouldn't be too difficult).  None of these depend
on CKD.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed?

[R.S.]

W dniu 2012-02-08 16:03, John Gilmore pisze:

Minimally, modus ponens yields the result that the production of real
CKD devices did not end before the production of real 3390s--which
were/are real CKD devices--ended.


Yes and no.
It depends on definition of "real CKD device".
Actually 3390 and 3380 were FBA under the cover. The "data cells" (32 or 
34 bytes) were the fixed size sectors. Indeed, the device was not 
emulated - physical disc was presented as single I/O device, but the 
elecronics hidden the cells from MVS view.


AFAIK the last "fully real" CKD device was 3350 (1975 GA).


--
Radoslaw Skorupka
Lodz, Poland


--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed?

[Pommier, Rex R.]

A couple questions.  When did IBM actually stop manufacturing the 3390 device, 
and was the 9345 an actual CKD device?  The digging I did in IBM says it was.  
If so, when did that device (with a different geometry than either the 3380 or 
the 3390) stop manufacturing?

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Vernooij, CP - SPLXM
Sent: Wednesday, February 08, 2012 8:54 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Why can't the track format be changed?

I think when manufacturing real 3390 devices ended.

Kees.


The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed?

[John Gilmore]

Minimally, modus ponens yields the result that the production of real
CKD devices did not end before the production of real 3390s--which
were/are real CKD devices--ended.

On 2/8/12, Vernooij, CP - SPLXM  wrote:
> I think when manufacturing real 3390 devices ended.
>
> Kees.
>
> "Bill Fairchild"  wrote in message
> news:<77142D37C0C3C34DA0D7B1DA7D7CA346AE5C@nwt-s-mbx1.rocketsoftware
> .com>...
>> When did the manufacturing of real CKD devices end?
>>
>> Bill Fairchild
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Anne & Lynn Wheeler
>> Sent: Tuesday, February 07, 2012 6:20 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: Why can't the track format be changed?
>>
>> it wasn't too long before real CKD were no longer manufactured ...
> CKD becoming an obsolete technology simulated on real FBA. various past
> posts on the subject http://www.garlic.com/~lynn/submain.html#dasd
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 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.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
>   
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>


-- 
John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed?

[Vernooij, CP - SPLXM]

I think when manufacturing real 3390 devices ended.

Kees.

"Bill Fairchild"  wrote in message
news:<77142D37C0C3C34DA0D7B1DA7D7CA346AE5C@nwt-s-mbx1.rocketsoftware
.com>...
> When did the manufacturing of real CKD devices end?
> 
> Bill Fairchild
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Anne & Lynn Wheeler
> Sent: Tuesday, February 07, 2012 6:20 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Why can't the track format be changed?
> 
> it wasn't too long before real CKD were no longer manufactured ...
CKD becoming an obsolete technology simulated on real FBA. various past
posts on the subject http://www.garlic.com/~lynn/submain.html#dasd
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

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. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Bill Fairchild]

IBM still supports the KEYLEN parameter in the DCB macro for new user-created 
data sets in BSAM, BDAM, and BPAM.  The VTOC and PDS directory are the only 
system structures still using keys, but access methods are also part of the 
operating system and are supported.  IBM still supports having their customers 
create keyed files.  As long as customers continue creating and using keyed 
files, IBM must continue supporting them in the z/OS access methods.

Bill Fairchild 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
R.S.
Sent: Wednesday, February 08, 2012 2:37 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Why can't the track format be changed? (was: Physical record size 
query)

Yes, I listed only two things supported, but you did not add anything else 
which is SUPPORTED. ISAM datasets, PASSWORD - those things are dead now.
User applications? Well, there still can be user applications using ISAM... but 
usage of ISAM is *impossible* on current systems. Existing ISAM files can be 
deleted - the only support for ISAM. AFAIK The application can still work with 
VSAM files, using IIP. Of course that means no KEY of CKD.
Radoslaw Skorupka

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed?

[Bill Fairchild]

When did the manufacturing of real CKD devices end?

Bill Fairchild

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Anne & Lynn Wheeler
Sent: Tuesday, February 07, 2012 6:20 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Why can't the track format be changed?

it wasn't too long before real CKD were no longer manufactured ...  CKD 
becoming an obsolete technology simulated on real FBA. various past posts on 
the subject http://www.garlic.com/~lynn/submain.html#dasd

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Shmuel Metz (Seymour J.)]

In , on 02/07/2012
   at 09:03 PM, Clark Morris  said:

>4.  Restrict the FBA devices to FBA data architectures (VSAM, PDSE,
>HFS, zFS, any other FBA architecture.  Thus no QSAM, no BSAM, no PDS,
>no BDAM, no traditional Spool.

How do you plan to access the PDSE if not BSAM and QSAM? It might be
desirable to have ACB/RPL access, but a DCB compatability facility is
needed for existing code.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Shmuel Metz (Seymour J.)]

In
,
on 02/07/2012
   at 05:36 PM, Mike Schwab  said:

>Actually, VSAM basically formats its datasets like FBA disk, and PDSE
>is a type of VSAM file.

No, VSAM has no way to format a disk as FBA; it has to impliment
control intervals on top of CKD, as Paul said. The same applies to
PDSE.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[R.S.]

W dniu 2012-02-07 23:22, Bill Fairchild pisze:
> You listed the only two things supported by IBM in its operating
> system.   There is also an unknown number of user applications with
> files that have keys, which could be BSAM, BDAM, or BPAM (PDS with
> keys in its members and not just in its directory).  IBM no longer
> supports ISAM, but there may still be some ISAM files that are being
> used somehow.   And long, long ago the operating system used a
> dataset named PASSWORD that was unblocked with keys.  The ancient
> system catalog structure with 8-byte keys has been replaced by
>  VSAM structures.

Yes, I listed only two things supported, but you did not add anything 
else which is SUPPORTED. ISAM datasets, PASSWORD - those things are dead 
now.
User applications? Well, there still can be user applications using 
ISAM... but usage of ISAM is *impossible* on current systems. Existing 
ISAM files can be deleted - the only support for ISAM. AFAIK The 
application can still work with VSAM files, using IIP. Of course that 
means no KEY of CKD.


--
Radoslaw Skorupka
Lodz, Poland


--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Ed Gould]

Allan:

All good stuff. But I think IBM indicated that the use of SDB would  
be king. Indeed it makes sense. To tie themselves forever to 3390 is  
foolish (IMO) not that its bad mind you but it defeats the whole idea  
of system managed storage.


SMS is a stated direction. The map is in place now to handle all  
changes reasonably painless (as long as SDB is used).


Ed

On Feb 7, 2012, at 2:23 PM, Staller, Allan wrote:


Think of all of the code within z/OS that actually depends upon device
geometry. The C and H in CCHHR, etc. A hallmark of z/OS has been
backward compatibility. If this code were to be changed, all of that
backward compatibility would go poof! For what benefit. Customers have
revolted against making massive changes to support "arbitrary"  
hardware

design changes.

Another reason is that back in the SLED days, every new device type  
had
a different geometry, and caused massive JCL changes to accommodate  
that

new geometry efficiently in terms of space utilization, and indirectly
$$$. 1/2 track block size (27998) on a 3390 (track length  56664)   
will

waste about 40% of the available space if used on a 3380 (track length
47476).

That is the reason a few vendor products are still distributing
source/load modules with a approx. 6k block size, as opposed to 1/2
track blocking.  A 6k block size is fairly efficient (although
sub-optimal) on both 3380 and 3390.

A secondary effect of the geometry issue is the reason for 3390-9, 27,
54, To get around some of the other limitations imposed by volume
limits arising from the basic 3390-3 configuration.
These other volume sizes are compatible with the CCHHR format of a
3390-3.

IBM has stated that future devices will be compatible with 3390  
geometry

to prevent the need for mass JCL changes.


That leads to a question that I've been thinking about for some time.
Since the 3390 geometry is emulated by modern storage control units,
why then are the inefficiencies of small blocks emulated also?  There
are not SLEDs actually storing the data, why are IBG's,  sectors,  and
all the other CKD nastiness emulated that makes 80 byte blocks such a
bad idea?   IOW, why can't the control unit  simply store  708 * 80  
byte
blocks on a 56,664 byte 3390 track?   Does zos's calculations take  
these
inefficiencies into account and only write 78 of these blocks per  
track?


The "C" in CKD stands for "count" and this is some information  
about the

amount of data following in the next data block (the amount may vary
from block to block). Likewise "K" in CKD stands for "key" and some
access methods are using key data that is stored before the actual  
data.

So, both are bits of information that are used and thus cannot be
dropped.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Clark Morris]

On 7 Feb 2012 14:20:19 -0800, in bit.listserv.ibm-main you wrote:

>In
>,
>on 02/07/2012
>   at 08:24 PM, "Hunkeler Peter (KIUP 4)"
> said:
>
>>So, both are bits of information that are used and thus cannot be
>>dropped.
>
>ITYM that they cannot be dropped without first updating the software
>to support the new formats. VM has had support for LBA for decades.
> 
If IBM were to finally support FBA in z/OS, my recommendation would be
for them to do the following:

1.  Finally allow PDSE to be available at IPL/NIP time.
2.  Have an alternate spool method that stores spool data for both
JESs in a zFS.
3.  Have an enhanced GDG facility that applies to VSAM ESDS data sets.
Also allow concatenation of all data files that can be read
sequentially.
4.  Restrict the FBA devices to FBA data architectures (VSAM, PDSE,
HFS, zFS, any other FBA architecture.  Thus no QSAM, no BSAM, no PDS,
no BDAM, no traditional Spool.
5.  Replace NIP with as big a block as needed to bring in all of the
Nucleus from IPL/boot area.
6.  Eliminate the need for any non-FBA data architectures such as PDS
while continuing to support them on "CKD" devices.

Clark Morris
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed?

[Anne & Lynn Wheeler]

paulgboul...@aim.com (Paul Gilmartin) writes:
> But doesn't PDSE emulate FBA under CKD emulated on RAID
> implemented on FBA?  Even as VM/CMS emulates FBA for MDFS.

CMS has been logical FBA (on real CKD) all the way back to cp40/cms
... when it was originally developed ... and was called cambridge
monitor system and could run stand-alone on a real 360/40 ... cambridge
had done hardware modifications to 360/40 to support virtual memory
... for development of cp40. I was recently sent scan copy (by the
author) of cp40 presentation given at 1982 SEAS meeting (european share)
... which I ocr'ed
http://www.garlic.com/~lynn/cp40seas1982.txt

when 360/67 became available (with virtual memory standard), cp40
morphed into cp67
http://www.bitsavers.org/pdf/ibm/360/cp67/

later when virtual memory became available on 370, cp67 morphs into
vm370 and "cambridge monitor system" morphs into "conversational monitor
system" (and ability to run on "real" hardware was crippled)
http://www.bitsavers.org/pdf/ibm/370/vm370/

when disk division announces real FBA (3310 & 3370) disks, it is
very straight-forward for CMS to support:
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3370.html

this also shows up in the 3090 service processor, 3092 ... 
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3090.html

at the bottom mentions 3092 requiring two 3370s ... 3092 is actually a
pair of vm/cms 4361s running custom modified version of vm370 release 6
...  a couple old emails (3092 was originally developed on 4331):
http://www.garlic.com/~lynn/2010e.html#email861031
http://www.garlic.com/~lynn/2010e.html#email861223

it wasn't too long before real CKD were no longer manufactured ...  CKD
becoming an obsolete technology simulated on real FBA. various past posts
on the subject
http://www.garlic.com/~lynn/submain.html#dasd

past posts mentioning cambridge science center (formed 1Feb1964)
http://www.garlic.com/~lynn/subtopic.html#545tech

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Mike Schwab]

On Tue, Feb 7, 2012 at 3:12 PM, Paul Gilmartin  wrote:

> But doesn't PDSE emulate FBA under CKD emulated on RAID
> implemented on FBA?  Even as VM/CMS emulates FBA for MDFS.
>
> -- gil
Actually, VSAM basically formats its datasets like FBA disk, and PDSE
is a type of VSAM file.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Bill Fairchild]

You listed the only two things supported by IBM in its operating system.   
There is also an unknown number of user applications with files that have keys, 
which could be BSAM, BDAM, or BPAM (PDS with keys in its members and not just 
in its directory).  IBM no longer supports ISAM, but there may still be some 
ISAM files that are being used somehow.   And long, long ago the operating 
system used a dataset named PASSWORD that was unblocked with keys.  The ancient 
system catalog structure with 8-byte keys has been replaced by VSAM structures.

Bill Fairchild

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
R.S.
Sent: Tuesday, February 07, 2012 3:49 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Why can't the track format be changed? (was: Physical record size 
query)

Well... The only supported things that still use K from CKD are:
1. PDS (not PDSE) directory blocks. As documentation says PDS dir block is 256 
bytes long, but there is also 8-byte KEY.
2. VTOC. AFAIR 44-byte KEY is part of 140-byte VTOC record.

AND NOTHING ELSE!

-- 
Radoslaw Skorupka

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Shmuel Metz (Seymour J.)]

In
,
on 02/07/2012
   at 08:24 PM, "Hunkeler Peter (KIUP 4)"
 said:

>So, both are bits of information that are used and thus cannot be
>dropped.

ITYM that they cannot be dropped without first updating the software
to support the new formats. VM has had support for LBA for decades.
 
-- 
 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[R.S.]

W dniu 2012-02-07 20:24, Hunkeler Peter (KIUP 4) pisze:
[...]


The "C" in CKD stands for "count" and this is some information about the
amount of data following in the next data block (the amount may vary
from block to block). Likewise "K" in CKD stands for "key" and some
access methods are using key data that is stored before the actual data.
So, both are bits of information that are used and thus cannot be
dropped.


Well... The only supported things that still use K from CKD are:
1. PDS (not PDSE) directory blocks. As documentation says PDS dir block 
is 256 bytes long, but there is also 8-byte KEY.

2. VTOC. AFAIR 44-byte KEY is part of 140-byte VTOC record.

AND NOTHING ELSE!
So there are very few access method functions which really use KEY of CKD.
Of course the KEY is not the only reason for compatibility between 
emulated 3390's and plain old SLEDs.



--
Radoslaw Skorupka
Lodz, Poland


--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Paul Gilmartin]

On Tue, 7 Feb 2012 15:56:26 -0500, Scott Ford  wrote:
>
>I worked with a guy for years who said records was the way to allocate because 
>it we geometry independent...no cchhrr
>
Heresy!  He'll never know how many tracks he's using, nor how
many records in each.  Next thing you know, he'll even embrace
SDB and relinquish control of the block size.

But doesn't PDSE emulate FBA under CKD emulated on RAID
implemented on FBA?  Even as VM/CMS emulates FBA for MDFS.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Scott Ford]

Guys,

I worked with a guy for years who said records was the way to allocate because 
it we geometry independent...no cchhrr


Sent from my iPad
Scott Ford
Senior Systems Engineer

www.identityforge.com



On Feb 7, 2012, at 3:51 PM, "Vernooij, CP - SPLXM"  
wrote:

> "Staller, Allan"  wrote in message
> news:<45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc>...
>> Think of all of the code within z/OS that actually depends upon device
>> geometry. The C and H in CCHHR, etc. A hallmark of z/OS has been
>> backward compatibility. If this code were to be changed, all of that
>> backward compatibility would go poof! For what benefit. 
> 
> Sure, it is in the black box, under the hood and you don't have to worry
> about it. All 'problems' are virtualized out. Why get it out of the box
> and what external improvements could be achieved?
> 
> 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. 
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
> Airlines) is registered in Amstelveen, The Netherlands, with registered 
> number 33014286
> 
>
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Vernooij, CP - SPLXM]

"Staller, Allan"  wrote in message
news:<45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc>...
> Think of all of the code within z/OS that actually depends upon device
> geometry. The C and H in CCHHR, etc. A hallmark of z/OS has been
> backward compatibility. If this code were to be changed, all of that
> backward compatibility would go poof! For what benefit. 

Sure, it is in the black box, under the hood and you don't have to worry
about it. All 'problems' are virtualized out. Why get it out of the box
and what external improvements could be achieved?

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. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Staller, Allan]

Think of all of the code within z/OS that actually depends upon device
geometry. The C and H in CCHHR, etc. A hallmark of z/OS has been
backward compatibility. If this code were to be changed, all of that
backward compatibility would go poof! For what benefit. Customers have
revolted against making massive changes to support "arbitrary" hardware
design changes.

Another reason is that back in the SLED days, every new device type had
a different geometry, and caused massive JCL changes to accommodate that
new geometry efficiently in terms of space utilization, and indirectly
$$$. 1/2 track block size (27998) on a 3390 (track length  56664)  will
waste about 40% of the available space if used on a 3380 (track length
47476).

That is the reason a few vendor products are still distributing
source/load modules with a approx. 6k block size, as opposed to 1/2
track blocking.  A 6k block size is fairly efficient (although
sub-optimal) on both 3380 and 3390. 

A secondary effect of the geometry issue is the reason for 3390-9, 27,
54, To get around some of the other limitations imposed by volume
limits arising from the basic 3390-3 configuration.
These other volume sizes are compatible with the CCHHR format of a
3390-3.

IBM has stated that future devices will be compatible with 3390 geometry
to prevent the need for mass JCL changes.


That leads to a question that I've been thinking about for some time.
Since the 3390 geometry is emulated by modern storage control units,
why then are the inefficiencies of small blocks emulated also?  There
are not SLEDs actually storing the data, why are IBG's,  sectors,  and
all the other CKD nastiness emulated that makes 80 byte blocks such a
bad idea?   IOW, why can't the control unit  simply store  708 * 80 byte
blocks on a 56,664 byte 3390 track?   Does zos's calculations take these
inefficiencies into account and only write 78 of these blocks per track?

The "C" in CKD stands for "count" and this is some information about the
amount of data following in the next data block (the amount may vary
from block to block). Likewise "K" in CKD stands for "key" and some
access methods are using key data that is stored before the actual data.
So, both are bits of information that are used and thus cannot be
dropped.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Why can't the track format be changed? (was: Physical record size query)

[Mike Schwab]

Behind the scenes, some controllers only store the active amount of
data for a track, and monitor the VTOC for datasets being deleted.
This is called Thin Provisioning and allows a small amount of
overcommitting.

On Tue, Feb 7, 2012 at 1:24 PM, Hunkeler Peter (KIUP 4)
 wrote:
>>That leads to a question that I've been thinking about for some time.
> Since the 3390 geometry is emulated by modern storage control units,
> why then are the inefficiencies of small blocks emulated also?  There
> are not SLEDs actually storing the data, why are IBG's,  sectors,  and
> all the other CKD nastiness emulated that makes 80 byte blocks such a
> bad idea?   IOW, why can't the control unit  simply store  708 * 80 byte
> blocks on a 56,664 byte 3390 track?   Does zos's calculations take these
> inefficiencies into account and only write 78 of these blocks per track?
>
> The "C" in CKD stands for "count" and this is some information about the
> amount of data following in the next data block (the amount may vary
> from block to block). Likewise "K" in CKD stands for "key" and some
> access methods are using key data that is stored before the actual data.
> So, both are bits of information that are used and thus cannot be
> dropped.
>
> --
> Peter Hunkeler
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Why can't the track format be changed? (was: Physical record size query)

[Hunkeler Peter (KIUP 4)]

>That leads to a question that I've been thinking about for some time.
Since the 3390 geometry is emulated by modern storage control units,
why then are the inefficiencies of small blocks emulated also?  There
are not SLEDs actually storing the data, why are IBG's,  sectors,  and
all the other CKD nastiness emulated that makes 80 byte blocks such a
bad idea?   IOW, why can't the control unit  simply store  708 * 80 byte
blocks on a 56,664 byte 3390 track?   Does zos's calculations take these
inefficiencies into account and only write 78 of these blocks per track?

The "C" in CKD stands for "count" and this is some information about the
amount of data following in the next data block (the amount may vary
from block to block). Likewise "K" in CKD stands for "key" and some
access methods are using key data that is stored before the actual data.
So, both are bits of information that are used and thus cannot be
dropped.

--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN