subject:"UNIT=SEP still alive $\?$"

Re: UNIT=SEP still alive (?)

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

In p06240805ce4d9305cf4f@[192.168.1.11], on 09/04/2013
   at 09:55 PM, Robert A. Rosenberg hal9...@panix.com said:

Except for one MAJOR difference - PASS will leave the tape mounted 
(although it might rewind it) while KEEP will unload the tape 

Not if you specify RETAIN. Unfortunately, there's no text unit for
RETAIN, at least prior to z/OS V2R1, and probably not there either.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: UNIT=SEP still alive (?)

2013-09-04 Thread Shmuel Metz (Seymour J.)

In
caarmm9tsfrlc3zzj2fspy8kmu90crt8j714oxgvijlz7q4y...@mail.gmail.com,
on 09/03/2013
   at 10:43 PM, Tony Harminc t...@harminc.net said:

But Dynalloc did not exist until MVS,

Not as a supported facility for user code, but it was there for use by
DAIR in TSO. As I recall, the interface was different.

and MVS has never restricted its use to TSO.

True, but PASS is still intended for the situation where there is a
receiving DD in a subsequent step. Within the same step, KEEP and PASS
are equivalent.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: UNIT=SEP still alive (?)

2013-09-04 Thread Tony Harminc

On 4 September 2013 09:41, Shmuel Metz (Seymour J.)
shmuel+...@patriot.net wrote:

But Dynalloc did not exist until MVS,

 Not as a supported facility for user code, but it was there for use by
 DAIR in TSO. As I recall, the interface was different.

There was an SVC 99 in MVT, but it wasn't dynalloc; it was a
TSO-only service routine between DAIR and DADSM and such, with a
completely different parameter list and return values, and much less
function. (Some Dynalloc functions were done in DAIR itself without
calling the old SVC 99, e.g. allocation information retrieval.) A
Dynalloc SVC 99 invocation requires that the high bit of R1 be on to
show that it's the new format. Nowadays I believe SVC 99, when called
with the DAIR-type list, builds a modern Dynalloc list and falls
into Dynalloc processing. Since it was allowable to link-edit DAIR
into one's program, this calling format is in theory supported
forever.

Tony H.

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

Re: UNIT=SEP still alive (?)

2013-09-04 Thread Robert A. Rosenberg

At 09:41 -0400 on 09/04/2013, Shmuel Metz (Seymour J.) wrote about 
Re: UNIT=SEP still alive (?):



True, but PASS is still intended for the situation where there is a
receiving DD in a subsequent step. Within the same step, KEEP and PASS
are equivalent.


Except for one MAJOR difference - PASS will leave the tape mounted 
(although it might rewind it) while KEEP will unload the tape 
(requiring the tape to need to be reloaded to read another file on 
the tape) at CLOSE. I do not remember when when the final disposition 
of a PASSed file is done if it does not get referenced in a 
subsequent step. I have the impression that it occurs at JOB TERM 
time. BTW: If the SVC99 (with DISP=PASS) is done in the last/only 
step then this becomes a non-issue if the intent is to dynamically 
access multiple files on the same tape volume and you use DISP=PASS 
to keep the volume mounted.


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

Re: UNIT=SEP still alive (?)

2013-09-04 Thread Robert A. Rosenberg

At 23:57 -0500 on 09/03/2013, Ed Gould wrote about Re: UNIT=SEP still 
alive (?):



On Sep 3, 2013, at 3:50 PM, Robert A. Rosenberg wrote:

MY memory from 20 years ago. NOT ALL Datasets are supported with SVC 
99 (good indication is GDG but there are othrs).


If you say so. I see no reason why GDGs would/should not be supported 
via SVC99 but I am not sure.




Ed

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


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

Re: UNIT=AFF was Re: UNIT=SEP still alive (?)

2013-09-03 Thread R.S.

W dniu 2013-09-02 19:54, Clark Morris pisze:

On 1 Sep 2013 07:03:23 -0700, in bit.listserv.ibm-main you wrote:

On 9/1/2013 6:47 AM, Tom Russell wrote:

In the case of multiple steps each allocating one file on the same
tape, and no AFF parameter used, there was (is?) a significant
difference between JES2 and JES3.

For allocating tape drives within a step (and UNIT=AFF is only within
a step) UNIT=AFF is still needed to allocate SORTIN and SORTOUT in
SORT operations to the same drive in both JES2 and JES3 (or for any
other non-concurrent allocations where it is possible to share the
drive.
IMHO it's bad idea to use tapes for such operations. Tapes nowadays are
for backups, dumps, ML2, etc. but not direct application use.

My €0.02

--
Radoslaw Skorupka
Lodz, Poland

--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.

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

Re: UNIT=AFF was Re: UNIT=SEP still alive (?)

2013-09-03 Thread R.S.

W dniu 2013-09-03 12:19, Paul Gilmartin pisze:

On 2013-09-03, at 00:05, R.S. wrote:

IMHO it's bad idea to use tapes for such operations. Tapes nowadays are for backups, dumps, ML2, etc. but not direct application use.

My €0.02

We are still committed to deliver some products (or at least
their corrective service) to some customers on tape.

Oh, yes, software installation, I didn't mention it.
(Disclaimer: I'm fully aware that customer decides, so you have to
follow his requirements.)

However ... what tape format do you deliver?
I'm pretty sure you don't deliver virtual tapes ;-)
3480 aka 18 trk aka CST?
3490E aka 36 trk aka ECCST?
Please note, nobody manufactures new media (although it is still
possible to purchase already produced carts). It's even worse with the
drives. New drives are unavailable for many years, service of existing
ones is very limited.

