Re: Top 10 software install gripes
On Sat, 12 May 2007 00:22:19 -0400, Pinnacle wrote: Dynamic ISPF covers that. Also, z/OS V1R8 has an option to make STACK the default for all LIBDEFs (my enhancement request, since no one could ever tell me what a non-STACKed LIBDEF was ever good for except screwing up your ISPF session). You have to run ISPCCONF (check out my Configuring ISPF for Fun and Profit session. But, can an ISV depend all customers' having Dynamic ISPF or any other idiosyncratic ISPF configuration. Some may be much put off by instructions that begin, Begin by checking out Tom's session, then download from CBT and install ...) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
On Fri, 11 May 2007 11:21:13 -0500, Thomas Conley wrote: #7 - Get rid of your stupid SMP/E procs and give me DDDEFS!! (this means you CA-1 and Panvalet) #2 - Stop giving me 3K and 6K blocksizes, loadlibs should be blocked at 32760 and everything else should get 0 for SDB (unless you have a wacky format like CA-Viewpoint). Does SDB make an adverse selection for loadlibs? Has a suggestion been made to IBM to ameliorate this? How much worse, by what metric, is SDB's default (half track?) than 32760? #1 - Change your stupid SYSDA default UNIT to SYSALLDA, PUHLEEEZZEEE!!! I haven't been in a shop where SYSDA has worked for over a DECADE! Many sites stopped defining SYSDA in favor of the system esoteric SYSALLDA, so get with the program! That's what JCL symbols are for. I'd like to be able to edit a single JCLLIB INCLUDE member to tailor an entire installation suite. (But each job would still need to be edited to specify the correct JCLLIB.) And installation setup is what most makes me wish for symbolic substition in instream data sets. It would be invaluable to be able to change a single // SET DSPREFIX=XYZZY and have both the DD statements in the IEFBR14 step and the DDDEFS in the SMPCNTL UCLIN track accordingly. The lack of such a facility is a factor influencing vendors to use stupid SMP/E procs instead of DDDEFs. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
But, can an ISV depend all customers' having Dynamic ISPF Yes, this is SOP. All a vendor needs to do is code a clist or exec that does the LIBDEFs and have the customer activate it from a panel. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
#2 - Stop giving me 3K and 6K blocksizes, loadlibs should be blocked at 32760 and everything else should get 0 for SDB (unless you have a wacky format like CA-Viewpoint). Does SDB make an adverse selection for loadlibs? Has a suggestion been made to IBM to ameliorate this? How much worse, by what metric, is SDB's default (half track?) than 32760? I understood the BINDER, aka linkage editor, knows how to utilize the space in a LOADLIB, so 32760 is the best number to use. Following the earlier suggestion to use 32760 on a loadlib and 0 everywhere means SDB is not choosing a blksize for loadlibs, and I agree that is fine. Before SDB can choose 32760 for every RECFM=U LRECL=0 dataset, the user community would have to swear this is never used for other than a loadlib. Until then, the two BLKSIZE values work for me. As for stupid PROCs versus DDDEFs - in my opinion, SMS means uniquely named datasets and they are are catalogued so a DDDEF only needs to have DSNAME and DISP. If a vendor has trouble doing this, they are stupid. UNIT=SYSALLDA during allocation makes perfect sense. My ACS routine will assign a volume. For those shops working in the 1980's (non-SMS), they can add parameters to make the install complete. Use today's technology. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
Paul Gilmartin wrote: On Fri, 11 May 2007 11:21:13 -0500, Thomas Conley wrote: #7 - Get rid of your stupid SMP/E procs and give me DDDEFS!! (this means you CA-1 and Panvalet) #2 - Stop giving me 3K and 6K blocksizes, loadlibs should be blocked at 32760 and everything else should get 0 for SDB (unless you have a wacky format like CA-Viewpoint). Does SDB make an adverse selection for loadlibs? Has a suggestion been made to IBM to ameliorate this? How much worse, by what metric, is SDB's default (half track?) than 32760? #1 - Change your stupid SYSDA default UNIT to SYSALLDA, PUHLEEEZZEEE!!! I haven't been in a shop where SYSDA has worked for over a DECADE! Many sites stopped defining SYSDA in favor of the system esoteric SYSALLDA, so get with the program! That's what JCL symbols are for. I'd like to be able to edit a single JCLLIB INCLUDE member to tailor an entire installation suite. (But each job would still need to be edited to specify the correct JCLLIB.) To install files for labs in our courses we have our customers modify a single rexx exec; then students run the exec which is an ISPF dialog that creates files for each student, including copying JCL into a CNTL library and running an edit macro that modifies the JOB statement in the student library; then another edit macro is invoked against each job that copies the student's JOB statement to the front. The exec the customer modifies includes their choice for UNIT (we default to SYSALLDA) as well as the name of the library for a JOBLIB statement everyone will use. [We do have to have them also edit an INLCUDE member that has the names of relevant files. This include member is referenced in the generated JOB statement.] And installation setup is what most makes me wish for symbolic substition in instream data sets. It would be invaluable to be able to change a single // SET DSPREFIX=XYZZY and have both the DD statements in the IEFBR14 step and the DDDEFS in the SMPCNTL UCLIN track accordingly. The lack of such a facility is a factor influencing vendors to use stupid SMP/E procs instead of DDDEFs. -- gil -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Looking for a copy of B2H.ZIP (Bookmaster to HTML)
I downloaded the zip file from from http://www.vm.ibm.com/download/packages/alltime.html and unzipped it just fine. I even browsed every file. This is a May 2002 version. If your copy was damaged, was it the vmarc or zip version? Did you report it to IBM? What indication led you to believe it is damaged? It woud be nice to others to get it fixed on the IBM site if is is damaged. On Fri, 11 May 2007 10:15:38 +0200, Hunkeler Peter (KIUK 3) [EMAIL PROTECTED] wrote: Does anyone have a copy of B2H.ZIP, the Bookmaster to HTML conversion tool? If so, I'd appreciate if you send me a copy to [EMAIL PROTECTED] The file on IBM's VM download site is damaged. Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
Similar to what I do for labs at the SHARE Conference. I have simpler needs so I provide one edit macro for them to run while they are editing the IEBUPDTE input they will use to populate their PDS. IBM uses CPPUPDTE and the SERVERPAC dialog to alter and tailor JCL for installations. ISPF file tailoring is not difficult for a vendor to use. I have written my own simple pdsupdte rexx code. I prefer simple, so if vendors need to deliver a PDS format, have a simple way to make global changes. If you provide an IEBUPDTE stream have instructions on how to do a change all command of what needs to be changed and then load a PDS. I hae read a wonderful PDS that Steve Comstcok has available on his website, vendors should consider getting some training before they concoct screwy installation processes. - My opinion. On Sat, 12 May 2007 07:53:08 -0600, Steve Comstock [EMAIL PROTECTED] wrote: To install files for labs in our courses we have our customers modify a single rexx exec; then students run the exec which is an ISPF dialog that creates files for each student, including copying JCL into a CNTL library and running an edit macro that modifies the JOB statement in the student library; then another edit macro is invoked against each job that copies the student's JOB statement to the front. The exec the customer modifies includes their choice for UNIT (we default to SYSALLDA) as well as the name of the library for a JOBLIB statement everyone will use. [We do have to have them also edit an INLCUDE member that has the names of relevant files. This include member is referenced in the generated JOB statement.] Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
It had some small effect, back when RPS delay was a signivicant factor. I still allocate directories in full track amounts, but mostly from force of habit. I can't see that it does any harm, and the allocations that come from IBM and OEM software providers aren't always large enough to apply maintenance or upgrades. Call me Old Fashioned if you like; I don't care. G Eric Bielefeld wrote: I thought that long ago when the old 3380 3390 dasd was current, that allocating the PDS directory on either a track or cylinder boundary had some advantages. At least that's what I remember. Eric Bielefeld On Sat, 12 May 2007 01:34:38 +0100, Tony [EMAIL PROTECTED] wrote: I don't know the answer. It may be in a Redbook. I doubt it. I've never seen any reccomendation that directories be allocated so that they will fill up tracks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
The PDS directory records are a fixed size, LRECL=255, I believe. My reason to allocate a PDS filling a track, or multiples, with the directory comes from thinking half-track blocking is efficient for reads and if I use one half, or full track directory then I am doing the least amount of I/O as possible. Reality may be different. The optimum number of PDS entries to allocate depends on the type of PDS, loadlib or other. For other, are statistics kept or not. How many of us ignore taking the time to plan the need and just allocate with a larger number than we need? I chose to allocate larger based on number of tracks. I no longer use a PDS for non-loadlib datasets. I believe in my testing I found 44 directory blocks will fit on one track with the end-of-file block following it on the same track. There will be room for the starting text of one member on the same track. 45 directory blocks will fit on one track with the end-of-file block spilling over to the second track. For this reason I had been using multiples of 44 directory blocks when I used a PDS. When you use ISPF to access a member list, you must read all of the necessary directory entries to populate the list. 44 means reading two half track blocks, while 45 means reading three to reach the end-of-file block. That was from m belief the directory entries fit in the half-track blksize I used to allocate the PDS. Nowadays I would still consider using 44 as my smallest, and if I need more I would use multiples of 45 plus 44 for the last. Couple that with having learned CYL allocation performed better than TRK or BLK and assigning one track to a small PDS is of no concern. I still favor allocating based on some planning, but laziness prevails more often than not. Take a bunch of so-called facts and we end up doing things of dubious quality. And as things change we persist in using our outdated thinking. Conclusion - vendors should allocate a directory to fit what they deliver plus maybe 10% for future growth. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Tom Marchant I'm not sure how many PDS directory blocks will fit on a track, but I don't see why it's important either. IIRC, the remainder of the last directory track will be used for data. In any case, I see no reason to make the directory larger just to make it fill the last track. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where did the term clip come from?
I haven't looked lately; does it contain the noun RAX ?? or the 2848 controller and the 2260 display terminal? Michael Stack wrote: I dunno. My personal completeness measure would be the presence of the term GOVRFLB. No particular reason - I just like to pronounce it. Mike At 01:26 PM 5/11/2007 -0500, you wrote: ... That IBM *jargon dictionary* is GREAT. But it lacks one important def from *back-in-the-day* DIRF bit = DASDM Interrupt Recording Facility bit Anyone remember that one?! Looks like a revision is in order?! Michael Stack [EMAIL PROTECTED] http://www.kcats.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
-snip- The PDS directory records are a fixed size, LRECL=255, I believe. My reason to allocate a PDS filling a track, or multiples, with the directory comes from thinking half-track blocking is efficient for reads and if I use one half, or full track directory then I am doing the least amount of I/O as possible. Reality may be different. The optimum number of PDS entries to allocate depends on the type of PDS, loadlib or other. For other, are statistics kept or not. How many of us ignore taking the time to plan the need and just allocate with a larger number than we need? I chose to allocate larger based on number of tracks. I no longer use a PDS for non-loadlib datasets. --unsnip--- Ken, the physical BLKSIZE of the directory is 255, plus a 8-byte physical key. You can set a PDS BLKSIZE to any value you like, but it will have NO effect on the directory characteristics. On a 3390, that means that you will always get 45 directory blocks to a track, or 44 blocks plus the EOF mark. -snip-- I believe in my testing I found 44 directory blocks will fit on one track with the end-of-file block following it on the same track. There will be room for the starting text of one member on the same track. 45 directory blocks will fit on one track with the end-of-file block spilling over to the second track. For this reason I had been using multiples of 44 directory blocks when I used a PDS. When you use ISPF to access a member list, you must read all of the necessary directory entries to populate the list. 44 means reading two half track blocks, while 45 means reading three to reach the end-of-file block. That was from m belief the directory entries fit in the half-track blksize I used to allocate the PDS. ---unsnip You still do the same number, 45 reads (assuming no CCW chaining) for each track of directory space. See above. snip-- Nowadays I would still consider using 44 as my smallest, and if I need more I would use multiples of 45 plus 44 for the last. unsnip I do the same, partly because I'm just an old-fashioned cuss. -snip--- Conclusion - vendors should allocate a directory to fit what they deliver plus maybe 10% for future growth. -unsnip--- Make that 20% and round to a full track and I'll go along with you. There may be a few poor slobs stuck on physical 3390's yet and in that case, there are RPS considerations. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
Pinnacle wrote: Tom, I tested this in the old days of SLED DASD, and the directory was a keyed track and you COULD NOT store a member in the directory track. It always took 2 tracks minimum for a PDS (of course, this has not been true for about 15 years). Regards, Tom Conley -- Tom, I agree with (the other) Tom - I don't think this has ever been true. I just tried making a member in a new single track PDS under MVS 3.8 and it worked without a problem - and that software is more than 20 years old. There would be an increased statistical likelihood that the first member would start at the start of a track because it is possible that there is not enough room after the directory to fit a data block on the last directory track. But there seems to be nothing to prevent it in general - which is good because that matches my recollection from those times. BTW, on the cylinders vs tracks allocation point, I think that if a data set is allocated in cylinders then the access method can use the MT bit (the Multi Track bit is the x'80' bit in the CCW opcode) when building search channel programs, thus reducing CPU overhead and the chance of RPS miss. For example, for search-key-equal-or-high, a x'69' CCW can search a track, while a x'E9' CCW can search till the end of the cylinder. Note that the end of extent being on a cylinder boundary is important, not that the extent starts on a cylinder boundary. At least that what I've heard. Mind you, I think this is all superceded by ECKD now-a-days. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
255? Really? Bob -snip- The PDS directory records are a fixed size, LRECL=255, I believe. My reason to allocate a PDS filling a track, or multiples, with the directory comes from thinking half-track blocking is efficient for reads and if I use one half, or full track directory then I am doing the least amount of I/O as possible. Reality may be different. The optimum number of PDS entries to allocate depends on the type of PDS, loadlib or other. For other, are statistics kept or not. How many of us ignore taking the time to plan the need and just allocate with a larger number than we need? I chose to allocate larger based on number of tracks. I no longer use a PDS for non-loadlib datasets. --unsnip--- Ken, the physical BLKSIZE of the directory is 255, plus a 8-byte physical key. You can set a PDS BLKSIZE to any value you like, but it will have NO effect on the directory characteristics. On a 3390, that means that you will always get 45 directory blocks to a track, or 44 blocks plus the EOF mark. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Load Library BLKSIZE=32760 (Was: Top 10 software install gripes)
Paul Gilmartin wrote: Does SDB make an adverse selection for loadlibs? The issue is not block size selection but rather deterministic recognition of the library as being a loadlib. Though common, DSORG=PO and RECFM=U do not necessarily indicate a loadlib/polib. Therefore, the system can't arbitrarily assume BLKSIZE=32760. Has a suggestion been made to IBM to ameliorate this? How much worse, by what metric, is SDB's default (half track?) than 32760? Non-sequitur. SDB does not choose 1/2 track blocking when RECFM=U. My suggestion is to enhance SMS data classes to provide block size information. If absent, SDB will be used. That way a user/task/program can specify something like DATACLAS=LOADLIB to assign shop standard attributes for load and program object libraries -- including block size -- when they are created. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where did the term clip come from?
IIRC, the DIRF bit was implemented because of a problem in DADSM causing overlapping tracks on 2314 volumes in a shared DASD environment with 2 controllers (2314 2844). I was playing systems programmer at NIH in the late '60s thru the early '80s and we ran into the problem with horrific results. We were fortunate to have, as a result of a SEV-1 incident, some of the best DASDM folks on-site for several weeks trying to reproduce/trap the situation. These folks implemented the first version of DIRF, to serialize updating of the F5 stuff. I believe this was known as the ping-pong problem. I have remained close friends with two of these folks (long since retired from IBM). On 5/11/07, Mark H. Young [EMAIL PROTECTED] wrote: On Thu, 10 May 2007 10:42:18 -0400, John Eells [EMAIL PROTECTED] wrote: The IBM Jargon Dictionary confirms my recollection that it came from Change Label Information Program. http://www.comlay.net/ibmjarg.pdf -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] That IBM *jargon dictionary* is GREAT. But it lacks one important def from *back-in-the-day* DIRF bit = DASDM Interrupt Recording Facility bit Anyone remember that one?! Looks like a revision is in order?! ...mhyI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- No trees were killed in the sending of this message. However - a large number of electrons were terribly inconvenienced. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
Rick Fochtman said: Ken, the physical BLKSIZE of the directory is 255, plus a 8-byte physical key. I think you'll find that's 256. From: Rick Fochtman [EMAIL PROTECTED] Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Top 10 software install gripes Date: Sat, 12 May 2007 10:06:29 -0500 -snip- The PDS directory records are a fixed size, LRECL=255, I believe. My reason to allocate a PDS filling a track, or multiples, with the directory comes from thinking half-track blocking is efficient for reads and if I use one half, or full track directory then I am doing the least amount of I/O as possible. Reality may be different. The optimum number of PDS entries to allocate depends on the type of PDS, loadlib or other. For other, are statistics kept or not. How many of us ignore taking the time to plan the need and just allocate with a larger number than we need? I chose to allocate larger based on number of tracks. I no longer use a PDS for non-loadlib datasets. --unsnip--- Ken, the physical BLKSIZE of the directory is 255, plus a 8-byte physical key. You can set a PDS BLKSIZE to any value you like, but it will have NO effect on the directory characteristics. On a 3390, that means that you will always get 45 directory blocks to a track, or 44 blocks plus the EOF mark. -snip-- I believe in my testing I found 44 directory blocks will fit on one track with the end-of-file block following it on the same track. There will be room for the starting text of one member on the same track. 45 directory blocks will fit on one track with the end-of-file block spilling over to the second track. For this reason I had been using multiples of 44 directory blocks when I used a PDS. When you use ISPF to access a member list, you must read all of the necessary directory entries to populate the list. 44 means reading two half track blocks, while 45 means reading three to reach the end-of-file block. That was from m belief the directory entries fit in the half-track blksize I used to allocate the PDS. ---unsnip You still do the same number, 45 reads (assuming no CCW chaining) for each track of directory space. See above. snip-- Nowadays I would still consider using 44 as my smallest, and if I need more I would use multiples of 45 plus 44 for the last. unsnip I do the same, partly because I'm just an old-fashioned cuss. -snip--- Conclusion - vendors should allocate a directory to fit what they deliver plus maybe 10% for future growth. -unsnip--- Make that 20% and round to a full track and I'll go along with you. There may be a few poor slobs stuck on physical 3390's yet and in that case, there are RPS considerations. _ More photos, more messages, more storageget 2GB with Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-usocid=TXT_TAGHM_migration_HM_mini_2G_0507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
Pinnacle wrote: [...] Regardless of how many you specified, the first member starts on/in the next track after the directory. That's not correct. Never was. You can prove it easily enough. Create a PDS with one track, no secondary. If what you say was true, you'd never be able to create a member. Tom, I tested this in the old days of SLED DASD, and the directory was a keyed track and you COULD NOT store a member in the directory track. It always took 2 tracks minimum for a PDS (of course, this has not been true for about 15 years). I believe there is no difference between SLED and RAID in this case. From MVS point of view nothing was changed. Key, directory, members - those are only bytes on the track. Emulated or real. It would be more likely that OS changed data format here, however still unlikely... BTW: I asked why 45 directory blocks are ROT. I've seen answers it should be 44, 45, or 46, but still haven't seen an explanation. BTW2: (assuming the answer is related to space utilization) Isn't it funny today to worry about possibly lost fragment of track ? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
- Original Message - From: Greg Price [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Saturday, May 12, 2007 11:19 AM Subject: Re: Top 10 software install gripes Pinnacle wrote: Tom, I tested this in the old days of SLED DASD, and the directory was a keyed track and you COULD NOT store a member in the directory track. It always took 2 tracks minimum for a PDS (of course, this has not been true for about 15 years). Regards, Tom Conley -- Tom, I agree with (the other) Tom - I don't think this has ever been true. I just tried making a member in a new single track PDS under MVS 3.8 and it worked without a problem - and that software is more than 20 years old. There would be an increased statistical likelihood that the first member would start at the start of a track because it is possible that there is not enough room after the directory to fit a data block on the last directory track. But there seems to be nothing to prevent it in general - which is good because that matches my recollection from those times. BTW, on the cylinders vs tracks allocation point, I think that if a data set is allocated in cylinders then the access method can use the MT bit (the Multi Track bit is the x'80' bit in the CCW opcode) when building search channel programs, thus reducing CPU overhead and the chance of RPS miss. For example, for search-key-equal-or-high, a x'69' CCW can search a track, while a x'E9' CCW can search till the end of the cylinder. Note that the end of extent being on a cylinder boundary is important, not that the extent starts on a cylinder boundary. At least that what I've heard. Mind you, I think this is all superceded by ECKD now-a-days. Greg, All I can tell you is that I tested this on an old 3380 circa 1994 with MVS 4.2(? so long ago not sure anymore). Nothing other than the directory was stored on the first track. I then tested on a RAMAC2, but no problem creating a 1-track PDS and storing a member. If I'm wrong, I'm wrong, but that's what I remember. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Top 10 software install gripes
thus reducing CPU overhead and the chance of RPS miss. That is so five minutes ago. 1. ECKD got rid of most overhead 2. RAID took care of the rest. 3. Talk about cache. Allocate with whatever units you wish. Performance issues regarding cylinder, block, track allocation are long gone. Can you say: Define Extent? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Load Library BLKSIZE=32760 (Was: Top 10 software install gripes)
On Sat, 12 May 2007 08:36:03 -0700, Edward Jaffe wrote: Paul Gilmartin wrote: Does SDB make an adverse selection for loadlibs? The issue is not block size selection but rather deterministic recognition of the library as being a loadlib. Though common, DSORG=PO and RECFM=U do not necessarily indicate a loadlib/polib. Therefore, the system can't arbitrarily assume BLKSIZE=32760. The system must arbitrarily assume something. It should optimize for the preponderance of uses, loadlibs; set BLKSIZE to 32760 and let the minority applications supply an explicit different value. Has a suggestion been made to IBM to ameliorate this? How much worse, by what metric, is SDB's default (half track?) than 32760? Non-sequitur. SDB does not choose 1/2 track blocking when RECFM=U. If neither 32760 nor 1/2 track, then what? OK. I'll try it: //STEP EXEC PGM=IEWL //SYSPRINT DD SYSOUT=(,) //SYSLMOD DD DISP=(,CATLG),SPACE=(1000,(1,,3)),UNIT=SYSALLDA, // DSORG=PO,BLKSIZE=0, // DSN=SYSUID..TESTWTF.LINKLIB //SYSLIBDD DISP=SHR,DSN=SYS1.LINKLIB //SYSLINDD * INCLUDE SYSLIB(IEFBR14) NAMEWHATEVER ... and I see: ISRUAIPO Data Set Information Data Set Name . . . : user.TESTWTF.LINKLIB General Data Current Allocation Volume serial . . . : TSO017 Allocated blocks . : 1 Device type . . . . : 3390Allocated extents . : 1 Organization . . . : PO Maximum dir. blocks : 3 Record format . . . : U Record length . . . : 0 Block size . . . . : 32760 Current Utilization 1st extent blocks . : 1 Used blocks . . . . : 1 Secondary blocks . : 0 Used extents . . . : 1 Used dir. blocks . : 1 Creation date . . . : 2007/05/12 Number of members . : 1 Referenced date . . : 2007/05/12 Expiration date . . : ***None*** Someone supplied 32760. But I have no assurance that it wasn't an installation exit, have I? WOMBAT! I'll side with R.S. and Ted: this is much like discussing whether XR or SR is better. (Please don't take that up here; it belongs to ASSEMBLER_LIST). BLKSIZE=0 seems good enough for me. (BTW, it fit in one track.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Multiple Clusters (was: Top 10 software install gripes)
On Fri, 11 May 2007 11:21:13 -0500, Thomas Conley wrote: #8 - Stop telling me to jam all my SMP/E zones into one GLOBAL, at least give me the JCL to create multiple VSAM clusters for the TARGET and DLIB zones. OK. Educate me: Why does this matter; what's the motivation? Is there perhaps similarly strong opinion for the opposite convention? Do you wish to be able to combine products from multiple ISVs under a single GLOBAL? Do you desire, under a single GLOBAL, multiple TARGET and DLIB pairs, e.g. for test configurations? Do you want each TARGET/DLIB pair in a single cluster or in two clusters? Do you want the facility to create additional TARGET/DLIB pairs under an existing GLOBAL? Etc. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Load Library BLKSIZE=32760 (Was: Top 10 software install gripes)
On Sat, 12 May 2007 08:36:03 -0700, Edward Jaffe wrote: Non-sequitur. SDB does not choose 1/2 track blocking when RECFM=U. OK. I RTFM. Using Data Sets confirms that SDB does not operate on RECFM=U. But why not? However: Title: z/OS V1R7.0 MVS Program Management: User's Guide and Reference Document Number: SA22-7643-04 3.1.3.1 Binder DD statements * ... Procedures used by the binder to assign block size to a load module are: 1. If the data set is new: a. When the DCBS option is not specified # When the data set is created without a block size, the block size is the maximum supported by the access method for that device type. I.e. 32760. So I can equally well use BLKSIZE=0 for load module libraries as for other data sets. It matters little to me whether BLKSIZE gets set by SDB or by the binder. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Multiple Clusters (was: Top 10 software install gripes)
Paul Gilmartin wrote: On Fri, 11 May 2007 11:21:13 -0500, Thomas Conley wrote: #8 - Stop telling me to jam all my SMP/E zones into one GLOBAL, at least give me the JCL to create multiple VSAM clusters for the TARGET and DLIB zones. OK. Educate me: Why does this matter; what's the motivation? Is there perhaps similarly strong opinion for the opposite convention? Do you wish to be able to combine products from multiple ISVs under a single GLOBAL? Do you desire, under a single GLOBAL, multiple TARGET and DLIB pairs, e.g. for test configurations? Do you want each TARGET/DLIB pair in a single cluster or in two clusters? Do you want the facility to create additional TARGET/DLIB pairs under an existing GLOBAL? Gil I wouldn't dare to educate you, however I think the requirement could be related to the size of CSI file. For large SMP/E db it is good idea to split CSI into many files, especially when considering many zones. IMVHO (very humble) it's not a problem unless we're talking about z/OS as a product. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2007 r. kapitał zakładowy BRE Banku SA (w całości opłacony) wynosi 118.064.140 zł. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwał XVI WZ z dnia 21.05.2003 r., kapitał zakładowy BRE Banku SA może ulec podwyższeniu do kwoty 118.760.528 zł. Akcje w podwyższonym kapitale zakładowym będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OEM software electronic download report card
Mark Zelden wrote: [...] As far as more options... I know you use Sun/STK like we do... I think I heard VTCS 6.2 will have some help there. VTCS 6.2 supports 4GB VTVs. Before compression. AFAIK, new IBM VTS supports even 12GB VTVs. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BLKSIZE parm of DCB macro(QSAM locate mode)
Hi Howard, On Fri, 4 May 2007 12:05:45 -0600, Howard Brazee [EMAIL PROTECTED] wrote: I would think that most reasons for blocking at particular rates would be less important now with such cheap memory. I'm curious whether the tape drives nowadays have sufficient buffering, not to mention how the virtual swapping works to make our old calculations irrelevant. Here's some info about current tape drive buffer sizes. From the SUN (STK) T1 data sheet: Speed-matching functionality supports high throughput rates and reduces media wear. The T1 design includes two motor speeds and a 256- megabyte buffer that allows the drive to continuously and automatically adjust the buffer to match the speed of the data feed from the server. Data transfer rate, native (uncompressed) 120 MB/sec Data transfer rate, (compressed, maximum) 360 MB/sec (future 4 Gb) From IBM TS1120 (3592-E05) announcement: Large internal data buffer: ...512 MB internal data buffer. ...Along with enabling higher performance characteristics, the data buffer is designed to use support [sic] read ahead of approximately 500 MB of compressed data from tape and provide high performance random skip forward sequential (short hop) locates common in database search and tape software recycle operations. native data rate...up to 100 MB/sec Note: The actual throughput a customer may achieve is a function of many components, such as system processor, disk data rate, data block size, data compressibility, I/O attachments, SAN, and the system or application software used. Although the drive is capable of a 100 MB/sec native data rate, other components may limit the actual effective data rate. Regards, Mike Baldwin Cartagena Software Ltd. www.cartagena.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
MIDAW and EMC
Hi, for some reason nobody turn on this flag in our EMC box (DMX3000 and DMX2000). After a long discussion EMC support turn on this flag and now the decive shows MIDAW enabled. We running z/OS R7. Any experience in this area? Performance for DB2 or others? Roland Schiradin ALTE LEIPZIGER Lebensversicherung auf Gegenseitigkeit IT Betrieb - DB/DC Tel. (06171) 66-4095, Fax (06171) 66-7500-4095 mailto:[EMAIL PROTECTED] http://www.Alte-Leipziger.de -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OEM software electronic download report card
On 12 May 2007 13:44:55 -0700, in bit.listserv.ibm-main you wrote: Mark Zelden wrote: [...] As far as more options... I know you use Sun/STK like we do... I think I heard VTCS 6.2 will have some help there. VTCS 6.2 supports 4GB VTVs. Before compression. AFAIK, new IBM VTS supports even 12GB VTVs. The 3 year old computer this is being typed on has 80 GB. My wife's one year old laptop, has 100 GB and the small external drive on top of the desktop has 320 GB. Should I be impressed with a 12 GB VTV that would require multiple volumes to back up any of the aforementioned drives if full? Let's see, 25+ volumes for the external drive that is not much bigger than the 3480 cartridge I have somewhere in my room. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
