Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
Yes, BDAM can use the key portion, however faster access was achived if the lookup value for finding a record was mapped by some calculation into CCHHR; otherwise BDAM's performance was not much better than ISAM's There was an article in Datamation (back when it was a good magazine) called The Hidden Speed of ISAM. Anyone still have a copy? There's a rhyme in German: ISAM ist langsam, VSAM is grausam. ISAM is slow, VSAM is horrible. And yes - in German it both scans and rhymes. -- Phil Payne http://www.isham-research.com +44 7785 302 803 +49 173 6242039
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
For VSE with FBA devices, the VTOC wasn't keyed as it was on a CKD device; it's been years since I used a 3310 or a 3370; so I'm stretching here; but the if I remember correctly, the vtoc was built on a VSAM KSDS model. Yes, BDAM can use the key portion, however faster access was achived if the lookup value for finding a record was mapped by some calculation into CCHHR; otherwise BDAM's performance was not much better than ISAM's It is my understanding that most of the PDS/PDSE support in MVS nowadays is based on VSAM ESDS structures; with the changes for Systems Managed Storage support, DASD is actually viewed as VSAM space. A release or two back in OS/390 the ability to share packs between VSE MVS went away; the OS/390 VTOCs weren't structured the same way as they use to be, and VSE would no longer be able to access them. Garry E. Ward Senior Software Specialist Maritz Research Automotive Research Group 419-725-4123 -Original Message- From: John Summerfield [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 1:27 PM To: [EMAIL PROTECTED] Subject: Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?] The only folks that would really be in trouble are those who wrote code to mathmaticaly map some data value into a CCHHRR value, which is what Direct Access Method originally did. These people would have to come up with a way to convert their key value to a relative record number instead of a CCHHR VTOCs use keyed records, and AFAIK it's possible to share disks between DOS and OS families (heard of the DOS contamination bit?). The file I had in mind in the example below is the VTOC. BDAM can use keyed records. Partitioned dataset directories are keyed files. Or have these things changed over the years? For VSAM it isn't that bad; and Relative Byte Address is a Relative Byte Address, on FBA it's a little easier becasue you just map from the first byte on the pack. VTOC's used the relative record approach instead of an CCHHRR. I was think more of the CKD disks' ability to store and recognise keys as distinct from data. Mapping CCHR address is just a matter of simple arithmetic and bothers me not at all. However, if my program logic is to search the file for the record with the key accounts.sourcelib and read the data, then I don't see how this maps to the FBA architecture. Unless the drives have that capability. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right! font size=1Confidentiality Warning: This e-mail contains information int ended only for the use of the individual or entity named above. If the reade r of this e-mail is not the intended recipient or the employee or agent respo nsible for delivering it to the intended recipient, any dissemination, public ation or copying of this e-mail is strictly prohibited. The sender does not a ccept any responsibility for any loss, disruption or damage to your data or c omputer system that may occur while using data contained in, or transmitted w ith, this e-mail. If you have received this e-mail in error, please immedia tely notify us by return e-mail. Thank you. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right! font size=1Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
The CKD's ability to handle separate keys from the data was born in the days of ISAM, when an indexed file was literally written with the index on the track. If the ISAM file was unblocked, then each record had the key for that record written first, then the data; an index search was data at the channel program level. If it was blocked, then the highest key in the block became the key written on the track. In this case, the channel program looked for a higher than key and the ISAM routines read that block and pulled it apart looking for the correct record. The separate index in ISAM was simply used to store the highest key in each cylinder, so that the channel program could be tailored to scan the keys in only one cylinder at a time, rather than trying to hunt across multiple cylinders. Also why ISAM files were preferred to be placed on cylinder boundaries A great technique for the 1960s; but in today's environment, not such a good idea. A VSAM Key Sequence file does not use the key part of the CKD; everything is in relative CI format, with the index part being nothing more than a collection of CIs with keys RBAs to where the record is located. Maps to FBA like a charm. The only folks that would really be in trouble are those who wrote code to mathmaticaly map some data value into a CCHHRR value, which is what Direct Access Method originally did. These people would have to come up with a way to convert their key value to a relative record number instead of a CCHHR Garry E. Ward Senior Software Specialist Maritz Research Automotive Research Group 419-725-4123 -Original Message- From: John Summerfield [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 10:13 PM To: [EMAIL PROTECTED] Subject: Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?] For VSAM it isn't that bad; and Relative Byte Address is a Relative Byte Address, on FBA it's a little easier becasue you just map from the first byte on the pack. VTOC's used the relative record approach instead of an CCHHRR. I was think more of the CKD disks' ability to store and recognise keys as distinct from data. Mapping CCHR address is just a matter of simple arithmetic and bothers me not at all. However, if my program logic is to search the file for the record with the key accounts.sourcelib and read the data, then I don't see how this maps to the FBA architecture. Unless the drives have that capability. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right! font size=1Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
Has anyone tried iSCSI with S/390 ? Yes. The limiting factor is currently network adapter performance, but it does work for everything except IPL (duh). We're doing a bit more stress testing internally before letting it loose on the world. -- db
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
Really? As in talking to existing Fiber Channel[1] disk arrays that speak FC-SCSI? and/or via FC-SCSI bridges to random SCSI devices? Where can I find out more? I used to work on FC-attached storage array systems at Compaq... Yup. They were demonstrating it at LinuxWorld in NYC in January. Burning CDs from the z800. -- db
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
The only folks that would really be in trouble are those who wrote code to mathmaticaly map some data value into a CCHHRR value, which is what Direct Access Method originally did. These people would have to come up with a way to convert their key value to a relative record number instead of a CCHHR VTOCs use keyed records, and AFAIK it's possible to share disks between DOS and OS families (heard of the DOS contamination bit?). The file I had in mind in the example below is the VTOC. BDAM can use keyed records. Partitioned dataset directories are keyed files. Or have these things changed over the years? For VSAM it isn't that bad; and Relative Byte Address is a Relative Byte Address, on FBA it's a little easier becasue you just map from the first byte on the pack. VTOC's used the relative record approach instead of an CCHHRR. I was think more of the CKD disks' ability to store and recognise keys as distinct from data. Mapping CCHR address is just a matter of simple arithmetic and bothers me not at all. However, if my program logic is to search the file for the record with the key accounts.sourcelib and read the data, then I don't see how this maps to the FBA architecture. Unless the drives have that capability. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right! font size=1Confidentiality Warning: This e-mail contains information int ended only for the use of the individual or entity named above. If the reade r of this e-mail is not the intended recipient or the employee or agent respo nsible for delivering it to the intended recipient, any dissemination, public ation or copying of this e-mail is strictly prohibited. The sender does not a ccept any responsibility for any loss, disruption or damage to your data or c omputer system that may occur while using data contained in, or transmitted w ith, this e-mail. If you have received this e-mail in error, please immedia tely notify us by return e-mail. Thank you. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
Re: How to pre-allocate a 4GB File?
On Thu, 18 Apr 2002 12:58:41 -0400 Don Stubbs said: Has anyone heard of any IBM plans to provide non-ECKD DASD support for zOS? We can't go on emulating 33X0 volumes much longer. Why not? I can't think of a technical reason we can't. There are support reasons to maintain it. Sure it would be nice to remove some restrictions, but the basic emulation has no reason to disappear. Don Stubbs /ahw
Re: How to pre-allocate a 4GB File?
I believe I would at least need 2 free dasdpacks to get 4+ GB with LVM. What are the steps to activate this 2 packs as LVM pack? I have to add these 2 at /etc/lvmtab. Should I have to specify any parameter in /etc/fstab at all? Thanks, Samy Rengasamy. -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 12:39 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Samy, SuSE 7.0 has LVM support built into it. Red Hat 7.2 does not. For RAID support, take a look at http://www.marist.edu/htbin/wlvtype?LINUX-VM.22398 and http://www.linuxdoc.org/HOWTO/Software-RAID-HOWTO.html Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 1:28 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Do I have to upgrade to 2.4 kernel to run LVM? How can I build software RAID-O? Thanks, Samy Rengasamy. -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 10:20 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Samy, You'll need to be running a 2.4 kernel, and either LVM, or RAID to aggregate multiple 3390 volumes, or have some 3390-9 volumes available. Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 6:16 PM To: [EMAIL PROTECTED] Subject: How to pre-allocate a 4GB File? How to pre-allocate a 4GB File in a system with several 2.3 GB dasds? We're looking for a way to be able to create a single file slightly larger than 4Gbytes (to test some logic in the code which has been known to break on ports where seek offsets go over 32-bits). Or is the largest file we can ever make around 2.3Gbytes ? Thanks, Samy Rengasamy.
Re: How to pre-allocate a 4GB File?
Samy, The Distributions Redbook covers what you need to do in a step-by-step process in Chapter 17. Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 3:46 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? I believe I would at least need 2 free dasdpacks to get 4+ GB with LVM. What are the steps to activate this 2 packs as LVM pack? I have to add these 2 at /etc/lvmtab. Should I have to specify any parameter in /etc/fstab at all? Thanks, Samy Rengasamy. -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 12:39 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Samy, SuSE 7.0 has LVM support built into it. Red Hat 7.2 does not. For RAID support, take a look at http://www.marist.edu/htbin/wlvtype?LINUX-VM.22398 and http://www.linuxdoc.org/HOWTO/Software-RAID-HOWTO.html Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 1:28 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Do I have to upgrade to 2.4 kernel to run LVM? How can I build software RAID-O? Thanks, Samy Rengasamy. -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 10:20 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Samy, You'll need to be running a 2.4 kernel, and either LVM, or RAID to aggregate multiple 3390 volumes, or have some 3390-9 volumes available. Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 6:16 PM To: [EMAIL PROTECTED] Subject: How to pre-allocate a 4GB File? How to pre-allocate a 4GB File in a system with several 2.3 GB dasds? We're looking for a way to be able to create a single file slightly larger than 4Gbytes (to test some logic in the code which has been known to break on ports where seek offsets go over 32-bits). Or is the largest file we can ever make around 2.3Gbytes ? Thanks, Samy Rengasamy.
Re: How to pre-allocate a 4GB File?
Thanks for the info. We run SuSe Linux 7.0 - Kernel 2.2.16 (2). I believe the red book is with info for 2.2 kernels Thanks again, Samy Rengasamy. -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 3:00 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Samy, The Distributions Redbook covers what you need to do in a step-by-step process in Chapter 17. Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 3:46 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? I believe I would at least need 2 free dasdpacks to get 4+ GB with LVM. What are the steps to activate this 2 packs as LVM pack? I have to add these 2 at /etc/lvmtab. Should I have to specify any parameter in /etc/fstab at all? Thanks, Samy Rengasamy. -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 12:39 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Samy, SuSE 7.0 has LVM support built into it. Red Hat 7.2 does not. For RAID support, take a look at http://www.marist.edu/htbin/wlvtype?LINUX-VM.22398 and http://www.linuxdoc.org/HOWTO/Software-RAID-HOWTO.html Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 1:28 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Do I have to upgrade to 2.4 kernel to run LVM? How can I build software RAID-O? Thanks, Samy Rengasamy. -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 10:20 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Samy, You'll need to be running a 2.4 kernel, and either LVM, or RAID to aggregate multiple 3390 volumes, or have some 3390-9 volumes available. Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 6:16 PM To: [EMAIL PROTECTED] Subject: How to pre-allocate a 4GB File? How to pre-allocate a 4GB File in a system with several 2.3 GB dasds? We're looking for a way to be able to create a single file slightly larger than 4Gbytes (to test some logic in the code which has been known to break on ports where seek offsets go over 32-bits). Or is the largest file we can ever make around 2.3Gbytes ? Thanks, Samy Rengasamy.
Re: How to pre-allocate a 4GB File?
Has anyone heard of any IBM plans to provide non-ECKD DASD support for zOS? We can't go on emulating 33X0 volumes much longer. What Harry said. While I agree that MVS should grok FBA, but the problem is not that we have and continue to have CKD. The problem is that FBA is so poorly valued in S/390 circles. There is the incorrect assumption that all S/390 DASD is CKD. One of the inelegant results is where the S/390 side of some storage subsystem continues to use CKD flavor while the SCSI side gives access to that same content. IFF such dual-port access is enabled, it should on the SCSI side retain all the key, track record blocking, count, and whatever other non data content. OR, let the S/390 side of such a thing be FBA. I confess that I have limited experience with multi-protocol DASD, but at least one engineer has told me that the plan is to wrap distributed systems content (just blocks) in CKD style records. That bothers me. I'm hoping he's wrong. The value of FBA is that it *only* supports data. There is no non data to be lost in the translation one way nor to be simulated in some cheezy glue microcode the other way. I guess I'm just looking for consistency. But we can't make others do the right thing, can we?
Re: How to pre-allocate a 4GB File?
As a matter of fact, I was using a SuSE 2.2 system to write that chapter. I did a lot of cutting an pasting from my TeraTerm window to make sure I got it all exactly right. (Including the forgetting to run certain commands in the right order!) Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 4:11 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Thanks for the info. We run SuSe Linux 7.0 - Kernel 2.2.16 (2). I believe the red book is with info for 2.2 kernels Thanks again, Samy Rengasamy. -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 3:00 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Samy, The Distributions Redbook covers what you need to do in a step-by-step process in Chapter 17. Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 3:46 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? I believe I would at least need 2 free dasdpacks to get 4+ GB with LVM. What are the steps to activate this 2 packs as LVM pack? I have to add these 2 at /etc/lvmtab. Should I have to specify any parameter in /etc/fstab at all? Thanks, Samy Rengasamy. -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 12:39 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Samy, SuSE 7.0 has LVM support built into it. Red Hat 7.2 does not. For RAID support, take a look at http://www.marist.edu/htbin/wlvtype?LINUX-VM.22398 and http://www.linuxdoc.org/HOWTO/Software-RAID-HOWTO.html Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 1:28 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Do I have to upgrade to 2.4 kernel to run LVM? How can I build software RAID-O? Thanks, Samy Rengasamy. -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 10:20 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Samy, You'll need to be running a 2.4 kernel, and either LVM, or RAID to aggregate multiple 3390 volumes, or have some 3390-9 volumes available. Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 6:16 PM To: [EMAIL PROTECTED] Subject: How to pre-allocate a 4GB File? How to pre-allocate a 4GB File in a system with several 2.3 GB dasds? We're looking for a way to be able to create a single file slightly larger than 4Gbytes (to test some logic in the code which has been known to break on ports where seek offsets go over 32-bits). Or is the largest file we can ever make around 2.3Gbytes ? Thanks, Samy Rengasamy.
Re: How to pre-allocate a 4GB File?
On Wed, 17 Apr 2002, John Summerfield wrote:
Or can I do better on a PC than you can on a mainframe?
John, the reason why large filesystems are challenging on S/390 is
because the disk hardware is still tuned mostly for MVS, which does not
use a fixed-block storage strategy. As a result, DASD tend to be of
record/track/cylinder geometry and in standard sizes. Now there
*is* a 10G size, but the common one these days is about 2.3G.
S/390 does also have FBA (fixed block architecture) DASD devices.
Sadly, even in the Linux world these are not widely known or used.
I maintain that they should be employed heavily and heartily!
The benefits are numerous.
Back when I was a sysprog we used VS1, and that had no support for FBA
devices (I think the 3370 was supported on MVS back then).
We used 2314 (and 2319), and Memorex 3330-{1,11} equivalents.
I wasn't referring to the use of LVM. I was referring to the assertion
that ext2 and/oor glibc can't cope.
They can, and I've done it on my PC. However, I don't recall the
precise software requirements.
Of course, you need some disk-combining facility such as RAID or LVM if
your physical disks are not that big.
I'm sadly out of touch with mainframe hardware; it seems strange to me
I can get 120 Gbyte disks for my PC and you folk are using 2.3 Gbyte
drives on your mainframes. I know the theoretical limit is larger than
that, and was back when S/360 was announced.
--
Cheers
John Summerfield
Microsoft's most solid OS: http://www.geocities.com/rcwoolley/
Note: mail delivered to me is deemed to be intended for me, for my
disposition.
==
If you don't like being told you're wrong,
be right!
Re: How to pre-allocate a 4GB File?
[EMAIL PROTECTED] said: Do I have to upgrade to 2.4 kernel to run LVM? You need 2.4 for files larger then 2.1 Gbytes. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
Re: How to pre-allocate a 4GB File?
I'm sadly out of touch with mainframe hardware; it seems strange to me I can get 120 Gbyte disks for my PC and you folk are using 2.3 Gbyte drives on your mainframes. I know the theoretical limit is larger than that, and was back when S/360 was announced. One advantage to the limited disk size is that since you can only have one I/O active to a disk volume at one time, spreading data over many smaller volumes allows more I/Os to be active at the same time. This can dramatically improve system I/O throughput. IBM even warns that using 3390-9s can degrade performance, think what using a 3390-120Gigabyte would do! In the PC world, I believe you can see the same sort of effect by using RAID0 across multiple volumes, versus one large volume.
Re: How to pre-allocate a 4GB File?
On Thu, Apr 18, 2002 at 07:23:55AM +0800, John Summerfield wrote: S/390 does also have FBA (fixed block architecture) DASD devices. Sadly, even in the Linux world these are not widely known or used. I maintain that they should be employed heavily and heartily! The benefits are numerous. Oh? Like what? Remember that, these days, most DASD is made up of huge RAID arrays emulating either classic FBA or CKD devices, and the emulation overhead of either is pretty small. Back when I was a sysprog we used VS1, and that had no support for FBA devices (I think the 3370 was supported on MVS back then). MVS never has supported any FBA devices. The problem is that the CKD architecture is heavily embedded deep in two critical pieces of the MVS core: program fetch and VTOC processing. I'm not familiar with the details of PDSEs for program fetch, but if load libraries are PDSes, they're still searched by SEARCH KEY CCWs. I'm sadly out of touch with mainframe hardware; it seems strange to me I can get 120 Gbyte disks for my PC and you folk are using 2.3 Gbyte drives on your mainframes. I know the theoretical limit is larger than that, and was back when S/360 was announced. The limit is that the cylinder number is a halfword, and exceeding that breaks a LOT of things. There are even today things you can't put on a 3390-9 beyond cylinder 65535 (the JES2 spool dataset springs immediately to mind). OTOH, MVS shops ran into the need to span volumes a long time before others did, and so they understand how to manage multivolume datasets very well.
Re: How to pre-allocate a 4GB File?
I'm sadly out of touch with mainframe hardware; it seems strange to me I can get 120 Gbyte disks for my PC and you folk are using 2.3 Gbyte drives on your mainframes. I know the theoretical limit is larger than that, and was back when S/360 was announced. One advantage to the limited disk size is that since you can only have one I/O active to a disk volume at one time, spreading data over many smaller volumes allows more I/Os to be active at the same time. This can dramatically improve system I/O throughput. IBM even warns that using 3390-9s can degrade performance, think what using a 3390-120Gigabyte would do! In the PC world, I believe you can see the same sort of effect by using RAID0 across multiple volumes, versus one large volume. Locality of reference applies to files, too - 3 3390-3s are not three times better than one 3390-9. PAV is the proper approach. -- Phil Payne http://www.isham-research.com +44 7785 302 803 +49 173 6242039
Re: How to pre-allocate a 4GB File?
-Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of John Summerfield Sent: Wednesday, April 17, 2002 4:24 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Of course, you need some disk-combining facility such as RAID or LVM if your physical disks are not that big. I'm sadly out of touch with mainframe hardware; it seems strange to me I can get 120 Gbyte disks for my PC and you folk are using 2.3 Gbyte drives on your mainframes. I know the theoretical limit is larger than that, and was back when S/360 was announced. Until very recently, the length of the cylinder count field in a CCW was, iirc, 12 bits; limiting the cylinder range to max of 4096. However, the new ESS (a.k.a SHARK) dasd units now allow 3390 devices to be configured with up to 32760 cylinders, yielding a DASD volume capacity of about 26Gb. z/VM has already been updated to recognize and support these new dasd sizes in both CMS and CP environments. Since the S/3XX architecture got its start when dasd devices where considerably smaller than today's, both the MVS and VM system evolved other ways of handling large files on small devices: MVS has had multi-volume file support for ages, and VM uses the SFS to allow the storage of files up to 17x10**12 bytes in size. Dave Dave
Re: How to pre-allocate a 4GB File?
[EMAIL PROTECTED] said: MVS never has supported any FBA devices. The problem is that the CKD architecture is heavily embedded deep in two critical pieces of the MVS core: program fetch and VTOC processing. I'm not familiar with the details of PDSEs for program fetch, but if load libraries are PDSes, they're still searched by SEARCH KEY CCWs. Load library members have imbedded channel programs. Moving a load library to an FBA disk might have been a challenge. All partitioned datasets have keyed directory blocks. VTOCs are keyed datasets (or were, I don't how the newer format introduced with the DF products worked). However, VSE has the same VTOC format. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
Re: How to pre-allocate a 4GB File?
Jay Maynard wrote: The limit is that the cylinder number is a halfword, and exceeding that breaks a LOT of things. There are even today things you can't put on a 3390-9 beyond cylinder 65535 (the JES2 spool dataset springs immediately to mind). Minor nit. On MVS a single extent cannot exceed 65535 *tracks* and a 3390-9 has 10017 cylinders (150255 trks). Theoretically, ckd architecture can support 65535 cyls, 65535 heads (or trks/cyl), 255 blks/trk, each blk with a 255 byte key area and a 65535 byte data area (which adds up to a fairly large number). Greg
Re: How to pre-allocate a 4GB File?
Jay Maynard wrote: The limit is that the cylinder number is a halfword, and exceeding that breaks a LOT of things. There are even today things you can't put on a 3390-9 beyond cylinder 65535 (the JES2 spool dataset springs immediately to mind). Minor nit. On MVS a single extent cannot exceed 65535 *tracks* and a 3390-9 has 10017 cylinders (150255 trks). Theoretically, ckd architecture can support 65535 cyls, 65535 heads (or trks/cyl), 255 blks/trk, each blk with a 255 byte key area and a 65535 byte data area (which adds up to a fairly large number). Greg Not quite - the key for this purpose is included in the length of the data block. (65535 * 255 * 65535) is still fairly large. More than 2.3 Gbytes. Back in my time the maximum data length supported on any device was 32k-8, but I did hear of someone reading an entire tape written (by some metering device) as a single block. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
Re: How to pre-allocate a 4GB File?
Unfortunately we are emulating the geometry of the last generation of ECDK devices (3390's) by creating virtual volumes within an array of SCSI disks. In its day the model 9 was a bulk data storage model with poor performance characteristics. The performance of virtual 3390 volume however is a function of the real hardware used to build the SCSI array. Some systems programmers still persist in defining only 3390-3 volumes concerned over the performance issues associated with real 3390-9's. This results in a larger number of volumes to manage than necessary. Given today's multi-terabyte DASD farms, the number of logical volumes becomes staggering. It is however true that I/O is queued at the device level and there may be situations where more emulated volumes are better. However one can do no more transfers than the number of upper interfaces available (number of channel connections to the subsystem). In developing a capacity management system for a client last year, reporting for DASD services times only listed volumes whose services times exceeded 8 milliseconds. We have come a long way since the 1st cached controllers in the mid-80's. 3390's were state of the art disk drives 10 YEARS ago. Even if you were given the required 3990 controllers and some 3390 drives, it would still be cheaper to purchase a new Shark, EMC, etc. storage subsystem due to the cost of maintenance and the cost of power to spin them and to cool them. That is to say that real 3390's are for all practical purposes no longer in use. I have not been in a data center in the last 6 years that had any 3390's install. Maybe I have been lucky or oblivious to their presence. Has anyone heard of any IBM plans to provide non-ECKD DASD support for zOS? We can't go on emulating 33X0 volumes much longer. Don Stubbs -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Webb, Toronto Transit Commission Sent: Thursday, April 18, 2002 11:07 AM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? I'm sadly out of touch with mainframe hardware; it seems strange to me I can get 120 Gbyte disks for my PC and you folk are using 2.3 Gbyte drives on your mainframes. I know the theoretical limit is larger than that, and was back when S/360 was announced. One advantage to the limited disk size is that since you can only have one I/O active to a disk volume at one time, spreading data over many smaller volumes allows more I/Os to be active at the same time. This can dramatically improve system I/O throughput. IBM even warns that using 3390-9s can degrade performance, think what using a 3390-120Gigabyte would do! In the PC world, I believe you can see the same sort of effect by using RAID0 across multiple volumes, versus one large volume.
FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
I said (to John): S/390 does also have FBA (fixed block architecture) DASD devices. Sadly, even in the Linux world these are not widely known or used. I maintain that they should be employed heavily and heartily! The benefits are numerous. On Thu, 18 Apr 2002, Jay Maynard wrote: Oh? Like what? Using FBA hardware alleviates the need for the DASD driver to deal with C/H/S translation and work directly with blocks. A UNIX filesystem is a structure placed into a string-of-bytes. Where the hardware looks like a string-of-bytes, it is (theoretically, and I say in practice too) easier for the system to present a linear space since the device is already linear. Why does loop-back mounting work? Why is LBA preferred on PC hardware nowadays? Note that CD can be presented as FBA *today* on some S/390. Specifically, for P/390 (and presumably for Multiprise) a CD image, a .iso file, can be configured to the S/390 as an FBA. The support system may (in my case does) complain about no IBM volser, but it works as expected. I installed SuSE 7.0 directly from CD, as far as the S/390 knew. (It was an ISO image, but the S/390 did not know that it was not a CD copied block-for-block onto a 3370.) So CD could be attached to zSeries neatly if attached as FBA. With FBA, the effect of DDR approaches the effect of the Linux (UNIX) command 'dd' for copying a volume. And what will happen now with SCSI attachment to zSeries? I can only hope that there will NOT be some CKD protocol. It just doesn't seem worth it when FBA is what is really happening. Remember that, these days, most DASD is made up of huge RAID arrays emulating either classic FBA or CKD devices, and the emulation overhead of either is pretty small. Right. And since the actual backing store is fixed-block, I say let that which is presented also be fixed-block and ditch the track, record, count, and key info and the associated work. With CKD, Linux must play the C/H/S game. With emulated CKD, so must the DASD subsystem. Why not let both ends stop faking it?? John said: Back when I was a sysprog we used VS1, and that had no support for FBA devices (I think the 3370 was supported on MVS back then). then Jay said: MVS never has supported any FBA devices. The problem is that the CKD architecture is heavily embedded deep in two critical pieces of the MVS core: program fetch and VTOC processing. I'm not familiar with the details of PDSEs for program fetch, but if load libraries are PDSes, they're still searched by SEARCH KEY CCWs. But VSE and VM both work with FBA DASD. I'm not saying that we should endorse FBA to the demise of MVS. I am only saying that we should endorse FBA to the benefit of Linux, VM, and VSE. And with modern DASD subsystems, it should be no great pain to present either flavor as needed. Let MVS have its CKD. But let the rest have FBA when they want.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
[EMAIL PROTECTED] said: Right. And since the actual backing store is fixed-block, I say let that which is presented also be fixed-block and ditch the track, record, count, and key info and the associated work. With CKD, Linux must play the C/H/S game. With emulated CKD, so must the DASD subsystem. Why not let both ends stop faking it?? VSAM, Partitioned Datasets and VTOCs for starters all depend on keyed records. How well do these perform on VSE on FBA devices? With the emulation the stuffing around needed is done off the host CPU - I don't care a lot whether it's the channel or controller or the device itself. I presume that for the FBA devices to be supported directly then it would be done by the host CPU and people tell me it's not that strong. Of course, Linux would get along just fine with FBA devices, so the option to attach sharks etc natively would clearly be of use. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
Note that CD can be presented as FBA *today* on some S/390. Specifically, for P/390 (and presumably for Multiprise) a CD image, a .iso file, can be configured to the S/390 as an FBA. Yup. Works on a Multiprise too, as Dave Jones can attest. Adam
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
On Thu, Apr 18, 2002 at 12:44:13PM -0500, Adam Thornton wrote: Note that CD can be presented as FBA *today* on some S/390. Specifically, for P/390 (and presumably for Multiprise) a CD image, a .iso file, can be configured to the S/390 as an FBA. Yup. Works on a Multiprise too, as Dave Jones can attest. And, for that matter, on Hercules. (Which is one reason I want .iso files to install Linux/390 from...it can't be any slower than an FTP install over a Hercules CTC.)
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
On Thu, Apr 18, 2002 at 10:44:39AM -0500, Rick Troth wrote: And what will happen now with SCSI attachment to zSeries? I can only hope that there will NOT be some CKD protocol. It just doesn't seem worth it when FBA is what is really happening. Probably so, at least for VM, VSE, and Linux. With CKD, Linux must play the C/H/S game. With emulated CKD, so must the DASD subsystem. Why not let both ends stop faking it?? Mainframers - at least MVS types - aren't used to thinking that way. A sile as a stream of bytes is completely alien to them. But VSE and VM both work with FBA DASD. VM has always used a fixed-block structured filesystem internally anyway, so it was just a matter of changing block sizes. I can't speak to VSE, never having dealt with it. I'm not saying that we should endorse FBA to the demise of MVS. I am only saying that we should endorse FBA to the benefit of Linux, VM, and VSE. And with modern DASD subsystems, it should be no great pain to present either flavor as needed. Let MVS have its CKD. But let the rest have FBA when they want. I believe that's the case now. There's one benefit for Hercules users of using CKD instead of FBA: compressed DASD images. Compressed CKD is a big win. Unfortunately, there's no compressed FBA support.
Re: How to pre-allocate a 4GB File?
There were gapless tapes generated by seismo trucks, used
for recording data from the geophones, normally seen as data
input for 3DFFTs. I last dealt with these 20+ years ago working
w/ oil exploration stuff. At the time triple-buffering and
multiactivity
(multithreading) was de rigeur.
The tape density wasn't incredibly high but it was a continuous
stream that you couldn't afford to drop since that'd require re-
starting the process.
John R. Campbell, Speaker to Machines (GNUrd) {813-356|697}-5322
Will Work for CLAIM Codes
IBM Certified: IBM AIX 4.3 System Administration, System Support
John Summerfield [EMAIL PROTECTED]@VM.MARIST.EDU on 04/18/2002
12:52:03 PM
Please respond to Linux on 390 Port [EMAIL PROTECTED]
Sent by:Linux on 390 Port [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:Re: How to pre-allocate a 4GB File?
Jay Maynard wrote:
The limit is that the cylinder number is a halfword, and exceeding that
breaks a LOT of things. There are even today things you can't put on a
3390-9 beyond cylinder 65535 (the JES2 spool dataset springs
immediately to
mind).
Minor nit. On MVS a single extent cannot exceed 65535 *tracks* and
a 3390-9 has 10017 cylinders (150255 trks).
Theoretically, ckd architecture can support 65535 cyls, 65535 heads
(or trks/cyl), 255 blks/trk, each blk with a 255 byte key area and a
65535 byte data area (which adds up to a fairly large number).
Greg
Not quite - the key for this purpose is included in the length of the
data block.
(65535 * 255 * 65535) is still fairly large. More than 2.3 Gbytes.
Back in my time the maximum data length supported on any device was
32k-8, but I did hear of someone reading an entire tape written (by
some metering device) as a single block.
--
Cheers
John Summerfield
Microsoft's most solid OS: http://www.geocities.com/rcwoolley/
Note: mail delivered to me is deemed to be intended for me, for my
disposition.
==
If you don't like being told you're wrong,
be right!
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
VSE used the FBA devices, 3310 3370s, in the 80s. As of VSE 2.4, 3310s are not listed as supported, and 3370s are listed as data volumes only, not for systems or installation use. There is a 9336 listed under FBA that appearently can still be used as a system or installation device, but I'm not familliar with it. Direct Access files are not support on any FBA device under VSE, which can make life difficult for some database software, like ADABAS Garry E. Ward Senior Software Specialist Maritz Research Automotive Research Group 419-725-4123 -Original Message- From: Jay Maynard [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 2:10 PM To: [EMAIL PROTECTED] Subject: Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?] On Thu, Apr 18, 2002 at 10:44:39AM -0500, Rick Troth wrote: And what will happen now with SCSI attachment to zSeries? I can only hope that there will NOT be some CKD protocol. It just doesn't seem worth it when FBA is what is really happening. Probably so, at least for VM, VSE, and Linux. With CKD, Linux must play the C/H/S game. With emulated CKD, so must the DASD subsystem. Why not let both ends stop faking it?? Mainframers - at least MVS types - aren't used to thinking that way. A sile as a stream of bytes is completely alien to them. But VSE and VM both work with FBA DASD. VM has always used a fixed-block structured filesystem internally anyway, so it was just a matter of changing block sizes. I can't speak to VSE, never having dealt with it. I'm not saying that we should endorse FBA to the demise of MVS. I am only saying that we should endorse FBA to the benefit of Linux, VM, and VSE. And with modern DASD subsystems, it should be no great pain to present either flavor as needed. Let MVS have its CKD. But let the rest have FBA when they want. I believe that's the case now. There's one benefit for Hercules users of using CKD instead of FBA: compressed DASD images. Compressed CKD is a big win. Unfortunately, there's no compressed FBA support.
Re: How to pre-allocate a 4GB File?
John Summerfield wrote: Not quite - the key for this purpose is included in the length of the data block. (65535 * 255 * 65535) is still fairly large. More than 2.3 Gbytes. Don't think so. CKD stands for count,key,data. Each record on a track has a count area, optional key area and optional data area. The format of an 8-byte count area is CCHHRKDD CC is a 16 bit cylinder number, HH is a 16 bit head number, R is a 8 bit record number, K is a 8 bit key length and DD is a 16 bit data length. The data length does not include the key length. And 65535*65535*255*(255+65535) is a little larger than 2.3G. In fact, a 3390-3, which has limits well below these theoretical maximums, is about 2.3G in size. Of course, the theoritical maximum does break down in a number of areas. To do anything useful, record 0 must be `standard' (ie no key and an 8 byte data area). The device characteristics information has only a three byte field for track capacity. And I know for a fact that Hercules would break if the max track size exceeds 64K ;-) Greg
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
On Thu, Apr 18, 2002 at 01:04:28PM -0500, Jay Maynard wrote: On Thu, Apr 18, 2002 at 12:44:13PM -0500, Adam Thornton wrote: Note that CD can be presented as FBA *today* on some S/390. Specifically, for P/390 (and presumably for Multiprise) a CD image, a .iso file, can be configured to the S/390 as an FBA. Yup. Works on a Multiprise too, as Dave Jones can attest. And, for that matter, on Hercules. (Which is one reason I want .iso files to install Linux/390 from...it can't be any slower than an FTP install over a Hercules CTC.) Jay Maynard, if the author of hercules wants to have this, I'll reconsider this for the next rawhide upload. :-) At least our 64bit version already has iso images available, so you might already test with those if you have enough RAM/CPU available. cu, Florian La Roche
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
On Thu, Apr 18, 2002 at 08:27:35PM +0200, Florian La Roche wrote: if the author of hercules wants to have this, I'll reconsider this for the next rawhide upload. :-) That would be nice. Thanks! I must point out, though, that I'm not really the author of Hercules; I'm just the guy who gets to build formal production releases and host the web site and talk about it in public. A lot of other folks have done a lot of work on the package, many of them contributors here. At least our 64bit version already has iso images available, so you might already test with those if you have enough RAM/CPU available. Oh, okkay...didn't know that. I just started a download. Having 30 GB on my laptop has its uses.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
For VSAM it isn't that bad; and Relative Byte Address is a Relative Byte Address, on FBA it's a little easier becasue you just map from the first byte on the pack. VTOC's used the relative record approach instead of an CCHHRR. Garry E. Ward Senior Software Specialist Maritz Research Automotive Research Group 419-725-4123 -Original Message- From: John Summerfield [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 1:36 PM To: [EMAIL PROTECTED] Subject: Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?] [EMAIL PROTECTED] said: Right. And since the actual backing store is fixed-block, I say let that which is presented also be fixed-block and ditch the track, record, count, and key info and the associated work. With CKD, Linux must play the C/H/S game. With emulated CKD, so must the DASD subsystem. Why not let both ends stop faking it?? VSAM, Partitioned Datasets and VTOCs for starters all depend on keyed records. How well do these perform on VSE on FBA devices? With the emulation the stuffing around needed is done off the host CPU - I don't care a lot whether it's the channel or controller or the device itself. I presume that for the FBA devices to be supported directly then it would be done by the host CPU and people tell me it's not that strong. Of course, Linux would get along just fine with FBA devices, so the option to attach sharks etc natively would clearly be of use. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right! font size=1Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
-Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of Adam Thornton Sent: Thursday, April 18, 2002 10:44 AM To: [EMAIL PROTECTED] Subject: Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?] Note that CD can be presented as FBA *today* on some S/390. Specifically, for P/390 (and presumably for Multiprise) a CD image, a .iso file, can be configured to the S/390 as an FBA. Yup. Works on a Multiprise too, as Dave Jones can attest. Works very well, indeed. Hard part was figuring out how to make an .iso image from the CD, but once that was done, it was a piece of cake. DJ Adam
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
On Thu, Apr 18, 2002 at 11:17:45PM +0200, Phil Payne wrote: Mainframers - at least MVS types - aren't used to thinking that way. A sile as a stream of bytes is completely alien to them. System types, or application types? We've had RBA since VSAM I - lots of things like DB2 logs are RBA-governed. Systems types that I know of, certainly. They tend to think of files in terms of records, not as a stream of bytes. VSAM ESDSs and the like are definitely in the minority. I can't speak to applications (or, for that matter, IMS and DB2 DBA) folks.
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
Mainframers - at least MVS types - aren't used to thinking that way. A sile as a stream of bytes is completely alien to them. System types, or application types? We've had RBA since VSAM I - lots of things like DB2 logs are RBA-governed. -- Phil Payne http://www.isham-research.com +44 7785 302 803 +49 173 6242039
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
On Thursday, 04/18/2002 at 10:44 EST, Rick Troth [EMAIL PROTECTED] wrote: And what will happen now with SCSI attachment to zSeries? I can only hope that there will NOT be some CKD protocol. It just doesn't seem worth it when FBA is what is really happening. As hard as it might be to believe, zSeries operating systems will talk SCSI over Fibre Channel Protocol adapters to SCSI devices. Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: FBA for Jay [was: Re: How to pre-allocate a 4GB File?]
Really? As in talking to existing Fiber Channel[1] disk arrays that speak FC-SCSI? and/or via FC-SCSI bridges to random SCSI devices? Where can I find out more? I used to work on FC-attached storage array systems at Compaq... Has anyone tried iSCSI with S/390 ?
Re: How to pre-allocate a 4GB File?
John Summerfield wrote: Not quite - the key for this purpose is included in the length of the data block. (65535 * 255 * 65535) is still fairly large. More than 2.3 Gbytes. Don't think so. CKD stands for count,key,data. Each record on a track has a count area, optional key area and optional data area. The format of an 8-byte count area is CCHHRKDD CC is a 16 bit cylinder number, HH is a 16 bit head number, R is a 8 bit record number, K is a 8 bit key length and DD is a 16 bit data length. The data length does not include the key length. The data length in the channel program is the total length of the data transfer. Back when, you could get round it in excp, but I don't think other access methods such as BDAN and BSAM would hand it. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
Re: How to pre-allocate a 4GB File?
17.04.2002 01:16:12 Rengasamy, Samy wrote: How to pre-allocate a 4GB File in a system with several 2.3 GB dasds? We're looking for a way to be able to create a single file slightly larger than 4Gbytes (to test some logic in the code which has been known to break on ports where seek offsets go over 32-bits). Or is the largest file we can ever make around 2.3Gbytes ? You can create Software RAID-0. WBR, Sergey
Re: How to pre-allocate a 4GB File?
[EMAIL PROTECTED] said: The Linux LVM allows you to build a larger filesystem using several dasds - but if you use the ext2-filesystem the maximum filesize will - afaik - only be 2GB. Twaddle. [summer@numbat summer]$ ll /tmp/hdb5 -h -rw-r-1 root 8.0G Feb 1 18:27 /tmp/hdb5 [summer@numbat summer]$ Or can I do better on a PC than you can on a mainframe? You do need a 2.4 kernel. I'm running RHL 7.2. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. == If you don't like being told you're wrong, be right!
Re: How to pre-allocate a 4GB File?
Do I have to upgrade to 2.4 kernel to run LVM? How can I build software RAID-O? Thanks, Samy Rengasamy. -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 10:20 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Samy, You'll need to be running a 2.4 kernel, and either LVM, or RAID to aggregate multiple 3390 volumes, or have some 3390-9 volumes available. Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 6:16 PM To: [EMAIL PROTECTED] Subject: How to pre-allocate a 4GB File? How to pre-allocate a 4GB File in a system with several 2.3 GB dasds? We're looking for a way to be able to create a single file slightly larger than 4Gbytes (to test some logic in the code which has been known to break on ports where seek offsets go over 32-bits). Or is the largest file we can ever make around 2.3Gbytes ? Thanks, Samy Rengasamy.
Re: How to pre-allocate a 4GB File?
Samy, SuSE 7.0 has LVM support built into it. Red Hat 7.2 does not. For RAID support, take a look at http://www.marist.edu/htbin/wlvtype?LINUX-VM.22398 and http://www.linuxdoc.org/HOWTO/Software-RAID-HOWTO.html Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 1:28 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Do I have to upgrade to 2.4 kernel to run LVM? How can I build software RAID-O? Thanks, Samy Rengasamy. -Original Message- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 10:20 PM To: [EMAIL PROTECTED] Subject: Re: How to pre-allocate a 4GB File? Samy, You'll need to be running a 2.4 kernel, and either LVM, or RAID to aggregate multiple 3390 volumes, or have some 3390-9 volumes available. Mark Post -Original Message- From: Rengasamy, Samy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 6:16 PM To: [EMAIL PROTECTED] Subject: How to pre-allocate a 4GB File? How to pre-allocate a 4GB File in a system with several 2.3 GB dasds? We're looking for a way to be able to create a single file slightly larger than 4Gbytes (to test some logic in the code which has been known to break on ports where seek offsets go over 32-bits). Or is the largest file we can ever make around 2.3Gbytes ? Thanks, Samy Rengasamy.
Re: How to pre-allocate a 4GB File?
Does anyone knows the max size of ORACLE database and table on the 32bits Linux machine... INTEL or Z/VM running on G5 machine.
Re: How to pre-allocate a 4GB File?
How can I build software RAID-O? # cd /dev # mknod md0 b 9 0 ... # cat /etc/raidtab raiddev /dev/md0 raid-level 0 nr-raid-disks 4 persistent-superblock 1 chunk-size 128 device /dev/dasdf1 raid-disk 0 device /dev/dasdg1 raid-disk 1 device /dev/dasdh1 raid-disk 2 device /dev/dasdi1 raid-disk 3 # mkraid /dev/md0 # mkreiserfs /dev/md0 // or mke2fs # mkdir /swRAID0 # mount /dev/md0 /swRAID0 # df -h | grep md0 /dev/md0 9.2G 53M 9.1G 1% /s -Mike MacIsaac, IBM [EMAIL PROTECTED] (845) 433-7061
Re: How to pre-allocate a 4GB File?
I am going to guess that Oracle has theoretical and practical database size limitations. I would not expect that those limitations would change. All tempered by the size limitations of your chosen filesystem. As mentioned here before, LVM can be used to cobble together many 3390-3 (2.3GB) or -9 (7GB) devices for the use on large filesystems. I intend to do this for a DB2 project (hopefully) later this spring/summer. On Wednesday 17 April 2002 01:00 pm, you wrote: Does anyone knows the max size of ORACLE database and table on the 32bits Linux machine... INTEL or Z/VM running on G5 machine. -- Rich Smrcina Sytek Services, Inc. Milwaukee, WI [EMAIL PROTECTED] [EMAIL PROTECTED] Catch the WAVV! Stay for Requirements and the Free for All! Update your S/390 skills in 4 days for a very reasonable price. WAVV 2003 in Winston-Salem, NC. April 25-29, 2003 For details see http://www.wavv.org
Re: How to pre-allocate a 4GB File?
Do I have to upgrade to 2.4 kernel to run LVM? How can I build software RAID-O? Well you could always cheat. Unix/Linux are bright enough not to store empty never written blocks, so you can open64/ftruncate a file up to 4Gb long and it uses very little disk space, then just play with the points you need to check
Re: How to pre-allocate a 4GB File?
Hi Samy ! How to pre-allocate a 4GB File in a system with several 2.3 GB dasds? We're looking for a way to be able to create a single file slightly larger than 4Gbytes (to test some logic in the code which has been known to break on ports where seek offsets go over 32-bits). Or is the largest file we can ever make around 2.3Gbytes ? The Linux LVM allows you to build a larger filesystem using several dasds - but if you use the ext2-filesystem the maximum filesize will - afaik - only be 2GB. robert.
Re: How to pre-allocate a 4GB File?
We're looking for a way to be able to create a single file slightly larger than 4Gbytes (to test some logic in the code which has been known to break on ports where seek offsets go over 32-bits). Or is the largest file we can ever make around 2.3Gbytes ? The Linux LVM allows you to build a larger filesystem using several dasds - but if you use the ext2-filesystem the maximum filesize will - afaik - only be 2GB. The 2.4 kernel and glibc 2.2 support 64bit file sizes. The actual limit then is about 1Tb. Alan