So, what tape media to choose? Obsolete MAGSTAR family?
Or maybe Jaguar, but maybe someone decided to use STK tapes?

Note, the drive used just for software installation purposes is very
expensive toy, it's definitely not a 3,5 FDD. The cost of single
(first) Jaguar drive can be as $100k high.

A lot of money spent just to insist on tape media for the installation.

--
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: UNIT=SEP still alive (?)

2013-09-03 Thread Shmuel Metz (Seymour J.)

In 6708946340357622.wa.paulgboulderaim@listserv.ua.edu, on
09/02/2013
   at 05:13 PM, Paul Gilmartin paulgboul...@aim.com said:

And what's the TU corresponding to PASS?

DALNDISP (0005) and DALCDISP (0006)with value X'02' is close. PASS is
intended for multi-step jobs, and TSO sessions are supposed to be
single step.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: UNIT=SEP still alive (?)

2013-09-03 Thread Tony Harminc

On 3 September 2013 09:33, Shmuel Metz (Seymour J.)
shmuel+...@patriot.net wrote:
 In 6708946340357622.wa.paulgboulderaim@listserv.ua.edu, on
 09/02/2013
at 05:13 PM, Paul Gilmartin paulgboul...@aim.com said:

And what's the TU corresponding to PASS?

 DALNDISP (0005) and DALCDISP (0006)with value X'02' is close. PASS is
 intended for multi-step jobs, and TSO sessions are supposed to be
 single step.

But Dynalloc did not exist until MVS, and MVS has never restricted its
use to TSO. So why should TSO environmental restrictions have anything
to do with Dynalloc?

Tony H.

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

Re: UNIT=SEP still alive (?)

2013-09-03 Thread Robert A. Rosenberg

At 09:33 -0400 on 09/03/2013, Shmuel Metz (Seymour J.) wrote about 
Re: UNIT=SEP still alive (?):



In 6708946340357622.wa.paulgboulderaim@listserv.ua.edu, on
09/02/2013
   at 05:13 PM, Paul Gilmartin paulgboul...@aim.com said:


And what's the TU corresponding to PASS?


DALNDISP (0005) and DALCDISP (0006)with value X'02' is close. PASS is
intended for multi-step jobs, and TSO sessions are supposed to be
single step.


DYNALLOC (SVC99) is not restricted to use by TSO. There are many 
Batch utilities which use it. As an example, there are SORTs which 
allocate their work files via SVC99.


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

Re: UNIT=SEP still alive (?)

2013-09-03 Thread Ed Gould


On Sep 3, 2013, at 3:50 PM, Robert A. Rosenberg wrote:

MY memory from 20 years ago. NOT ALL Datasets are supported with SVC  
99 (good indication is GDG but there are othrs).



Ed

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

Re: UNIT=SEP still alive (?)

2013-09-02 Thread Paul Gilmartin

On Sun, 1 Sep 2013 10:53:19 -0400, DanD wrote:

Device allocation for JES2 occurs at step initiation.
Each step would allocate a single device.  If RETAIN was coded AVR would
recognize the mounted volume and reuse the same device for the next step.
 
Let's talk about DYNALLOC.  AFAICT, DYNALLOC has no analogue of RETAIN.
It unloads the volume after each FREE, and it must be remounted.  In
desperation, I supplied a DD LABEL=(nn,BLP) for each file (including the
labels) so I could process the entire volume with a Rexx EXEC.

Bruce Black once generously performed an experiment and concluded that
there's no way to DYNALLOC two or more data sets on the same volume
concurrently although JCL DD allocation has no problem with it.  (Of course
at most one of those data sets can be open at a time.)

Why the DYNALLOC restriction?  The message adds insult to injury by
saying ... ANOTHER JOB OR USER.  False.  It's the same job and user.
I wonder whether the message alludes to the intent of the restriction,
and there's an aboriginal logic error in that DYNALLOC fails to recognize
that it's the same user, same job, and same job step?

-- gil

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

UNIT=AFF was Re: UNIT=SEP still alive (?)

2013-09-02 Thread Clark Morris

On 1 Sep 2013 07:03:23 -0700, in bit.listserv.ibm-main you wrote:

On 9/1/2013 6:47 AM, Tom Russell wrote:
 In the case of multiple steps each allocating one file on the same 
 tape, and no AFF parameter used, there was (is?) a significant 
 difference between JES2 and JES3.

