date:20130610

PPRC has a bit map for updated tracks.  If a mirroring set becomes
suspended, you can resume the mirroring and just the updated tracks
are sent.

On Mon, Jun 10, 2013 at 2:24 AM, Paolo Cacciari
paolo.cacci...@it.ibm.com wrote:
 AFAIK, XRC incremental resynch is a GDPS-only feature. I've never seen non
 GDPS/XRC users using it.

 Paolo Cacciari - IBM BCRS Italy

-- 
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: Check out CERN Data Centre passes 100 petabytes | CERN

2013-06-10 Thread Elardus Engelbrecht

Ed Finnell wrote:

http://en.wikipedia.org/wiki/Utah_Data_Center

Future Home of a bigger PRISM when the current spy drama has settled down?

If you want to be an instant expert according to J. G., look at and be very 
afraid about losing privacy:

http://en.wikipedia.org/wiki/PRISM_%28surveillance_program%29 

http://edition.cnn.com/2013/06/10/politics/nsa-leak/index.html?hpt=hp_t1

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: Choosing a tape library

2013-06-10 Thread Hervey Martinez

Gadi,

We are about to start testing a Luminex VTS and, from everything that we've 
read, it appears to be an excellent solution. 

Regards,

Hervey

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ??? ?? ???
Sent: Sunday, June 09, 2013 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Choosing a tape library

Hi,

I was asked to help choose a tape library for our system.
We currently have 4 3590’s connected to an 3590-a60 using ESCON.
We have a z114-I04 running z/OS 1.13.

We use tapes for backing up full volumes disks using DFSMSdss, and for ADABAS 
backups. These tapes are shipped to the DR site.
Tapes are managed using CA-1.

Thanks

Gadi


לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, 
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company, unless 
accompanied by a duly signed separate document (or a scanned version thereof), 
affixed with the company's seal.

--
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: Choosing a tape library

2013-06-10 Thread גדי בן אבי

Thanks,
But from what I see, they do not have a reseller in Israel.
I also doubt that our DR site, which is run by IBM, will let us use this.
Our main use for tapes, is to transfer data to the DR site.

gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hervey Martinez
Sent: Monday, June 10, 2013 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Choosing a tape library

Gadi,

We are about to start testing a Luminex VTS and, from everything that we've 
read, it appears to be an excellent solution.

Regards,

Hervey

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ??? ?? ???
Sent: Sunday, June 09, 2013 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Choosing a tape library

Hi,

I was asked to help choose a tape library for our system.
We currently have 4 3590’s connected to an 3590-a60 using ESCON.
We have a z114-I04 running z/OS 1.13.

We use tapes for backing up full volumes disks using DFSMSdss, and for ADABAS 
backups. These tapes are shipped to the DR site.
Tapes are managed using CA-1.

Thanks

Gadi


לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, 
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company, unless 
accompanied by a duly signed separate document (or a scanned version thereof), 
affixed with the company's seal.

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

לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון,
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company,
unless accompanied by a duly signed separate document (or a scanned version 
thereof), affixed with the company's seal.

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

Re: Choosing a tape library

2013-06-10 Thread R.S.

W dniu 2013-06-10 13:29, גדי בן אבי pisze:

Thanks,
But from what I see, they do not have a reseller in Israel.
I also doubt that our DR site, which is run by IBM, will let us use this.
Our main use for tapes, is to transfer data to the DR site.

I'd suggest 4 3590's connected to A60.

Seriously: define your needs.
Do you want to get rid off ESCON?
Improve throughput? Increase cart capacity? Add encryption?
What about DR site possibilities?

You can have 3590's connected via FICON, you can buy new/used Jaguar
drives with controller, you can buy whole library (ATL), you can buy
some appliance like Luminex or MDL, you can buy STK/Sun/Oracle
drives/libraries...

--
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 osb 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 przedsibiorcw 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: Choosing a tape library

2013-06-10 Thread גדי בן אבי

Our goals are:
Make backups run fast so we can back more data in a limited backup window.
Transfer the tapes to our DR site. They definitely have 3592's.
Encryption is not required.

Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, June 10, 2013 2:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Choosing a tape library

W dniu 2013-06-10 13:29, גדי בן אבי pisze:
 Thanks,
 But from what I see, they do not have a reseller in Israel.
 I also doubt that our DR site, which is run by IBM, will let us use this.
 Our main use for tapes, is to transfer data to the DR site.


I'd suggest 4 3590's connected to A60.

Seriously: define your needs.
Do you want to get rid off ESCON?
Improve throughput? Increase cart capacity? Add encryption?
What about DR site possibilities?

You can have 3590's connected via FICON, you can buy new/used Jaguar drives 
with controller, you can buy whole library (ATL), you can buy some appliance 
like Luminex or MDL, you can buy STK/Sun/Oracle drives/libraries...

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

לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון,
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company,
unless accompanied by a duly signed separate document (or a scanned version 
thereof), affixed with the company's seal.

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

Re: Choosing a tape library

2013-06-10 Thread Richard Marchant

Gadi,

In South Africa we have installed Luminex VTL / Data Domain solutions for 
mainframe customers and it works very well. The Data Domain is not mandatory 
and could be replaced with less expensive disk as Luminex now has replication 
and compression capabilities, this would make it a cheaper solution.

Richard
Johannesburg

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hervey Martinez
Sent: Monday, June 10, 2013 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Choosing a tape library

Gadi,

We are about to start testing a Luminex VTS and, from everything that we've 
read, it appears to be an excellent solution. 

Regards,

Hervey

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ??? ?? ???
Sent: Sunday, June 09, 2013 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Choosing a tape library

Hi,

I was asked to help choose a tape library for our system.
We currently have 4 3590’s connected to an 3590-a60 using ESCON.
We have a z114-I04 running z/OS 1.13.

We use tapes for backing up full volumes disks using DFSMSdss, and for ADABAS 
backups. These tapes are shipped to the DR site.
Tapes are managed using CA-1.

Thanks

Gadi


לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, 
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company, unless 
accompanied by a duly signed separate document (or a scanned version thereof), 
affixed with the company's seal.

--
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: Choosing a tape library

LTOs are pretty high capacity.
http://en.wikipedia.org/wiki/Linear_Tape-Open

On Mon, Jun 10, 2013 at 6:52 AM, גדי בן אבי gad...@malam.com wrote:
 Our goals are:
 Make backups run fast so we can back more data in a limited backup window.
 Transfer the tapes to our DR site. They definitely have 3592's.
 Encryption is not required.

 Gadi


-- 
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: X11 forwarding

2013-06-10 Thread Mark Pace

True - that was my stated objective.  But it was out of ignorance, I
thought all X went through SSH.  Since this test is over a VPN, I don't
care how it works, as long as it does.


On Fri, Jun 7, 2013 at 5:09 PM, Paul Gilmartin paulgboul...@aim.com wrote:

 On Fri, 7 Jun 2013 13:53:38 -0400, Mark Pace wrote:

 I appreciate the heads-up, Mark.  But this traffic is going through a VPN,
 so I'm not concerned about it.  I will make note of this if I ever have to
 do this in the clear.
 
 Your initial stated objective was to get X11 forwarding working and
 verified.
 But now that it isn't but something else is working, you seem satisfied.


 On Fri, Jun 7, 2013 at 1:31 PM, Mark Post wrote:
 
   In this case the export DISPLAY IP is my desktop running the X server.
 
  Well, what is working is _not_ tunneling X over SSH.  You're sending X
  traffic back to your desktop over an entirely different port, with no
  encryption.  If anyone decides to close off traffic on ports 6000+
 you're
  going to be out of luck.
 
 A common pitfall is that programmers accustomed to other techniques code
 in their .profile, $ENV, .login, .cshrc, .bashrc, ... code to set and
 export
 DISPLAY, often based on parsing the output of a command such as who am i.
 This code must be made conditional wherever it occurs (often in several
 places) with a conditional construct such as:

 DISPLAY=${DISPLAY-`find-value-of-display`} export DISPLAY

 in order not to override the value correctly set by sshd.

 -- gil

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




-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: Choosing a tape library

2013-06-10 Thread R.S.

W dniu 2013-06-10 14:03, Mike Schwab pisze:

LTOs are pretty high capacity.
http://en.wikipedia.org/wiki/Linear_Tape-Open

Oh, yes, but there are no FICON-attached versions. So, no z/OS system
can use them (directly).
Indirect use via some magic box like BusTech, Luminex or Interkom is
another story.
Linux on System z can attach LTO drive via FCP channel, but it's also
another story.

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

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: Choosing a tape library

2013-06-10 Thread R.S.

W dniu 2013-06-10 13:52, גדי בן אבי pisze:

