Re: Delete all members of a PDS that is allocated
In 4c2d598f.3050...@valley.net, on 07/01/2010 at 11:14 PM, Gerhard Postpischil gerh...@valley.net said: Rather than argue, I decided to run a quick test. Right answer to wrong question. Did you run a test, on a current system, of an OPEN/STOW/CLOSE while another job still had the PDS OPEN? AFAIK you get an ABEND due to ENQ failure if your try it; I don't recall what release that came in. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SV: Delete all members of a PDS that is allocated
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin Skickat: den 1 juli 2010 21:59 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Delete all members of a PDS that is allocated On Thu, 1 Jul 2010 19:38:40 +0200, Thomas Berg wrote: -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin Skickat: den 1 juli 2010 18:26 On Wed, 30 Jun 2010 17:51:40 +0200, Thomas Berg wrote: When I have needed to compress a PDS that was in frequent/continuous use, e g a target load library in test env, I use a command/rexx that submits a job which begins with submitting another job that has the pds allocated with DISP=OLD. This as a way to shut the door behind. Then it waits typically 30 seconds where after it starts the compress (w DISP=SHR). And in the last step cancels the shut the door job and ends. Something along this could be used as a way to minimize problems when deleting members. I have never had any problems with this approach. You're lucky. It will also shut the door on jobs that have the data set open, and have done BLDLs, and may subsequently use TTRs that point to trash. How ? The shut the door job is *waiting* for EXCL ENQ (OLD). As I read it, shut the door never completes its wait. So you don't know how many other jobs may have previously allocated the data set SHR, opened it, done BLDLs, and not yet closed it. They are holding TTRs which will point to unpredictable content once you compress (w DISP=SHR). (The STD job is cancelled by the compress job when it's finished.) Yes, a couple of other jobs has opened the pds and if they haven't finished their update it may theoretically cause local corruption in the pds. But I have never experienced that, maybe because of the 30 seconds wait I do before beginning the compress. And of course, this is in a test environment. BTW, the STD is not a problem in this case, the only potential problem is the compress (job). And if You are worried You can always wait until all jobs that may have opened the pds are finished before You start the compress. Then there is no problem anymore regarding the risk ds corruption. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: Delete all members of a PDS that is allocated
On Fri, 2 Jul 2010 13:26:41 +0200, Thomas Berg wrote: How ? The shut the door job is *waiting* for EXCL ENQ (OLD). As I read it, shut the door never completes its wait. So you don't know how many other jobs may have previously allocated the data set SHR, opened it, done BLDLs, and not yet closed it. They are holding TTRs which will point to unpredictable content once you compress (w DISP=SHR). (The STD job is cancelled by the compress job when it's finished.) Yes, a couple of other jobs has opened the pds and if they haven't finished their update it may theoretically cause local corruption in the pds. But I have never experienced that, maybe because of the 30 seconds wait I do before beginning the compress. I was concerned less with directory corruption than with the harmful effect on other DISP=SHR jobs already running. And of course, this is in a test environment. Ah! So you don't care if a few jobs fail. I, also, often operate in that mode. BTW, the STD is not a problem in this case, the only potential problem is the compress (job). And if You are worried You can always wait until all jobs that may have opened the pds are finished before You start the compress. Then there is no problem anymore regarding the risk ds corruption. IOW, simply submit a compress job with DISP=OLD. I sometimes do that, too. Then the operators telephone me to complain about the flood of MIM ENQ messages on the console, and to relay complaints from other testers attempting to allocate the data set. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SV: SV: Delete all members of a PDS that is allocated
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin Skickat: den 2 juli 2010 15:40 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: Delete all members of a PDS that is allocated On Fri, 2 Jul 2010 13:26:41 +0200, Thomas Berg wrote: How ? The shut the door job is *waiting* for EXCL ENQ (OLD). As I read it, shut the door never completes its wait. So you don't know how many other jobs may have previously allocated the data set SHR, opened it, done BLDLs, and not yet closed it. They are holding TTRs which will point to unpredictable content once you compress (w DISP=SHR). (The STD job is cancelled by the compress job when it's finished.) Yes, a couple of other jobs has opened the pds and if they haven't finished their update it may theoretically cause local corruption in the pds. But I have never experienced that, maybe because of the 30 seconds wait I do before beginning the compress. I was concerned less with directory corruption than with the harmful effect on other DISP=SHR jobs already running. And of course, this is in a test environment. Ah! So you don't care if a few jobs fail. I, also, often operate in that mode. Well, I do care, but it's not a very big problem if it happens and, as mentioned, in practice it very seldom do. BTW, the STD is not a problem in this case, the only potential problem is the compress (job). And if You are worried You can always wait until all jobs that may have opened the pds are finished before You start the compress. Then there is no problem anymore regarding the risk ds corruption. IOW, simply submit a compress job with DISP=OLD. I sometimes do that, too. Then the operators telephone me to complain about the flood of MIM ENQ messages on the console, and to relay complaints from other testers attempting to allocate the data set. The problem with the DISP=OLD compress job is that some jobs that enques the pds could be running VERY long time after the access to the pds due to unrelated (but valid/correct) causes. (And with DISP=OLD You are placed behind all other jobs that are *waiting* for the enq.) Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: Delete all members of a PDS that is allocated
On Wed, 30 Jun 2010 17:51:40 +0200, Thomas Berg wrote: When I have needed to compress a PDS that was in frequent/continuous use, e g a target load library in test env, I use a command/rexx that submits a job which begins with submitting another job that has the pds allocated with DISP=OLD. This as a way to shut the door behind. Then it waits typically 30 seconds where after it starts the compress (w DISP=SHR). And in the last step cancels the shut the door job and ends. Something along this could be used as a way to minimize problems when deleting members. I have never had any problems with this approach. You're lucky. It will also shut the door on jobs that have the data set open, and have done BLDLs, and may subsequently use TTRs that point to trash. PDSEs avoid this problem and introduce others, including a notorious lack of robustness. While UNIX directories can contain program objects, they can't (as yet) be used in TASKLIB concatenations. For other content, they avoid most serialization problems while providing LUW isolation. I don't know how UNIX directories compare to PDSE in robustness. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SV: SV: Delete all members of a PDS that is allocated
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin Skickat: den 1 juli 2010 18:26 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: Delete all members of a PDS that is allocated On Wed, 30 Jun 2010 17:51:40 +0200, Thomas Berg wrote: When I have needed to compress a PDS that was in frequent/continuous use, e g a target load library in test env, I use a command/rexx that submits a job which begins with submitting another job that has the pds allocated with DISP=OLD. This as a way to shut the door behind. Then it waits typically 30 seconds where after it starts the compress (w DISP=SHR). And in the last step cancels the shut the door job and ends. Something along this could be used as a way to minimize problems when deleting members. I have never had any problems with this approach. You're lucky. It will also shut the door on jobs that have the data set open, and have done BLDLs, and may subsequently use TTRs that point to trash. How ? The shut the door job is *waiting* for EXCL ENQ (OLD). Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On Thu, 1 Jul 2010 19:38:40 +0200, Thomas Berg wrote: -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin Skickat: den 1 juli 2010 18:26 On Wed, 30 Jun 2010 17:51:40 +0200, Thomas Berg wrote: When I have needed to compress a PDS that was in frequent/continuous use, e g a target load library in test env, I use a command/rexx that submits a job which begins with submitting another job that has the pds allocated with DISP=OLD. This as a way to shut the door behind. Then it waits typically 30 seconds where after it starts the compress (w DISP=SHR). And in the last step cancels the shut the door job and ends. Something along this could be used as a way to minimize problems when deleting members. I have never had any problems with this approach. You're lucky. It will also shut the door on jobs that have the data set open, and have done BLDLs, and may subsequently use TTRs that point to trash. How ? The shut the door job is *waiting* for EXCL ENQ (OLD). As I read it, shut the door never completes its wait. So you don't know how many other jobs may have previously allocated the data set SHR, opened it, done BLDLs, and not yet closed it. They are holding TTRs which will point to unpredictable content once you compress (w DISP=SHR). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On 6/30/2010 9:16 PM, Shmuel Metz (Seymour J.) wrote: And it would be interesting to determine whether the common practice of updating a PDS with a primary ENQ of SHR has led IBM to add format 1 updates to the STOW logic. I doubt it; they don't permit concurrent OPEN for update. Rather than argue, I decided to run a quick test. I allocated a PDS with one directory block, linked one member, inspected the DSCB, ran a second link step with two members, but having the last include a member from a (forced) unready pack, allowing the DSCB to be inspected after the link for member 2, and before member 3. After the first link, the DS1NOBDB field is 49, and DS1LSTAR is 0A. After the second link, the format 1 has not changed; after the third link, it shows DS1LSTAR as 1A and DS1NOBDB as 121. DISP was SHR for all libraries. So STOW may set information in storage, but only a CLOSE (or TCLOSE) will update the DSCB. So long running tasks with a shared PDS would be advised to close it before issuing the secondary (link or ISPF) enqueue, and reopen to update. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
In 45d79eacefba9b428e3d400e924d36b903a24...@iwdubcormsg007.sci.local, on 06/27/2010 at 03:00 PM, Thompson, Steve steve_thomp...@stercomm.com said: How difficult is it to get the number of directory blocks from a PDS in a _ program (where the blank can be filled in with COBOL, PL/1, REXX, etc., but not HLASM/ASM) and then open the data set with RECFM=U and then write an initial directory block followed by n empty blocks? Very; you have to write the keys without update the key length in the DSCB1. There's also the issue of PDSE. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
In 4c27c8dd.7010...@valley.net, on 06/27/2010 at 05:55 PM, Gerhard Postpischil gerh...@valley.net said: The intrinsic problem is that to do it correctly (for a PDS) the program needs to be authorized, as DS1NOBDB needs to be reset. Doesn't CLOSE update it from the DCB? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Is there any downside to just deleting the PDS and recreating it? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Yes. You have to wait until no one else has it allocated. Date: Wed, 30 Jun 2010 08:40:10 -0600 From: howard.bra...@cusys.edu Subject: Re: Delete all members of a PDS that is allocated To: IBM-MAIN@bama.ua.edu Is there any downside to just deleting the PDS and recreating it? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of J R Sent: Wednesday, June 30, 2010 9:44 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated Yes. You have to wait until no one else has it allocated. Is HLASM so out of the question? STOW DCB,,I is made for this. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
The OP said that job scheduler product has it allocated and that assembler may not be used. Date: Wed, 30 Jun 2010 09:47:20 -0500 From: john.mck...@healthmarkets.com Subject: Re: Delete all members of a PDS that is allocated To: IBM-MAIN@bama.ua.edu -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of J R Sent: Wednesday, June 30, 2010 9:44 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated Yes. You have to wait until no one else has it allocated. Is HLASM so out of the question? STOW DCB,,I is made for this. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of J R Sent: Wednesday, June 30, 2010 10:02 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated The OP said that job scheduler product has it allocated and that assembler may not be used. OK. Sounds like a foolish restriction to me, but the OP knows his requirements better than I ever could. The following REXX program will do it. It stinks, but it works. /* REXX */ ALLOC DDN(SYSIN) SPACE(10 10) TRACKS NEW DELETE REUSE , RECFM(F B) LRECL(80) BLKSIZE(3120) DSORG(PS) IF RC 0 THEN EXIT 8 X = LISTDSI(KILLPDS FILE) IF X 4 THEN EXIT 8 IF PO LEFT(SYSDSORG,2) THEN DO SAY SYSDSNAME SYSDSORG SYSVOLUME EXIT 8 END SAY SYSDSNAME SYSDSORG SYSVOLUME DUMMY = OUTTRAP(DATA.,*) LISTDS 'SYSDSNAME' MEMBERS DUMMY = OUTTRAP(OFF) DO I = 7 TO DATA.0 MEMBER = SPACE(WORD(DATA.I,1),0) LINE = SCRATCH DSNAME=SYSDSNAME, LINE = LEFT(LINE,71)X QUEUE LINE LINE =VOL=SYSDA=SYSVOLUME,MEMBER=MEMBER QUEUE LINE EXECIO 2 DISKW SYSIN IF RC 0 THEN DO SAY ERROR WRITING CONTROL RECORD. ABORTING. EXIT 16 END END EXECIO 0 DISKW SYSIN(FINIS ADDRESS ATTACH IEHPROGM EXIT RC //STEP010 EXEC PGM=IKJEFT01, // REGION=4096K, // DYNAMNBR=40 //SYSTSPRT DD SYSOUT=* //SYSEXEC DD DSN=my.REXX.EXEC, // DISP=SHR //SYSTSIN DD * EXECUTIL SEARCHDD(YES) %KILLPDS /* //SYSPRINT DD SYSOUT=* //KILLPDS DD DSN=some.pds, // DISP=SHR -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SV: Delete all members of a PDS that is allocated
When I have needed to compress a PDS that was in frequent/continuous use, e g a target load library in test env, I use a command/rexx that submits a job which begins with submitting another job that has the pds allocated with DISP=OLD. This as a way to shut the door behind. Then it waits typically 30 seconds where after it starts the compress (w DISP=SHR). And in the last step cancels the shut the door job and ends. Something along this could be used as a way to minimize problems when deleting members. I have never had any problems with this approach. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För J R Skickat: den 30 juni 2010 17:02 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Delete all members of a PDS that is allocated The OP said that job scheduler product has it allocated and that assembler may not be used. Date: Wed, 30 Jun 2010 09:47:20 -0500 From: john.mck...@healthmarkets.com Subject: Re: Delete all members of a PDS that is allocated To: IBM-MAIN@bama.ua.edu -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of J R Sent: Wednesday, June 30, 2010 9:44 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated Yes. You have to wait until no one else has it allocated. Is HLASM so out of the question? STOW DCB,,I is made for this. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON :WL:en-US:WM_HMP:042010_2 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On 6/30/2010 6:34 AM, Shmuel Metz (Seymour J.) wrote: The intrinsic problem is that to do it correctly (for a PDS) the program needs to be authorized, as DS1NOBDB needs to be reset. Doesn't CLOSE update it from the DCB? The approaches posted previously all treated the directory as sequential. AFAIK, the DS1NOBDB field is not altered unless a STOW is issued. And it would be interesting to determine whether the common practice of updating a PDS with a primary ENQ of SHR has led IBM to add format 1 updates to the STOW logic. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
In 4c2b89f9.5050...@valley.net, on 06/30/2010 at 02:16 PM, Gerhard Postpischil gerh...@valley.net said: The approaches posted previously all treated the directory as sequential. AFAIK, the DS1NOBDB field is not altered unless a STOW is issued. Does STOW set the flag in the DCB or in the DEB? And it would be interesting to determine whether the common practice of updating a PDS with a primary ENQ of SHR has led IBM to add format 1 updates to the STOW logic. I doubt it; they don't permit concurrent OPEN for update. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler programs was Re: Delete all members of a PDS that is allocated
On Mon, 28 Jun 2010 22:51:59 -0500, Joel C. Ewing wrote: Why does such a language need to be provided by IBM? Can a third-party vendor provide it? - Dave Rivers - It would be unreasonable for IBM to require a third-party product to customize z/OS, or to expect IBM to help diagnose strange z/OS failures caused by bad exits generated by some other vendor's product. z/OS customization must be possible with what is included with z/OS. So until IBM supplies alternative non-Assembler facilities for all exits and customization, some Assembler expertise would seem to be a requirement. I'll disagree with that. It's closing the OS in an undesirable way. If the exit meets the interface specifications, I'd expect IBM to provide help with diagnosis under terms of the service contract regardless of the source language, using dumps, GTF traces, whatever is available for debugging assembler programs. And if the translator cascades through HLASM, as Dave Rivers's product does, there is assembler source available for debugging. There's a minor argument here for being able to use HLASM, not only the ISV assembler, when supplying supporting information. I once reported a bug in the firmware of a PostScript printer: What application created your PostScript code? Vi. I had typed it in by hand. The bug didn't get fixed; it was called WAD. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Thompson, Steve Sent: Sunday, June 27, 2010 7:26 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Sunday, June 27, 2010 5:26 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated SNIPPAGE That might work, as long as you have a mechanism for manipulating the keys in the directory also. The last used block in the directory has a key of X''. snip Yeah, there is that issue. I was trying to think of a way around STOW. The xSAM writes of directory blocks would work, if you could get the KEY of CKD involved. However, if you did this and then immediately followed it by IEBCOPY for compress, I wonder if that would solve all the problems. I guess I can find out sometime tomorrow, when I have the time, to try this with IDCAMS with a REPRO of a bunch of pseudo directory blocks... SNIP Well, just using IDCAMS to repro in the first directory block as the initial empty block and then follow this by a repro of a place-holder member in the source PDS I was practicing with -- SB14-10. So much for this idea. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler programs was Re: Delete all members of a PDS that is allocated
On 06/29/2010 10:08 AM, George Orwell wrote: Our application programmers are not that familiar with z-architecture, much less Assembly Language; but those of us in mainframe Technical Support certainly are. Judging from the questions asked on this list, the above statement is certainly not true. While sysprogs may be familiar at a deep level on many aspects of z/OS, especially tuning and customization, understanding assembler and systems software (and how to write it) are certainly not among them. Not to say we haven't had one or two posters who *do* understand those things, but the vast majority of sysprogs and the vast majority of sysprogs *on this list* demonstrably do not. ... I obviously failed to convey the intended meaning. In the context of Our application programmers I intended us in mainframe Technical Support to be similarly specific to our installation, not a general statement about sysprogs everywhere. I believe all of our mainframe sysprogs at Data-Tronics have a general knowledge of z-architecture and could make sense out of Assembler code, and at least half of those deal with Assembler code often enough to be fairly competent. Thirty years ago there was significant use here of Assembler in applications areas, but there is only a little of that left and only in some very narrow areas, so I would be surprised to find as many as 5% of Applications Support able to deal with Assembler; and I don't have a problem with that as long as we maintain a cadre able to deal with any issues. DTC maintains a Training Department and makes a significant investment in initial training and continuing education using materials developed locally, with classes taught by Training personnel, Technical Services personnel, and some of the more experienced applications programmers. New recruits spend a significant percentage of their first 6 months in classes and working closely with a trainer from their assigned department, who serves as a mentor. Over the decades we have consistently found through contacts at conferences that our installation tends to support higher CICS transaction rates and higher DB2 query rates than many other sites while using less hardware, which gives us a distinct competitive advantage. I attribute that to a large extent to continual performance monitoring and tuning efforts spearheaded by Technical Services over the years, which in a large part have depended on Technical Services personnel understanding the nature of the hardware platform on which we run - and some understanding of machine language and Assembler is part of that picture. -- Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org Sr. Technical Admin., Mainframe Systems, Data-Tronics Corp. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler programs was Re: Delete all members of a PDS that is allocated
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. joa...@swbell.net (John McKown) writes: I think that there is a difference between having a normal (ain't no such beastie) application programmer and an old style sysprog. I think sysprogs need HLASM. I am not convinced that it is necessary for applications people to really know HLASM or even z architecture. Today's COBOL is much better than in the past. I can see needing the speed of assembler in embedded type applications. But that is not z/OS's forte. Commercial programming and COBOL go together like pancakes and maple syrup. But other languages are coming up for the webified world. I like PHP. PHP using DB2 with perhaps some COBOL stored programs is, IMO, likely one of the best ways to talk via the web. But others may reasonable disagree. there was the period in the 90s ... when various parts of the financial industry spent billions on re-engineering for straight through processing as part of eliminating the overnight batch window. there were spectacular failures ... tainting re-engineering efforts for years to come. they tended to use new technologies that were known to have some increased overhead (compared to the batch cobol) ... but thot it could be compensated for by using parallelism with large numbers of killer micros. the problem was that there was lots of hand-waving about the increased overhead ... but not actually quantified. when the efforts started to be deployed and the factor turned out to be one hundred times ... the efforts went down in flames. the factor of one hundred ... totally swamping any offsetting benefits of using large number of killer micros. recently there have been some new re-engineering with approaches that use high-level specification that is translated into lots of SQL. rather than relying on large number of application programmers, each trying to invent their own optimized parallelism methodology ... it relies on the significant parallelism optimization investments that have gone into major RDBMS. Part of this plays out in how much investment different vendors are pouring into RDBMS parallelism ... aka recent item Larry Ellison's IBM-Slayer Is Oracle Exadata Machine http://www.informationweek.com/news/global-cio/interviews/showArticle.jhtml?articleID=225701468 and from last year DB2 announces technology that trumps Oracle RAC and Exadata http://freedb2.com/2009/10/10/for-databases-size-does-matter/ IBM pureScale Technology Redefines Transaction Processing Economics. New DB2 Feature Sets the Bar for System Performance on More than 100 IBM Power Systems http://www-03.ibm.com/press/us/en/pressrelease/28593.wss mentioned in these posts: http://www.garlic.com/~lynn/2009p.html#43 From The Annals of Release No Software Before Its Time http://www.garlic.com/~lynn/2009p.html#46 From The Annals of Release No Software Before Its Time ... and past posts mentioning original relational/SQL System/R implementation http://www.garlic.com/~lynn/submain.html#systemr other posts in other parts of this thread: http://www.garlic.com/~lynn/2010j.html#81 Percentage of code executed that is user written was Re: Delete all members of a PDS that is allocated http://www.garlic.com/~lynn/2010j.html#82 Percentage of code executed that is user written was Re: Delete all members of a PDS that is allocated http://www.garlic.com/~lynn/2010j.html#83 Percentage of code executed that is user written was Re: De -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On Sun, 27 Jun 2010 15:00:14 -0400, Thompson, Steve steve_thomp...@stercomm.com wrote: I just have to ask this one question. How difficult is it to get the number of directory blocks from a PDS in a _ program (where the blank can be filled in with COBOL, PL/1, REXX, etc., but not HLASM/ASM) and then open the data set with RECFM=U and then write an initial directory block followed by n empty blocks? With that question asked, if it is not so difficult, wouldn't that allow you to clear a PDS right rapidly? The only access you would have to have for the data set is update, because you aren't deleting it or [re-]allocating it. Even easier than you wrote... /* rexx - zero a PDS Directory */ ARG dsn ALLOC F(PDSDIR) DA(dsn) SHR REUSE RECFM(F), /* pds directory */ DSORG(PS) LRECL(256) BLKSIZE(256) EXECIO 1 DISKRU PDSDIR (STEM DIR./* read pds directory */ /* for update */ DIR.1 = '000E'x/* End of Directory */ EXECIO 1 DISKW PDSDIR (STEM DIR. FINIS /* Rewrite Directory */ FREE F(PDSDIR) Exit Obviously it won't work with PDSE. -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On Mon, 28 Jun 2010 07:43:26 -0500 Mark Zelden mzel...@flash.net wrote: :Even easier than you wrote... :/* rexx - zero a PDS Directory */ :ARG dsn :ALLOC F(PDSDIR) DA(dsn) SHR REUSE RECFM(F), /* pds directory */ : DSORG(PS) LRECL(256) BLKSIZE(256) :EXECIO 1 DISKRU PDSDIR (STEM DIR./* read pds directory */ : /* for update */ :DIR.1 = '000E'x/* End of Directory */ :EXECIO 1 DISKW PDSDIR (STEM DIR. FINIS /* Rewrite Directory */ :FREE F(PDSDIR) :Exit :Obviously it won't work with PDSE. That does not change the key. I wonder what would happen if member GHJK was added and the keys shows that it should be inserted in block #3. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler programs was Re: Delete all members of a PDS that is allocated
Clark Morris wrote: On 27 Jun 2010 07:30:35 -0700, in bit.listserv.ibm-main you wrote: Until IBM provides a language or variant such as a systems flavor of C/C++ that has access to all of the facilities (including the peculiar linking conventions for some JES exits, any management that does not keep access to assembler expertise is playing with fire. ... Clark Morris Why does such a language need to be provided by IBM? Can a third-party vendor provide it? - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler programs was Re: Delete all members of a PDS that is allocated
Feel free to do an advert. Your stuff is good. On Mon, 28 Jun 2010 09:32:17 -0400 Thomas David Rivers riv...@dignus.com wrote: :Clark Morris wrote: : On 27 Jun 2010 07:30:35 -0700, in bit.listserv.ibm-main you wrote: : : Until IBM provides a language or variant such as a systems flavor of : C/C++ that has access to all of the facilities (including the peculiar : linking conventions for some JES exits, any management that does not : keep access to assembler expertise is playing with fire. ... : : Clark Morris : : :Why does such a language need to be provided by IBM? :Can a third-party vendor provide it? : : - Dave Rivers - -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On 25 Jun 2010 15:26:46 -0700, rfocht...@ync.net (Rick Fochtman) wrote: Even BAL programmers can produce lousy code; it's just sometimes harder to spot. :-) Character string manipulations, like scanning control statements, can be inordinately complex in BAL if you're not really careful in the design phase. Not to mention code manipulation, which is so cool - and so dumb in a working environment. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On 25 Jun 2010 13:33:38 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote: What is the definition of user here? Programmers, etc. I went into more detail of what I meant into a previous response to Mark Z. Then that statistic is a show me stat. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
-snip-- Even easier than you wrote... /* rexx - zero a PDS Directory */ ARG dsn ALLOC F(PDSDIR) DA(dsn) SHR REUSE RECFM(F), /* pds directory */ DSORG(PS) LRECL(256) BLKSIZE(256) EXECIO 1 DISKRU PDSDIR (STEM DIR. /* read pds directory */ /* for update */ DIR.1 = '000E'x /* End of Directory */ EXECIO 1 DISKW PDSDIR (STEM DIR. FINIS /* Rewrite Directory */ FREE F(PDSDIR) Exit Obviously it won't work with PDSE. --unsnip--- What does it do about the keys? or DS1LSTAR? Or that other field showing the usage of the last block of the directory? Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On Mon, 28 Jun 2010 07:43:26 -0500, Mark Zelden mzel...@flash.net wrote: /* rexx - zero a PDS Directory */ snip On Mon, 28 Jun 2010 16:00:39 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: That does not change the key. I wonder what would happen if member GHJK was added and the keys shows that it should be inserted in block #3. I think it would be in limbo. On Mon, 28 Jun 2010 14:41:38 -0500, Rick Fochtman rfocht...@ync.net wrote: What does it do about the keys? or DS1LSTAR? Or that other field showing the usage of the last block of the directory? Oh... you want something that will leave the PDS still usable when it is done with it? :-)Ok, stick to PDS (PDS86) or one of the EMPTYPDS programs on the CBT. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler programs was Re: Delete all members of a PDS that is allocated
On 06/28/2010 08:32 AM, Thomas David Rivers wrote: Clark Morris wrote: On 27 Jun 2010 07:30:35 -0700, in bit.listserv.ibm-main you wrote: Until IBM provides a language or variant such as a systems flavor of C/C++ that has access to all of the facilities (including the peculiar linking conventions for some JES exits, any management that does not keep access to assembler expertise is playing with fire. ... Clark Morris Why does such a language need to be provided by IBM? Can a third-party vendor provide it? - Dave Rivers - It would be unreasonable for IBM to require a third-party product to customize z/OS, or to expect IBM to help diagnose strange z/OS failures caused by bad exits generated by some other vendor's product. z/OS customization must be possible with what is included with z/OS. So until IBM supplies alternative non-Assembler facilities for all exits and customization, some Assembler expertise would seem to be a requirement. Our application programmers are not that familiar with z-architecture, much less Assembly Language; but those of us in mainframe Technical Support certainly are. That knowledge is not just relevant to writing Assembly code utilities and exits, but is also useful in understanding why some approaches to application implementation in higher level languages are inefficient, and useful in having the credibility to communicate that to applications development. A management that thinks it can do without any of that expertise in house is short-changing the organization on multiple fronts. -- Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org Sr. Technical Admin., Mainframe Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler programs was Re: Delete all members of a PDS that is allocated
Joel C. Ewing wrote: On 06/28/2010 08:32 AM, Thomas David Rivers wrote: Clark Morris wrote: On 27 Jun 2010 07:30:35 -0700, in bit.listserv.ibm-main you wrote: Until IBM provides a language or variant such as a systems flavor of C/C++ that has access to all of the facilities (including the peculiar linking conventions for some JES exits, any management that does not keep access to assembler expertise is playing with fire. ... Clark Morris Why does such a language need to be provided by IBM? Can a third-party vendor provide it? - Dave Rivers - It would be unreasonable for IBM to require a third-party product to customize z/OS, or to expect IBM to help diagnose strange z/OS failures caused by bad exits generated by some other vendor's product. z/OS customization must be possible with what is included with z/OS. So until IBM supplies alternative non-Assembler facilities for all exits and customization, some Assembler expertise would seem to be a requirement. Our application programmers are not that familiar with z-architecture, much less Assembly Language; but those of us in mainframe Technical Support certainly are. That knowledge is not just relevant to writing Assembly code utilities and exits, but is also useful in understanding why some approaches to application implementation in higher level languages are inefficient, and useful in having the credibility to communicate that to applications development. A management that thinks it can do without any of that expertise in house is short-changing the organization on multiple fronts. And so you'll bring us in to teach Assembler to your applications programmers? Great! The benefits will be amazing and the costs low. :-) -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
In listserv%201006231937408428.0...@bama.ua.edu, on 06/23/2010 at 07:37 PM, gsg gsg_...@yahoo.com said: Does anyone know of a way to delete all of the members of a PDS which is allocated by job scheduler software? Yes; STOW DCB,,I is the one least likely to break. But if that software has the PDS open then you may have issues. We currently use an assembler program that does a reset(I think), but management wants us to not use assembler. I can pretty much guaranty decreased reliability and increased maintenance cost, but it's not my dog. I know that IEHPROGM can delete a specific member, When another job has the PDS allocated? I don't think you can wild card it. I believe that the most recent IDCAMS let's you wildcard the member name. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
In aanlktilff16w3azr3ycvb5pfguqddt8th-shz6aaj...@mail.gmail.com, on 06/25/2010 at 02:29 PM, George Henke gahe...@gmail.com said: Years ago Bell Labs Management required all application programming be done in BAL. They were running BPS? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On 06/26/2010 09:16 PM, Ted MacNEIL wrote: But here we are talking about a case of manipulating directory entries and internal content of an Operating-system-specific construct, a PDS. I can do that with REXX and ISPF Library Management Services -- no HLASM on my part. This prompted me to check latest ISPF manuals for LM services to see if I had missed something new. I see the the member delete service that has always been there, but there is still no PDS reset function (like in the CBT PDS utility). I wouldn't call deleting all individual members via ISPF LM services a viable production approach except for a PDS with a small number of members, or perhaps for a one time exercise. Going that route starts off requiring an order of magnitude more processing resources than a reset for even a small PDS and gets exponentially worse as the number of members increases. My unquoted remarks after the quoted sentence were: Higher-level languages like COBOL, that are deliberately designed to be machine-independent, provide no syntax to specify actions on that level. It just can't be done without depending at some point on code written in Assembler - either a local utility or some vendor utility. The LM management Services callable from REXX are of course vendor supplied utilities probably written in Assembler, not part of the REXX language itself, which simply re-makes my point that to do machine-dependent type things you have to go outside the machine-independent high-level language. The issue in this case becomes one of whether you use Assembler-implemented utilities that your installation writes and maintains or Assembler-implemented utilities from some other source. I don't know of any IBM utilities or non-Assembler interfaces included with z/OS that do a PDS RESET, but perhaps they exist. This capability certainly exists in freebie utlities on the CBT collection, or non-free vendor product alternatives if management insists that all utilities used have full maintenance support. -- Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Assembler programs was Re: Delete all members of a PDS that is allocated
On 27 Jun 2010 07:30:35 -0700, in bit.listserv.ibm-main you wrote: On 06/26/2010 09:16 PM, Ted MacNEIL wrote: But here we are talking about a case of manipulating directory entries and internal content of an Operating-system-specific construct, a PDS. I can do that with REXX and ISPF Library Management Services -- no HLASM on my part. This prompted me to check latest ISPF manuals for LM services to see if I had missed something new. I see the the member delete service that has always been there, but there is still no PDS reset function (like in the CBT PDS utility). I wouldn't call deleting all individual members via ISPF LM services a viable production approach except for a PDS with a small number of members, or perhaps for a one time exercise. Going that route starts off requiring an order of magnitude more processing resources than a reset for even a small PDS and gets exponentially worse as the number of members increases. My unquoted remarks after the quoted sentence were: Higher-level languages like COBOL, that are deliberately designed to be machine-independent, provide no syntax to specify actions on that level. It just can't be done without depending at some point on code written in Assembler - either a local utility or some vendor utility. Until IBM provides a language or variant such as a systems flavor of C/C++ that has access to all of the facilities (including the peculiar linking conventions for some JES exits, any management that does not keep access to assembler expertise is playing with fire. Assembler can be largely self taught by looking at generated code from the HLL of choice although a course on Macros was helpful. Clark Morris The LM management Services callable from REXX are of course vendor supplied utilities probably written in Assembler, not part of the REXX language itself, which simply re-makes my point that to do machine-dependent type things you have to go outside the machine-independent high-level language. The issue in this case becomes one of whether you use Assembler-implemented utilities that your installation writes and maintains or Assembler-implemented utilities from some other source. I don't know of any IBM utilities or non-Assembler interfaces included with z/OS that do a PDS RESET, but perhaps they exist. This capability certainly exists in freebie utlities on the CBT collection, or non-free vendor product alternatives if management insists that all utilities used have full maintenance support. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
I just have to ask this one question. How difficult is it to get the number of directory blocks from a PDS in a _ program (where the blank can be filled in with COBOL, PL/1, REXX, etc., but not HLASM/ASM) and then open the data set with RECFM=U and then write an initial directory block followed by n empty blocks? With that question asked, if it is not so difficult, wouldn't that allow you to clear a PDS right rapidly? The only access you would have to have for the data set is update, because you aren't deleting it or [re-]allocating it. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On Sun, 27 Jun 2010 15:00:14 -0400, Thompson, Steve wrote: How difficult is it to get the number of directory blocks from a PDS in a _ program (where the blank can be filled in with COBOL, PL/1, REXX, etc., but not HLASM/ASM) and then open the data set with RECFM=U and then write an initial directory block followed by n empty blocks? Don't forget the keys. And what about DS1LSTAR? And what about PDSE? Other than that, I believe you need only overwrite the first block. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On Sun, 27 Jun 2010 09:30:10 -0500, Joel C. Ewing wrote: the CBT PDS utility). I wouldn't call deleting all individual members via ISPF LM services a viable production approach except for a PDS with a small number of members, or perhaps for a one time exercise. Going that route starts off requiring an order of magnitude more processing resources than a reset for even a small PDS and gets exponentially worse as the number of members increases. Not exponentially. Quadratically, if I understand the technique. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
I was unaware of Mr. Smith's involvement. Rick - Ed Finnell wrote: In a message dated 6/25/2010 5:31:07 P.M. Central Daylight Time, rfocht...@ync.net writes: with Bruce Leland, the original author, for about 25 years. Author(s) Mike Smith and Bruce Leland. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On 6/27/2010 3:00 PM, Thompson, Steve wrote: How difficult is it to get the number of directory blocks from a PDS in a _ program (where the blank can be filled in with COBOL, PL/1, REXX, etc., but not HLASM/ASM) and then open the data set with RECFM=U and then write an initial directory block followed by n empty blocks? With that question asked, if it is not so difficult, wouldn't that allow you to clear a PDS right rapidly? The only access you would have to have for the data set is update, because you aren't deleting it or [re-]allocating it. The intrinsic problem is that to do it correctly (for a PDS) the program needs to be authorized, as DS1NOBDB needs to be reset. DS1LSTAR could be set correctly by having the write flag on, and the correct CCHHR in the DCB (of the EOF at end of directory). An IEBCOPY compress in place would also reset DS1LSTAR, but I've never tried whether it resets DS1NOBDB (normally it would have no need to, as a compress doesn't change the member count). Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
-snip Management may know something you don't. Management may know that very few of their staff knows BAL. And if a program blows up in the middle of the night (or any other time) no one may be available to debug it. I have seen this happen myself as I was the one that was called in. For support. I lobbied after that for no more assembler and was successful at getting this approved. --unsnip-- Been in a similar situation myself. Made appropriate corrections and notified the progrmmer what the problem was and how to fix it. When he ignored that advice and the problem recurred, he got called on the carpet. After several more occurences, requiring me to come in and affect the fix, he was promoted to the sidewalk and I became responsible for the program. End of problem. Aft4er that, management would accept any BAL program, providing that I wrote it and was willing to provide assistance if it failed. Track records mean a lot! :-) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
---snip-- I just have to ask this one question. How difficult is it to get the number of directory blocks from a PDS in a _ program (where the blank can be filled in with COBOL, PL/1, REXX, etc., but not HLASM/ASM) and then open the data set with RECFM=U and then write an initial directory block followed by n empty blocks? With that question asked, if it is not so difficult, wouldn't that allow you to clear a PDS right rapidly? The only access you would have to have for the data set is update, because you aren't deleting it or [re-]allocating it. -unsnip--- That might work, as long as you have a mechanism for manipulating the keys in the directory also. The last used block in the directory has a key of X''. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler programs was Re: Delete all members of a PDS that is allocated
On 27 Jun 2010 15:20:32 -0700, in bit.listserv.ibm-main you wrote: ---snip-- Until IBM provides a language or variant such as a systems flavor of C/C++ that has access to all of the facilities (including the peculiar linking conventions for some JES exits, any management that does not keep access to assembler expertise is playing with fire. Assembler can be largely self taught by looking at generated code from the HLL of choice although a course on Macros was helpful. --unsnip--- I disagree. Looking at others' code might help to learn the usage of the instruction set, but it won't teach efficient programming techniques. Rick Looking at good generated code from decently coded HLL programs can give a clue. However, what amount of knowledge is adequate for maintaining JES exits and simple tools from the CBT tape? More important does the person believe in testing in a safe environment and reading the appropriate manuals (and knowing whether they understand them)? When you start getting into cross memory services, I don't know that I would want to touch that code let alone things that get into locks so knowing your limitations is important. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Assembler programs was Re: Delete all members of a PDS that is allocated
On Sun, 2010-06-27 at 21:02 -0300, Clark Morris wrote: On 27 Jun 2010 15:20:32 -0700, in bit.listserv.ibm-main you wrote: ---snip-- Until IBM provides a language or variant such as a systems flavor of C/C++ that has access to all of the facilities (including the peculiar linking conventions for some JES exits, any management that does not keep access to assembler expertise is playing with fire. Assembler can be largely self taught by looking at generated code from the HLL of choice although a course on Macros was helpful. --unsnip--- I disagree. Looking at others' code might help to learn the usage of the instruction set, but it won't teach efficient programming techniques. Rick Looking at good generated code from decently coded HLL programs can give a clue. However, what amount of knowledge is adequate for maintaining JES exits and simple tools from the CBT tape? More important does the person believe in testing in a safe environment and reading the appropriate manuals (and knowing whether they understand them)? When you start getting into cross memory services, I don't know that I would want to touch that code let alone things that get into locks so knowing your limitations is important. Clark Morris I think that there is a difference between having a normal (ain't no such beastie) application programmer and an old style sysprog. I think sysprogs need HLASM. I am not convinced that it is necessary for applications people to really know HLASM or even z architecture. Today's COBOL is much better than in the past. I can see needing the speed of assembler in embedded type applications. But that is not z/OS's forte. Commercial programming and COBOL go together like pancakes and maple syrup. But other languages are coming up for the webified world. I like PHP. PHP using DB2 with perhaps some COBOL stored programs is, IMO, likely one of the best ways to talk via the web. But others may reasonable disagree. -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
At 3:55 PM -0500 on 06/27/2010, Paul Gilmartin wrote about Re: Delete all members of a PDS that is allocated: On Sun, 27 Jun 2010 09:30:10 -0500, Joel C. Ewing wrote: the CBT PDS utility). I wouldn't call deleting all individual members via ISPF LM services a viable production approach except for a PDS with a small number of members, or perhaps for a one time exercise. Going that route starts off requiring an order of magnitude more processing resources than a reset for even a small PDS and gets exponentially worse as the number of members increases. Not exponentially. Quadratically, if I understand the technique. -- gil If I remember correctly, the index blocks at the start of PDS are filled with the directory entries and when you delete one member, all of the subsequent entries shift forward (and shift from block to block). Thus when you delete in alpha order (as opposed to reverse alpha order), you remove the first member entry and all the others shift to fill the gap. Assuming that the same number of members fill each block (due to being the same length) then the number of write operations is computed by this method: T = Total number of Members M = The number of members per block For I = 1 to T Compute the Sum of the Ceiling of I/M (Ceiling meaning I/M rounded up to the next integer). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Ed Finnell wrote: In a message dated 6/25/2010 5:31:07 P.M. Central Daylight Time, rfocht...@ync.net writes: with Bruce Leland, the original author, for about 25 years. Author(s) Mike Smith and Bruce Leland. Big bloke with the red hair? Steve Smith. Most of the original ISPF interface was his work. I remember his presentation in 1990 when using PDS as a workbench was being encouraged. His pitch began Now, I don't know what your idea of a workbench is, but... and he showed a slide of a backyard shed workbench covered with as astonishing degree of clutter. I think he meant to imply that PDS offers lots of features and facilities. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Greg Pruce of the IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 06/26/2010 01:00:32 AM: Ed Finnell wrote: In a message dated 6/25/2010 5:31:07 P.M. Central Daylight Time, rfocht...@ync.net writes: with Bruce Leland, the original author, for about 25 years. Author(s) Mike Smith and Bruce Leland. Big bloke with the red hair? Steve Smith. Most of the original ISPF interface was his work. I remember his presentation in 1990 when using PDS as a workbench was being encouraged. His pitch began Now, I don't know what your idea of a workbench is, but... and he showed a slide of a backyard shed workbench covered with as astonishing degree of clutter. I think he meant to imply that PDS offers lots of features and facilities. Cheers, Greg Here is an excerpt from the PDS doc, presumably written by Steve Smith. The first goal of the ideal work bench is to provide within easy reach those things the programmer uses all the time. Key strokes should be reduced. Reentering object names should be nearly eliminated. The user should be able to keep several activities going at one time. He should be able to apply any number of tools at any time to the things he is working on. Another goal of the ideal work bench is to provide several ways to narrowly target the objects and data that are important to the programmer. This reduces the background clutter and allows the programmer to concentrate on items of interest. This would help alleviate the information overload we all experience. Another goal of the work bench would be to provide better ways to get the right information about objects for display. This includes information not available through common utilities. It would combine and present common information on objects in ways that enhance the understanding of this data. The work bench would integrate a great many tools for processing information and also provide affective interfaces to the excellent tools provided by others. Many of these tools would be applied to individual objects or applied in mass automatically. The work bench should provide an easy way to add user supplied tools. The work bench would reduce or simplfy many of the maintenance chores we have to live with. Compressing and copying data would be easy. Means for converting data formats would be part of the copy process. The ideal work bench should really shine when it comes to handling problem situations with datasets. It would isolate and identify these problems and provide a corrective procedure. Much of the information that might be extracted by a work bench product may be useful for outside processing. The work bench would provide ways to capture information and put it into user files useful for other processing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Percentage of code executed that is user written was Re: Delete all members of a PDS that is allocated
On 25 Jun 2010 20:47:56 -0700, in bit.listserv.ibm-main you wrote: Your point that the language used for that 5% doesn't matter is only partly true, IMHO. Knowing how to optimize the language that you or your management chose and knowing the hot spots to avoid helps avoid writing or correct bad code no matter the language used. Algorithms! Algorithms! Bad code is bad code and good code is good code. But, in z/OS, when I've written bad code, I'm invoking ISV/IBM code, inefficiently. When I've written good code, I've invoked the other stuff efficiently. There also is the trick in knowing whether to use LE or system functions as opposed to doing the calculation in line and when in the overall scheme of things it matters. For example the COBOL functions to convert Gregorian dates to day year format and vice versa take far more CPU relatively than coding the conversion in line. READ x INTO y can be more costly than READ x, MOVE x-record into y when x-record is variable length or 1 of 5 different length records that can be read. The question is whether the inefficiency gets buried because of other issues or the overall volume makes the difference trivial. Critical path and response time issues then should focus the attention. The issue of intermodule overhead also becomes important. In some cases combining the code in the same module by using nested programs can have a significant impact. In others, it isn't worth the cost. HLASM or COBOL really doesn't matter. That's just an implementation detail. It's only hot if you're calling services excessively. Even interest calculations call vendor code, even if it's just linkage to LE, which you didn't write. I'm not saying that that 5% is trivial, but it only does business logic, as important as that is. But, everything else is vendor code. READ. PROCESS. WRITE. Plus initiation, allocate, open, close, de-allocate and terminate. Only one section is written by the user. The rest may seem like the user wrote it, but how much system code is invoked by a simple open statement? Take care of your algorithms, and the language will tend to become secondary. The optimum language will be the one that your staff knows. And, before it's said, are languages like JAVA, or SAS, inefficient, or are their runtime environments? Interpreted languages always add a degree of inefficiency which may or may not be acceptable in a given environment. Clark Morris - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
In a message dated 6/26/2010 1:01:21 A.M. Central Daylight Time, greg.pr...@optushome.com.au writes: Big bloke with the red hair? Steve Smith. Most of the original ISPF interface was his work. Sorry, yes Steve. Was thinking of Mike Loos(Deluxe Check) and long association with SHARE. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
In a message dated 6/26/2010 9:33:31 A.M. Central Daylight Time, efinnel...@aol.com writes: Sorry, yes Steve. Was thinking of Mike Loos(Deluxe Check) and long association with SHARE. Funny story. Came back from a SHARE in early eighties and gave a brief trip report about Sessions attended and what was new. We were ESPing and that's where most of the interest was. I had about a half page on ISPF, PDS command and some of the things Aetna(maybe Rob Mura) was doing with ISPCALL. So thanks back to ESP land. About six weeks later, get a call to come bless an Item Processing system. They had gotten an interface to the Check processing system with ISPF full screen using the ISPCALL macro. Said it cut overhead by 40%. Don't know how they measured, but they were happy campers for a while -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Percentage of code executed that is user written was Re: Delete all members of a PDS that is allocated
peter.far...@broadridge.com (Farley, Peter x23353) writes: Attention to details like this (and some similar optimizations) saved one application I have worked on almost 50% of its previous CPU utilization without changing the application algorithm in any other way. the science center had pioneered a lot of performance tools in the 60s 70s, workload profiling ... and stuff that eventually turned into things like capacity planning. misc. past posts mentioning science center, 4th flr, 545 tech sq http://www.garlic.com/~lynn/subtopic.html#545tech they had activity counter snap shots ... starting with the science center cp67 ... eventually every 5-10 mins, 7x24 for nearly decade. the convention was followed by internal systems installing first cp67 and then vm370 ... so there were hundreds of systems with lots of different workloads configurations with years of data. another activity was several system simulators ... some written in pli others in apl ... that could simulate effects of different algorithms. one of the apl simulators ... using the enormous amount of snapshot information evolved into the performance predictor ... made available on the worldwide sales marketing hone system; customer support people could enter profiles of their customers workload configuration ... and then ask what-if questions regarding what happens selling an additional mbyte of memory (or other configurations changes) /or what happens when there are workload changes. in the 90s, rights to a descendent of the performance predictor were sold ... the person ran it thru and apl-to-c convertor and then made a living doing consulting at number of high-end datacenters around the world. the science center also did some number of other kinds of hot-spot monitoring. not at cambridge ... but from palo alto science center (by people that brought you the 370/145 apl microcode assist) ... they gen'ed up a 145 microcode path for me that sampled instruction address. I used this for help in identifying pieces of code to be dropped into microcode for the ECPS performance assist. this is old post with result of some of the other kinds of analysis done on the kernel code as part of selecting what went into the microcode: http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist The science center also did a project that started out with the POK redcap instruction simulator (recorded information about each instruction simulated ... was used in helping design processors /or new instruction). Several changes to the information recording were made at the science center ... which was then used as input into a virtual memory simulator. Science center eventually released this as vs/repack product ... which included ability to do semi-automated program re-organization. It was used by a number of corporate products ... both as an instruction hot-spot identifier ... as well as helping in transition from real storage environment to virtual memory environment (i.e. products like IMS made a lot of use of it). about the turn of the century had a chance to look at a large, 450+K statement cobol application that ran all night on something like 40+ CECs (billion plus in mainframe equipment). the consultant that was using the descendent of the performance predictor had been called in on the project ... to look for possible system and application bottlenecks. the operation also had a large performance group that had been tending the application for years (decades?) ... mostly with hotspot analysis. the consultant turned up some things that had gone unnoticed by the group doing hot-spot analysis ... but there was still strong feeling that there was significant thruput inefficiencies (in part based on cpu processing/operation from decades earlier and currently). One of the things done at the science center decades earlier was multiple regression analysis of the activity counters. I decided to try something similar for this application; collected fairly large number of application counts from several nights run across large number of CECs. It turned up some meta level activity that was quite anomolous ... and when reworked, resulted in significant thruput improvement. Part of the issue was that the system analytical models and the hot-spot analysis had been highlighting micro level activity ... but didn't catch the application doing several anomolous unnecessary passes of whole operations. misc. past posts mentioning performance predictor /or vs/repack: http://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc) http://www.garlic.com/~lynn/99.html#68 The Melissa Virus or War on Microsoft? http://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back? http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic) http://www.garlic.com/~lynn/2001c.html#31 database (or b-tree) page sizes http://www.garlic.com/~lynn/2001c.html#33 database (or b-tree) page sizes
Re: Delete all members of a PDS that is allocated
On Wed, 23 Jun 2010 20:47:24 -0400, Lizette Koehler wrote: It is going to depend. You can write a REXX that uses the LM functions to delete a member. If you have PDSMAN with FASTCOPY you can ZERODIR. If you have SAS you can KILL a pds. And I am sure there are other ways. The requirement is that the dataset is enqueued with DISP=SHR and that the SCHEDULER does not try to load from it when you are emptying it. Delete every member, using the technique of programmer's choice. For performance work in reverse alphabetical order. Compress with DISP=SHR. Integrity concerns are left to the user. More generally, SCHEDULER isn't necessarily the only victim. For performance, nearly the best is STOW DCB,,I. Nearly? Overwriting the first directory block and resetting DS1LSTAR is probably better. But that's incompatible with PDSE. But the OP didn't say PDSE, after all. Delete and re-create is not an option while the data set is allocated. STOW DCB,,I won't handle Unix directories, nowadays otherwise (partly) supported by BPAM. Mounting via NFS and using rm -r handles all of PDS, PDSE, and Unix directories. I won't recommend it, although I've surely used it when it was convenient. Probably technically the best is STOW DCB,,I using any language which supports it at runtime. Does anyone know of a way to delete all of the members of a PDS which is allocated by job scheduler software? We currently use an assembler program that does a reset(I think), but management wants us to not use assembler. I know that IEHPROGM can delete a specific member, but the members change from day to day. I don't think you can wild card it. Will the OP's scheduler tolerate the use of Unix directories (now partly supported by BPAM) as its libraries? These could remove most of the ENQ bottleneck while providing LUW isolation similar to that of PDSE. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Percentage of code executed that is user written was Re: Delete all members of a PDS that is allocated
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. re: http://www.garlic.com/~lynn/2010j.html#81 Percentage of code executed that is user written for slightly different slant on the subject ... in the early 70s ... Amdahl gave a talk at MIT in large auditorium on subject of forming his own clone processor company. one of the questions from student in the audience was what was the pitch/spin he used to get venture capital funding for his corporation. his reply was something about customers had already spent billions in 360 software development ... that even if IBM was to completely walk away from 360/370 ... that software base would be enough to keep him in business through the end of the century. the reference to possibility of IBM completely walking away from 360/370 ... might be considered a veiled reference to future system effort ... which was planning on doing just that. misc. past posts mentioning future system http://www.garlic.com/~lynn/submain.html#futuresys this has some reference to the future system period letting 370 software hardware product pipeline go dry: http://www.jfsowa.com/computer/memo125.htm and this fergus morris book reference http://www.garlic.com/~lynn/2001f.html#33 IBM's VM for the PC c.1984?? makes mention that letting the 370 product pipeline go dry, in large part contributed to letting clone processor vendors gain market foothold. -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On 06/25/2010 02:42 PM, Ted MacNEIL wrote: Whatever became of efficiency. Years ago Bell Labs Management required all application programming be done in BAL. The myth that BAL is more efficient, is (in general) just that, a myth. COBOL, with optimisation, is almost as efficient, and easier to maintain. People costs are more than coding costs. In a z/OS environment, with access methods, online sub-systems, utilities, and the like, less than 5% of the code running on the z/Box is user-written. Complaining about the efficiency of BAL (or HLASM) is false economy. Write assembler where required; allow the technician to use whatever tools they are comfortable with for the rest. IT is to improve the efficiency of people, NOT the reverse. ... When implementing algorithms that are a good match for the language capabilities, high-level languages with a good optimizing compiler can certainly approach excellent Assembly code, or even greatly exceed Assembler efficiency when a more readable algorithm representation allows you to recognize and implement a more efficient approach to an application. But here we are talking about a case of manipulating directory entries and internal content of an Operating-system-specific construct, a PDS. Higher-level languages like COBOL, that are deliberately designed to be machine-independent, provide no syntax to specify actions on that level. It just can't be done without depending at some point on code written in Assembler - either a local utility or some vendor utility. If there is a management concern that a local utility might break at some unknown point in the future with no one locally qualified to fix it, then look for alternatives to be sure it can be replaced if needed. But since it would take some major system maintenance to break something basic like this, this is not something likely to die over night with no prior warning. I concur with others that say it doesn't make sense to spend time and money to ditch something that is working satisfactorily just because it is written in Assembler code, unless and until it can be shown to fail at some future maintenance level of z/OS. -- Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
But here we are talking about a case of manipulating directory entries and internal content of an Operating-system-specific construct, a PDS. I can do that with REXX and ISPF Library Management Services -- no HLASM on my part. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
--- On Wed, 6/23/10, Ted MacNEIL eamacn...@yahoo.ca wrote: From: Ted MacNEIL eamacn...@yahoo.ca Subject: Re: Delete all members of a PDS that is allocated To: IBM-MAIN@bama.ua.edu Date: Wednesday, June 23, 2010, 11:57 PM but management wants us to not use assembler. I'm sorry, but I have to chime in. If your staff knows how to use a tool, why should management care? Management assigns tasks, NOT how-t Ted: MAnagement may know something you don't. Management may know that very few of their staff knows BAL. And if a program blows up in the middle of the night (or any other time) no one may be available to debug it. I have seen this happen myself as I was the one that was called in. For support. I lobbied after that for no more assembler and was successful at getting this approved. Ed (sent via IPAD) - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On 24 Jun 2010 05:12:04 -0700, john.mck...@healthmarkets.com (McKown, John) wrote: In general, I agree, but management must also be concerned with maintainability. The perceived decrease in HLASM programming skills have likely made management do one of its infamous one size fits all commands. I've seen some cheating here - with people writing assembler imbedded in higher order languages. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Whatever became of efficiency. Years ago Bell Labs Management required all application programming be done in BAL. On Fri, Jun 25, 2010 at 11:34 AM, Howard Brazee howard.bra...@cusys.eduwrote: On 24 Jun 2010 05:12:04 -0700, john.mck...@healthmarkets.com (McKown, John) wrote: In general, I agree, but management must also be concerned with maintainability. The perceived decrease in HLASM programming skills have likely made management do one of its infamous one size fits all commands. I've seen some cheating here - with people writing assembler imbedded in higher order languages. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of George Henke Sent: Friday, June 25, 2010 1:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated Whatever became of efficiency. Years ago Bell Labs Management required all application programming be done in BAL. Machine vs. programmer? Sometimes it is more efficient to use an HLL. If by efficient you mean cost effective. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
(Sorry, I originally sent this to the newsgroup instead of the Listserv.) On 23 Jun 2010 17:39:54 -0700, in bit.listserv.ibm-main (Message-ID:listserv%201006231937408428.0...@bama.ua.edu) gsg_...@yahoo.com (gsg) wrote: Does anyone know of a way to delete all of the members of a PDS which is allocated by job scheduler software? We currently use an assembler program that does a reset(I think), but management wants us to not use assembler. In other words, you have a technique which has been working, and has been tested over time. It costs nothing. Instead, your management wants you to come up with something new, that will cost, at minimum, many man-hours to find, write, debug, test, and get moved into production. It's quite possible that the solution you come up with (e.g. Startools or its free cousin, the PDS command from the CBT tape) is also written in assembler. You might start by asking your management why they want to waste money or man-hours in a tight economy. You might also tell them that you're *not* using assembler; you're using an executable program that's very little different from any other executable except that it does just what you want it to do. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Not everybody... Is the action bar the menu they added a few years back that everybody I knew turned off? Maybe I need to turn it on to get to the help that would include your command. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Whatever became of efficiency. Years ago Bell Labs Management required all application programming be done in BAL. The myth that BAL is more efficient, is (in general) just that, a myth. COBOL, with optimisation, is almost as efficient, and easier to maintain. People costs are more than coding costs. In a z/OS environment, with access methods, online sub-systems, utilities, and the like, less than 5% of the code running on the z/Box is user-written. Complaining about the efficiency of BAL (or HLASM) is false economy. Write assembler where required; allow the technician to use whatever tools they are comfortable with for the rest. IT is to improve the efficiency of people, NOT the reverse. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On Fri, 25 Jun 2010 19:42:27 +, Ted MacNEIL eamacn...@yahoo.ca wrote: In a z/OS environment, with access methods, online sub-systems, utilities, and the like, less than 5% of the code running on the z/Box is user-written. Where did you get that statistic from? Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Friday, June 25, 2010 3:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated On Fri, 25 Jun 2010 19:42:27 +, Ted MacNEIL eamacn...@yahoo.ca wrote: In a z/OS environment, with access methods, online sub-systems, utilities, and the like, less than 5% of the code running on the z/Box is user-written. Where did you get that statistic from? Mark -- And does it mean: 5% of the CPU resource used on a z/OS system is consumed by user written code or 5% of the number of lines of code for all the executable programs on a given z/OS system are user written. From context, I would guess the former. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On 25 Jun 2010 12:42:43 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote: In a z/OS environment, with access methods, online sub-systems, utilities, and the like, less than 5% of the code running on the z/Box is user-written. What is the definition of user here? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Where did you get that statistic from? IBM Canada. They don't like to publicise it, since it looks bad to sell machines to run their code. I did verify it, empirically, using STROBE on some production jobs. For example: We do not write code to open a file, alllocate buffers, and actually read or write data. The requests are OPEN -- IBM code does the work. READ (or WRITE), and IBM code does the work. CLOSE, and guess who does the work. Those are generic statements (OPEN, READ/WRITE, and CLOSE), but how many IBM-Written statements do you think you think they generate. Consider LOGON (one statement/command) and, especially with RACF involved, how much IBM code is generated. Or, a single SQL statement. Or, even JAVA -- who wrote the JVM? Need I go on? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On Fri, 25 Jun 2010 15:25:58 -0500, McKown, John john.mck...@healthmarkets.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Friday, June 25, 2010 3:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated On Fri, 25 Jun 2010 19:42:27 +, Ted MacNEIL eamacn...@yahoo.ca wrote: In a z/OS environment, with access methods, online sub-systems, utilities, and the like, less than 5% of the code running on the z/Box is user-written. Where did you get that statistic from? Mark -- And does it mean: 5% of the CPU resource used on a z/OS system is consumed by user written code or 5% of the number of lines of code for all the executable programs on a given z/OS system are user written. From context, I would guess the former. With all the recovery code written into the OS, subsystems and ISV software, I would think the latter if anything (but I find that a hard to believe number also, but could be close to that in a small shop I guess). The system idles quite nicely at very low utilization, so saying that running production and development environments at or near 100% (which most cost conscience shops do) isn't because of user written code just because it invokes access methods, system services, CICS services, SQL or whatever would be a very misleading statement IMO. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
What is the definition of user here? Programmers, etc. I went into more detail of what I meant into a previous response to Mark Z. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Friday, June 25, 2010 3:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated On Fri, 25 Jun 2010 19:42:27 +, Ted MacNEIL eamacn...@yahoo.ca wrote: In a z/OS environment, with access methods, online sub-systems, utilities, and the like, less than 5% of the code running on the z/Box is user-written. Where did you get that statistic from? SNIPPAGE Well, aren't 86.7% of all stats made up on the spot? And wouldn't this mean that 90+% of all code running on the system is from IBM or an ISV? Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Well, aren't 86.7% of all stats made up on the spot? It wasn't made upbn And wouldn't this mean that 90+% of all code running on the system is from IBM or an ISV? Yes. It's invoked by user code, which may grind only 5%, but the requests are handled by non-user code. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
I don't even know how to subset this message to formulate a response. So, I'm replying intact. But, my point is, while the percentage may not believed, how many users write access methods, terminal handlers, abend handlers, DB2 optimisers, ENQ-Handlers, operator commands, interupt handlers, message passers, or any other system function. These functions are requested by programmes, operators, terminal users, or whatever. Empirical data has shown, to me at least, including statements from IBM, that the user code is a small part of this. So, what is the point, on today's fast machines, about worrying about the optimisation of the small stuff? Yes, you can drive a z/Box nuts with poorly indexed DB's or bad loops. But, are these faults caused by the language, or bad programmers, DBA's, or others? - Too busy driving to stop for gas! -Original Message- From: Mark Zelden mzel...@flash.net Sender: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Date: Fri, 25 Jun 2010 15:33:05 To: IBM-MAIN@bama.ua.edu Reply-To: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated On Fri, 25 Jun 2010 15:25:58 -0500, McKown, John john.mck...@healthmarkets.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Friday, June 25, 2010 3:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated On Fri, 25 Jun 2010 19:42:27 +, Ted MacNEIL eamacn...@yahoo.ca wrote: In a z/OS environment, with access methods, online sub-systems, utilities, and the like, less than 5% of the code running on the z/Box is user-written. Where did you get that statistic from? Mark -- And does it mean: 5% of the CPU resource used on a z/OS system is consumed by user written code or 5% of the number of lines of code for all the executable programs on a given z/OS system are user written. From context, I would guess the former. With all the recovery code written into the OS, subsystems and ISV software, I would think the latter if anything (but I find that a hard to believe number also, but could be close to that in a small shop I guess). The system idles quite nicely at very low utilization, so saying that running production and development environments at or near 100% (which most cost conscience shops do) isn't because of user written code just because it invokes access methods, system services, CICS services, SQL or whatever would be a very misleading statement IMO. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Well, now you've top posted so I have to do the same thing. :-) I think you were confirming with what I wrote to John and I guess I can see that being true (5% # of lines of code vs. resources). But that small percent (5% or not) is the part you have to pay most attention to. You don't have much if any control of the other parts. So saying it should be ignored because it's a small percentage of the number of lines of total code running around the system is absolutely the wrong thing to do. My client does constant analyzing of application code (batch, CICS, WebSphere) and has made a huge difference to CPU consumption numbers in many cases (some small gains, some big ones). This usually happens in testing, but sometimes is missed. There are major application releases every other month and minor ones every month and despite all the testing, we still run into unexpected utilization increases at times. Without analyzing and changing code to address what has been found in testing and sometimes after it hits production, there would have already been many more millions of dollars spent on CPU upgrades. Small amount of user code or not, you should worry about the optimisation of the small stuff. And yes, it is the fault of the programmer or bad indexes or whatever (but not the OS's fault) - so what? If you have this same discussion for a server running wintel or unix, the same is probably more true. It's all the OS and infrastructure in terms of number of lines of code, but it is still the business application that will make the box over utilized or more utilized than a well written app. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ On Fri, 25 Jun 2010 20:53:51 +, Ted MacNEIL eamacn...@yahoo.ca wrote: I don't even know how to subset this message to formulate a response. So, I'm replying intact. But, my point is, while the percentage may not believed, how many users write access methods, terminal handlers, abend handlers, DB2 optimisers, ENQ-Handlers, operator commands, interupt handlers, message passers, or any other system function. These functions are requested by programmes, operators, terminal users, or whatever. Empirical data has shown, to me at least, including statements from IBM, that the user code is a small part of this. So, what is the point, on today's fast machines, about worrying about the optimisation of the small stuff? Yes, you can drive a z/Box nuts with poorly indexed DB's or bad loops. But, are these faults caused by the language, or bad programmers, DBA's, or others? - Too busy driving to stop for gas! -Original Message- From: Mark Zelden mzel...@flash.net Sender: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Date: Fri, 25 Jun 2010 15:33:05 To: IBM-MAIN@bama.ua.edu Reply-To: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated On Fri, 25 Jun 2010 15:25:58 -0500, McKown, John john.mck...@healthmarkets.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Friday, June 25, 2010 3:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated On Fri, 25 Jun 2010 19:42:27 +, Ted MacNEIL eamacn...@yahoo.ca wrote: In a z/OS environment, with access methods, online sub-systems, utilities, and the like, less than 5% of the code running on the z/Box is user-written. Where did you get that statistic from? Mark -- And does it mean: 5% of the CPU resource used on a z/OS system is consumed by user written code or 5% of the number of lines of code for all the executable programs on a given z/OS system are user written. From context, I would guess the former. With all the recovery code written into the OS, subsystems and ISV software, I would think the latter if anything (but I find that a hard to believe number also, but could be close to that in a small shop I guess). The system idles quite nicely at very low utilization, so saying that running production and development environments at or near 100% (which most cost conscience shops do) isn't because of user written code just because it invokes access methods, system services, CICS services, SQL or whatever would be a very misleading statement IMO. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message:
Percentage of code executed that is user written was Re: Delete all members of a PDS that is allocated
On 25 Jun 2010 13:41:08 -0700, in bit.listserv.ibm-main you wrote: Well, aren't 86.7% of all stats made up on the spot? It wasn't made upbn And wouldn't this mean that 90+% of all code running on the system is from IBM or an ISV? Yes. It's invoked by user code, which may grind only 5%, but the requests are handled by non-user code. - Too busy driving to stop for gas! My take is that most of the execution time of any given unit of work such as a job step or CICS transaction is spent executing system code including access methods, CICS and DB2 supplied code. An SQL statement presumably would spend most of its time executing DB2 code. What this is saying is that for the most part optimizing COBOL programs or REXX code probably has relatively little payback compared to optimizations like VSAM buffering. My take is that if a good set of guidelines is available and used, most code and tool use will be efficient enough. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
So saying it should be ignored because it's a small percentage of the number of lines of total code running around the system is absolutely the wrong thing to do. Are you analysing the code, or the algorithm? A bad approach is a bad approach, but a good approach is moot regardless of the language. Bad code calling system services stinks in any language. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
snip Whatever became of efficiency. Years ago Bell Labs Management required all application programming be done in BAL. unsnip--- Even BAL programmers can produce lousy code; it's just sometimes harder to spot. :-) Character string manipulations, like scanning control statements, can be inordinately complex in BAL if you're not really careful in the design phase. Design an input editor to reject bad input and some ingenious idiot will find a way to get bad input past it. :-) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Art, those are very good points. Wish I'd thought of them a few years ago. StarTool and PDS are both written in Assembler; I've been acquainted with Bruce Leland, the original author, for about 25 years. Rick --snip- In other words, you have a technique which has been working, and has been tested over time. It costs nothing. Instead, your management wants you to come up with something new, that will cost, at minimum, many man-hours to find, write, debug, test, and get moved into production. It's quite possible that the solution you come up with (e.g. Startools or its free cousin, the PDS command from the CBT tape) is also written in assembler. You might start by asking your management why they want to waste money or man-hours in a tight economy. You might also tell them that you're *not* using assembler; you're using an executable program that's very little different from any other executable except that it does just what you want it to do. -unsnip- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
-snip I don't even know how to subset this message to formulate a response. So, I'm replying intact. But, my point is, while the percentage may not believed, how many users write access methods, terminal handlers, abend handlers, DB2 optimisers, ENQ-Handlers, operator commands, interupt handlers, message passers, or any other system function. ---unsnip In college I took a 30-wk course that required many of those things. DB2 didn't exist then, but I had to write message-switching programs for TCAM, operator commands, etc. and the final exam was a complete system that could load and run an object deck fed in via 2540. The system (The SELF system, for Semi Efficient Little Fiasco) had to handle I/O, SVC and Program interrupts and take appropriate action. I even had 12 System-Defined SVC's. Granted, that probably makes me an exception to the average user, but at the time I thought it was just part of becoming a System Programmer, to bolster my understanding of the hardware/software interactions of the day. (1972) snip- Consider: how many Users are actully Programmers ?? Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Percentage of code executed that is user written was Re: Delete all members of a PDS that is allocated
snip--- My take is that most of the execution time of any given unit of work such as a job step or CICS transaction is spent executing system code including access methods, CICS and DB2 supplied code. An SQL statement presumably would spend most of its time executing DB2 code. What this is saying is that for the most part optimizing COBOL programs or REXX code probably has relatively little payback compared to optimizations like VSAM buffering. My take is that if a good set of guidelines is available and used, most code and tool use will be efficient enough. ---unsnip-- Clark, I'll concede PART of the validity of your point. Consider the following example: Program before checks BEGIN LOOP. OPEN DB FOR UPDATE. UPDATE DB RECORD.(s) CLOSE DB. END LOOP. Run time averaged 300-330 minutes. Program after checks and changes: OPEN DB FOR UPDATE. BEGIN LOOP. UPDATE DB RECORD(s) END LOOP. CLOSE DB. Run time now 20-25 minutes. It's ok to generalize and say that most time is spent in non-user-written code, but abuse of that code can also be incredibly damaging. Badly written code by a shop's programming staff can lead to terrible performance just as easily as badly written IBM or OEM code. This example was drawn from actual experience; I can still name the programmer, even though he's now retired. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Percentage of code executed that is user written was Re: Delete all members of a PDS that is allocated
It's ok to generalize and say that most time is spent in non-user-written code, but abuse of that code can also be incredibly damaging. That has been my point all along! The bad code does what it does, but it's what it does. I said 5%, which may be wrong, exagerated, and empirical, but the algorithm is key. And, a bad one in assembler can cost more than the best in COBOL. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Percentage of code executed that is user written was Re: Delete all members of a PDS that is allocated
On 25 Jun 2010 15:59:23 -0700, in bit.listserv.ibm-main you wrote: snip--- My take is that most of the execution time of any given unit of work such as a job step or CICS transaction is spent executing system code including access methods, CICS and DB2 supplied code. An SQL statement presumably would spend most of its time executing DB2 code. What this is saying is that for the most part optimizing COBOL programs or REXX code probably has relatively little payback compared to optimizations like VSAM buffering. My take is that if a good set of guidelines is available and used, most code and tool use will be efficient enough. ---unsnip-- Clark, I'll concede PART of the validity of your point. Consider the following example: Program before checks BEGIN LOOP. OPEN DB FOR UPDATE. UPDATE DB RECORD.(s) CLOSE DB. END LOOP. Run time averaged 300-330 minutes. Program after checks and changes: OPEN DB FOR UPDATE. BEGIN LOOP. UPDATE DB RECORD(s) END LOOP. CLOSE DB. Run time now 20-25 minutes. It's ok to generalize and say that most time is spent in non-user-written code, but abuse of that code can also be incredibly damaging. Badly written code by a shop's programming staff can lead to terrible performance just as easily as badly written IBM or OEM code. I saw a program with VSAM code like that. If the program had been on a critical path I would have pushed for rewriting it. Forgetting the BLOCK CONTAINS 0 clause on output non-VSAM could also do wonderful things. A good set of guidelines and minimal code review should have caught both cases. Not that I ever wrote dumb code. G D R Clark This example was drawn from actual experience; I can still name the programmer, even though he's now retired. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Percentage of code executed that is user written was Re: Delete all members of a PDS that is allocated
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Friday, June 25, 2010 7:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Percentage of code executed that is user written was Re: Delete all members of a PDS that is allocated It's ok to generalize and say that most time is spent in non-user-written code, but abuse of that code can also be incredibly damaging. That has been my point all along! The bad code does what it does, but it's what it does. I said 5%, which may be wrong, exagerated, and empirical, but the algorithm is key. And, a bad one in assembler can cost more than the best in COBOL. Agreed, BUT... There ARE still peephole optimizations to algorithms (COBOL, HLASM, etc. take your pick) that are necessary because the hardware itself does some things very slowly. Prime example: MVCL (and CLCL too) instructions used by HLASM programmers or generated by COBOL compilers are terribly slow. The bigger the area moved or compared the slower they are. Changing the algorithm to use the language-specific equivalent of QSAM GET-Locate mode as opposed to GET-Move mode yields tremendous reductions in CPU time consumed by user-written code (NO system services involved, unless you consider the hardware instructions system code). In COBOL for instance, using a file-section record definition as opposed to a working-storage-section definition avoids READ ... INTO and the cost of the MVCL to implement the INTO (I am assuming large data records here). In HLASM you would use DCB MACRF=GL and use the pointer returned by the GET as opposed to using DCB MACRF=GM. Being aware of the hot spots (high CPU usage) in the hardware *and* in the system software means you can avoid writing bad code or correct bad code that has already been written. Attention to details like this (and some similar optimizations) saved one application I have worked on almost 50% of its previous CPU utilization without changing the application algorithm in any other way. It might or might not be only 5% user/programmer code burning those CPU seconds, but paying close attention to optimizing the code that implements the application algorithm DOES save significant CPU time. Your point that the language used for that 5% doesn't matter is only partly true, IMHO. Knowing how to optimize the language that you or your management chose and knowing the hot spots to avoid helps avoid writing or correct bad code no matter the language used. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Percentage of code executed that is user written was Re: Delete all members of a PDS that is allocated
Your point that the language used for that 5% doesn't matter is only partly true, IMHO. Knowing how to optimize the language that you or your management chose and knowing the hot spots to avoid helps avoid writing or correct bad code no matter the language used. Algorithms! Algorithms! Bad code is bad code and good code is good code. But, in z/OS, when I've written bad code, I'm invoking ISV/IBM code, inefficiently. When I've written good code, I've invoked the other stuff efficiently. HLASM or COBOL really doesn't matter. That's just an implementation detail. It's only hot if you're calling services excessively. Even interest calculations call vendor code, even if it's just linkage to LE, which you didn't write. I'm not saying that that 5% is trivial, but it only does business logic, as important as that is. But, everything else is vendor code. READ. PROCESS. WRITE. Plus initiation, allocate, open, close, de-allocate and terminate. Only one section is written by the user. The rest may seem like the user wrote it, but how much system code is invoked by a simple open statement? Take care of your algorithms, and the language will tend to become secondary. The optimum language will be the one that your staff knows. And, before it's said, are languages like JAVA, or SAS, inefficient, or are their runtime environments? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
In a message dated 6/25/2010 5:31:07 P.M. Central Daylight Time, rfocht...@ync.net writes: with Bruce Leland, the original author, for about 25 years. Author(s) Mike Smith and Bruce Leland. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
If the existing program does a reset, it probably rewrites the directory and resets the LSTAR to make it look empty. This would be very efficient. If there are many members, any method, even in assembler, that deletes members one at a time, will potentially suck performace-wise. Date: Wed, 23 Jun 2010 23:54:58 -0400 From: choelsc...@humana.com Subject: Re: Delete all members of a PDS that is allocated To: IBM-MAIN@bama.ua.edu 1) execute IEHLIST to produce list of members 2) use any report writer to parse output and create appropriate input to ... 3) IEHPROGM to delete members 4) IEBCOPY lib to itself to clean up directory Chris Hoelscher IDMS/DB2 System Database Architect Humana Inc 502-476-2538 choelsc...@humana.com you only need to test the programs that you want to work correctly From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@bama.ua.edu Date: 06/23/2010 08:47 PM Subject: Re: [IBM-MAIN] Delete all members of a PDS that is allocated Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu It is going to depend. You can write a REXX that uses the LM functions to delete a member. If you have PDSMAN with FASTCOPY you can ZERODIR. If you have SAS you can KILL a pds. And I am sure there are other ways. The requirement is that the dataset is enqueued with DISP=SHR and that the SCHEDULER does not try to load from it when you are emptying it. Lizette Does anyone know of a way to delete all of the members of a PDS which is allocated by job scheduler software? We currently use an assembler program that does a reset(I think), but management wants us to not use assembler. I know that IEHPROGM can delete a specific member, but the members change from day to day. I don't think you can wild card it. TIA _ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
File 182 on your CBT dial. The PDS command. Regards, John K gsg of the IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote: Does anyone know of a way to delete all of the members of a PDS which is allocated by job scheduler software? We currently use an assembler program that does a reset(I think), but management wants us to not use assembler. I know that IEHPROGM can delete a specific member, but the members change from day to day. I don't think you can wild card it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Wednesday, June 23, 2010 11:58 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated but management wants us to not use assembler. I'm sorry, but I have to chime in. If your staff knows how to use a tool, why should management care? Management assigns tasks, NOT how-to! - Too busy driving to stop for gas! In general, I agree, but management must also be concerned with maintainability. The perceived decrease in HLASM programming skills have likely made management do one of its infamous one size fits all commands. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On Wed, 23 Jun 2010 20:01:57 -0500, gsg gsg_...@yahoo.com wrote: Thanks Lizette. We don't have PDSMAN or SAS. I know how to spell REXX and play around a little, but probably can't write a routine that will give me the results that I want. Is PDSMAN similar to Startools? We do have that product. Someone already mentioned DEL A:Z.An easier way with PDS (PSD86) or Startool is just DEL :. However, this doesn't free any of the space for a PDS and you would have to compress the library. The thing you want to do with PDS / Startool is use the FIX RESET command. This empties the PDS / PDSE. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Management assigns tasks, NOT how-to! Maybe where YOU live. Correction: GOOD Management assigns tasks, NOT how-to! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
You also do a 3.4 and enter S * DEL on the command line to delete everything. Thanks Ms. Terri E. Shaffer terri.e.shaf...@jpmchase.com Engineer J.P.Morgan Chase Co. GTI DCT ECS Core Services zSoftware Group / Emerging Technologies Office: # 614-213-3467 Cell: # 412-519-2592 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Thursday, June 24, 2010 9:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated On Wed, 23 Jun 2010 20:01:57 -0500, gsg gsg_...@yahoo.com wrote: Thanks Lizette. We don't have PDSMAN or SAS. I know how to spell REXX and play around a little, but probably can't write a routine that will give me the results that I want. Is PDSMAN similar to Startools? We do have that product. Someone already mentioned DEL A:Z.An easier way with PDS (PSD86) or Startool is just DEL :. However, this doesn't free any of the space for a PDS and you would have to compress the library. The thing you want to do with PDS / Startool is use the FIX RESET command. This empties the PDS / PDSE. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Thanks Terri! Just tried it. Didn't know about that one. Dave _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Terri E Shaffer Sent: Thursday, June 24, 2010 9:59 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated You also do a 3.4 and enter S * DEL on the command line to delete everything. Thanks Ms. Terri E. Shaffer terri.e.shaf...@jpmchase.com Engineer J.P.Morgan Chase Co. GTI DCT ECS Core Services zSoftware Group / Emerging Technologies Office: # 614-213-3467 Cell: # 412-519-2592 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Glad to see the correction. I thought we had another one of those Canada/U.S. translation issues. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, June 24, 2010 8:58 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Delete all members of a PDS that is allocated Management assigns tasks, NOT how-to! Maybe where YOU live. Correction: GOOD Management assigns tasks, NOT how-to! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Attention: The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. (GWCC) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On 23 Jun 2010 17:39:54 -0700, gsg_...@yahoo.com (gsg) wrote: Does anyone know of a way to delete all of the members of a PDS which is allocated by job scheduler software? We currently use an assembler program that does a reset(I think), but management wants us to not use assembler. I know that IEHPROGM can delete a specific member, but the members change from day to day. I don't think you can wild card it. Do you need it compressed as well? I'm wondering if you should consider deleting and re-creating the PDS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
/* REXX */ /* from http://www.mainframesupport.dk/tips/tip0344.html */ /* DELETE ALL MEMBERS OF A GIVEN LIBRARY DSN */ TRACE 'N' /* TRACE 'R' */ /* TRACE 'O' */ PARSE UPPER ARG DSNAME DSN = STRIP(DSNAME, 'BOTH', ) /* IN CASE IT'S IN QUOTES */ QUOTE = ' QDSN = QUOTE||DSN||QUOTE /* FULLY QUOTED DSN */ ADDRESS ISPEXEC LMINIT DATAID( MYDATAID) DATASET( QDSN ) ENQ(SHRW) LMOPEN DATAID(MYDATAID) OPTION(OUTPUT) LMMDEL DATAID(MYDATAID) MEMBER(*) LMCLOSE DATAID(MYDATAID) LMFREE DATAID(MYDATAID) SAY DSN IS NOW EMPTY EXIT On Wed, 23 Jun 2010 19:37:40 -0500, gsg gsg_...@yahoo.com wrote: Does anyone know of a way to delete all of the members of a PDS which is allocated by job scheduler software? We currently use an assembler program that does a reset(I think), but management wants us to not use assembler. I know that IEHPROGM can delete a specific member, but the members change from day to day. I don't think you can wild card it. TIA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On 24 Jun 2010 07:00:44 -0700, terri.e.shaf...@jpmchase.com (Terri E Shaffer) wrote: You also do a 3.4 and enter S * DEL on the command line to delete everything. Interesting. I entered HELP there and got: HELP NOT AVAILABLE+ LIST OF COMMANDS NOT FOUND How can I get a list of such commands? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
Howard Brazee wrote: On 24 Jun 2010 07:00:44 -0700, terri.e.shaf...@jpmchase.com (Terri E Shaffer) wrote: You also do a 3.4 and enter S * DEL on the command line to delete everything. Interesting. I entered HELP there and got: HELP NOT AVAILABLE+ LIST OF COMMANDS NOT FOUND How can I get a list of such commands? Howard, Where exactly where you when you entered HELP? If you get into a member list of a library, then go to the action bar and select HELP, the drop down list shows: __ 1. Workplace General 2. Library/DSLIST General 3. Scrolling 4. Pattern matching 5. LOCATE command 6. SORT command 7. SAVE command 8. RESET command 9. SELECT command 10. MLC command 11. MLS command 12. S line command 13. Statistics 14. Appendices 15. Index Then option 9 takes you to a tutorial on SELECT as a primary command, which includes using wildcards and so on. HTH. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
On 24 Jun 2010 10:30:24 -0700, st...@trainersfriend.com (Steve Comstock) wrote: Howard Brazee wrote: On 24 Jun 2010 07:00:44 -0700, terri.e.shaf...@jpmchase.com (Terri E Shaffer) wrote: You also do a 3.4 and enter S * DEL on the command line to delete everything. Interesting. I entered HELP there and got: HELP NOT AVAILABLE+ LIST OF COMMANDS NOT FOUND How can I get a list of such commands? Howard, Where exactly where you when you entered HELP? If you get into a member list of a library, then go to the action bar and select HELP, the drop down list shows: Several places. That error was caused by entering HELP to the left of a particular PDS. I also tried it in the command line and got normal help menus, but not the one you show below. I did look through line commands from there, but I did not see anything close to: S * DEL Is the action bar the menu they added a few years back that everybody I knew turned off? Maybe I need to turn it on to get to the help that would include your command. __ 1. Workplace General 2. Library/DSLIST General 3. Scrolling 4. Pattern matching 5. LOCATE command 6. SORT command 7. SAVE command 8. RESET command 9. SELECT command 10. MLC command 11. MLS command 12. S line command 13. Statistics 14. Appendices 15. Index Then option 9 takes you to a tutorial on SELECT as a primary command, which includes using wildcards and so on. HTH. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
---snip If the existing program does a reset, it probably rewrites the directory and resets the LSTAR to make it look empty. This would be very efficient. If there are many members, any method, even in assembler, that deletes members one at a time, will potentially suck performace-wise. unsnip-- That performance can be considerably improved if you delete the members in descending sequence, from back to front of the useddirectory space Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Delete all members of a PDS that is allocated
--snip--- but management wants us to not use assembler. I'm sorry, but I have to chime in. If your staff knows how to use a tool, why should management care? Management assigns tasks, NOT how-to! - Too busy driving to stop for gas! In general, I agree, but management must also be concerned with maintainability. The perceived decrease in HLASM programming skills have likely made management do one of its infamous one size fits all commands. -unsnip--- That's probably true, but a tool of this nature should be simple enough that even a COBOL programmer should be able to understand the code. :-) Assuming he has an IQ above room temperature! Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Delete all members of a PDS that is allocated
Does anyone know of a way to delete all of the members of a PDS which is allocated by job scheduler software? We currently use an assembler program that does a reset(I think), but management wants us to not use assembler. I know that IEHPROGM can delete a specific member, but the members change from day to day. I don't think you can wild card it. TIA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