For allocating tape drives within a step (and UNIT=AFF is only within
a step) UNIT=AFF is still needed to allocate SORTIN and SORTOUT in
SORT operations to the same drive in both JES2 and JES3 (or for any
other non-concurrent allocations where it is possible to share the
drive.

Clark Morris

 JES2 would allocate as many tapes as there were steps, and rewind an 
 unload the volume after each step and issue a mount for the same 
 volume on the next tape drive.  JES3 had Tape High-Water Setup, and 
 would allocate a single tape unit for the volume, and not rewind and 
 unload it between steps.

 The only fix for JES2 was to add UNIT=AFF  and DISP=(,PASS) to the 
 JCL.  JES3 didn't mind that you left them out.

 I can't test this as I have no JES3 system.

Yes, It magically behaves almost as if JES3 under the covers issues an 
MVS MOUNT command for the tape volume and then later issues the MVS 
UNLOAD command at exactly the right time.

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

Re: UNIT=SEP still alive (?)

2013-09-02 Thread Robert A. Rosenberg

At 10:50 -0500 on 09/02/2013, Paul Gilmartin wrote about Re: UNIT=SEP 
still alive (?):



Bruce Black once generously performed an experiment and concluded that
there's no way to DYNALLOC two or more data sets on the same volume
concurrently although JCL DD allocation has no problem with it.  (Of course
at most one of those data sets can be open at a time.)


Wouldn't DISP=PASS handle this so the volume is not unloaded and thus 
allow a 2nd allocation (ie: To another file on the tape)?


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

Re: UNIT=SEP still alive (?)

2013-09-02 Thread efinnell15

IIRC still need referback incrementing label as you go for multivolume files.

//DD1 LABEL=(1,SL)
//DD2 LABEL=(2,SL),VOL=REF=DD1
//DD3 LABEL=(3,SL),VOL=REF=DD2



In a message dated 09/02/13 15:31:09 Central Daylight Time, hal9...@panix.com 
writes:
DISP=PASS handle this so the volume is not unloaded and thus 
allow a 2nd allocation (ie: To another file on the tape)? 

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

Re: UNIT=SEP still alive (?)

2013-09-02 Thread Paul Gilmartin

On Mon, 2 Sep 2013 17:05:23 -0500, efinnell15 wrote:

IIRC still need referback incrementing label as you go for multivolume files.

//DD1 LABEL=(1,SL)
//DD2 LABEL=(2,SL),VOL=REF=DD1
//DD3 LABEL=(3,SL),VOL=REF=DD2
 
Yes, but I was trying to use DYNALLOC.  POSITION is easy, but
what's the SVC 99 TU corresponding to VOL=REF?

In a message dated 09/02/13 15:31:09 Central Daylight Time, hal9...@panix.com 
writes:
DISP=PASS handle this so the volume is not unloaded and thus
allow a 2nd allocation (ie: To another file on the tape)?
 
And what's the TU corresponding to PASS?

And is either of these supported by BPXWDYN or ALLOCATE?

-- gil

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

Re: UNIT=SEP still alive (?)

2013-09-01 Thread Shmuel Metz (Seymour J.)

In
CAE1XxDH4S9kUDN4T=psp43g0n_qpq7vkzo3syjct4z6qvkw...@mail.gmail.com,
on 08/30/2013
   at 08:43 AM, John Gilmore jwgli...@gmail.com said:

SEP= dates back to the early days of OS/360, and it was then
unproblematic.  Device addresses comprised of just three hexadecimal
digits were part numbers, immediately decodable into their three
channelcontrol unitdevice components,

Not even close.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: UNIT=SEP still alive (?)

2013-09-01 Thread Tom Russell

In the case of multiple steps each allocating one file on the same tape, 
and no AFF parameter used, there was (is?) a significant difference 
between JES2 and JES3.


JES2 would allocate as many tapes as there were steps, and rewind an 
unload the volume after each step and issue a mount for the same volume 
on the next tape drive.  JES3 had Tape High-Water Setup, and would 
allocate a single tape unit for the volume, and not rewind and unload it 
between steps.


The only fix for JES2 was to add UNIT=AFF  and DISP=(,PASS) to the JCL.  
JES3 didn't mind that you left them out.


I can't test this as I have no JES3 system.

Tom Russell
On 2013-09-01 12:00 AM, IBM-MAIN automatic digest system wrote:

Date:Sat, 31 Aug 2013 02:19:26 -0400
From:Gerhard Postpischilgerh...@valley.net
Subject: Re: UNIT=SEP still alive (?)

On 8/30/2013 9:22 PM, Robert A. Rosenberg wrote:

I know for multi-volume datasets UNIT=(TAPE,2) handled the mount of
volume3 while volume1 rewound and unloaded. I do not remember if you
could allocate 2 units and have concatenated input volumes alternate
between them. AVR might have helped since it say Find the device with
the Tape Volume and allocate the DD to it but I do not think it would
handle the case where you want to reuse a drive where the tape has
unloaded - It was for allocation at step start.

All true, but the thread is about distinct DD cards, beginning with SEP,
and drifting into AFF. Joel Ewing complained that the default takes too
many drives, but hasn't offered a practical means for IBM to allocate
drives, when the user specifies neither SEP nor AFF, that would allow
reducing the allocation to less than one drive per DD.

Gerhard Postpischil
Bradford, Vermont


--
Tom Russell

“Stay calm. Be brave. Wait for the signs.” — Jasper FriendlyBear
“... and remember to leave good news alone.” — Gracie HeavyHand

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

Re: UNIT=SEP still alive (?)

2013-09-01 Thread Ed Jaffe


On 9/1/2013 6:47 AM, Tom Russell wrote:
In the case of multiple steps each allocating one file on the same 
tape, and no AFF parameter used, there was (is?) a significant 
difference between JES2 and JES3.


JES2 would allocate as many tapes as there were steps, and rewind an 
unload the volume after each step and issue a mount for the same 
volume on the next tape drive.  JES3 had Tape High-Water Setup, and 
would allocate a single tape unit for the volume, and not rewind and 
unload it between steps.


The only fix for JES2 was to add UNIT=AFF  and DISP=(,PASS) to the 
JCL.  JES3 didn't mind that you left them out.


I can't test this as I have no JES3 system.


Yes, It magically behaves almost as if JES3 under the covers issues an 
MVS MOUNT command for the tape volume and then later issues the MVS 
UNLOAD command at exactly the right time.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: UNIT=SEP still alive (?)

2013-09-01 Thread DanD


From: Tom Russell
...
JES2 would allocate as many tapes as there were steps, and rewind an
unload the volume after each step and issue a mount for the same volume
on the next tape drive.
...

Not quite Tom.

Device allocation for JES2 occurs at step initiation.
Each step would allocate a single device.  If RETAIN was coded AVR would 
recognize the mounted volume and reuse the same device for the next step.


Dan D 


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

Re: UNIT=SEP still alive (?)

2013-08-31 Thread Gerhard Postpischil


On 8/30/2013 9:22 PM, Robert A. Rosenberg wrote:

I know for multi-volume datasets UNIT=(TAPE,2) handled the mount of
volume3 while volume1 rewound and unloaded. I do not remember if you
could allocate 2 units and have concatenated input volumes alternate
between them. AVR might have helped since it say Find the device with
the Tape Volume and allocate the DD to it but I do not think it would
handle the case where you want to reuse a drive where the tape has
unloaded - It was for allocation at step start.


All true, but the thread is about distinct DD cards, beginning with SEP, 
and drifting into AFF. Joel Ewing complained that the default takes too 
many drives, but hasn't offered a practical means for IBM to allocate 
drives, when the user specifies neither SEP nor AFF, that would allow 
reducing the allocation to less than one drive per DD.


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: UNIT=SEP still alive (?)

2013-08-31 Thread Ron Hawkins

I forget when it was, but quite some time ago, perhaps pre-SMS, allocation
started massaging the Eligible Device list so that unit addresses already
allocated to a DD in a step were moved to the bottom of the EDL.

The reason for this was to prevent the behavior I think you are describing
below - all new datasets allocated to the same volume because it was at the
top of the EDL. This is why you'll see all SORTWKnn datasets allocated to
different volumes if the number of eligible devices is greater than the
number of new datasets.

I think this change to allocation may have made UNIT=SEP redundant.

Ron

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of efinnell15
 Sent: Friday, August 30, 2013 11:39 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: [IBM-MAIN] UNIT=SEP still alive (?)
 
 We had one in early XA ESP where techy changed a few jobs and had
 UNIT=3800 for SORTWKs  and it tried to honor it. Can you say wreck?
 
 
 
 In a message dated 08/30/13 13:23:33 Central Daylight Time,
 gerh...@valley.net writes:
 He reported that a CoBOL programmer submitted a sort job with all sort
 work files on the same 2321 data cell drive!
 
 --
 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: UNIT=SEP still alive (?)

2013-08-30 Thread R.S.

W dniu 2013-08-29 23:09, Ted MacNEIL pisze:

I started as a JCL jockey in Prod Support, under MVS.
It was still supported, then (pre-XA).
-

Supported or just syntax-checked and ignored ?

--
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: UNIT=SEP still alive (?)

2013-08-30 Thread R.S.

W dniu 2013-08-29 23:33, John Gilmore pisze:

The z/OS V1R9 MVS JCL Reference--The 12th edition of 2007 September
and the oldest one I have on my workstation--describes AFF, SEP,
SPLIT, and SUBALLOC as obsolete subparameters on page 5-18.

It's still there (at least at z/OS 1.13 level).
However this is only information about forbidden symbol names. No clue
about previous meaning of the parameters and (more important) when it
can be used. The last one means where such keyword is syntax-checked and
ignored.
Not a big deal, but if you want to check whether UNIT=SEP=DD1 will work
you have to try it ...or ask author to avoid obsolete parameters.

--
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: UNIT=SEP still alive (?)

2013-08-30 Thread Ted MacNEIL

It seemed to work.
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: R.S. r.skoru...@bremultibank.com.pl
Sender:   IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Date: Fri, 30 Aug 2013 10:38:57 
To: IBM-MAIN@LISTSERV.UA.EDU
Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UNIT=SEP still alive (?)

W dniu 2013-08-29 23:09, Ted MacNEIL pisze:
 I started as a JCL jockey in Prod Support, under MVS.
 It was still supported, then (pre-XA).
 -

Supported or just syntax-checked and ignored ?

-- 
Radoslaw Skorupka
Lodz, Poland

--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorised to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive. 

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 168.555.904 złotych.

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

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

Re: UNIT=SEP still alive (?)

2013-08-30 Thread R.S.

W dniu 2013-08-30 11:50, Ted MacNEIL pisze:

It seemed to work.
-

Tiny Harminc wrote:

I slightly more than vaguely remember it the same way. SEP=
disappeared (was ignored) with MVS, i.e. OS/VS2 2.0, because it
limited the then-new SRM's ability to swap a job in or out to control
the I/O workload on a channel.

Personally, I'm just to young to remember those keyword. In 70's I used
computer (paper!) tape to make paper stars on Christmas tree. It was my only
contact with IT then ;-)