Our goals are:
Make backups run fast so we can back more data in a limited backup window.
Transfer the tapes to our DR site. They definitely have 3592's.
Encryption is not required.

Then buy some second-hand J70 (with FICON cards) + FC switch + several
3592-J1A drives.

--
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: Choosing a tape library

2013-06-10 Thread גדי בן אבי

Thanks, I will let the higher ups know.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, June 10, 2013 3:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Choosing a tape library

W dniu 2013-06-10 13:52, גדי בן אבי pisze:
 Our goals are:
 Make backups run fast so we can back more data in a limited backup window.
 Transfer the tapes to our DR site. They definitely have 3592's.
 Encryption is not required.

Then buy some second-hand J70 (with FICON cards) + FC switch + several 3592-J1A 
drives.

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

לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון,
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.

Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company,
unless accompanied by a duly signed separate document (or a scanned version 
thereof), affixed with the company's seal.

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

Re: Why does IBM keep saying things like this:

2013-06-10 Thread John Gilmore

In defense|defence of IBM's use of 'actionable' Timothy Sipples has
used recognition by a Merriam-Webster dictionary of the sense 'capable
of being acted upon'.

The single example he cites is semantically contaminated by its
law-enforcement/legal context, but for his purposes this is not
perhaps a fatal defect.

We must all choose our own authorities, and he has every right to
choose his.  I, however, prefer the OED because it includes quotations
over long periods of time that permit me to judge the contexts in
which a word has been used and its connotations in those contexts.
There 'actionable' in his/IBM's sense has no respectable antecedents.

I am prepared to concede that IBM evolves.  Some of this evolution is
admirable, some not; but it is important to remember that not
corporations buy people write text.  Some write English or another
language well, and some do not.  Merriam-Webster takes the view that
usage is all, that current usage is a fortiori legitimate usage.

My view is different.  I can perhaps best summarize it by borrowing an
example from E. B. White, who observed that while those who use the
English-language verb 'to personalize' should be free to do so, they
should not perhaps be equally free to teach English to others.

Finally, of course, we are dealing here with matters of taste.  In his
post Mr Sipples wrote

True, definition #2 is not as old as definition #1.

in conformity with much current usage, where the canons of standard
English dictate, and I should have written,

True, definition #2 is not so old as definition #1.

He is certainly free to do this.  Again, as he has repeatedly, he is
free to use data as a singular noun.  Equally, I am free to judge his
use of such constructs, favorably or adversely.

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: Allocated a Non SMS managed Multi volume HFS dataset

2013-06-10 Thread Mark Jacobs

That JCL example works fine for a single ZFS file system, but if you 
need to define many, and don't want to use multiple job steps, you can 
do something like this using the CoZ Toolkit.


