subject:"Re\: SCRT question"

Re: SCRT Question -- Group in =P5==

2021-11-16 Thread Steve Thompson


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==

2021-11-16 Thread Edward King

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==

2021-11-16 Thread Richards, Robert B. (CTR)

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==

2021-11-15 Thread ste...@copper.net

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==

2021-11-15 Thread Richards, Robert B. (CTR)

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

2013-08-27 Thread Gerhard Postpischil


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 ). 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

2013-08-27 Thread Gerhard Postpischil


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? 

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

2013-08-27 Thread Shmuel Metz (Seymour J.)

In <2436150148124474.wa.paulgboulderaim@listserv.ua.edu>, on
08/27/2013
   at 07:43 AM, Paul Gilmartin  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/2
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

2013-08-27 Thread R.S.

W dniu 2013-08-27 21:30, John Eells pisze:

R.S. wrote:

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.

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

2013-08-27 Thread John Eells


R.S. wrote:


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.



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

2013-08-27 Thread R.S.

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

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

Re: SCRT question

2013-08-27 Thread Gerhard Postpischil


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

2013-08-27 Thread Gerhard Postpischil


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

2013-08-27 Thread Paul Gilmartin

On Tue, 27 Aug 2013 08:26:02 -0400, 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.
> 
Would you be thinking of multi-volume?

And PDSE might have been a good place to introduce (optional) FBA
support.  PDSE is really just FBA simulated on CKD simulated on FBA.

And why are member primary names still restricted to 8 characters!?

-- 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

2013-08-27 Thread Shmuel Metz (Seymour J.)

In <4473679277803350.wa.paulgboulderaim@listserv.ua.edu>, on
08/25/2013
   at 01:39 PM, Paul Gilmartin  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/2
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

2013-08-26 Thread Mark Yuhas

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

2013-08-25 Thread Anthony Babonas

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"  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  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

2013-08-25 Thread Joel C. Ewing

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  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

2013-08-25 Thread Mike Schwab

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  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

2013-08-25 Thread John Gilmore

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

2013-08-25 Thread Ted MacNEIL

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 
Sender:   IBM Mainframe Discussion List 
Date: Sun, 25 Aug 2013 13:39:42 
To: 
Reply-To: IBM Mainframe Discussion List 
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

2013-08-25 Thread Paul Gilmartin

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

2013-08-25 Thread Gerhard Postpischil


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

2013-08-24 Thread Shmuel Metz (Seymour J.)

In <521898ce.8020...@bremultibank.com.pl>, on 08/24/2013
   at 01:28 PM, "R.S."  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/2
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

2013-08-24 Thread John Gilmore

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

2013-08-24 Thread Ted MacNEIL

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." 
Sender:   IBM Mainframe Discussion List 
Date: Sat, 24 Aug 2013 13:28:14 
To: 
Reply-To: IBM Mainframe Discussion List 
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." 
> Sender:   IBM Mainframe Discussion List 
> Date: Fri, 23 Aug 2013 20:56:52
> To: 
> Reply-To: IBM Mainframe Discussion List 
> 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

2013-08-24 Thread R.S.


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." 
Sender:   IBM Mainframe Discussion List 
Date: Fri, 23 Aug 2013 20:56:52
To: 
Reply-To: IBM Mainframe Discussion List 
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

2013-08-23 Thread Ted MacNEIL

I have NO idea what your point is!
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: "R.S." 
Sender:   IBM Mainframe Discussion List 
Date: Fri, 23 Aug 2013 20:56:52 
To: 
Reply-To: IBM Mainframe Discussion List 
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

2013-08-23 Thread R.S.

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

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

Re: SCRT question

2013-08-23 Thread Greg Shirey

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

2013-08-23 Thread Ted MacNEIL

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." 
Sender:   IBM Mainframe Discussion List 
Date: Fri, 23 Aug 2013 05:21:07 
To: 
Reply-To: IBM Mainframe Discussion List 
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

 

Radoslaw Skorupka pisze:
>SCRT report is text file, PS FB 80.  

 

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

2013-08-23 Thread Elardus Engelbrecht

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



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

2013-08-23 Thread Richards, Robert B.

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

 

Radoslaw Skorupka pisze:
>SCRT report is text file, PS FB 80.  

 

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

2013-08-23 Thread R.S.

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

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

Re: SCRT question

2013-08-22 Thread Greg Shirey

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

 

Radoslaw Skorupka pisze:
>SCRT report is text file, PS FB 80.  

 

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

2013-08-22 Thread Elardus Engelbrecht

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

2013-08-22 Thread R.S.

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.

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

2013-08-21 Thread Ted MacNEIL

>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

Re: SCRT question

2013-08-21 Thread Paul Gilmartin

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

39 matches

Mail list logo