--
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: UNIT=SEP still alive (?)

2013-08-30 Thread John Gilmore

Tony Harminc wrote:

begin extract
And on that note, I even more vaguely remember that SEP= (in pre-MVS
OSs) was done at the channel level rather then the device, but that's
so vague as to be unreliable.
/end extract

and, unlike many such, this particular vague memory is veridical.

SEP= dates back to the early days of OS/360, and it was then
unproblematic.  Device addresses comprised of just three hexadecimal
digits were part numbers, immediately decodable into their three
channelcontrol unitdevice components, so that, for example, 01F
meant [multiplexor] channel 0, control unit 1, and device F and
specified, unambiguously, the single path to/from a device.

ACPs first compromised this simple scheme, and it is now all but meaningless.

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: UNIT=SEP still alive (?)

2013-08-30 Thread Clark Morris

On 29 Aug 2013 20:39:00 -0700, in bit.listserv.ibm-main you wrote:

On Thu, Aug 29, 2013 at 6:25 PM, Clark Morris cfmpub...@ns.sympatico.ca 
wrote:
 On 29 Aug 2013 14:33:21 -0700, in bit.listserv.ibm-main you wrote:

The z/OS V1R9 MVS JCL Reference--The 12th edition of 2007 September
and the oldest one I have on my workstation--describes AFF, SEP,
SPLIT, and SUBALLOC as obsolete subparameters on page 5-18.

 I can see SEP, SPLIT and SUBALLOC being obsolete but AFF still should
 be useful in conserving device use for tape drives.  For example
 SORTIN and SORTOUT many times were allocated that way.

