Re: SCRT Question -- Group in =P5==
Thank you. I'll look them up. Meanwhile, at this shop, I have no idea who runs the SCRT report. I just know which network drive and folder to find it. Regards, Steve Thompson On 11/16/21 10:09 AM, Edward King wrote: Hi Steve, ...[I] am trying to figure out what is meant in the SCRT "P5" section (Product Max Contributors) *when* the entry for z/OS V2 shows each LPAR of the CEC (running z/OS and part of the same group) all have 0 for MSUs and then the GROUP entry (line total area) has 1500 (example). I also have line items for CICS, and others as well that also under GROUP have 1500. This means that the sum of the LPARs' 4HRA has exceeded the defined capacity of the group. In this case, SCRT has enforced the group capacity limit and the contribution to the product's sub-capacity value comes from the group limit rather than the individual LPARs. Example: LPARA and LPARB are in GROUP1. LPARA's 4HRA value in the hour is 100 MSU. LPARB's 4HRA value in the hour is 105 MSU. GROUP1 capacity is 200 MSU. The effective 4HRA for products running on LPARA and LPARB is reported as 200 MSU (the group limit) rather than 205 MSU (the sum of the individual LPARs). If LPARC were also active at 50 MSU, but not part of GROUP1, the 4HRA would be reported as 250 MSU (the sum of GROUP1 and LPARC). How do I find what the MSU value should be for each of these LPARs or are they group capped to 1500, and that is my total? If you need the individual LPAR values prior to the cap being enforced, you can generate detailed data section V5 (or W3 in a Country Multiplex or Enterprise Tailored Fit report) by specifying the GENERATE_DETAILED_DATA control statement in the SPECIAL DD of the SCRT job. In the V5/W3 section, find the row corresponding to the peak hour and look for the LPAR columns you care about. The notation is "G(xxx)" where G indicates that the group capacity limit was enforced and xxx is the LPAR's original value before enforcement. Otherwise, who do you call at IBM that could even answer this question? You can open a Case through the usual service process. Regards, Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT Question -- Group in =P5==
Hi Steve, >> ...[I] am trying to figure out what >> is meant in the SCRT "P5" section (Product Max Contributors) >> *when* the entry for z/OS V2 shows each LPAR of the CEC (running >> z/OS and part of the same group) all have 0 for MSUs and then the >> GROUP entry (line total area) has 1500 (example). I also have >> line items for CICS, and others as well that also under GROUP >> have 1500. This means that the sum of the LPARs' 4HRA has exceeded the defined capacity of the group. In this case, SCRT has enforced the group capacity limit and the contribution to the product's sub-capacity value comes from the group limit rather than the individual LPARs. Example: LPARA and LPARB are in GROUP1. LPARA's 4HRA value in the hour is 100 MSU. LPARB's 4HRA value in the hour is 105 MSU. GROUP1 capacity is 200 MSU. The effective 4HRA for products running on LPARA and LPARB is reported as 200 MSU (the group limit) rather than 205 MSU (the sum of the individual LPARs). If LPARC were also active at 50 MSU, but not part of GROUP1, the 4HRA would be reported as 250 MSU (the sum of GROUP1 and LPARC). >> How do I find what the MSU value should be for each of these >> LPARs or are they group capped to 1500, and that is my total? If you need the individual LPAR values prior to the cap being enforced, you can generate detailed data section V5 (or W3 in a Country Multiplex or Enterprise Tailored Fit report) by specifying the GENERATE_DETAILED_DATA control statement in the SPECIAL DD of the SCRT job. In the V5/W3 section, find the row corresponding to the peak hour and look for the LPAR columns you care about. The notation is "G(xxx)" where G indicates that the group capacity limit was enforced and xxx is the LPAR's original value before enforcement. >> Otherwise, who do you call at IBM that could even answer this >> question? You can open a Case through the usual service process. Regards, Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT Question -- Group in =P5==
Glad I could be of some help. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of ste...@copper.net Sent: Monday, November 15, 2021 3:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT Question -- Group in =P5== Bob: Thank you for that tip. After checking a few things, I found that that number in col C is probably what those LPARs would have added up to in that line after double-checking this against the other two P5 sections where capping took place after the first hour past IPL. So it appears that the small LPARs that use single digit MSUs (not production systems at all, and not part of the LPAR Grouping) get subtracted and that will correct the col C number to what it should have been. And no, not all the P5 sections have 1500 in Col C. Just this one CEC was different and think I know why -- It was doing recovery so it did not have normal capping working in the first hour after the IPL. Regards, Steve Thompson --- 01c91f408b9e-dmarc-requ...@listserv.ua.edu wrote: From: "Richards, Robert B. (CTR)" <01c91f408b9e-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] SCRT Question -- Group in =P5== Date: Mon, 15 Nov 2021 19:05:38 + Steve, What does Column C have in each of these P5 sections? I suspect it may have "1500". Even if it doesn't, use the value that is there for each z/OS P5 segment and add them up. For z/OS in that other spreadsheet, they probably want Column C's value for z/OS in each P5 segment placed in that other cell. If you are unsure, call the ISV for clarification as it is their rules, not IBM's, that you are trying to satisfy. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Thompson Sent: Monday, November 15, 2021 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SCRT Question -- Group in =P5== I am having a headache with SCRT (SCRT 28.2, SC23-6845-19 is the manual I have). Background -- I got moved to the z/VM side of the house doing Capacity Management and Planning so I've mostly been gone from z/OS for a while. I had already been doing true-ups for other ISVs, and so when someone retired, I ended up with this one, which is done very differently than the others. And I didn't get a lot of turn-over for this. I'm going to make this as simple as I can, because we have multiple CECs and multiple groups and multiple "P5" sections, so this gets complicated (besides IBM having to mix in VSE LPARs and VM LPARs and z/OS running under z/VM, etc. just to make this whole thing about as clear a mud). I am working on as ISV "true-up" and am trying to figure out what is meant in the SCRT "P5" section (Product Max Contributors) *when* the entry for z/OS V2 shows each LPAR of the CEC (running z/OS and part of the same group) all have 0 for MSUs and then the GROUP entry (line total area) has 1500 (example). I also have line items for CICS, and others as well that also under GROUP have 1500. What this particular vendor wants is the numbers for the z/OS V2 LPARs combined and put in a cell of another spreadsheet. Up until now, the end of month (which we do at QTR end) has numbers in the columns for each LPAR. So I take those add them and put them in this other spreadsheet. Simple. Tedious, but simple. This is the exception, and it appears this is because the system missed capping in the first hour (I think that is what the manual said/and meant -- my eyes glazed over a few times while reading through all of this, this morning. How do I find what the MSU value should be for each of these LPARs or are they group capped to 1500, and that is my total? Otherwise, who do you call at IBM that could even answer this question? I think I would rather read the instructions for F1040 and do it all by hand (Base form for Personal Income tax for USofA). And for those of you who demand details -- I'm not allowed to do that. I'm pushing it just by asking this with faked numbers. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT Question -- Group in =P5==
Bob: Thank you for that tip. After checking a few things, I found that that number in col C is probably what those LPARs would have added up to in that line after double-checking this against the other two P5 sections where capping took place after the first hour past IPL. So it appears that the small LPARs that use single digit MSUs (not production systems at all, and not part of the LPAR Grouping) get subtracted and that will correct the col C number to what it should have been. And no, not all the P5 sections have 1500 in Col C. Just this one CEC was different and think I know why -- It was doing recovery so it did not have normal capping working in the first hour after the IPL. Regards, Steve Thompson --- 01c91f408b9e-dmarc-requ...@listserv.ua.edu wrote: From: "Richards, Robert B. (CTR)" <01c91f408b9e-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] SCRT Question -- Group in =P5== Date: Mon, 15 Nov 2021 19:05:38 + Steve, What does Column C have in each of these P5 sections? I suspect it may have "1500". Even if it doesn't, use the value that is there for each z/OS P5 segment and add them up. For z/OS in that other spreadsheet, they probably want Column C's value for z/OS in each P5 segment placed in that other cell. If you are unsure, call the ISV for clarification as it is their rules, not IBM's, that you are trying to satisfy. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Thompson Sent: Monday, November 15, 2021 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SCRT Question -- Group in =P5== I am having a headache with SCRT (SCRT 28.2, SC23-6845-19 is the manual I have). Background -- I got moved to the z/VM side of the house doing Capacity Management and Planning so I've mostly been gone from z/OS for a while. I had already been doing true-ups for other ISVs, and so when someone retired, I ended up with this one, which is done very differently than the others. And I didn't get a lot of turn-over for this. I'm going to make this as simple as I can, because we have multiple CECs and multiple groups and multiple "P5" sections, so this gets complicated (besides IBM having to mix in VSE LPARs and VM LPARs and z/OS running under z/VM, etc. just to make this whole thing about as clear a mud). I am working on as ISV "true-up" and am trying to figure out what is meant in the SCRT "P5" section (Product Max Contributors) *when* the entry for z/OS V2 shows each LPAR of the CEC (running z/OS and part of the same group) all have 0 for MSUs and then the GROUP entry (line total area) has 1500 (example). I also have line items for CICS, and others as well that also under GROUP have 1500. What this particular vendor wants is the numbers for the z/OS V2 LPARs combined and put in a cell of another spreadsheet. Up until now, the end of month (which we do at QTR end) has numbers in the columns for each LPAR. So I take those add them and put them in this other spreadsheet. Simple. Tedious, but simple. This is the exception, and it appears this is because the system missed capping in the first hour (I think that is what the manual said/and meant -- my eyes glazed over a few times while reading through all of this, this morning. How do I find what the MSU value should be for each of these LPARs or are they group capped to 1500, and that is my total? Otherwise, who do you call at IBM that could even answer this question? I think I would rather read the instructions for F1040 and do it all by hand (Base form for Personal Income tax for USofA). And for those of you who demand details -- I'm not allowed to do that. I'm pushing it just by asking this with faked numbers. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT Question -- Group in =P5==
Steve, What does Column C have in each of these P5 sections? I suspect it may have "1500". Even if it doesn't, use the value that is there for each z/OS P5 segment and add them up. For z/OS in that other spreadsheet, they probably want Column C's value for z/OS in each P5 segment placed in that other cell. If you are unsure, call the ISV for clarification as it is their rules, not IBM's, that you are trying to satisfy. Bob -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Thompson Sent: Monday, November 15, 2021 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SCRT Question -- Group in =P5== I am having a headache with SCRT (SCRT 28.2, SC23-6845-19 is the manual I have). Background -- I got moved to the z/VM side of the house doing Capacity Management and Planning so I've mostly been gone from z/OS for a while. I had already been doing true-ups for other ISVs, and so when someone retired, I ended up with this one, which is done very differently than the others. And I didn't get a lot of turn-over for this. I'm going to make this as simple as I can, because we have multiple CECs and multiple groups and multiple "P5" sections, so this gets complicated (besides IBM having to mix in VSE LPARs and VM LPARs and z/OS running under z/VM, etc. just to make this whole thing about as clear a mud). I am working on as ISV "true-up" and am trying to figure out what is meant in the SCRT "P5" section (Product Max Contributors) *when* the entry for z/OS V2 shows each LPAR of the CEC (running z/OS and part of the same group) all have 0 for MSUs and then the GROUP entry (line total area) has 1500 (example). I also have line items for CICS, and others as well that also under GROUP have 1500. What this particular vendor wants is the numbers for the z/OS V2 LPARs combined and put in a cell of another spreadsheet. Up until now, the end of month (which we do at QTR end) has numbers in the columns for each LPAR. So I take those add them and put them in this other spreadsheet. Simple. Tedious, but simple. This is the exception, and it appears this is because the system missed capping in the first hour (I think that is what the manual said/and meant -- my eyes glazed over a few times while reading through all of this, this morning. How do I find what the MSU value should be for each of these LPARs or are they group capped to 1500, and that is my total? Otherwise, who do you call at IBM that could even answer this question? I think I would rather read the instructions for F1040 and do it all by hand (Base form for Personal Income tax for USofA). And for those of you who demand details -- I'm not allowed to do that. I'm pushing it just by asking this with faked numbers. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
In 4473679277803350.wa.paulgboulderaim@listserv.ua.edu, on 08/25/2013 at 01:39 PM, Paul Gilmartin paulgboul...@aim.com said: Small wonder old-timers resent the advent of PDSE. Some do. Some believe that IBM didn't go far enough. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
On 8/27/2013 8:43 AM, Paul Gilmartin wrote: And PDSE might have been a good place to introduce (optional) FBA support. PDSE is really just FBA simulated on CKD simulated on FBA. If you defined CKD as devices accepting count-field oriented commands, then you are correct. However, all disks I've looked at (not all that many), have a count field preceding the data, hidden by the firmware, so you could add an extra overlaid on CKD to that. And why are member primary names still restricted to 8 characters!? At the time, it was a critical decision leading to easier acceptance. I recall many people who had to be dragged, kicking and screaming, into using PDSEs at all. Perhaps a compromise would allow for an option on OPEN (?) to support an extension, but what business case could you make to IBM to support the change? Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
On 8/27/2013 8:26 AM, Shmuel Metz (Seymour J.) wrote: Small wonder old-timers resent the advent of PDSE. Some do. Some believe that IBM didn't go far enough. What I miss most is the inability to recover erroneously scratched members. More than once I have recovered a member that was too new to be on a backup, or where it was faster to run the recovery than a restore. VSAM keeps chains of free blocks, and an option of queueing released blocks at the end of that chain would have preserved that, at possible cost (then) of performance. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
W dniu 2013-08-27 15:41, Gerhard Postpischil pisze: On 8/27/2013 8:43 AM, Paul Gilmartin wrote: And PDSE might have been a good place to introduce (optional) FBA support. PDSE is really just FBA simulated on CKD simulated on FBA. If you defined CKD as devices accepting count-field oriented commands, then you are correct. However, all disks I've looked at (not all that many), have a count field preceding the data, hidden by the firmware, so you could add an extra overlaid on CKD to that. Well, don't take those names literally. In the very old days CKD became ECKD, but the name CKD remain as simple distintcion from FBA disks. BTW: In FBA world ther is some hidden field to every block (sector), but it's neither count, nor it is called such. Last, but not least: CKD could be understood as VBA - VARIABLE Block Architecture. IMHO it's easier to talk about mainframe disks and open (distributed) system disks. And why are member primary names still restricted to 8 characters!? At the time, it was a critical decision leading to easier acceptance. I recall many people who had to be dragged, kicking and screaming, into using PDSEs at all. Perhaps a compromise would allow for an option on OPEN (?) to support an extension, but what business case could you make to IBM to support the change? At the time... PDSE is approx 20 years old. It's quite enough time to create new filesystem from scratch or enhance some features of existing operating system. I remember DOS+Windows 3.1 and see what could be done those years. Not to mention Linux (apperance), Netware, VMS (disapperance for last two entries). -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
R.S. wrote: snip Well, don't take those names literally. In the very old days CKD became ECKD, but the name CKD remain as simple distintcion from FBA disks. snip It's sometimes useful to differentiate between CKD the track format (Count, Key, and Data), and the original set of CKD disk channel commands. ECKD identifies extensions only to the CKD command set; the CKD track format itself is the same. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
W dniu 2013-08-27 21:30, John Eells pisze: R.S. wrote: snip Well, don't take those names literally. In the very old days CKD became ECKD, but the name CKD remain as simple distintcion from FBA disks. snip It's sometimes useful to differentiate between CKD the track format (Count, Key, and Data), and the original set of CKD disk channel commands. ECKD identifies extensions only to the CKD command set; the CKD track format itself is the same. Not to mention that K of CKD almost became extinct, since it lives only as part of VTOC or PDS directory (did I miss something?), so the track format is usually C-D. ;-) -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
In 2436150148124474.wa.paulgboulderaim@listserv.ua.edu, on 08/27/2013 at 07:43 AM, Paul Gilmartin paulgboul...@aim.com said: Would you be thinking of multi-volume? I was thinking of an equivalent to QPAM in TSS, but using an ACB interface and an RCI for PDS. And PDSE might have been a good place to introduce (optional) FBA support. VSAM would have been a better time and place, with an RCI for DCB access. And why are member primary names still restricted to 8 characters!? Lack of a business case? Lack of foresight? Understaffing? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
On 8/27/2013 3:37 PM, R.S. wrote: Not to mention that K of CKD almost became extinct, since it lives only as part of VTOC or PDS directory (did I miss something?), so the track format is usually C-D. ;-) You mean nobody uses BDAM or ISAM any more? g And I almost miss the Search Key and Data CCW. On 3330s and earlier (or 3350 and earlier on Memorex) one could use a search command for data, and use x'FF' as a don't care byte. Just for fun (i.e., educational purposes), I wrote a quick EDIT program that used unblocked records, and searched on column 73-80; it was horribly inefficient, tied up the channel, and was useless for practical applications. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
On 8/27/2013 2:39 PM, R.S. wrote: At the time... PDSE is approx 20 years old. It's quite enough time to create new filesystem from scratch or enhance some features of existing operating system. I remember DOS+Windows 3.1 and see what could be done those years. Not to mention Linux (apperance), Netware, VMS (disapperance for last two entries). zOS still has a lot number of components twice that age, but that doesn't mean that they are obsolete (quite a number of list members are older g). IBM offers new products and major upgrades only when it anticipates getting new business, retaining large customers, or getting an edge over the competition. It might be easier to persuade an IVP, or even a skilled individual, to build something. For example, I could build a VSAM file, assign an 8-byte generated value to 1024-byte keys, and provide a front end to PDSE services. With a good interface, this could be almost transparent to prospective users. Don't get me started on DOS and Windows. Microsoft appears to have adopted the paradigm of selling software mainly by issuing incompatible versions every year or so, forcing users to upgrade everything. IBM at least tries to preserve compatibility. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
My apologies for not responding sooner. Extended weekend. I was upating a current production batch job that generates the SCRT and FTPs the report to a Windows Server. I decided to change the Windows Server to a DFS server. I just had sideblinders on and focused on the FTP step. When someone mentioned OCOPY, the light bulb went on. I dropped the FTP step. Replaced it with BATCH TMP with the necessary commands for the directories, allocations and OCOPY invocation. The solution is now in place. Thanks for the suggestion. Worked like a charm. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
On 8/24/2013 10:06 AM, John Gilmore wrote: A preoccupation with having a first PDS member begin on a notional track boundary of an emulated device strikes me as misplaced, even bizarre; but it would be my guess that it is also benign. I agree, but only when it comes to general considerations (see below). To take it seriously for the moment, It is achievable by calculating the number D of directory blocks that fit on an emulated 3390 track and then always allocating some integral multiple of D directory blocks. (This calculation is trivial, but I have suppressed its result here to avoid encouraging its misuse.) This is far from trivial. I just ran some tests, and an allocation of the number of directory blocks you posit, on a 3390, will place the directory EOF block on the next track. There were some device types where there was enough space on a track to place the EOF, but on the 3390 there isn't, and if you change the allocation to one block less, there is not only room for the EOF, but possibly also a (small) block of the first member. I do not myself think initial-member track alignment should be sought. What was perhaps optimal for a spinning physical 3390 DASD will only adventitiously be optimal or even appropriate for an emulated one. Modern controllers I'm familiar with operate on a track basis, whatever the hardware or firmware does internally. It is therefore plausible than I/O for data that will fit on a single track will be faster than if the same data were split between tracks. There may be extremely critical (e.g., real-time) systems for which such placement considerations are anything but bizarre. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
On Sun, 25 Aug 2013 13:17:21 -0400, Gerhard Postpischil wrote: On 8/24/2013 10:06 AM, John Gilmore wrote: A preoccupation with having a first PDS member begin on a notional track boundary of an emulated device strikes me as misplaced, even bizarre; but it would be my guess that it is also benign. Benign except for being a waste of developer time, But, hey, that's what happens here. (This calculation is trivial, but I have suppressed its result here to avoid encouraging its misuse.) (There's a table in the Reference Manual.) This is far from trivial. I just ran some tests, and an allocation of the number of directory blocks you posit, on a 3390, will place the directory EOF block on the next track. There were some device types where there was enough space on a track to place the EOF, but on the 3390 there isn't, and if you change the allocation to one block less, there is not only room for the EOF, but possibly also a (small) block of the first member. Your experiment discovers the geometry. Have you evaluated the difference in performance? You might consider creating a dummy member so the first real member begins on a track boundary. In fact you might consider doing so for each interval between members. But if the first member begins (or is fully contained) in the track containing the directory, doesn't it save the expense of repositioning the heads between the BLDL and the READ? PDSE, with its undisclosed data format renders all this exercise pointless. Small wonder old-timers resent the advent of PDSE. (is it still Friday?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
It's not a waste of time once you know the figures. All my 'canned' JCL has had the corresponding directory blocks for years. I may have mis-stated the exact number of corresponding blocks to fill the first block, incorrectly. But, my points were: 1. I'm anal enough to care. 2. 15 blocks are not too many. But, teto! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Paul Gilmartin paulgboul...@aim.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Sun, 25 Aug 2013 13:39:42 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT question On Sun, 25 Aug 2013 13:17:21 -0400, Gerhard Postpischil wrote: On 8/24/2013 10:06 AM, John Gilmore wrote: A preoccupation with having a first PDS member begin on a notional track boundary of an emulated device strikes me as misplaced, even bizarre; but it would be my guess that it is also benign. Benign except for being a waste of developer time, But, hey, that's what happens here. (This calculation is trivial, but I have suppressed its result here to avoid encouraging its misuse.) (There's a table in the Reference Manual.) This is far from trivial. I just ran some tests, and an allocation of the number of directory blocks you posit, on a 3390, will place the directory EOF block on the next track. There were some device types where there was enough space on a track to place the EOF, but on the 3390 there isn't, and if you change the allocation to one block less, there is not only room for the EOF, but possibly also a (small) block of the first member. Your experiment discovers the geometry. Have you evaluated the difference in performance? You might consider creating a dummy member so the first real member begins on a track boundary. In fact you might consider doing so for each interval between members. But if the first member begins (or is fully contained) in the track containing the directory, doesn't it save the expense of repositioning the heads between the BLDL and the READ? PDSE, with its undisclosed data format renders all this exercise pointless. Small wonder old-timers resent the advent of PDSE. (is it still Friday?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
Gerhard, Your arguments would be/are persuasive for a real, spinning DASD. On an emulated one they are not. What, for example, does 'track oriented' mean when the underlying architecture is FBA? When the underlying architecture is random-access storage? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
On emulated DASD, I/O is almost always an entire track at a time. On Sun, Aug 25, 2013 at 3:25 PM, John Gilmore jwgli...@gmail.com wrote: Gerhard, Your arguments would be/are persuasive for a real, spinning DASD. On an emulated one they are not. What, for example, does 'track oriented' mean when the underlying architecture is FBA? When the underlying architecture is random-access storage? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
Yes, physical I/O internally within the DASD subsystem would likely be at least full track I/O or even multi-track. However, physical I/O over the channel will still be based on the z/OS perception that the devices behind the controller are CKD DASD, with device-specific track and cylinder structure, and channel I/O would still be at the single z/OS logical-block, C-K-D-record level if from an application that considers that the appropriate granularity of access. As long as z/OS perceives these as CKD devices with tracks and cylinders, one cannot presume that those emulated track and cylinder boundaries have no significance. z/OS still has to make decisions on how to map data to the device and how to structure channel programs for the device based on those perceived boundaries. Those decisions can still impact the amount of useful data stored per track and the overhead involved with transferring useful data over the physical channel. That said, sizing a PDS directory to end or not end at a track boundary is probably irrelevant to performance; unless one encounters a boundary-condition bug in an application that is somehow sensitive to perceived track boundaries. Joel C. Ewing On 08/25/2013 03:55 PM, Mike Schwab wrote: On emulated DASD, I/O is almost always an entire track at a time. On Sun, Aug 25, 2013 at 3:25 PM, John Gilmore jwgli...@gmail.com wrote: Gerhard, Your arguments would be/are persuasive for a real, spinning DASD. On an emulated one they are not. What, for example, does 'track oriented' mean when the underlying architecture is FBA? When the underlying architecture is random-access storage? John Gilmore, Ashland, MA 01721 - USA -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
Where's Shai Hess in our time of need? Tony's iPhone (with toy keyboard) is responsible for this Email. Please do not snicker. On Aug 25, 2013, at 8:25 PM, Joel C. Ewing jcew...@acm.org wrote: Yes, physical I/O internally within the DASD subsystem would likely be at least full track I/O or even multi-track. However, physical I/O over the channel will still be based on the z/OS perception that the devices behind the controller are CKD DASD, with device-specific track and cylinder structure, and channel I/O would still be at the single z/OS logical-block, C-K-D-record level if from an application that considers that the appropriate granularity of access. As long as z/OS perceives these as CKD devices with tracks and cylinders, one cannot presume that those emulated track and cylinder boundaries have no significance. z/OS still has to make decisions on how to map data to the device and how to structure channel programs for the device based on those perceived boundaries. Those decisions can still impact the amount of useful data stored per track and the overhead involved with transferring useful data over the physical channel. That said, sizing a PDS directory to end or not end at a track boundary is probably irrelevant to performance; unless one encounters a boundary-condition bug in an application that is somehow sensitive to perceived track boundaries. Joel C. Ewing On 08/25/2013 03:55 PM, Mike Schwab wrote: On emulated DASD, I/O is almost always an entire track at a time. On Sun, Aug 25, 2013 at 3:25 PM, John Gilmore jwgli...@gmail.com wrote: Gerhard, Your arguments would be/are persuasive for a real, spinning DASD. On an emulated one they are not. What, for example, does 'track oriented' mean when the underlying architecture is FBA? When the underlying architecture is random-access storage? John Gilmore, Ashland, MA 01721 - USA -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
My point is first member does not start on track boundary. As a proof I presented some data of PDS having 1 dir block and two members. First member (actually the second member too) does not start at track boundary, because both members and directory are kept in (part of) first track. Ergo, there is no reason to take care how many dir blocks occupy exactly one member - the space between end of directory and any track boundary is used for members. -- Radoslaw Skorupka Lodz, Poland W dniu 2013-08-23 22:07, Ted MacNEIL pisze: I have NO idea what your point is! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: R.S. r.skoru...@bremultibank.com.pl Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Fri, 23 Aug 2013 20:56:52 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT question W dniu 2013-08-23 16:35, Ted MacNEIL pisze: Why overkill? 45 blocks fill a track, and I'm anal enough to like the first member to start on a track boundary. PS: I'm too anal retentive to have OCD! Wrong forum IMHO (I mean anal). Regarding meritum: It's not. Proof: Current Utilization Used tracks . . . . : 1 Used extents . . . : 1 Used dir. blocks . : 1 Number of members . : 2 The above is PDS with SPACE=(TRK,(1,1,1)) wtih two small members. -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
That is why I fill the first track with directory blocks, as I said. If there is no space on the first track, how can a member occupy any part of it? Or, did you not read my post? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: R.S. r.skoru...@bremultibank.com.pl Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Sat, 24 Aug 2013 13:28:14 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT question My point is first member does not start on track boundary. As a proof I presented some data of PDS having 1 dir block and two members. First member (actually the second member too) does not start at track boundary, because both members and directory are kept in (part of) first track. Ergo, there is no reason to take care how many dir blocks occupy exactly one member - the space between end of directory and any track boundary is used for members. -- Radoslaw Skorupka Lodz, Poland W dniu 2013-08-23 22:07, Ted MacNEIL pisze: I have NO idea what your point is! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: R.S. r.skoru...@bremultibank.com.pl Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Fri, 23 Aug 2013 20:56:52 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT question W dniu 2013-08-23 16:35, Ted MacNEIL pisze: Why overkill? 45 blocks fill a track, and I'm anal enough to like the first member to start on a track boundary. PS: I'm too anal retentive to have OCD! Wrong forum IMHO (I mean anal). Regarding meritum: It's not. Proof: Current Utilization Used tracks . . . . : 1 Used extents . . . : 1 Used dir. blocks . : 1 Number of members . : 2 The above is PDS with SPACE=(TRK,(1,1,1)) wtih two small members. -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
Radoslaw wins on points. A preoccupation with having a first PDS member begin on a notional track boundary of an emulated device strikes me as misplaced, even bizarre; but it would be my guess that it is also benign. To take it seriously for the moment, It is achievable by calculating the number D of directory blocks that fit on an emulated 3390 track and then always allocating some integral multiple of D directory blocks. (This calculation is trivial, but I have suppressed its result here to avoid encouraging its misuse.) I do not myself think initial-member track alignment should be sought. What was perhaps optimal for a spinning physical 3390 DASD will only adventitiously be optimal or even appropriate for an emulated one. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
In 521898ce.8020...@bremultibank.com.pl, on 08/24/2013 at 01:28 PM, R.S. r.skoru...@bremultibank.com.pl said: My point is first member does not start on track boundary. Read his message. As a proof I presented some data of PDS having 1 dir block and two members. Specifying 1 directory block proves nothing about what happens with 45 directory blocks. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
W dniu 2013-08-22 23:05, Greg Shirey pisze: The supplied JCL for SCRT contains the following: //* FOR SEQUENTIAL OUTPUT (ALL CPCS IN ONE DS) //* CHANGE SPACE PARAMETER TO SPACE=(TRK,(15,15)) //OUTPUT DDDISP=(,CATLG),DSN=HLQ.SCRTTOOL.CSV, // SPACE=(TRK,(15,15,15)),UNIT=SYSDA So, PDS is the default you could say. So? How is it related to the problem of weird file in ZFS? -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
I suppose you could use a PS dataset *if* you only were reporting on one CEC. I never been in that situation since SCRT's inception, so I haven't tried it to know for sure. 15 directory blocks seems overkill though! :-) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Thursday, August 22, 2013 5:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT question The supplied JCL for SCRT contains the following: //* FOR SEQUENTIAL OUTPUT (ALL CPCS IN ONE DS) //* CHANGE SPACE PARAMETER TO SPACE=(TRK,(15,15)) //OUTPUT DDDISP=(,CATLG),DSN=HLQ.SCRTTOOL.CSV, // SPACE=(TRK,(15,15,15)),UNIT=SYSDA So, PDS is the default you could say. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, August 22, 2013 5:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT question snip Radoslaw Skorupka pisze: SCRT report is text file, PS FB 80. snip Ok, mine is PO VB 4096, perhaps not right, but that is good enough + usable to FTP to a windoze machine ready to be picked by my browser when uploading. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
Richards, Robert B. wrote: 15 directory blocks seems overkill though! :-) Indeed! :-D Perhaps the original author of that JCL could not decide between 1 or 5, so he/she/it ends up at 15. ;-D shields on/up/activated and running far far away! Groete / Greetings Elardus Engelbrecht Friday joke: Waiter asks our land's president what he wants for lunch. I had like to have State Tender. Waiter is puzzled, Excuse me please? Sorry, I meant 'Steak, Tender' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
Why overkill? 45 blocks fill a track, and I'm anal enough to like the first member to start on a track boundary. PS: I'm too anal retentive to have OCD! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Richards, Robert B. robert.richa...@opm.gov Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Fri, 23 Aug 2013 05:21:07 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT question I suppose you could use a PS dataset *if* you only were reporting on one CEC. I never been in that situation since SCRT's inception, so I haven't tried it to know for sure. 15 directory blocks seems overkill though! :-) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: Thursday, August 22, 2013 5:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT question The supplied JCL for SCRT contains the following: //* FOR SEQUENTIAL OUTPUT (ALL CPCS IN ONE DS) //* CHANGE SPACE PARAMETER TO SPACE=(TRK,(15,15)) //OUTPUT DDDISP=(,CATLG),DSN=HLQ.SCRTTOOL.CSV, // SPACE=(TRK,(15,15,15)),UNIT=SYSDA So, PDS is the default you could say. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, August 22, 2013 5:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT question snip Radoslaw Skorupka pisze: SCRT report is text file, PS FB 80. snip Ok, mine is PO VB 4096, perhaps not right, but that is good enough + usable to FTP to a windoze machine ready to be picked by my browser when uploading. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
It is related to the comment that an SCRT report data set that is PO VB 4096 is perhaps not right. Sorry for confusing you with the topic drift. Regards, Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Friday, August 23, 2013 2:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT question So? How is it related to the problem of weird file in ZFS? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
W dniu 2013-08-23 16:35, Ted MacNEIL pisze: Why overkill? 45 blocks fill a track, and I'm anal enough to like the first member to start on a track boundary. PS: I'm too anal retentive to have OCD! Wrong forum IMHO (I mean anal). Regarding meritum: It's not. Proof: Current Utilization Used tracks . . . . : 1 Used extents . . . : 1 Used dir. blocks . : 1 Number of members . : 2 The above is PDS with SPACE=(TRK,(1,1,1)) wtih two small members. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
I have NO idea what your point is! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: R.S. r.skoru...@bremultibank.com.pl Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Fri, 23 Aug 2013 20:56:52 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT question W dniu 2013-08-23 16:35, Ted MacNEIL pisze: Why overkill? 45 blocks fill a track, and I'm anal enough to like the first member to start on a track boundary. PS: I'm too anal retentive to have OCD! Wrong forum IMHO (I mean anal). Regarding meritum: It's not. Proof: Current Utilization Used tracks . . . . : 1 Used extents . . . : 1 Used dir. blocks . : 1 Number of members . : 2 The above is PDS with SPACE=(TRK,(1,1,1)) wtih two small members. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
W dniu 2013-08-22 01:16, Mark Yuhas pisze: Has anybody successfully FTPd the SCRT report in a batch job to a zFS file? When I try it, I get a weird file. When I use a Windows, the file transfers without a problem. SCRT report is text file, PS FB 80. Such file format (and content) usually is easy to transfer/copy. What is your problem? What do you mean by weird ? Did you try to copy any other text file? -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
Mark Yuhas wrote: Has anybody successfully FTPd the SCRT report in a batch job to a zFS file? When I try it, I get a weird file. When I use a Windows, the file transfers without a problem. Show us your FTP attempt and all messages. Please define 'weird file'. Oh, please check Paul Gilmartin's post he kindly placed. But why FTP? Why not just ocopy? IEBGENER/ICEGENER? Radoslaw Skorupka pisze: SCRT report is text file, PS FB 80. Weird. ;-D But over the years, when I inhereted SCRT, the batch job generates that dataset. No DCB attributes, just let the PGM=LOADER sort out the attributes during allocation. Ok, mine is PO VB 4096, perhaps not right, but that is good enough + usable to FTP to a windoze machine ready to be picked by my browser when uploading. usually is easy to transfer/copy. Indeed. Just a quick put statement. Alternatively use ocopy/whatever in this case. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
The supplied JCL for SCRT contains the following: //* FOR SEQUENTIAL OUTPUT (ALL CPCS IN ONE DS) //* CHANGE SPACE PARAMETER TO SPACE=(TRK,(15,15)) //OUTPUT DDDISP=(,CATLG),DSN=HLQ.SCRTTOOL.CSV, // SPACE=(TRK,(15,15,15)),UNIT=SYSDA So, PDS is the default you could say. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, August 22, 2013 5:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SCRT question snip Radoslaw Skorupka pisze: SCRT report is text file, PS FB 80. snip Ok, mine is PO VB 4096, perhaps not right, but that is good enough + usable to FTP to a windoze machine ready to be picked by my browser when uploading. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
On Wed, 21 Aug 2013 23:16:17 +, Mark Yuhas wrote: Has anybody successfully FTPd the SCRT report in a batch job to a zFS file? When I try it, I get a weird file. When I use a Windows, the file transfers without a problem. People will want much more information: o What are the attributes of the SCRT report? o Was the zFS file accessed by the client or the server (and presumably the SCRT report vice-versa)? o What were the specific FTP subcommands? o Were the SCRT report and the zFS file on the same system? If so, why not use IEBGENER? o In the Windows instance, was Windows the client or the server? o What were the specific FTP subcommands transferring to Windows? o Can you be more specific about weird? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCRT question
o Were the SCRT report and the zFS file on the same system? If so, why not use IEBGENER? Or OCOPY? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