//COZBATCH EXEC COZBATCH
//STDENV   DD *
cyl=1 1
volumes=ZOS3AZ
aggr001=SYSZFS.FILESYSA
aggr002=SYSZFS.FILESYSB
/*
  //STDIN DD *
export _BPX_SHAREAS=YES
zfsadm define -aggr $aggr001 -cyl $cyl -volumes $volumes
zfsadm define -aggr $aggr002 -cyl $cyl -volumes $volumes
zfsadm format -aggr $aggr001 -compat
zfsadm format -aggr $aggr002 -compat
/*



On 06/08/13 03:59, baby eklavya wrote:

Sure . Thank you John !


On Fri, Jun 7, 2013 at 5:43 PM, John McKown john.archie.mck...@gmail.comwrote:


I agree. One argument that I have gotten in the past was but I can easily
allocate an HFS filesystem using simple JCL. To allocate a ZFS, I need to
run an IDCAMS, then the initialization program. What a bother!. Well,
assuming that your ZFS data sets are SMS managed, you can easily allocate
and format a ZFS data set using simple JCL too! I use:

// SET FS= DATA SET NAME
//MKZFS EXEC PGM=IOEAGFMT,REGION=0M,
//  PARM=('-aggregate FS -compat')
//ZFS   DD DSN=FS,
//  DISP=(NEW,CATLG),
//  UNIT=SYSDA,
//  SPACE=(CYL,(200,100)),
//  RECORG=LS
//SYSPRINT  DD SYSOUT=*
//STDOUTDD SYSOUT=*
//STDERRDD SYSOUT=*
//SYSUDUMP  DD SYSOUT=*
//CEEDUMP   DD SYSOUT=*
//*


snip

--
Mark Jacobs
Time Customer Service
Tampa, FL


The quiet ones are the ones that change the universe...
The loud ones only take the credit.

Londo Mollari - Babylon 5

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

Re: Why does IBM keep saying things like this:

2013-06-10 Thread Steve Comstock


On 6/10/2013 6:45 AM, John Gilmore wrote:
[snip]



I am prepared to concede that IBM evolves.  Some of this evolution is
admirable, some not;
but it is important to remember that not corporations buy people write text.


interesting construction above



 Some write English or another language well, and some do not


Perhaps this is a commentary on his own writing. :-)



[snip]


-Steve Comstock
The Trainer's Friend, Inc.

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

zIIP enablement with BMC

2013-06-10 Thread Jan Vanbrabant

Hi,
Is thee some documentation or some article which globalizes all (BMC
products which are zIIP-capable?
Is it correct that zIIP-capable offloading is discovered by the tools and
utilities themselves and that it starts by itself (without parametrization,
I mean),  *IF*  they are at the correct maintenance levels of course?
Rgds,
Jan

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

Re: Why does IBM keep saying things like this:

2013-06-10 Thread John Gilmore

The letters 'y' and 't' are adjacent on my keyboard (and many others).
 The token 'buy' should have been 'but', less interesting but what I
meant.

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: DFHSM QUESTION : Allocation/migration Threshold: High . . 95 (1-99) Low . . 80 (0-99)

2013-06-10 Thread Staller, Allan

It is my understanding that if the volume does not exceed the high threshold, 
migration will not begin on that volume.
Once migration begins, It will continue until the low threshold is reached 
(normally, oldest datasets migrated first).

A specific dataset may or may not migrate as specified in the SMS MGMTCLAS, 
dfHSM exits, and a few miscellaneous additional rules (e.g. APF authorized DS, 
DSORG=PSU,...).

HTH,

snip
I am referring to primary space management.  When I say  dsns are not being 
migrated often enough' I meant to say that the dsns in the storage group are 
not ALL being migrated when SP is run.  To fix the problem I migrate the volume 
- HSEND MIGRATE VOLUME(RPM105 MIGRATE(0)) - and lots of space is now available. 
 Is the cause related to the thresholds settings?  What could I do instead of 
having to migrate the volume?  Should I lower the Allocation/Migration 
Threshold from 85 to 40?
 
:: I have a problem with primary ML0 SMS managed pool which for some reason
:: the dsns are not being migrated often enough.  The setup is as follows :
::  Allocation/migration Threshold : High    85   (1-100)  Low . .
:: 1   (0-99)
:: Alloc/Migr Threshold Track-Managed:  High    85   (1-100)  Low . .
:: 1   (0-99)
:: Guaranteed Backup Frequency  . . . . . . NOLIMIT  (1 to  or
:: NOLIMIT)
:: BreakPointValue  . . . . . . . . . . . .  (0-65520 or
:: blank)
::
::  If I lower the Allocation/migration Threshold  High to 55 would that do
:: the trick when Space management runs?
/snip

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

Re: zIIP enablement with BMC

2013-06-10 Thread Bright, Randy

The easiest way to find out how zIIP enabled the products you are licensed for 
is to contact your local friendly BMC Software Consultant or Sales person.  
They can provide you with information about which products you own can make use 
of zIIP and to what degree.  Or you could open a Support Issue and the Support 
Representatives will be happy to assist you.  As far as a global document that 
lists all BMC products that make use of zIIP eligibility, I'm not sure.

I am most familiar with the DB2 Utilities.  Their use of BMCSORT affords some 
zIIP utilization.  In addition, if you have an XBM address space operational in 
the LPAR running the Utility, the Utility will discover the XBM and utilize a 
proprietary interface to move some processes to an enclave within XBM to make 
even more of the Utility workload zIIP eligible.

Other of the DB2 products utilize the same interface with XBM and there are 
other BMC products that use it as well.  And some products (such as BMCSORT 
mentioned earlier) are zIIP eligible outside of XBM.  The best way to know for 
sure is to contact Support, your SC, or Sales person, as I said before, and 
they can help you with the specific products you own.

Randy Bright
Solutions Architect
DB2 Utilities
BMC Software, Inc.

phone: (512) 340-6014
fax: (512) 340-6646

10431 Morado Circle 
Austin, TX 78759



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jan Vanbrabant
Sent: Monday, June 10, 2013 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: zIIP enablement with BMC

Hi,
Is thee some documentation or some article which globalizes all (BMC products 
which are zIIP-capable?
Is it correct that zIIP-capable offloading is discovered by the tools and 
utilities themselves and that it starts by itself (without parametrization, I 
mean),  *IF*  they are at the correct maintenance levels of course?
Rgds,
Jan

--
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: Why does IBM keep saying things like this:

2013-06-10 Thread Elardus Engelbrecht

John Gilmore wrote:

The letters 'y' and 't' are adjacent on my keyboard (and many others). The 
token 'buy' should have been 'but', less interesting but what I meant.

I don't buy it, but ...  pun intended! ;-D

No offense meant, I just like and learn what all of you wrote. ;-D

All of the very best for you all in this thread.  :-D

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: Choosing a tape library

2013-06-10 Thread Scott Fagen

גדי בן אבי said:

Hi, 

I was asked to help choose a tape library for our system.
-- snip --

As mentioned by another poster, for your use, a tapeless solution might prove 
most scalable.  You can use a something other than shipping to get your data 
to D/R.  See shameless-plug 
href=http://www.ca.com/us/products/detail/ca-vtape-virtual-tape-system.aspxCA 
VTAPE/shameless-plug.

Scott Fagen
Chief Architect - Mainframe
CA Technologies

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

Re: Data volumes

2013-06-10 Thread Richard Peurifoy


On 6/9/2013 10:07 AM, John Gilmore wrote:

The numbers 9 and 27 (for the venturesome) still prevail in many
shops.  Much larger values, never available as physical, spinning
DASD, appear to make some people uneasy.

They get used, reluctantly at least on the first occasion, only when
some compelling special argument is made for them.

In querying people about such decisions I have been told things like
The smaller volumes are more reliable or I wasn't sure the big ones
would work.


In our case management wouldn't buy PAV, so we don't use really
large volumes to avoid contention.

--
Richard

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

Re: Data volumes

2013-06-10 Thread John Gilmore

Richard,

I don't  of course know the details of your situation, but in each of
the 6 six rather different shops where I have looked at this issue in
detail it has turned out that PAV was the economic choice, decisively
so.

If an occasion for revisiting it quantitatively ever arises, you
should try to get your management to have another look at this
decision in changed circumstances.

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

Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Farley, Peter x23353

Rant
Like a few others on this list, I have often gritted my teeth at the necessity 
to estimate disk storage quantities that vary widely over time in a fixed 
manner (i.e., SPACE in JCL) when the true need is just to match output volume 
to input volume each day.

Why is it that IBM (and organizations that use their mainframe systems) so 
vigorously resist a conversion off of the ECKD standard?  (Yes, I know it's 
all about conversion cost, but in the larger picture that is a red herring.)  
Not that I'm likely to see such a transition in my lifetime, but in this 
dawning time of soi-disant big data, perhaps it is past time to change the 
storage paradigm entirely, not from ECKD to FBA but to transition instead to 
something like the Multics model where every object in the system (whether in 
memory or on external storage, whether data or program) has an address, and all 
addresses are unique.  Let the storage subsystem decide how to optimally 
position and aggregate the various parts of objects, and how to organize them 
for best performance.  Such decisions should not require human guesstimate 
input to be optimal, or nearly so.  Characteristics of application access are 
far more critical specifications than mere size.  The ability to specify just 
the desired application access characteristics (random, sequential, growing, 
shrinking, response-time-critical, etc.) should be necessary and sufficient.

EAV or not EAV, guaranteed space or not, candidate volumes, striped or not 
striped, compressed or not compressed - all of that baggage is clearly 
non-optimal for getting the job done in a timely manner.  Why should allocating 
a simple sequential file require a team of Storage Administration experts to 
accomplish effectively?
/Rant

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Sunday, June 09, 2013 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Data volumes

On 6/9/2013 7:12 AM, Scott Ford wrote:
 We need bigger dasd ...ouch

The largest 3390 volumes in our tiny shop hold 3,940,020 tracks or 262,668 
cylinders. That is the maximum size supported by the back-level DASD we are 
running. Newer DASD hardware can support volumes up to 1TB in size. I assume 
nearly all zEC12 and z196 customers are capable of exploiting these large 
sizes. But, do they?

I spent three years dealing with, and eventually helping IBM to solve (via 
OA40210 - HIPER, DATALOSS), a serious EAV bug that should have been seen in 
most every shop in the world that uses the DFSMSdss CONSOLIDATE function (with 
or without DEFRAG). The experience was a real eye-opener for me and I concluded 
that almost nobody is using EAV!

Why not? Personally, I would find it embarrassing if the Corsair thumb drive in 
my pocket held more data than our largest mainframe volumes. 
But, that's just me...
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Storage paradigm [was: RE: Data volumes]

In general, I agree. But I will say that I need something to limit run-away
usage of disk space. Why? Because we have had programmers who didn't want
to be bother either. So they put out a report to SPOOL. And then their
program went into a loop; writing the same message over and over. This
exhausted the SPOOL space. Which caused a production outage on a weekend
(we run dark on the weekends). I can easily envision the same thing
happening if DASD ever went to an all you can eat. Of course, with SMS
control, it is easier to segregate the data into pools. We currently try to
do a type of all you can reasonably eat by having our data classes have a
dynamic volume count of 59. And we have a semi-standard (read:
recommendation) that files of an unknown size be allocated CYL,(500,100)
. Oh, and we use space release in the data class to get rid of excess
allocation. If the data set cannot abide space release for some reason,
there is an exempt data class for the programmers to use.

On Mon, Jun 10, 2013 at 10:38 AM, Farley, Peter x23353 
peter.far...@broadridge.com wrote:

 Rant
 Like a few others on this list, I have often gritted my teeth at the
 necessity to estimate disk storage quantities that vary widely over time in
 a fixed manner (i.e., SPACE in JCL) when the true need is just to match
 output volume to input volume each day.

 Why is it that IBM (and organizations that use their mainframe systems) so
 vigorously resist a conversion off of the ECKD standard?  (Yes, I know
 it's all about conversion cost, but in the larger picture that is a red
 herring.)  Not that I'm likely to see such a transition in my lifetime, but
 in this dawning time of soi-disant big data, perhaps it is past time to
 change the storage paradigm entirely, not from ECKD to FBA but to
 transition instead to something like the Multics model where every object
 in the system (whether in memory or on external storage, whether data or
 program) has an address, and all addresses are unique.  Let the storage
 subsystem decide how to optimally position and aggregate the various parts
 of objects, and how to organize them for best performance.  Such decisions
 should not require human guesstimate input to be optimal, or nearly so.
  Characteristics of application access are far more critical specifications
 than mere size.  The ability to specify just the desired application access
 characteristics (random, sequential, growing, shrinking,
 response-time-critical, etc.) should be necessary and sufficient.

 EAV or not EAV, guaranteed space or not, candidate volumes, striped or not
 striped, compressed or not compressed - all of that baggage is clearly
 non-optimal for getting the job done in a timely manner.  Why should
 allocating a simple sequential file require a team of Storage
 Administration experts to accomplish effectively?
 /Rant

 Peter

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of Ed Jaffe
 Sent: Sunday, June 09, 2013 10:47 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Data volumes

 On 6/9/2013 7:12 AM, Scott Ford wrote:
  We need bigger dasd ...ouch

 The largest 3390 volumes in our tiny shop hold 3,940,020 tracks or 262,668
 cylinders. That is the maximum size supported by the back-level DASD we are
 running. Newer DASD hardware can support volumes up to 1TB in size. I
 assume nearly all zEC12 and z196 customers are capable of exploiting these
 large sizes. But, do they?

 I spent three years dealing with, and eventually helping IBM to solve (via
 OA40210 - HIPER, DATALOSS), a serious EAV bug that should have been seen in
 most every shop in the world that uses the DFSMSdss CONSOLIDATE function
 (with or without DEFRAG). The experience was a real eye-opener for me and I
 concluded that almost nobody is using EAV!

 Why not? Personally, I would find it embarrassing if the Corsair thumb
 drive in my pocket held more data than our largest mainframe volumes.
 But, that's just me...
 --

 This message and any attachments are intended only for the use of the
 addressee and may contain information that is privileged and confidential.
 If the reader of the message is not the intended recipient or an authorized
 representative of the intended recipient, you are hereby notified that any
 dissemination of this communication is strictly prohibited. If you have
 received this communication in error, please notify us immediately by
 e-mail and delete the message and any attachments from your system.

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




-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! 
John McKown

--
For IBM-MAIN subscribe /

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Dale R. Smith

On Mon, 10 Jun 2013 11:38:08 -0400, Farley, Peter x23353 
peter.far...@broadridge.com wrote:

Rant
Like a few others on this list, I have often gritted my teeth at the necessity 
to estimate disk storage quantities that vary widely over time in a fixed 
manner (i.e., SPACE in JCL) when the true need is just to match output volume 
to input volume each day.

Why is it that IBM (and organizations that use their mainframe systems) so 
vigorously resist a conversion off of the ECKD standard?  (Yes, I know it's 
all about conversion cost, but in the larger picture that is a red herring.) 
 Not that I'm likely to see such a transition in my lifetime, but in this 
dawning time of soi-disant big data, perhaps it is past time to change the 
storage paradigm entirely, not from ECKD to FBA but to transition instead to 
something like the Multics model where every object in the system (whether in 
memory or on external storage, whether data or program) has an address, and 
all addresses are unique.  Let the storage subsystem decide how to optimally 
position and aggregate the various parts of objects, and how to organize them 
for best performance.  Such decisions should not require human guesstimate 
input to be optimal, or nearly so.  Characteristics of application access are 
far more critical specifications than mere size.  The ability to specify just 
the desired application access characteristics (random, sequential, growing, 
shrinking, response-time-critical, etc.) should be necessary and sufficient.

EAV or not EAV, guaranteed space or not, candidate volumes, striped or not 
striped, compressed or not compressed - all of that baggage is clearly 
non-optimal for getting the job done in a timely manner.  Why should 
allocating a simple sequential file require a team of Storage Administration 
experts to accomplish effectively?
/Rant

Peter

Oh, then you want to move to IBM System i...  :-)

Seriously, System i, (formerly known by many different names), addresses 
everything in storage/memory and on disk and has been 64-bit since the mid 
1990s, (and it was 48-bit before that).  There is however, no need for system 
programmers on the i, (really IBM, you can't come up with better names for 
hardware/software than 1 character? And i, is this an Apple box?)

-- 
Dale R. Smith

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

Re: Check out CERN Data Centre passes 100 petabytes | CERN

2013-06-10 Thread DASDBILL2

A few more orders of magnitude and they'll maybe begin rivaling our NSA, whose 
mission is to track and record data on every electron in the universe. 


Bill Fairchild 
Franklin, TN 

“Political language is designed to make lies sound truthful and murder 
acceptable, and to give the appearance of solidity to pure wind.” [George 
Orwell] 

- Original Message -
From: Ed Finnell efinnel...@aol.com 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Saturday, June 8, 2013 1:52:58 PM 
Subject: Check out CERN Data Centre passes 100 petabytes | CERN 

_CERN  Data Centre passes 100 petabytes | CERN_ 
(http://home.web.cern.ch/about/updates/2013/02/cern-data-centre-passes-100-petabytes)
   
  
Give them a pretty big honkin data collection. 

-- 
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: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Blaicher, Christopher Y.

I am not a LUW person, other than I use a windows machine for simple things, so 
I am curious how external storage is allocated and controlled in that 
environment.  I think we have all heard the complaints about the short-comings 
of MVS in this area, but what would be a realistic solution?

I would imagine the people at IBM have spent a little time on this, and if it 
was easy would have started transitioning us from ECKD to 'the new way' a long 
time ago.  The idea of a 'run-away' program is what is the hang-up.

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: cblaic...@syncsort.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Monday, June 10, 2013 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Storage paradigm [was: RE: Data volumes]

Rant
Like a few others on this list, I have often gritted my teeth at the necessity 
to estimate disk storage quantities that vary widely over time in a fixed 
manner (i.e., SPACE in JCL) when the true need is just to match output volume 
to input volume each day.

Why is it that IBM (and organizations that use their mainframe systems) so 
vigorously resist a conversion off of the ECKD standard?  (Yes, I know it's 
all about conversion cost, but in the larger picture that is a red herring.)  
Not that I'm likely to see such a transition in my lifetime, but in this 
dawning time of soi-disant big data, perhaps it is past time to change the 
storage paradigm entirely, not from ECKD to FBA but to transition instead to 
something like the Multics model where every object in the system (whether in 
memory or on external storage, whether data or program) has an address, and all 
addresses are unique.  Let the storage subsystem decide how to optimally 
position and aggregate the various parts of objects, and how to organize them 
for best performance.  Such decisions should not require human guesstimate 
input to be optimal, or nearly so.  Characteristics of application access are 
far more critical specifications than mere size.  The ability to specify just 
the desired application access characteristics (random, sequential, growing, 
shrinking, response-time-critical, etc.) should be necessary and sufficient.

EAV or not EAV, guaranteed space or not, candidate volumes, striped or not 
striped, compressed or not compressed - all of that baggage is clearly 
non-optimal for getting the job done in a timely manner.  Why should allocating 
a simple sequential file require a team of Storage Administration experts to 
accomplish effectively?
/Rant

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Sunday, June 09, 2013 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Data volumes

On 6/9/2013 7:12 AM, Scott Ford wrote:
 We need bigger dasd ...ouch

The largest 3390 volumes in our tiny shop hold 3,940,020 tracks or 262,668 
cylinders. That is the maximum size supported by the back-level DASD we are 
running. Newer DASD hardware can support volumes up to 1TB in size. I assume 
nearly all zEC12 and z196 customers are capable of exploiting these large 
sizes. But, do they?

I spent three years dealing with, and eventually helping IBM to solve (via 
OA40210 - HIPER, DATALOSS), a serious EAV bug that should have been seen in 
most every shop in the world that uses the DFSMSdss CONSOLIDATE function (with 
or without DEFRAG). The experience was a real eye-opener for me and I concluded 
that almost nobody is using EAV!

Why not? Personally, I would find it embarrassing if the Corsair thumb drive in 
my pocket held more data than our largest mainframe volumes.
But, that's just me...
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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



ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other  confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written

Re: Storage paradigm [was: RE: Data volumes]

LUW works similar to z/OS UNIX file systems. I.e. there is a file system
which is formatted using some utility (mkfs in the Linux/UNIX world, format
in Windows). This sets up all the internals. In today's LUW, it is usually
possible for a single file to be as big as the file system upon which it
resides. But no bigger. There is nothing like a multi file system file
(which would vaguely like a multivolume data set). I'm not too Windows
literate any more, but it used to be that a file system had to reside on a
single disk (or in a partition of that disk). Linux/UNIX used to be that
way too. But Linux/UNIX now implements something called LVM (Logical Volume
Manager). In short, LVM can stitch together a number of physical disk
volumes (called a PV for Physical Volume), or partitions, and the subdivide
that aggregate space into one or more Logical Volumes (LV). A Logical
Volume can be created in many ways, such as using software RAID, or
striping. The admin then formats a file system on the Logical Volume. Even
after creating the PV, the storage admin can add another disk into a PV
(like adding a volume to a storage group in SMS). The storage admin can
then use the new space for another LV or to extend an existing LV.
Depending on the file system formatted on the LV, it might even be possible
to tell the file system to start using the newly added space. Most of the
current Linux file systems can at least be extended when they are unmounted
(not actively used). So, like a zFS file system on z/OS, using something
like EXT4 (or BTRFS) and LVM, it is possible to dynamically expand the size
of a file system. I don't know for certain, but I doubt that Windows can do
this kind of dynamic expansion at all. To control allocation, Linux and
UNIX can use disk quotas. I don't know much about that since I don't use it
on my personal systems.

On Mon, Jun 10, 2013 at 11:15 AM, Blaicher, Christopher Y. 
cblaic...@syncsort.com wrote:

 I am not a LUW person, other than I use a windows machine for simple
 things, so I am curious how external storage is allocated and controlled in
 that environment.  I think we have all heard the complaints about the
 short-comings of MVS in this area, but what would be a realistic solution?

 I would imagine the people at IBM have spent a little time on this, and if
 it was easy would have started transitioning us from ECKD to 'the new way'
 a long time ago.  The idea of a 'run-away' program is what is the hang-up.

 Chris Blaicher
 Principal Software Engineer, Software Development
 Syncsort Incorporated
 50 Tice Boulevard, Woodcliff Lake, NJ 07677
 P: 201-930-8260  |  M: 512-627-3803
 E: cblaic...@syncsort.com

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of Farley, Peter x23353
 Sent: Monday, June 10, 2013 10:38 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Storage paradigm [was: RE: Data volumes]

 Rant
 Like a few others on this list, I have often gritted my teeth at the
 necessity to estimate disk storage quantities that vary widely over time in
 a fixed manner (i.e., SPACE in JCL) when the true need is just to match
 output volume to input volume each day.

 Why is it that IBM (and organizations that use their mainframe systems) so
 vigorously resist a conversion off of the ECKD standard?  (Yes, I know
 it's all about conversion cost, but in the larger picture that is a red
 herring.)  Not that I'm likely to see such a transition in my lifetime, but
 in this dawning time of soi-disant big data, perhaps it is past time to
 change the storage paradigm entirely, not from ECKD to FBA but to
 transition instead to something like the Multics model where every object
 in the system (whether in memory or on external storage, whether data or
 program) has an address, and all addresses are unique.  Let the storage
 subsystem decide how to optimally position and aggregate the various parts
 of objects, and how to organize them for best performance.  Such decisions
 should not require human guesstimate input to be optimal, or nearly so.
  Characteristics of application access are far more critical specifications
 than mere size.  The ability to specify just the desired application access
 characteristics (random, sequential, growing, shrinking,
 response-time-critical, etc.) should be necessary and sufficient.

 EAV or not EAV, guaranteed space or not, candidate volumes, striped or not
 striped, compressed or not compressed - all of that baggage is clearly
 non-optimal for getting the job done in a timely manner.  Why should
 allocating a simple sequential file require a team of Storage
 Administration experts to accomplish effectively?
 /Rant

 Peter

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of Ed Jaffe
 Sent: Sunday, June 09, 2013 10:47 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Data volumes

 On 6/9/2013 7:12 AM, Scott Ford wrote:
  We need bigger dasd ...ouch

OLAs (was: Storage paradigm)

2013-06-10 Thread Paul Gilmartin

On Mon, 10 Jun 2013 11:08:32 -0500, Dale R. Smith wrote:

(really IBM, you can't come up with better names for hardware/software than 1 
character? And i, is this an Apple box?)

Just as challenging to search the web for as C.

-- gil

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

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Roberts, John J

For Windows Capabilities, I suggest reading about Dynamic Disks and Dynamic 
Volumes on MSDN:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363785(v=vs.85).aspx

John

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

Re: OLAs (was: Storage paradigm)

And it sounds so egotistical. grin/

On Mon, Jun 10, 2013 at 11:48 AM, Paul Gilmartin paulgboul...@aim.comwrote:

 On Mon, 10 Jun 2013 11:08:32 -0500, Dale R. Smith wrote:
 
 (really IBM, you can't come up with better names for hardware/software
 than 1 character? And i, is this an Apple box?)
 
 Just as challenging to search the web for as C.

 -- gil

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




-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! 
John McKown

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

Re: Why does IBM keep saying things like this:

2013-06-10 Thread DASDBILL2

Not my insight, but that sentence itself seems actionable, and reminds me  of 
some other winners I've seen from IBM over the decades: 

HASP sprayed bits at random, resulting in a S0C4 (seen in a RETAIN item 40 
years ago, and the only example here that is humorous); 

The operator onlined the volume (also in RETAIN 40 years ago); 

First you must dimension the problem, then you can solution the problem. (in an 
education class 20 years ago). 



The last two examples example that any word (especially a noun) can be verbed. 

Bill Fairchild 
Franklin, TN 


- Original Message -
From: John Gilmore jwgli...@gmail.com 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Saturday, June 8, 2013 4:26:22 PM 
Subject: Re: Why does IBM keep saying things like this: 

To anyone who cares for the English language 

Get Actionable Insight with Security Intelligence for Mainframe Environments 

is a good deal more offensive than a porous statistic. 

It sounds significant, bit it is pretentious nonsense.  Properly, 
'actionable' is a lawyer's term that means 'open to legal action, 
characterizing something that one can take legal action/bring suit 
against'. 

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 

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

Re: Storage paradigm [was: RE: Data volumes]


On 6/10/2013 12:15 PM, Blaicher, Christopher Y. wrote:

I am not a LUW person, other than I use a windows machine for simple
things, so I am curious how external storage is allocated and
controlled in that environment.  I think we have all heard the
complaints about the short-comings of MVS in this area, but what
would be a realistic solution?


Technically the easiest to implement would be adding a new device type, 
thus keeping (E)CKD completely distinct from FBA. The new type could be 
supported by VSAM/AMS only (and JCL, SVC 99, etc.) without impacting 
other programs. (I would hope there are no programs out there using TM 
UCBTBYT3 rather than CLI?)



I would imagine the people at IBM have spent a little time on this,
and if it was easy would have started transitioning us from ECKD to
'the new way' a long time ago.  The idea of a 'run-away' program is
what is the hang-up.


I cannot see IBM spend any effort on this unless one of the Fortune 10 
companies requires it. Even then I would expect them to stick with the 
pre-allocated space paradigm rather than transitioning. As to run-away 
programs, they should be thoroughly checked on a test system before 
going into production; a run-away in production should be so rare as to 
be immaterial.


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: Storage paradigm [was: RE: Data volumes]


On 6/10/2013 11:38 AM, Farley, Peter x23353 wrote:

Rant
Like a few others on this list, I have often gritted my teeth at the
necessity to estimate disk storage quantities that vary widely over
time in a fixed manner (i.e., SPACE in JCL) when the true need is
just to match output volume to input volume each day.


If it's that predictable, it's trivial to write code to produce an 
estimated output volume from input, and tailor and submit the 
appropriate JCL. So that's a non-issue.



EAV or not EAV, guaranteed space or not, candidate volumes, striped
or not striped, compressed or not compressed - all of that baggage is
clearly non-optimal for getting the job done in a timely manner.  Why
should allocating a simple sequential file require a team of Storage
Administration experts to accomplish effectively?
/Rant


There is no theoretical solution. On any system running jobs, it is 
possible for one job to monopolize available space, requiring other jobs 
to wait forever or be terminated. Even on a single job system that job 
may exhaust space. Requiring a space specification may be a PITA, but it 
guarantees that a started job will finish (subject to other 
constraints). And the SA experts, especially for sequential files, can 
be avoided with simple estimator programs.


This seems to be more of a religious war than a practical discussion.

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: Storage paradigm [was: RE: Data volumes]

Download GnuPartEd, Burn it to CD-ROM, Boot from it, resize as needed.

On Mon, Jun 10, 2013 at 11:56 AM, Roberts, John J
jrobe...@dhs.state.ia.us wrote:
 For Windows Capabilities, I suggest reading about Dynamic Disks and Dynamic 
 Volumes on MSDN:

 http://msdn.microsoft.com/en-us/library/windows/desktop/aa363785(v=vs.85).aspx

 John

-- 
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: DFHSM QUESTION : Allocation/migration Threshold: High . . 95 (1-99) Low . . 80 (0-99)

2013-06-10 Thread willie bunter

Would lowering the high threshold to as low as possible (for example 20) solve 
the problem.  The objective is to keep the volumes as free as possible because 
mostly GDG (output) dsns reside on the volumes and never used as input.




From: Staller, Allan allan.stal...@kbmg.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, June 10, 2013 9:47:04 AM
Subject: Re: DFHSM QUESTION : Allocation/migration Threshold: High . . 95 
(1-99) Low . . 80 (0-99)


It is my understanding that if the volume does not exceed the high threshold, 
migration will not begin on that volume.
Once migration begins, It will continue until the low threshold is reached 
(normally, oldest datasets migrated first).

A specific dataset may or may not migrate as specified in the SMS MGMTCLAS, 
dfHSM exits, and a few miscellaneous additional rules (e.g. APF authorized DS, 
DSORG=PSU,...).

HTH,

snip
I am referring to primary space management.  When I say  dsns are not being 
migrated often enough' I meant to say that the dsns in the storage group are 
not ALL being migrated when SP is run.  To fix the problem I migrate the volume 
- HSEND MIGRATE VOLUME(RPM105 MIGRATE(0)) - and lots of space is now available. 
 Is the cause related to the thresholds settings?  What could I do instead of 
having to migrate the volume?  Should I lower the Allocation/Migration 
Threshold from 85 to 40?
 
:: I have a problem with primary ML0 SMS managed pool which for some reason
:: the dsns are not being migrated often enough.  The setup is as follows :
::  Allocation/migration Threshold : High    85   (1-100)  Low . .
:: 1   (0-99)
:: Alloc/Migr Threshold Track-Managed:  High    85   (1-100)  Low . .
:: 1   (0-99)
:: Guaranteed Backup Frequency  . . . . . . NOLIMIT  (1 to  or
:: NOLIMIT)
:: BreakPointValue  . . . . . . . . . . . .  (0-65520 or
:: blank)
::
::  If I lower the Allocation/migration Threshold  High to 55 would that do
:: the trick when Space management runs?
/snip

--
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: I/O Optimization

2013-06-10 Thread DASDBILL2

Standard means that all block sizes are the same, except for possibly the last 
one, which might be short. 



Spanned means that a single logical record might span multiple physical blocks, 
but the way it is implemented results in having all block sizes be the same, 
except for possibly the last one, which might be short. 



In either case, the DCB attribute byte and bit setting are the same for both 
uses of 'S', allowing all access methods have only one place to test for the 
'S' attribute and thus are able to build channel programs slightly differently 
and thus often running slightly faster.  At least that was true in the 1960s 
when these concepts were invented, but maybe not so true now with device-level 
buffering, inter alia . 

Bill Fairchild 
Franklin, TN 


- Original Message -
From: Ted MacNEIL eamacn...@yahoo.ca 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, June 5, 2013 9:42:32 PM 
Subject: Re: I/O Optimization 

Where does spanned come into play? Why does that make the difference? 

An acronym conflict! 

I hate IBM's tendency to use the same letters (in the same position) to mean 
different things! 

vbS -- Variable Blocked Spanned 
fbS -- Fixed Blocked Standard 

(BTW: why Standard? What the H-E-Double-Toothpicks does that mean?) 

They did a similar thing with: 
PCB -- before I ever even became aware of IMS it meant (to me) Printed Circuit 
Board. 

ATM -- I thought it meant Automated Teller Machine. 

- 
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 

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

Re: DFHSM QUESTION : Allocation/migration Threshold: High . . 95 (1-99) Low . . 80 (0-99)

We use 10% 1% for these types of volumes.  Not 85% 1%.

On Mon, Jun 10, 2013 at 12:38 PM, willie bunter williebun...@yahoo.com wrote:
 Would lowering the high threshold to as low as possible (for example 20) 
 solve the problem.  The objective is to keep the volumes as free as possible 
 because mostly GDG (output) dsns reside on the volumes and never used as 
 input.

 From: Staller, Allan allan.stal...@kbmg.com

 It is my understanding that if the volume does not exceed the high threshold, 
 migration will not begin on that volume.
 Once migration begins, It will continue until the low threshold is reached 
 (normally, oldest datasets migrated first).

 A specific dataset may or may not migrate as specified in the SMS MGMTCLAS, 
 dfHSM exits, and a few miscellaneous additional rules (e.g. APF authorized 
 DS, DSORG=PSU,...).

Deleted
 ::  Allocation/migration Threshold : High85   (1-100)  Low . .
 :: 1   (0-99)
 :: Alloc/Migr Threshold Track-Managed:  High85   (1-100)  Low . .
 :: 1   (0-99)

-- 
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: DFHSM QUESTION : Allocation/migration Threshold: High . . 95 (1-99) Low . . 80 (0-99)

2013-06-10 Thread Staller, Allan

snip
Would lowering the high threshold to as low as possible (for example 20) solve 
the problem.  The objective is to keep the volumes as free as possible because 
mostly GDG (output) dsns reside on the volumes and never used as input.
/snip

Just off the top of my head, High 70, low 20. YMMV.

Check out # GDG ON PRIMARY in your management class descriptions This may 
do what you want without changing the thresholds.

HTH, 

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

Re: Check out CERN Data Centre passes 100 petabytes | CERN

2013-06-10 Thread Ed Finnell

Seems like it'd be cheaper to just befriend everybody on facebook. Remember 
 a SHARE presentation by NSA from mid-nineties and they described some of 
what  they do. Said their goal was to remain 5 yrs ahead of 
'state-of-the-art'.
 
 
In a message dated 6/10/2013 5:17:06 A.M. Central Daylight Time,  
elardus.engelbre...@sita.co.za writes:

If you  want to be an instant expert according to J. G., look at and be 
very afraid  about losing privacy:



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

Error or Journal Dataset

2013-06-10 Thread Mike Wojtukiewicz

I just got this error on a multi system shared DFHSM database. I can't anything 
recent and since the disk drives are new technology DS8 type I doubt 
there's a hardware error. The complete message is below. Any help would be 
appreciated and no we can't call IBM, it's z/OS 1.11 and they'd want ransom 
money to answer the problem. Thanks in advance

 ARC0645I DFHSM   ,DFHSM   ,7406,D,JOURNAL ,WRITE ,  205
 ARC0645I (CONT.) OVERFLOW INCOMP,020A000635,BSAM
 ARC0020I **
*ARC0026E JOURNALING DISABLED DUE TO JOURNAL I/O ERROR.  207
 ARC0026E (CONT.) MIGRATION, BACKUP, FRBACKUP, DUMP, TAPECOPY,
 ARC0026E (CONT.)  RECYCLE, ARECOVER, AUDIT, AND EXPIREBV HELD
 ARC0020I **
 ARC0200I TRAP IN MODULE ARCILOG, CODE=0900, SNAP ONCE  209
 ARC0200I (CONT.) ADDED
 IEA794I SVC DUMP HAS CAPTURED:  211
 DUMPID=004 REQUESTED BY JOB (DFHSM   )
 DUMP TITLE= HSM MODULE ARCILOG  ERROR CODE=0900 TYPE=SNAP
 ARC0900I DFSMSHSM ERROR CODE 0900 IN MODULE ARCILOG  212
 ARC0900I (CONT.) TYPE SNAP
*ARC0860E JOURNAL SPACE MONITORING DISABLED - RC=24.  214
 ARC0860E (CONT.) MIGRATION, BACKUP, FRBACKUP, DUMP, AND RECYC

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

Re: Error or Journal Dataset

2013-06-10 Thread Staller, Allan

The key to your problem is here  ERROR CODE=0900 TYPE=SNAP  ARC0900I DFSMSHSM 
ERROR CODE 0900 IN MODULE ARCILOG 
Most likely a journal full condition.

F DFHSM,Q CDS  (I would expect to see the journal 100% full)

F DFHSM, BACKVOL CDS   (backs up CDS's  and resets journals)

After successful completion

F DFHSM,release all  (restores normal operation

HTH,

snip
 ARC0645I DFHSM   ,DFHSM   ,7406,D,JOURNAL ,WRITE ,  205
 ARC0645I (CONT.) OVERFLOW INCOMP,020A000635,BSAM  ARC0020I 
** *ARC0026E JOURNALING DISABLED DUE TO JOURNAL I/O 
ERROR.  207  ARC0026E (CONT.) MIGRATION, BACKUP, FRBACKUP, DUMP, TAPECOPY,  
ARC0026E (CONT.)  RECYCLE, ARECOVER, AUDIT, AND EXPIREBV HELD  ARC0020I 
**  ARC0200I TRAP IN MODULE ARCILOG, CODE=0900, 
SNAP ONCE  209  ARC0200I (CONT.) ADDED  IEA794I SVC DUMP HAS CAPTURED:  211
 DUMPID=004 REQUESTED BY JOB (DFHSM   )
 DUMP TITLE= HSM MODULE ARCILOG  ERROR CODE=0900 TYPE=SNAP  ARC0900I DFSMSHSM 
ERROR CODE 0900 IN MODULE ARCILOG  212  ARC0900I (CONT.) TYPE SNAP *ARC0860E 
JOURNAL SPACE MONITORING DISABLED - RC=24.  214  ARC0860E (CONT.) MIGRATION, 
BACKUP, FRBACKUP, DUMP, AND RECYC
/snip


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

Re: Storage paradigm [was: RE: Data volumes]

2013-06-10 Thread Farley, Peter x23353

As to the religious aspect, I did try to signal the less-than-practical 
nature of my note with the Rant and /Rant tags.

To your point about tailoring and dynamically submitting JCL, it really is an 
issue.  In a typical large z/OS shop today, dynamically tailoring and 
submitting JCL is only permitted for test environments and users.  Production 
JCL is frozen and controlled and submitted only by the scheduler software, and 
there is no political possibility to dynamically adjust the parameters even if 
it is technically feasible.

There *are* non-theoretical solutions to runaway file output.  The *ix system 
model of using disk quotas per user makes it entirely possible to imagine 
z/OS application users with reasonable disk quotas specific to the 
application (i.e., not by job but by suite of jobs).  Not the best solution?  
Maybe not, but ISTM to be better than having to predict what each and every 
process (i.e., job and file) output volume will be.

And there may well be other process models out there different from anything I 
know or imagine.  I don't claim to have an exclusive lock on ideas to replace 
what we have to deal with.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard Postpischil
Sent: Monday, June 10, 2013 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage paradigm [was: RE: Data volumes]

On 6/10/2013 11:38 AM, Farley, Peter x23353 wrote:
 Rant
 Like a few others on this list, I have often gritted my teeth at the
 necessity to estimate disk storage quantities that vary widely over
 time in a fixed manner (i.e., SPACE in JCL) when the true need is
 just to match output volume to input volume each day.

If it's that predictable, it's trivial to write code to produce an 
estimated output volume from input, and tailor and submit the 
appropriate JCL. So that's a non-issue.

 EAV or not EAV, guaranteed space or not, candidate volumes, striped
 or not striped, compressed or not compressed - all of that baggage is
 clearly non-optimal for getting the job done in a timely manner.  Why
 should allocating a simple sequential file require a team of Storage
 Administration experts to accomplish effectively?
 /Rant

There is no theoretical solution. On any system running jobs, it is 
possible for one job to monopolize available space, requiring other jobs 
to wait forever or be terminated. Even on a single job system that job 
may exhaust space. Requiring a space specification may be a PITA, but it 
guarantees that a started job will finish (subject to other 
constraints). And the SA experts, especially for sequential files, can 
be avoided with simple estimator programs.

This seems to be more of a religious war than a practical discussion.

Gerhard Postpischil
Bradford, Vermont
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Error or Journal Dataset

I had a similar problem a few months ago on z/OS 1.12. The bottom line fix
was to stop DFHSM on all the sharing systems (two in my case). Use ISPF to
delete (or rename) and redefine the DFHSM journal data set. I made it much
bigger while I was at it, but that may not be necessary. I then restarted
DFHSM with a EMERG=YES. S DFHSM,EMERG=YES in my case. That was on the
first system. Once DFHSM was up on system #1, I did a normal start on
system #2.

Ref:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2s690/1.20.2



On Mon, Jun 10, 2013 at 1:43 PM, Mike Wojtukiewicz mw...@attglobal.netwrote:

 I just got this error on a multi system shared DFHSM database. I can't
 anything recent and since the disk drives are new technology DS8 type I
 doubt there's a hardware error. The complete message is below. Any help
 would be appreciated and no we can't call IBM, it's z/OS 1.11 and they'd
 want ransom money to answer the problem. Thanks in advance

  ARC0645I DFHSM   ,DFHSM   ,7406,D,JOURNAL ,WRITE ,  205
  ARC0645I (CONT.) OVERFLOW INCOMP,020A000635,BSAM
  ARC0020I **
 *ARC0026E JOURNALING DISABLED DUE TO JOURNAL I/O ERROR.  207
  ARC0026E (CONT.) MIGRATION, BACKUP, FRBACKUP, DUMP, TAPECOPY,
  ARC0026E (CONT.)  RECYCLE, ARECOVER, AUDIT, AND EXPIREBV HELD
  ARC0020I **
  ARC0200I TRAP IN MODULE ARCILOG, CODE=0900, SNAP ONCE  209
  ARC0200I (CONT.) ADDED
  IEA794I SVC DUMP HAS CAPTURED:  211
  DUMPID=004 REQUESTED BY JOB (DFHSM   )
  DUMP TITLE= HSM MODULE ARCILOG  ERROR CODE=0900 TYPE=SNAP
  ARC0900I DFSMSHSM ERROR CODE 0900 IN MODULE ARCILOG  212
  ARC0900I (CONT.) TYPE SNAP
 *ARC0860E JOURNAL SPACE MONITORING DISABLED - RC=24.  214
  ARC0860E (CONT.) MIGRATION, BACKUP, FRBACKUP, DUMP, AND RECYC

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




-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! 
John McKown

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

Re: Storage paradigm [was: RE: Data volumes]

Too true. And, around here, our QA people appear to be glitz checkers
instead of function and reliability checkers. They have more people than
any other group and do less testing on the mainframe. They seem to check
mainly for ease of use. That is, can a totally numb skull still use
this?

On Mon, Jun 10, 2013 at 1:57 PM, Ted MacNEIL eamacn...@yahoo.ca wrote:

 As to run-away programs, they should be thoroughly checked on a test
 system before
 going into production; a run-away in production should be so rare as to be
 immaterial.

 What planet are you from?
 Programmers seem able to test everything except that one condition that
 will break in Production
 -
 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




-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! 
John McKown

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

Re: command=verify

2013-06-10 Thread gsg

I'm being told we use MacKinney Batch and the open/close commands are within 
the batch job.  We also have Mailbox,job scheduler commands in the JCL.  100's 
of them.

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

USS - OMVS.USER

2013-06-10 Thread gsg

Is there a way/command to determine all of the file systems mounted on 
OMVS.USER?

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

Re: USS - OMVS.USER

2013-06-10 Thread Mark Pace

The way I check what filesystems are mounted is  D OMVS,F
or from a shell   df


On Mon, Jun 10, 2013 at 3:58 PM, gsg gsg_...@yahoo.com wrote:

 Is there a way/command to determine all of the file systems mounted on
 OMVS.USER?

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




-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: command=verify

2013-06-10 Thread Ed Gould


Hope your auditor doesn't find out;-)

ed
On Jun 10, 2013, at 2:52 PM, gsg wrote:

I'm being told we use MacKinney Batch and the open/close commands  
are within the batch job.  We also have Mailbox,job scheduler  
commands in the JCL.  100's of them.


--
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: command=verify

2013-06-10 Thread retired mainframer

Open and close are not z/OS or JES2 commands.  (Are they JES3?)  In any
event, since they are issued by the batch programs they would not be
affected by the command=verify setting.

Since command=verify is merely an auditor recommendation, it is up to
management to either accept the current risk and not implement the
recommended setting or direct your staff to develop new procedures that will
work with the new setting.

:: -Original Message-
:: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:: Behalf Of gsg
:: Sent: Monday, June 10, 2013 12:53 PM
:: To: IBM-MAIN@LISTSERV.UA.EDU
:: Subject: Re: command=verify
::
:: I'm being told we use MacKinney Batch and the open/close commands are
:: within the batch job.  We also have Mailbox,job scheduler commands in
:: the JCL.  100's of them.

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

Re: I/O Optimization

2013-06-10 Thread Paul Gilmartin

On Mon, 10 Jun 2013 17:43:58 +, DASDBILL2 wrote:

Spanned means that a single logical record might span multiple physical 
blocks, but the way it is implemented results in having all block sizes be the 
same, except for possibly the last one, which might be short. 
 
Is uniform lengths a requirement?  Do any applications rely on being
able to calculate a cylinder and track address within a VBS data set?
Is any error reported if an interior block is short?  Does this mean
one can't append (MOD) to a VBS data set?  What happens if after
writing the last segment of a logical record the block is not filled up
to BLKSIZE but fewer bytes are available than the length of a SDW?
I suppose using null segments might relax some of these constraints.
By the way it is implemented are you referring to the behavior of
QSAM?

-- gil

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

Re: I/O Optimization

2013-06-10 Thread Barry Merrill

VBS Blocksize in dumped SMF data with RECFM=VBS,LRECL=32760,BLKSIZE=0 does NOT
produce interior same-sized blocks, as this small file from my DEV machine 
shows:
  
LENGTHFREQUENCY PERCENT 
 15712   11.45
 27995   22.90
 27998  66   95.65  

The 15712 was the last block, but other two blocks were interior blocks that
were not quite filled.  I think I recall seeing similar values of up to 4 bytes
less than full blocksize when written to tape with BLKSIZE=32760.

  


Barry


Herbert W. “Barry” Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229
ba...@mxg.com

http://www.mxg.com - FAQ has Most Answers 
ad...@mxg.com  – invoices/PO/Payment
supp...@mxg.com– technical
tel: 214 351 1966  - expect slow reply, use email 
fax: 214 350 3694  – prefer email, still works

 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, June 10, 2013 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: I/O Optimization

On Mon, 10 Jun 2013 17:43:58 +, DASDBILL2 wrote:

Spanned means that a single logical record might span multiple physical 
blocks, but the way it is implemented results in having all block sizes be the 
same, except for possibly the last one, which might be short. 
 
Is uniform lengths a requirement?  Do any applications rely on being able to 
calculate a cylinder and track address within a VBS data set?
Is any error reported if an interior block is short?  Does this mean one can't 
append (MOD) to a VBS data set?  What happens if after writing the last segment 
of a logical record the block is not filled up to BLKSIZE but fewer bytes are 
available than the length of a SDW?
I suppose using null segments might relax some of these constraints.
By the way it is implemented are you referring to the behavior of QSAM?

-- 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: I/O Optimization

2013-06-10 Thread Ted MacNEIL

I seem to recall some doc from pre-VSAM SMF (pre-MVS/SP[SE?]) that many blocks 
were written 'short'.
For example: the Type-74 (Device Activity) RMF records (a collapsed link list 
of multiple devices) were always started on a block boundary, even if there was 
'room' in the previous record.

But, it's been over 30 years since I cared about that level of detail; I don't 
know if it's still true (or, really, ever was)
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: Barry Merrill ba...@mxg.com
Sender:   IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Date: Mon, 10 Jun 2013 17:18:48 
To: IBM-MAIN@LISTSERV.UA.EDU
Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: I/O Optimization

VBS Blocksize in dumped SMF data with RECFM=VBS,LRECL=32760,BLKSIZE=0 does NOT
produce interior same-sized blocks, as this small file from my DEV machine 
shows:
  
LENGTHFREQUENCY PERCENT 
 15712   11.45
 27995   22.90
 27998  66   95.65  

The 15712 was the last block, but other two blocks were interior blocks that
were not quite filled.  I think I recall seeing similar values of up to 4 bytes
less than full blocksize when written to tape with BLKSIZE=32760.

  


Barry


Herbert W. “Barry” Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229
ba...@mxg.com

http://www.mxg.com - FAQ has Most Answers 
ad...@mxg.com  – invoices/PO/Payment
supp...@mxg.com– technical
tel: 214 351 1966  - expect slow reply, use email 
fax: 214 350 3694  – prefer email, still works

 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, June 10, 2013 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: I/O Optimization

On Mon, 10 Jun 2013 17:43:58 +, DASDBILL2 wrote:

Spanned means that a single logical record might span multiple physical 
blocks, but the way it is implemented results in having all block sizes be the 
same, except for possibly the last one, which might be short. 
 
Is uniform lengths a requirement?  Do any applications rely on being able to 
calculate a cylinder and track address within a VBS data set?
Is any error reported if an interior block is short?  Does this mean one can't 
append (MOD) to a VBS data set?  What happens if after writing the last segment 
of a logical record the block is not filled up to BLKSIZE but fewer bytes are 
available than the length of a SDW?
I suppose using null segments might relax some of these constraints.
By the way it is implemented are you referring to the behavior of QSAM?

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

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

Re: I/O Optimization

2013-06-10 Thread Ted MacNEIL

Easy for you to way!
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: Blaicher, Christopher Y. cblaic...@syncsort.com
Sender:   IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Date: Mon, 10 Jun 2013 18:31:31 
To: IBM-MAIN@LISTSERV.UA.EDU
Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: I/O Optimization

�j���qԵ��U ���\j�4P��S0-�9�1e��$*���P�A 
zٶMQ��Nj|�6�d�2�o���z%4wQb~0��@�����7�
x[d.P���~SmU ��$:x��z�(ƹ�/��\+�+vxY g�'3U6���y�~^�-��ɥ���!Q�0�
�4�B�Ss��  
՞į��ؚ��#b�$w�K_����y��q�аv\-�y�a�m0ꖇ���2�����.l�%���xY�rt��H��8k�ѵ�Mz���/����
#ٴ�}$C =�@�   �Gw���Dt��svdZ�
�=oY�ѥ�b
�R��2�G|  �#Am���nx(�VwwI'NDi��ǘ�;bp�|�;��s��IK��*+F��C

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

Anyone familiar with how z/OS CSRCESRV works?

2013-06-10 Thread Charles Mills

Is anyone familiar with the internals of CSRCESRV run-length compression?
I am familiar with RLE schemes in general -- typically a run of n identical
characters is replaced with something like escapencharacter. Does
anyone know the specifics of z/OS's scheme? What is the escape character?
How is n specified? Is it escapencharacter or
escapecharactern. How do they handle occurrences of escape in the
original data? (A typical scheme is escape1escape.)

Thanks. I'm getting a 16 from CSRCESRV SERVICE=EXPAND and I am trying to
debug. The data *is* compressed by CSRCESRV but I am obviously fouling
something up.

Charles 

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

Re: Anyone familiar with how z/OS CSRCESRV works?

2013-06-10 Thread Tony Harminc

On 10 June 2013 19:58, Charles Mills charl...@mcn.org wrote:
 Is anyone familiar with the internals of CSRCESRV run-length compression?
 I am familiar with RLE schemes in general -- typically a run of n identical
 characters is replaced with something like escapencharacter. Does
 anyone know the specifics of z/OS's scheme? What is the escape character?
 How is n specified? Is it escapencharacter or
 escapecharactern. How do they handle occurrences of escape in the
 original data? (A typical scheme is escape1escape.)

I don't know, but without looking I'd guess it's SNA Character String
(SCS) format, or perhaps part of it.  The first byte would be a String
Control Byte (SCB), with the leftmost two bits indicating what
follows, and the rightmost six containing the length of the run of
data. Of course there might well be higher level header info.

00  cc  No compressed characters follow
10  cc  Repeat blanks
11  cc  Repeat the following non-blank character
01  cc  Compacted characters follow

The above is from the NJE Formats  Protocols book, but it's
documented in lots of places, including non-mainframe ones.

It should be pretty easy to check my guess against your data -
certainly if you have raw and compressed data to compare.

Tony H.

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

Re: Anyone familiar with how z/OS CSRCESRV works?

2013-06-10 Thread Charles Mills

Thanks. I remember SCS! I've written a couple of 3270 emulators. SCS was
used for 3270 printers, right?

Does not look quite right. As I recall, cc = 0 is illegal, right? Here
is the beginning of some compressed data:

80 7f 00 01 00 02 00 03 00 04 00 05 ... so cc is 0.

Circumstantial evidence indicates that the uncompressed data might be 00 01
00 02 ... so perhaps 807f says 7f bytes of uncompressed data follow. 

Yes, I could dump the compressed data, build test cases, etc. but I have not
done that. It's inside a program so dump the uncompressed data is a
program change. I was hoping that someone had already done that and knew and
was willing to share.

I found the problem so the urgency is off. I know that in some cases I have
only part of a compressed record. This is a known and acceptable condition.
It appears the 16 (not compressed by CSRCESRV) is actually your
compressed input data ends at an illogical point. I have a possible
work-around.

Thanks again.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tony Harminc
Sent: Monday, June 10, 2013 5:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Anyone familiar with how z/OS CSRCESRV works?

On 10 June 2013 19:58, Charles Mills charl...@mcn.org wrote:
 Is anyone familiar with the internals of CSRCESRV run-length
compression?
 I am familiar with RLE schemes in general -- typically a run of n 
 identical characters is replaced with something like 
 escapencharacter. Does anyone know the specifics of z/OS's scheme?
What is the escape character?
 How is n specified? Is it escapencharacter or 
 escapecharactern. How do they handle occurrences of escape in 
 the original data? (A typical scheme is escape1escape.)

I don't know, but without looking I'd guess it's SNA Character String
(SCS) format, or perhaps part of it.  The first byte would be a String
Control Byte (SCB), with the leftmost two bits indicating what follows, and
the rightmost six containing the length of the run of data. Of course there
might well be higher level header info.

00  cc  No compressed characters follow
10  cc  Repeat blanks
11  cc  Repeat the following non-blank character
01  cc  Compacted characters follow

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

Re: I/O Optimization

2013-06-10 Thread Paul Gilmartin

On Mon, 10 Jun 2013 17:18:48 -0500, Barry Merrill wrote:

VBS Blocksize in dumped SMF data with RECFM=VBS,LRECL=32760,BLKSIZE=0 does NOT
produce interior same-sized blocks, as this small file from my DEV machine 
shows:
  
LENGTHFREQUENCY PERCENT 
 15712   11.45
 27995   22.90
 27998  66   95.65  

The 15712 was the last block, but other two blocks were interior blocks that
were not quite filled.  I think I recall seeing similar values of up to 4 bytes
less than full blocksize when written to tape with BLKSIZE=32760.
 
You may have asked for 32760, but no block is even close to that; something
appears to be overriding to half-track.  In any case, your observation strongly
contradicts DASDBILL2's (theoretical?) assertion.  No I/O errors?

-- gil

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

Re: [SPAM] Re: Storage paradigm [was: RE: Data volumes]


On 6/10/2013 2:46 PM, Farley, Peter x23353 wrote:

To your point about tailoring and dynamically submitting JCL, it
really is an issue.  In a typical large z/OS shop today, dynamically
tailoring and submitting JCL is only permitted for test environments
and users.  Production JCL is frozen and controlled and submitted
only by the scheduler software, and there is no political possibility
to dynamically adjust the parameters even if it is technically
feasible.


The scheduler can be set up to submit the tailoring job just as easily 
as the job to be tailored. And a few critical production abends should 
take care of the political aspect.



There *are* non-theoretical solutions to runaway file output.  The
*ix system model of using disk quotas per user makes it entirely
possible to imagine z/OS application users with reasonable disk
quotas specific to the application (i.e., not by job but by suite of
jobs).  Not the best solution?  Maybe not, but ISTM to be better than
having to predict what each and every process (i.e., job and file)
output volume will be.


I've worked for service bureaus that established just such quotas. My 
objections stand, as both the single job and a suite of jobs can still 
fail; the difference is the number of jobs/users impacted, not the 
principle.



And there may well be other process models out there different from
anything I know or imagine.  I don't claim to have an exclusive lock
on ideas to replace what we have to deal with


Ditto.

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: Storage paradigm [was: RE: Data volumes]