UNIT=REF=DATA.SET.NAME,LABEL=(2,SL) does work.

While I don't have a JCL manual at home,
VOL=REF=data.set.name,LABEL=(n,SL) is the best way to put multiple
files on the same volume (for output
VOL=REF=*.stepname.procstepname.ddname works better).  UNIT=AFF=ddname
is for putting things on different volumes using the same device.

CLark Morris 

 Clark Morris

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: UNIT=SEP still alive (?)

2013-08-30 Thread efinnell15

We had one in early XA ESP where techy changed a few jobs and had UNIT=3800 for 
SORTWKs  and it tried to honor it. Can you say wreck? 



In a message dated 08/30/13 13:23:33 Central Daylight Time, gerh...@valley.net 
writes:
He reported that a CoBOL programmer submitted a sort job with 
all sort work files on the same 2321 data cell drive! 

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

Re: UNIT=SEP still alive (?)

2013-08-30 Thread Joel C. Ewing

On 08/30/2013 08:44 AM, Clark Morris wrote:
 On 29 Aug 2013 20:39:00 -0700, in bit.listserv.ibm-main you wrote:
 
 On Thu, Aug 29, 2013 at 6:25 PM, Clark Morris cfmpub...@ns.sympatico.ca 
 wrote:
 On 29 Aug 2013 14:33:21 -0700, in bit.listserv.ibm-main you wrote:

 The z/OS V1R9 MVS JCL Reference--The 12th edition of 2007 September
 and the oldest one I have on my workstation--describes AFF, SEP,
 SPLIT, and SUBALLOC as obsolete subparameters on page 5-18.

 I can see SEP, SPLIT and SUBALLOC being obsolete but AFF still should
 be useful in conserving device use for tape drives.  For example
 SORTIN and SORTOUT many times were allocated that way.

 UNIT=REF=DATA.SET.NAME,LABEL=(2,SL) does work.
 
 While I don't have a JCL manual at home,
 VOL=REF=data.set.name,LABEL=(n,SL) is the best way to put multiple
 files on the same volume (for output

 VOL=REF=*.stepname.procstepname.ddname works better).  UNIT=AFF=ddname
 is for putting things on different volumes using the same device.
 
 CLark Morris 

 Clark Morris

 John Gilmore, Ashland, MA 01721 - USA

...
I don't see any UNIT=REF=dsname syntax in my JCL manual, only
UNIT=AFF=ddname and VOL=REF=dsname.  I also don't see the need for
UNIT=AFF disappearing anytime soon.

 A highly counter-intuitive case for many new users used to be the case
of a DDNAME with concatenated tape data sets, where the data sets are
obviously constrained to access in sequential fashion; but the MVS
default (without UNIT=AFF) was to allocate separate tape drives
concurrently for each of the concatenated tape data sets, and then
proceed to use them one at a time -- a highly antisocial act in
environments with limited drives.  Especially in the case of tape data
sets, constraining the number of units via a dataset name reference
rather than DD reference wouldn't make sense, since tape data set names
aren't required to be cataloged and might not be unique even within the
same job step!
-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: UNIT=SEP still alive (?)

2013-08-30 Thread Robert A. Rosenberg

At 14:23 -0400 on 08/30/2013, Gerhard Postpischil wrote about Re: 
UNIT=SEP still alive (?):



This appears to be a no-win situation for IBM. Our systems used AVR, and
had enough drives, so that for us it was more important to reduce tape
mount delays (while the job sat occupying limited storage). A full tape
can take up to 4 minutes to rewind ...


I know for multi-volume datasets UNIT=(TAPE,2) handled the mount of 
volume3 while volume1 rewound and unloaded. I do not remember if you 
could allocate 2 units and have concatenated input volumes alternate 
between them. AVR might have helped since it say Find the device 
with the Tape Volume and allocate the DD to it but I do not think it 
would handle the case where you want to reuse a drive where the tape 
has unloaded - It was for allocation at step start.


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

UNIT=SEP still alive (?)

2013-08-29 Thread R.S.

I just found the following in some IBM same JCL (job, actually):
//SYSUT1 DD UNIT=(SYSDA,SEP=(SORTLIB,SYSLMOD,SYSLIN)),
// SPACE=(1000,(60,20))

Last change date is half of the 2013 (creation date is probably 2005 or so).
As far as I know SEP is syntax checked and ignored for many moons, at
least since first OS/390, but I vaguely remember somebody told me it was
obsoleted with advent of MVS.

--
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: UNIT=SEP still alive (?)

2013-08-29 Thread Pommier, Rex R.

OK, what does (did) SEP= do?  The only thing the JCL reference says is that you 
can't use it as a JCL symbol in certain types of jobs.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Thursday, August 29, 2013 3:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: UNIT=SEP still alive (?)

I just found the following in some IBM same JCL (job, actually):
//SYSUT1 DD UNIT=(SYSDA,SEP=(SORTLIB,SYSLMOD,SYSLIN)),
// SPACE=(1000,(60,20))

Last change date is half of the 2013 (creation date is probably 2005 or so).
As far as I know SEP is syntax checked and ignored for many moons, at least 
since first OS/390, but I vaguely remember somebody told me it was obsoleted 
with advent of MVS.

--
Radoslaw Skorupka
Lodz, Poland

--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorised to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88.
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 168.555.904 złotych.

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

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

NOTICE:  This e-mail message, including any attachments and appended messages, 
is for the sole use of the intended recipients and may contain confidential and 
legally privileged information.
If you are not the intended recipient, any review, dissemination, distribution, 
copying, storage or other use of all or any portion of this message is strictly 
prohibited.
If you received this message in error, please immediately notify the sender by 
reply e-mail and delete this message in its entirety.

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

Re: UNIT=SEP still alive (?)

2013-08-29 Thread R.S.

W dniu 2013-08-29 22:48, Pommier, Rex R. pisze:

OK, what does (did) SEP= do? The only thing the JCL reference says is that you
can't use it as a JCL symbol in certain types of jobs.

See ancient (really old!) version of JCL manual. I don't have any here,
but my failing memory says it was used for unit (device) separation.
The example I presented says: create SYSUT1 dataset, on some disk
belonging to SYSDA, but avoid using devices already used for the
following datasets: SORLTIB ,etc

--
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: UNIT=SEP still alive (?)

2013-08-29 Thread John McKown

SEP= was supposed to guarantee that the data sets were placed on SEParate
volumes. Likely to enhance concurrent I/O overlap.


On Thu, Aug 29, 2013 at 3:48 PM, Pommier, Rex R.
rex.pomm...@cnasurety.comwrote:

 OK, what does (did) SEP= do?  The only thing the JCL reference says is
 that you can't use it as a JCL symbol in certain types of jobs.

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of R.S.
 Sent: Thursday, August 29, 2013 3:18 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: UNIT=SEP still alive (?)

 I just found the following in some IBM same JCL (job, actually):
 //SYSUT1 DD UNIT=(SYSDA,SEP=(SORTLIB,SYSLMOD,SYSLIN)),
 // SPACE=(1000,(60,20))

 Last change date is half of the 2013 (creation date is probably 2005 or
 so).
 As far as I know SEP is syntax checked and ignored for many moons, at
 least since first OS/390, but I vaguely remember somebody told me it was
 obsoleted with advent of MVS.

 --
 Radoslaw Skorupka
 Lodz, Poland






 --
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku
 przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
 jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś
 adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej
 przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie,
 rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie
 zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo,
 prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale
 usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub
 zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is
 intended solely for business use of the addressee. This e-mail may only be
 received by the addressee and may not be disclosed to any third parties. If
 you are not the intended addressee of this e-mail or the employee
 authorised to forward it to the addressee, be advised that any
 dissemination, copying, distribution or any other similar activity is
 legally prohibited and may be punishable. If you received this e-mail by
 mistake please advise the sender immediately by using the reply facility in
 your e-mail software and delete permanently this e-mail including any
 copies of it either printed or saved to hard drive.

 BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00,
 fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
 Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego
 Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP:
 526-021-50-88.
 Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w
 całości wpłacony) wynosi 168.555.904 złotych.


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

 The information contained in this e-mail may contain confidential and/or
 privileged information and is intended for the sole use of the intended
 recipient. If you are not the intended recipient, you are hereby notified
 that any unauthorized use, disclosure, distribution or copying of this
 communication is strictly prohibited and that you will be held responsible
 for any such unauthorized activity, including liability for any resulting
 damages. As appropriate, such incident(s) may also be reported to law
 enforcement. If you received this e-mail in error, please reply to sender
 and destroy or delete the message and any attachments. Thank you.



 NOTICE:  This e-mail message, including any attachments and appended
 messages, is for the sole use of the intended recipients and may contain
 confidential and legally privileged information.
 If you are not the intended recipient, any review, dissemination,
 distribution, copying, storage or other use of all or any portion of this
 message is strictly prohibited.
 If you received this message in error, please immediately notify the
 sender by reply e-mail and delete this message in its entirety.


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




-- 
As of next week, passwords will be entered in Morse code.

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: UNIT=SEP still alive (?)

2013-08-29 Thread Paul Gilmartin

On 2013-08-29 14:56, John McKown wrote:
 SEP= was supposed to guarantee that the data sets were placed on SEParate
 volumes. Likely to enhance concurrent I/O overlap.
  
This was probably most effective if yours was the only job
running in the system at that instant.

 On Thu, Aug 29, 2013 at 3:48 PM, Pommier, Rex R. wrote:
 
 OK, what does (did) SEP= do?  The only thing the JCL reference says is
 that you can't use it as a JCL symbol in certain types of jobs.
 
Probably jobs started by operator commands, which supported
an abbreviated syntax for overrides.

So they removed the function but retained the restriction.  A
triumph of compatibility over common sense.

 //SYSUT1 DD UNIT=(SYSDA,SEP=(SORTLIB,SYSLMOD,SYSLIN)),

-- gil

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

Re: UNIT=SEP still alive (?)

2013-08-29 Thread Ted MacNEIL

I started as a JCL jockey in Prod Support, under MVS.
It was still supported, then (pre-XA).
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: John McKown john.archie.mck...@gmail.com
Sender:   IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Date: Thu, 29 Aug 2013 15:56:49 
To: IBM-MAIN@LISTSERV.UA.EDU
Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UNIT=SEP still alive (?)

SEP= was supposed to guarantee that the data sets were placed on SEParate
volumes. Likely to enhance concurrent I/O overlap.


On Thu, Aug 29, 2013 at 3:48 PM, Pommier, Rex R.
rex.pomm...@cnasurety.comwrote:

 OK, what does (did) SEP= do?  The only thing the JCL reference says is
 that you can't use it as a JCL symbol in certain types of jobs.

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of R.S.
 Sent: Thursday, August 29, 2013 3:18 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: UNIT=SEP still alive (?)

 I just found the following in some IBM same JCL (job, actually):
 //SYSUT1 DD UNIT=(SYSDA,SEP=(SORTLIB,SYSLMOD,SYSLIN)),
 // SPACE=(1000,(60,20))

 Last change date is half of the 2013 (creation date is probably 2005 or
 so).
 As far as I know SEP is syntax checked and ignored for many moons, at
 least since first OS/390, but I vaguely remember somebody told me it was
 obsoleted with advent of MVS.

 --
 Radoslaw Skorupka
 Lodz, Poland






 --
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku
 przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
 jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś
 adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej
 przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie,
 rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie
 zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo,
 prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale
 usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub
 zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is
 intended solely for business use of the addressee. This e-mail may only be
 received by the addressee and may not be disclosed to any third parties. If
 you are not the intended addressee of this e-mail or the employee
 authorised to forward it to the addressee, be advised that any
 dissemination, copying, distribution or any other similar activity is
 legally prohibited and may be punishable. If you received this e-mail by
 mistake please advise the sender immediately by using the reply facility in
 your e-mail software and delete permanently this e-mail including any
 copies of it either printed or saved to hard drive.

 BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00,
 fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
 Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego
 Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP:
 526-021-50-88.
 Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w
 całości wpłacony) wynosi 168.555.904 złotych.


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

 The information contained in this e-mail may contain confidential and/or
 privileged information and is intended for the sole use of the intended
 recipient. If you are not the intended recipient, you are hereby notified
 that any unauthorized use, disclosure, distribution or copying of this
 communication is strictly prohibited and that you will be held responsible
 for any such unauthorized activity, including liability for any resulting
 damages. As appropriate, such incident(s) may also be reported to law
 enforcement. If you received this e-mail in error, please reply to sender
 and destroy or delete the message and any attachments. Thank you.



 NOTICE:  This e-mail message, including any attachments and appended
 messages, is for the sole use of the intended recipients and may contain
 confidential and legally privileged information.
 If you are not the intended recipient, any review, dissemination,
 distribution, copying, storage or other use of all or any portion of this
 message is strictly prohibited.
 If you received this message in error, please immediately notify the
 sender by reply e-mail and delete this message in its entirety.


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




-- 
As of next week, passwords will be entered in Morse code.

Maranatha! 
John McKown

Re: UNIT=SEP still alive (?)

2013-08-29 Thread Binyamin Dissen

Back in Ye Olde days, it allowed for specifying that a different device
address be used thus improving I/O performance.

On Thu, 29 Aug 2013 20:48:30 + Pommier, Rex R.
rex.pomm...@cnasurety.com wrote:

:OK, what does (did) SEP= do?  The only thing the JCL reference says is that 
you can't use it as a JCL symbol in certain types of jobs.
:
:-Original Message-
:From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of R.S.
:Sent: Thursday, August 29, 2013 3:18 PM
:To: IBM-MAIN@LISTSERV.UA.EDU
:Subject: UNIT=SEP still alive (?)
:
:I just found the following in some IBM same JCL (job, actually):
://SYSUT1 DD UNIT=(SYSDA,SEP=(SORTLIB,SYSLMOD,SYSLIN)),
:// SPACE=(1000,(60,20))
:
:Last change date is half of the 2013 (creation date is probably 2005 or so).
:As far as I know SEP is syntax checked and ignored for many moons, at least 
since first OS/390, but I vaguely remember somebody told me it was obsoleted 
with advent of MVS.
:
:--
:Radoslaw Skorupka
:Lodz, Poland

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: UNIT=SEP still alive (?)

2013-08-29 Thread DanD

It was also useful when creating a backup so that the backup was not on the 
same device as the original.


I noticed this...

JCL example
z/OS V1R12.0 Metal C Programming Guide and Reference
SA23-2225-03
...
//SYSUT1   DD  UNIT=(SYSDA,SEP=SYSLIB),SPACE=(CYL,(10,5)),DSN=SYSUT1

Dan

-Original Message- 
From: Binyamin Dissen



Back in Ye Olde days, it allowed for specifying that a different device
address be used thus improving I/O performance.

On Thu, 29 Aug 2013 20:48:30 + Pommier, Rex R.
Rex.Pommier wrote:

:OK, what does (did) SEP= do?  The only thing the JCL reference says is 
that you can't use it as a JCL symbol in certain types of jobs.

:
:-Original Message-
:
:I just found the following in some IBM same JCL (job, actually):
://SYSUT1 DD UNIT=(SYSDA,SEP=(SORTLIB,SYSLMOD,SYSLIN)),
:// SPACE=(1000,(60,20))
:
:Last change date is half of the 2013 (creation date is probably 2005 or 
so).
:As far as I know SEP is syntax checked and ignored for many moons, at 
least since first OS/390, but I vaguely remember somebody told me it was 
obsoleted with advent of MVS.


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

Re: UNIT=SEP still alive (?)

2013-08-29 Thread John Gilmore

The z/OS V1R9 MVS JCL Reference--The 12th edition of 2007 September
and the oldest one I have on my workstation--describes AFF, SEP,
SPLIT, and SUBALLOC as obsolete subparameters on page 5-18.

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: UNIT=SEP still alive (?)

2013-08-29 Thread Clark Morris

On 29 Aug 2013 14:33:21 -0700, in bit.listserv.ibm-main you wrote:

The z/OS V1R9 MVS JCL Reference--The 12th edition of 2007 September
and the oldest one I have on my workstation--describes AFF, SEP,
SPLIT, and SUBALLOC as obsolete subparameters on page 5-18.

I can see SEP, SPLIT and SUBALLOC being obsolete but AFF still should
be useful in conserving device use for tape drives.  For example
SORTIN and SORTOUT many times were allocated that way.

Clark Morris

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: UNIT=SEP still alive (?)

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

In
3ebf9c9d119fd847b3a096c515a018f6949e4...@surfsdvmp35.cnasurety.net,
on 08/29/2013
   at 08:48 PM, Pommier, Rex R. rex.pomm...@cnasurety.com said:

OK, what does (did) SEP= do? 

Separated allocations on different devices; think of it as the
opposite of AFF.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: UNIT=SEP still alive (?)

2013-08-29 Thread Robert A. Rosenberg

At 20:48 + on 08/29/2013, Pommier, Rex R. wrote about Re: 
UNIT=SEP still alive (?):


OK, what does (did) SEP= do?  The only thing the JCL reference says 
is that you can't use it as a JCL symbol in certain types of jobs.


Others have also answered. To expand on what they said, UNIT=SYSDA 
says to allocate the dataset on one of the volumes that are addressed 
by SYSDA. It will select all volumes which has this address and then 
decide on one of them using other criteria (such as if there is 
enough free space on the volume to meet the requested SPACE parm). 
SEP says to remove the volumes which have been allocated to SORTLIB, 
SYSLMOD, and SYSLIN from the list of SYSDA volumes and only select 
from the remaining volumes - ie: Treat those volumes as if they were 
not part of SYSDA.




-Original Message-
From: IBM Mainframe Discussion List 
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S.

Sent: Thursday, August 29, 2013 3:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: UNIT=SEP still alive (?)

I just found the following in some IBM same JCL (job, actually):
//SYSUT1 DD UNIT=(SYSDA,SEP=(SORTLIB,SYSLMOD,SYSLIN)),
// SPACE=(1000,(60,20))

Last change date is half of the 2013 (creation date is probably 2005 or so).
As far as I know SEP is syntax checked and ignored for many moons, 
at least since first OS/390, but I vaguely remember somebody told me 
it was obsoleted with advent of MVS.


--
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: UNIT=SEP still alive (?)

2013-08-29 Thread Tony Harminc

On 29 August 2013 16:18, R.S. r.skoru...@bremultibank.com.pl wrote:
 I just found the following in some IBM same JCL (job, actually):
 //SYSUT1 DD UNIT=(SYSDA,SEP=(SORTLIB,SYSLMOD,SYSLIN)),
 // SPACE=(1000,(60,20))

 Last change date is half of the 2013 (creation date is probably 2005 or so).
 As far as I know SEP is syntax checked and ignored for many moons, at least
 since first OS/390, but I vaguely remember somebody told me it was obsoleted
 with advent of MVS.

I slightly more than vaguely remember it the same way. SEP=
disappeared (was ignored) with MVS, i.e. OS/VS2 2.0, because it
limited the then-new SRM's ability to swap a job in or out to control
the I/O workload on a channel. There is an element of conflict between
the application programmer/job owner's wish to have the best possible
performance for an individual job by spreading its I/O around, vs the
SRM's wish to control overall system performance as specified by the
performance group definitions. Swapping out or in a job with
allocations all over the place would not predictably change the load
on an over or under busy channel.

And on that note, I even more vaguely remember that SEP= (in pre-MVS
OSs) was done at the channel level rather then the device, but that's
so vague as to be unreliable.

Since the source code for MVT and MVS 3.8 are both available online,
anyone sufficiently interested can read the code and report back.

On the matter of a recent piece of JCL containing these obsolete
keywords, well that is all too common. There is a widespread and hard
to break culture consisting of some blend of if it ain't broke, don't
fix it, I'll just copy this JCL that works and change it minimally
to suit my needs, and we're not really sure we need this anymore,
but I don't want to be the one to remove it and find it breaks
something important, so I'd better leave it in.

I removed SEP= from one of our product manuals and around 2000, and
when we acquired another product almost ten years later, I found its
install manual to have SEP= too. I may yet have missed some...

Tony H.

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

44 matches

Mail list logo