Discussion:
SYS1 names (was SYS3 datasets)
(too old to reply)
Jesse 1 Robinson
2017-09-25 21:22:36 UTC
Permalink
Raw Message
ServerPac supplies a number of default names with three qualifiers such as SYS1.TCPIP.llq. We routinely eliminate any middle qualifier as being both redundant and confusing.

1. SMPE knows data sets by llq. SMPE cannot manage hlq.mlq1.llq and hlq.mlq2.llq concurrently. JCLIN does not know from anything other than llq.
2. Who can remember which data set groups have an mlq and which do not?

Does anyone attempt to carry these default names forward to production?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave
Sent: Monday, September 25, 2017 1:00 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: SYS3 datasets

To my knowledge, we've never had any SYS3 datasets. Kinda makes me cringe :) There's still a couple SYS2 from very old habits, but in general, we stick with what IBM provides for IBM and usually what the ISV suggests for other.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gibney, Dave
2017-09-25 21:33:09 UTC
Permalink
Raw Message
My SererPac(s) have always come as TCPIP.llq, CEE.llq, ASM.llq etc. and I've kept them. We did have a collision once before BMC bought IOA. IBM won ...

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> On Behalf Of Jesse 1 Robinson
> Sent: Monday, September 25, 2017 2:23 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: SYS1 names (was SYS3 datasets)
>
> ServerPac supplies a number of default names with three qualifiers such as
> SYS1.TCPIP.llq. We routinely eliminate any middle qualifier as being both
> redundant and confusing.
>
> 1. SMPE knows data sets by llq. SMPE cannot manage hlq.mlq1.llq and
> hlq.mlq2.llq concurrently. JCLIN does not know from anything other than llq.
> 2. Who can remember which data set groups have an mlq and which do not?
>
> Does anyone attempt to carry these default names forward to production?
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> ***@sce.com
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> On Behalf Of Gibney, Dave
> Sent: Monday, September 25, 2017 1:00 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: (External):Re: SYS3 datasets
>
> To my knowledge, we've never had any SYS3 datasets. Kinda makes me
> cringe :) There's still a couple SYS2 from very old habits, but in general, we
> stick with what IBM provides for IBM and usually what the ISV suggests for
> other.
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-09-25 23:04:14 UTC
Permalink
Raw Message
I misspoke in my original post. The three-qualifier data set names were our own choice to preserve the ServerPac qualifier but still fit into our naming standards. It was not a whimsical choice. We have 7 SAF-plexes to maintain. Introducing even one new HLQ means a lot of work to make all seven work for us. So at first we appended SYS1 to the front, making a three qualifier name with no SAF prep work required. Eventually we decided that the ServerPac HLQ was pointless and just removed it in subsequent releases. All data sets are now SYS1.xxxxxxxx with the necessarily unique llq that SMPE knows.

So my real question is whether you set up and maintain the ServerPac HLQs or just drop them as we do? As I said earlier, I don't see any benefit worth the trouble they are to manage.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave
Sent: Monday, September 25, 2017 2:34 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: SYS1 names (was SYS3 datasets)

My SererPac(s) have always come as TCPIP.llq, CEE.llq, ASM.llq etc. and I've kept them. We did have a collision once before BMC bought IOA. IBM won ...

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> On Behalf Of Jesse 1 Robinson
> Sent: Monday, September 25, 2017 2:23 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: SYS1 names (was SYS3 datasets)
>
> ServerPac supplies a number of default names with three qualifiers
> such as SYS1.TCPIP.llq. We routinely eliminate any middle qualifier as
> being both redundant and confusing.
>
> 1. SMPE knows data sets by llq. SMPE cannot manage hlq.mlq1.llq and
> hlq.mlq2.llq concurrently. JCLIN does not know from anything other than llq.
> 2. Who can remember which data set groups have an mlq and which do not?
>
> Does anyone attempt to carry these default names forward to production?
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> ***@sce.com
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> On Behalf Of Gibney, Dave
> Sent: Monday, September 25, 2017 1:00 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: (External):Re: SYS3 datasets
>
> To my knowledge, we've never had any SYS3 datasets. Kinda makes me
> cringe :) There's still a couple SYS2 from very old habits, but in
> general, we stick with what IBM provides for IBM and usually what the
> ISV suggests for other.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gibney, Dave
2017-09-25 23:34:40 UTC
Permalink
Raw Message
I am a much smaller and simpler system than yours. 4 monoplex lpars and only one is production. I think I actually ran the ServerPac RACF jobs way back when I got my first Serverpac, OS/390 1.5 or so.

I don't doubt your method works best for you.

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> On Behalf Of Jesse 1 Robinson
> Sent: Monday, September 25, 2017 4:05 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: Re: SYS1 names (was SYS3 datasets)
>
> I misspoke in my original post. The three-qualifier data set names were our
> own choice to preserve the ServerPac qualifier but still fit into our naming
> standards. It was not a whimsical choice. We have 7 SAF-plexes to maintain.
> Introducing even one new HLQ means a lot of work to make all seven work
> for us. So at first we appended SYS1 to the front, making a three qualifier
> name with no SAF prep work required. Eventually we decided that the
> ServerPac HLQ was pointless and just removed it in subsequent releases. All
> data sets are now SYS1.xxxxxxxx with the necessarily unique llq that SMPE
> knows.
>
> So my real question is whether you set up and maintain the ServerPac HLQs
> or just drop them as we do? As I said earlier, I don't see any benefit worth
> the trouble they are to manage.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> ***@sce.com
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> On Behalf Of Gibney, Dave
> Sent: Monday, September 25, 2017 2:34 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: (External):Re: SYS1 names (was SYS3 datasets)
>
> My SererPac(s) have always come as TCPIP.llq, CEE.llq, ASM.llq etc. and I've
> kept them. We did have a collision once before BMC bought IOA. IBM won ...
>
> > -----Original Message-----
> > From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> > On Behalf Of Jesse 1 Robinson
> > Sent: Monday, September 25, 2017 2:23 PM
> > To: IBM-***@LISTSERV.UA.EDU
> > Subject: SYS1 names (was SYS3 datasets)
> >
> > ServerPac supplies a number of default names with three qualifiers
> > such as SYS1.TCPIP.llq. We routinely eliminate any middle qualifier as
> > being both redundant and confusing.
> >
> > 1. SMPE knows data sets by llq. SMPE cannot manage hlq.mlq1.llq and
> > hlq.mlq2.llq concurrently. JCLIN does not know from anything other than
> llq.
> > 2. Who can remember which data set groups have an mlq and which do
> not?
> >
> > Does anyone attempt to carry these default names forward to production?
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > 626-543-6132 Office ⇐=== NEW
> > ***@sce.com
> >
> >
> > -----Original Message-----
> > From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> > On Behalf Of Gibney, Dave
> > Sent: Monday, September 25, 2017 1:00 PM
> > To: IBM-***@LISTSERV.UA.EDU
> > Subject: (External):Re: SYS3 datasets
> >
> > To my knowledge, we've never had any SYS3 datasets. Kinda makes me
> > cringe :) There's still a couple SYS2 from very old habits, but in
> > general, we stick with what IBM provides for IBM and usually what the
> > ISV suggests for other.
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lester, Bob
2017-09-25 23:43:00 UTC
Permalink
Raw Message
Hi,

Just chiming in with what we do. Note that I will not attempt to rationalize any of this!

XXX - IBM supplied DSNs. (CSF.**, BDT.**, etc) Distribution/Target Libraries. Mostly. Lives in the MCAT.
SYS1 - IBM supplied critical DSNs. (SYS1.PARMLIB, SYS1.MANx, SYS1.SIEALNKE (?)) Mostly. Lives in the MCAT
SYS2 - IBM/Vendor Loadlibs/Program Libraries that need to be in the LNKLST. Most are APF-Authorized, some are not. Mostly. Lives in the MCAT.
SYS3 - Vendor Software. (SYS3.CA.TMS.**, etc...). Not in LNKLST. May be APF-Authorized. Lives in USERCAT.
SYS4 - CICS System files. Copies in SYS2 are LNKLST and APF-Authorized as appropriate.
SYS5 - NCP. Remember NCP?
SYS6 - SAS. I have NO idea why, but I consider it a tribute to Dr. Merrill to have an HLQ just for his stuff. (and we don’t' even have SAS these days!) :-)

Thanks!
BobL


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Monday, September 25, 2017 5:05 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: SYS1 names (was SYS3 datasets) [ EXTERNAL ]

I misspoke in my original post. The three-qualifier data set names were our own choice to preserve the ServerPac qualifier but still fit into our naming standards. It was not a whimsical choice. We have 7 SAF-plexes to maintain. Introducing even one new HLQ means a lot of work to make all seven work for us. So at first we appended SYS1 to the front, making a three qualifier name with no SAF prep work required. Eventually we decided that the ServerPac HLQ was pointless and just removed it in subsequent releases. All data sets are now SYS1.xxxxxxxx with the necessarily unique llq that SMPE knows.

So my real question is whether you set up and maintain the ServerPac HLQs or just drop them as we do? As I said earlier, I don't see any benefit worth the trouble they are to manage.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave
Sent: Monday, September 25, 2017 2:34 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: SYS1 names (was SYS3 datasets)

My SererPac(s) have always come as TCPIP.llq, CEE.llq, ASM.llq etc. and I've kept them. We did have a collision once before BMC bought IOA. IBM won ...

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> On Behalf Of Jesse 1 Robinson
> Sent: Monday, September 25, 2017 2:23 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: SYS1 names (was SYS3 datasets)
>
> ServerPac supplies a number of default names with three qualifiers
> such as SYS1.TCPIP.llq. We routinely eliminate any middle qualifier as
> being both redundant and confusing.
>
> 1. SMPE knows data sets by llq. SMPE cannot manage hlq.mlq1.llq and
> hlq.mlq2.llq concurrently. JCLIN does not know from anything other than llq.
> 2. Who can remember which data set groups have an mlq and which do not?
>
> Does anyone attempt to carry these default names forward to production?
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> ***@sce.com
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> On Behalf Of Gibney, Dave
> Sent: Monday, September 25, 2017 1:00 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: (External):Re: SYS3 datasets
>
> To my knowledge, we've never had any SYS3 datasets. Kinda makes me
> cringe :) There's still a couple SYS2 from very old habits, but in
> general, we stick with what IBM provides for IBM and usually what the
> ISV suggests for other.


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

This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
i***@FOXMAIL.COM
2017-09-26 02:43:14 UTC
Permalink
Raw Message
Hi all

We want to move all datasets from one volume to the other volume.

Could you tell us how to verify whether the volume is empty or not by batch?

Thanks a lot !

Jason Cai

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2017-09-26 03:08:18 UTC
Permalink
Raw Message
Have you checked the CBTTAPE.org to see what tools may be there

File # 710 TSO commands to display DASD volume and dataset recds


Lizette
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
> Behalf Of ***@FOXMAIL.COM
> Sent: Monday, September 25, 2017 7:44 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: how to verify whether the volume is empty or not?
>
>
> Hi all
>
> We want to move all datasets from one volume to the other volume.
>
> Could you tell us how to verify whether the volume is empty or not by batch?
>
> Thanks a lot !
>
> Jason Cai
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
retired mainframer
2017-09-26 05:05:01 UTC
Permalink
Raw Message
For me, the easiest way is to display the volume in ISPF 3.4 and verify that no datasets appear other than the VTOC index and the VVDS, neither of which need appear.

But you asked for a batch method. You could execute IEHLIST and scan the output as described above. You can run ISPF in batch and use LMDINIT and LMDLIST to mimic the action of 3.4. You can read the VTOC looking for type 1 DSCBs.

Once you verify that a volume is empty, you need some method to insure new datasets are not placed on it. SMS supports DISABLE NEW. The best I can think of for a non-SMS volume is to vary it offline until you are ready to do something with it.

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
> Behalf Of ***@FOXMAIL.COM
> Sent: Monday, September 25, 2017 7:44 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: how to verify whether the volume is empty or not?
>
>
> Hi all
>
> We want to move all datasets from one volume to the other volume.
>
> Could you tell us how to verify whether the volume is empty or not by batch?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Finnell
2017-09-26 05:35:12 UTC
Permalink
Raw Message
The problem is that if the from volume has a UCAT on it some updates may me missed in the time it takes to do the copy. Guess I'd start with an INIT'd volume then duplex to it. If successful break the duplex, make the secondary primary and reinit the old from volume. 
 
In a message dated 9/26/2017 12:06:22 AM Central Standard Time, retired-***@Q.COM writes:

 
Once you verify that a volume is empty, you need some method to insure new datasets are not placed on it. SMS supports DISABLE NEW. The best I can think of for a non-SMS volume is to vary it offline until you are ready to do something with it.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Brian Fraser
2017-09-26 05:53:42 UTC
Permalink
Raw Message
Run ICKDSF with the INIT parameter.... then its verified empty :)

Brian

On Tue, Sep 26, 2017 at 1:36 PM, Edward Finnell <
0000000248cce9f3-dmarc-***@listserv.ua.edu> wrote:

> The problem is that if the from volume has a UCAT on it some updates may
> me missed in the time it takes to do the copy. Guess I'd start with an
> INIT'd volume then duplex to it. If successful break the duplex, make the
> secondary primary and reinit the old from volume.
>
> In a message dated 9/26/2017 12:06:22 AM Central Standard Time,
> retired-***@Q.COM writes:
>
>
> Once you verify that a volume is empty, you need some method to insure new
> datasets are not placed on it. SMS supports DISABLE NEW. The best I can
> think of for a non-SMS volume is to vary it offline until you are ready to
> do something with it.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
i***@FOXMAIL.COM
2017-09-26 11:06:00 UTC
Permalink
Raw Message
Brian

Could you send us a sample how to run ICKDSF with the INIT parameter.... then its verified empty :)




From: Brian Fraser
Date: 2017-09-26 13:44
To: IBM-MAIN
Subject: Re: how to verify whether the volume is empty or not?
Run ICKDSF with the INIT parameter.... then its verified empty :)

Brian

On Tue, Sep 26, 2017 at 1:36 PM, Edward Finnell <
0000000248cce9f3-dmarc-***@listserv.ua.edu> wrote:

> The problem is that if the from volume has a UCAT on it some updates may
> me missed in the time it takes to do the copy. Guess I'd start with an
> INIT'd volume then duplex to it. If successful break the duplex, make the
> secondary primary and reinit the old from volume.
>
> In a message dated 9/26/2017 12:06:22 AM Central Standard Time,
> retired-***@Q.COM writes:
>
>
> Once you verify that a volume is empty, you need some method to insure new
> datasets are not placed on it. SMS supports DISABLE NEW. The best I can
> think of for a non-SMS volume is to vary it offline until you are ready to
> do something with it.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Eells
2017-09-26 13:16:14 UTC
Permalink
Raw Message
***@foxmail.com wrote:
> Brian
>
> Could you send us a sample how to run ICKDSF with the INIT parameter.... then its verified empty :)
>
<snip>

If you only want to verify that it *is* empty without deleting anything
that's left on the volume, something along the lines of DFSMSdss DUMP
DATASET INCLUDE(**) with PARM='TYPRUN=NORUN' will tell you whether any
data sets remain on the volume without actually dumping any data.

IEHLIST LISTVTOC FORMAT will also show whether there are any data sets
on the volume.

If you want to logically delete anything that's left, ICKDSF INIT will
do that, but it will not overwrite or erase the actual data (for which
there are other operations like INSPECT with CHECK and TRKFMT with
ERASEDATA).

--
John Eells
IBM Poughkeepsie
***@us.ibm.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2017-09-26 15:39:42 UTC
Permalink
Raw Message
Brian

Would the INIT work if there was still a SYS1.VVDS or SYS1.VTOCIX still on the volume?

Lizette


> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
> Behalf Of Brian Fraser
> Sent: Monday, September 25, 2017 10:45 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: Re: how to verify whether the volume is empty or not?
>
> Run ICKDSF with the INIT parameter.... then its verified empty :)
>
> Brian
>
> On Tue, Sep 26, 2017 at 1:36 PM, Edward Finnell < 0000000248cce9f3-dmarc-
> ***@listserv.ua.edu> wrote:
>
> > The problem is that if the from volume has a UCAT on it some updates
> > may me missed in the time it takes to do the copy. Guess I'd start
> > with an INIT'd volume then duplex to it. If successful break the
> > duplex, make the secondary primary and reinit the old from volume.
> >
> > In a message dated 9/26/2017 12:06:22 AM Central Standard Time,
> > retired-***@Q.COM writes:
> >
> >
> > Once you verify that a volume is empty, you need some method to insure
> > new datasets are not placed on it. SMS supports DISABLE NEW. The best
> > I can think of for a non-SMS volume is to vary it offline until you
> > are ready to do something with it.
> >

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Allan Staller
2017-09-26 15:42:34 UTC
Permalink
Raw Message
yes

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Tuesday, September 26, 2017 10:41 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: how to verify whether the volume is empty or not?

Brian

Would the INIT work if there was still a SYS1.VVDS or SYS1.VTOCIX still on the volume?

Lizette


> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> On Behalf Of Brian Fraser
> Sent: Monday, September 25, 2017 10:45 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: Re: how to verify whether the volume is empty or not?
>
> Run ICKDSF with the INIT parameter.... then its verified empty :)
>
> Brian
>
> On Tue, Sep 26, 2017 at 1:36 PM, Edward Finnell <
> 0000000248cce9f3-dmarc- ***@listserv.ua.edu> wrote:
>
> > The problem is that if the from volume has a UCAT on it some updates
> > may me missed in the time it takes to do the copy. Guess I'd start
> > with an INIT'd volume then duplex to it. If successful break the
> > duplex, make the secondary primary and reinit the old from volume.
> >
> > In a message dated 9/26/2017 12:06:22 AM Central Standard Time,
> > retired-***@Q.COM writes:
> >
> >
> > Once you verify that a volume is empty, you need some method to
> > insure new datasets are not placed on it. SMS supports DISABLE NEW.
> > The best I can think of for a non-SMS volume is to vary it offline
> > until you are ready to do something with it.
> >

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


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
i***@FOXMAIL.COM
2017-09-27 06:57:36 UTC
Permalink
Raw Message
Hi

Could you send us a sample of using LMDINIT and LMDLIST to mimic the action of 3.4

Thanks a lot!

From: retired mainframer
Date: 2017-09-26 13:06
To: IBM-MAIN
Subject: Re: how to verify whether the volume is empty or not?
For me, the easiest way is to display the volume in ISPF 3.4 and verify that no datasets appear other than the VTOC index and the VVDS, neither of which need appear.

But you asked for a batch method. You could execute IEHLIST and scan the output as described above. You can run ISPF in batch and use LMDINIT and LMDLIST to mimic the action of 3.4. You can read the VTOC looking for type 1 DSCBs.

Once you verify that a volume is empty, you need some method to insure new datasets are not placed on it. SMS supports DISABLE NEW. The best I can think of for a non-SMS volume is to vary it offline until you are ready to do something with it.

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
> Behalf Of ***@FOXMAIL.COM
> Sent: Monday, September 25, 2017 7:44 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: how to verify whether the volume is empty or not?
>
>
> Hi all
>
> We want to move all datasets from one volume to the other volume.
>
> Could you tell us how to verify whether the volume is empty or not by batch?

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


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
retired mainframer
2017-09-27 08:49:40 UTC
Permalink
Raw Message
What part of the ISPF Services Guide was unclear?

ISPEXEC LMDINIT LISTID(ID) VOLUME(V12345)
ISPEXEC LMDLIST LISTID(ID) OPTION(SAVE) -
DATASET(' ') GROUP(V12345)

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
> Behalf Of ibmmain> Sent: Tuesday, September 26, 2017 11:59 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: Re: how to verify whether the volume is empty or not?
>
> Hi
>
> Could you send us a sample of using LMDINIT and LMDLIST to mimic the action of 3.4

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Craig Pace
2017-09-26 13:44:08 UTC
Permalink
Raw Message
You will find every shop to be unique in their own ways and the beauty is, the system allows it. I have worked in small shops, very large shops and medium shops with many, many, many different standards, sometimes across different systems!

Personally, I like to limit my security work, so the standards I have always like was to have ServerPac installations renamed to SYS1 HLQs. When IBM creates a new HLQ, don't have to go through any headache of making sure the security rules are right, unless needed to expand the data set from "protected" system-level data set.

As systems have improved, I do my best to run with a limited number of SYSRES volumes and share them across every LPAR (excepts being my Tech environment vs Test/Dev/Prod). User exits, custom LNKLST, APF, etc. can then be placed in LPAR level members and/or datasets where required so that configuration changes can still be made at an LPAR level.


Craig
________________________________

This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.

________________________________

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
m***@gmail.com
2017-09-26 00:05:46 UTC
Permalink
Raw Message
I started new mainframe shop on April 1, 2000 (actual date) with OS/390 2.8 and went through 2.10, 1.4, 1.7, 1.9, 1.11, 1.13, 2.2.
2.2 is the end. All frozen now at 2.2 and DB2 10.1 and CICSTS 4.2.
We have a sunset date around 2020, maybe 2021 or 2022.
I keep all IBM delivered names: TCPIP, ISP, ISF etc.
ABJ AOP ASM BZZ CBC CDS CEE CSF EOX EOY EPH EQAW EQQ EUVF FFST FMN GDDM GIM GLD GSK HAP ICQ IDI IGY IOA IOE IPV ISF ISP REXX
SYS1 TCPIP
we don't have SYS1.TCP*, we use TCPIP*
We have one plex, 3 LPARs (one TECH LPAR in the plex which is always down unless needed), and one completely isolated LPAR not in the PLEX.
Small shop. Real easy to maintain delivered names.
m***@gmail.com
2017-09-26 00:18:49 UTC
Permalink
Raw Message
Don't use sys3
Just use sys2.vendor
Paul Gilmartin
2017-09-26 15:35:23 UTC
Permalink
Raw Message
On Tue, 26 Sep 2017 09:17:21 -0400, John Eells wrote:

>ibmmain wrote:
>> Brian
>>
>> Could you send us a sample how to run ICKDSF with the INIT parameter.... then its verified empty :)
><snip>
>
I suspect there was some mischief in Brian's suggestion.

>If you only want to verify that it *is* empty without deleting anything
>that's left on the volume, something along the lines of DFSMSdss DUMP
>DATASET INCLUDE(**) with PARM='TYPRUN=NORUN' will tell you whether any
>data sets remain on the volume without actually dumping any data.
>
>IEHLIST LISTVTOC FORMAT will also show whether there are any data sets
>on the volume.
>
Which of these avoid even a minuscule TOCTTOU hazard?

>If you want to logically delete anything that's left, ICKDSF INIT will
>do that, but it will not overwrite or erase the actual data (for which
>there are other operations like INSPECT with CHECK and TRKFMT with
>ERASEDATA).

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-09-26 16:02:30 UTC
Permalink
Raw Message
My first reaction to the ICKDSF INIT suggestion was that it was a joke. Like the story of the two hunters in the woods. One accidentally shoots the other. Panicky emergency call:

"My friend has been shot. I think he's dead."

"In order to take the right action, we need to know. Can you make sure he's dead?"

Pause. BANG. "Yes, I'm sure he's dead."

In other words, don't INIT a volume just to 'make sure' it's empty.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Allan Staller
Sent: Tuesday, September 26, 2017 8:43 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: how to verify whether the volume is empty or not?

yes

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Tuesday, September 26, 2017 10:41 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: how to verify whether the volume is empty or not?

Brian

Would the INIT work if there was still a SYS1.VVDS or SYS1.VTOCIX still on the volume?

Lizette


> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> On Behalf Of Brian Fraser
> Sent: Monday, September 25, 2017 10:45 PM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: Re: how to verify whether the volume is empty or not?
>
> Run ICKDSF with the INIT parameter.... then its verified empty :)
>
> Brian
>
> On Tue, Sep 26, 2017 at 1:36 PM, Edward Finnell <
> 0000000248cce9f3-dmarc- ***@listserv.ua.edu> wrote:
>
> > The problem is that if the from volume has a UCAT on it some updates
> > may me missed in the time it takes to do the copy. Guess I'd start
> > with an INIT'd volume then duplex to it. If successful break the
> > duplex, make the secondary primary and reinit the old from volume.
> >
> > In a message dated 9/26/2017 12:06:22 AM Central Standard Time,
> > retired-***@Q.COM writes:
> >
> >
> > Once you verify that a volume is empty, you need some method to
> > insure new datasets are not placed on it. SMS supports DISABLE NEW.
> > The best I can think of for a non-SMS volume is to vary it offline
> > until you are ready to do something with it.
> >

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Brian Fraser
2017-09-27 08:25:43 UTC
Permalink
Raw Message
Sorry... I thought everyone would get that...

Brian

On Wed, Sep 27, 2017 at 12:03 AM, Jesse 1 Robinson <***@sce.com>
wrote:

> My first reaction to the ICKDSF INIT suggestion was that it was a joke.
> Like the story of the two hunters in the woods. One accidentally shoots the
> other. Panicky emergency call:
>
> "My friend has been shot. I think he's dead."
>
> "In order to take the right action, we need to know. Can you make sure
> he's dead?"
>
> Pause. BANG. "Yes, I'm sure he's dead."
>
> In other words, don't INIT a volume just to 'make sure' it's empty.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> ***@sce.com
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
> Behalf Of Allan Staller
> Sent: Tuesday, September 26, 2017 8:43 AM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: (External):Re: how to verify whether the volume is empty or not?
>
> yes
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Tuesday, September 26, 2017 10:41 AM
> To: IBM-***@LISTSERV.UA.EDU
> Subject: Re: how to verify whether the volume is empty or not?
>
> Brian
>
> Would the INIT work if there was still a SYS1.VVDS or SYS1.VTOCIX still on
> the volume?
>
> Lizette
>
>
> > -----Original Message-----
> > From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU]
> > On Behalf Of Brian Fraser
> > Sent: Monday, September 25, 2017 10:45 PM
> > To: IBM-***@LISTSERV.UA.EDU
> > Subject: Re: how to verify whether the volume is empty or not?
> >
> > Run ICKDSF with the INIT parameter.... then its verified empty :)
> >
> > Brian
> >
> > On Tue, Sep 26, 2017 at 1:36 PM, Edward Finnell <
> > 0000000248cce9f3-dmarc- ***@listserv.ua.edu> wrote:
> >
> > > The problem is that if the from volume has a UCAT on it some updates
> > > may me missed in the time it takes to do the copy. Guess I'd start
> > > with an INIT'd volume then duplex to it. If successful break the
> > > duplex, make the secondary primary and reinit the old from volume.
> > >
> > > In a message dated 9/26/2017 12:06:22 AM Central Standard Time,
> > > retired-***@Q.COM writes:
> > >
> > >
> > > Once you verify that a volume is empty, you need some method to
> > > insure new datasets are not placed on it. SMS supports DISABLE NEW.
> > > The best I can think of for a non-SMS volume is to vary it offline
> > > until you are ready to do something with it.
> > >
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Glenn Miller
2017-09-28 00:55:56 UTC
Permalink
Raw Message
Hi Jason,

Although it may not be exactly what you were looking for or thinking of, IBM added a parameter a few years back to the INIT command of ICKDSK called NODSEXIST via PTFs for APAR: PK83260 . Per the Comments in the APAR:

The INIT command will terminate with message ICK32179I DATA SETS EXIST ON VOLUME if NODSEXIST was specified and data sets other than the index data set and/or VVDS exist on the volume.

IBM implemented that function on the CKD version of the INIT command only. As originally implemented, that operand was not the default in the ICKDSF INIT command, so you had to explicitly specify it. However, I see that IBM has recently added support in ICKDSF and z/OS ( looks like in z/OS V2R1 and V2R2 ) so that you can use the DEVSUPxx Parmlib member to control whether that parameter would be a "system wide" default via APAR PI67283 .

As a "side note", I also noticed that the support added to the DEVSUPxx Parmlib member for the NODSEXIST operand created an unintended consequence to the ICKDSF INSPECT and TRKFMT commands. See APAR PI84856 . When I read about this NODSEXIST function, I was initially hesitant to use it because, well its the ICKDSF INIT command, which is somewhat destructive, so say the least. I would have felt more comfortable to have that function of the somewhat "less destructive" ICKDSF commands, like INSPECT or TRKFMT.

HTH

Glenn Miller

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2017-09-29 14:45:47 UTC
Permalink
Raw Message
W dniu 2017-09-25 o 23:23, Jesse 1 Robinson pisze:
> ServerPac supplies a number of default names with three qualifiers such as SYS1.TCPIP.llq. We routinely eliminate any middle qualifier as being both redundant and confusing.
>
> 1. SMPE knows data sets by llq. SMPE cannot manage hlq.mlq1.llq and hlq.mlq2.llq concurrently. JCLIN does not know from anything other than llq.
> 2. Who can remember which data set groups have an mlq and which do not?
>
> Does anyone attempt to carry these default names forward to production?

Ad 1. IMHO SMPE knows datasets by DDDEFs, which are usually equal to
LLQ, but need not to be.
Ad 2. It's much better to look at dslist, not to remember.

Yes, we do carry most of default names, including 3-qualifiers ones. No
animal was hurt because of that.

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

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2017-09-29 19:23:59 UTC
Permalink
Raw Message
> On Sep 29, 2017, at 9:46 AM, R.S. <***@BREMULTIBANK.COM.PL> wrote:
>
> W dniu 2017-09-25 o 23:23, Jesse 1 Robinson pisze:
>> ServerPac supplies a number of default names with three qualifiers such as SYS1.TCPIP.llq. We routinely eliminate any middle qualifier as being both redundant and confusing.
>>
>> 1. SMPE knows data sets by llq. SMPE cannot manage hlq.mlq1.llq and hlq.mlq2.llq concurrently. JCLIN does not know from anything other than llq.
>> 2. Who can remember which data set groups have an mlq and which do not?
>>
>> Does anyone attempt to carry these default names forward to production?
>
> Ad 1. IMHO SMPE knows datasets by DDDEFs, which are usually equal to LLQ, but need not to be.
> Ad 2. It's much better to look at dslist, not to remember.
>
> Yes, we do carry most of default names, including 3-qualifiers ones. No animal was hurt because of that.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>

Radoslaw:

IBM *used* to use only sys1. Then they slipped a few more in, then a few more in and kept increasing it.
I got sick and tired of updating the security product almost every 6 month to accommodate these changes. Then the security changed from us to a security group. Then all hell broke loose, they basically refused to do the update we requested as they became a burden to the group (that was their claim). I decided at that point it was easier for me to change than depend on an outside entity. I made the decission to hell with IBM naming standards and stay with sys1.
It was easier for me to rename the datasets and recatalog them than for the security people to get involved (we had a rock solid sys1 rule). Since I had control of all compile procedures as well that was a minor additional work for me to do.
The CEE and the ICQ (which we never used) and the others (ISR,ISP etc) were better maintained by me and only needed minor work.
I chucked IBM’s PITA naming conventions and never looked back. To this day you will not find any of those oddball datasets on any system that I am responsible for.
System installs (and blackouts although never used) were always a non event. One time I had to almost backout a JES2 change which they did not document but I used a PDS mass update programs to fix that.
The Hardcoded names like TCPIP… I had to live with and I have never forgiven IBM for doing such an jerky thing. The one exception I had to live with, which still boils my blood every time I have to deal with them.
BTW, IMO TCPIP was the starter of the of the evil IBM has set loose on sysprogs the world over.

Ed

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2017-10-02 08:16:54 UTC
Permalink
Raw Message
W dniu 2017-09-29 o 21:15, Edward Gould pisze:
>> On Sep 29, 2017, at 9:46 AM, R.S. <***@BREMULTIBANK.COM.PL> wrote:
>>
>> W dniu 2017-09-25 o 23:23, Jesse 1 Robinson pisze:
>>> ServerPac supplies a number of default names with three qualifiers such as SYS1.TCPIP.llq. We routinely eliminate any middle qualifier as being both redundant and confusing.
>>>
>>> 1. SMPE knows data sets by llq. SMPE cannot manage hlq.mlq1.llq and hlq.mlq2.llq concurrently. JCLIN does not know from anything other than llq.
>>> 2. Who can remember which data set groups have an mlq and which do not?
>>>
>>> Does anyone attempt to carry these default names forward to production?
>> Ad 1. IMHO SMPE knows datasets by DDDEFs, which are usually equal to LLQ, but need not to be.
>> Ad 2. It's much better to look at dslist, not to remember.
>>
>> Yes, we do carry most of default names, including 3-qualifiers ones. No animal was hurt because of that.
>>
>> --
>> Radoslaw Skorupka
>> Lodz, Poland
>>
>>
>>
> Radoslaw:
>
> IBM *used* to use only sys1. Then they slipped a few more in, then a few more in and kept increasing it.
> I got sick and tired of updating the security product almost every 6 month to accommodate these changes. Then the security changed from us to a security group. Then all hell broke loose, they basically refused to do the update we requested as they became a burden to the group (that was their claim). I decided at that point it was easier for me to change than depend on an outside entity. I made the decission to hell with IBM naming standards and stay with sys1.
> It was easier for me to rename the datasets and recatalog them than for the security people to get involved (we had a rock solid sys1 rule). Since I had control of all compile procedures as well that was a minor additional work for me to do.
> The CEE and the ICQ (which we never used) and the others (ISR,ISP etc) were better maintained by me and only needed minor work.
> I chucked IBM’s PITA naming conventions and never looked back. To this day you will not find any of those oddball datasets on any system that I am responsible for.
> System installs (and blackouts although never used) were always a non event. One time I had to almost backout a JES2 change which they did not document but I used a PDS mass update programs to fix that.
> The Hardcoded names like TCPIP… I had to live with and I have never forgiven IBM for doing such an jerky thing. The one exception I had to live with, which still boils my blood every time I have to deal with them.
> BTW, IMO TCPIP was the starter of the of the evil IBM has set loose on sysprogs the world over.

Well, I "was born" long after IBM started using other HLQs, not only
SYS1. And see no problem with that. Including RACF definitions which
are really simple to manage. The "rock solid SYS1 rule" seems to be a
little bit obsolete for last 20 years.
IMHO there are less troubles and surprises when following current IBM
rules, than when trying to change them.

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

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2017-10-02 10:42:30 UTC
Permalink
Raw Message
> On Oct 2, 2017, at 3:18 AM, R.S. <***@BREMULTIBANK.COM.PL> wrote:
>
>
> Well, I "was born" long after IBM started using other HLQs, not only SYS1. And see no problem with that. Including RACF definitions which are really simple to manage. The "rock solid SYS1 rule" seems to be a little bit obsolete for last 20 years.
> IMHO there are less troubles and surprises when following current IBM rules, than when trying to change them.
>
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland

To me it was a quick change and it was painless. I don’t have a hardcopy of our sys1 rule. BIIRC we set up to explicitly name the datasets we allowed and anything else was verbotten.
We were also a strictly COBOL shop so things like sys1.maclib was off limits.
The auditors would not allow us to write rules, so if we were in on Sunday 0300 and a rule had to go in at the same time, the security people were there. Hey if they won’t give me access then the people who can are there along side.
In downtown Chicago generally we couldn’t find a restaurant open around then so everybody bought the own coffee and donuts.
The security people hated us because of this (I had a good relation to the head of the security group so he didn’t complain), When I had to do some emergency mass changes to production because JES2 didn’t warn us ahead of time (No hold data) the security people were there so I had someone looking over my shoulder for stuff like this, but I did not mind. The installation meeting the next day to explain was always fun. Try explaining ++HOLD to people that could barely understand JCL.
I was very proactive and always looked at reports on violations as it probably meant I was going to have to battle a programming supervisor and I loved those battles.

Ed


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-09-29 19:53:45 UTC
Permalink
Raw Message
On Fri, 29 Sep 2017 16:46:56 +0200, R.S. wrote:

>W dniu 2017-09-25 o 23:23, Jesse 1 Robinson pisze:
>> ServerPac supplies a number of default names with three qualifiers such as SYS1.TCPIP.llq. We routinely eliminate any middle qualifier as being both redundant and confusing.
>>
>> 1. SMPE knows data sets by llq. SMPE cannot manage hlq.mlq1.llq and hlq.mlq2.llq concurrently. JCLIN does not know from anything other than llq.
>> 2. Who can remember which data set groups have an mlq and which do not?
>>
>> Does anyone attempt to carry these default names forward to production?
>
>Ad 1. IMHO SMPE knows datasets by DDDEFs, which are usually equal to
>LLQ, but need not to be.
>Ad 2. It's much better to look at dslist, not to remember.
>
Some systems programmers dislike DDDEFs, intensely.

In some cases, it's stronger than your "usually". If UCLIN contains:
//SYSLMOD DD DSN=hlq.mlq.llq
... llq must be supplied as either a name of a DDDEF in the target zone or
as the name of a DD statement in the APPLY step. (Is this true for any
DDNAME other than SYSLMOD?)

SMP/E might benefit systems programmers if it provided symbol substitution
in UCLIN an JCLIN. I have generally followed the practice of a predecessor and
supplied tailoring macros to achieve this effect prior to SUBMIT. If I had known
years ago the concerns discussed in this thread I might have supplied better
defaults.

>Yes, we do carry most of default names, including 3-qualifiers ones. No
>animal was hurt because of that.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2017-10-02 08:12:40 UTC
Permalink
Raw Message
W dniu 2017-09-29 o 21:54, Paul Gilmartin pisze:
> On Fri, 29 Sep 2017 16:46:56 +0200, R.S. wrote:
>
>> W dniu 2017-09-25 o 23:23, Jesse 1 Robinson pisze:
>>> ServerPac supplies a number of default names with three qualifiers such as SYS1.TCPIP.llq. We routinely eliminate any middle qualifier as being both redundant and confusing.
>>>
>>> 1. SMPE knows data sets by llq. SMPE cannot manage hlq.mlq1.llq and hlq.mlq2.llq concurrently. JCLIN does not know from anything other than llq.
>>> 2. Who can remember which data set groups have an mlq and which do not?
>>>
>>> Does anyone attempt to carry these default names forward to production?
>> Ad 1. IMHO SMPE knows datasets by DDDEFs, which are usually equal to
>> LLQ, but need not to be.
>> Ad 2. It's much better to look at dslist, not to remember.
>>
> Some systems programmers dislike DDDEFs, intensely.
>
> In some cases, it's stronger than your "usually". If UCLIN contains:
> //SYSLMOD DD DSN=hlq.mlq.llq
> ... llq must be supplied as either a name of a DDDEF in the target zone or
> as the name of a DD statement in the APPLY step. (Is this true for any
> DDNAME other than SYSLMOD?)

Interesting. How does it relate to dataset merge? During ServerPac
installation process one can merge several libraries (with like
attributes) into single library.


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

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Bruce Hewson
2017-09-30 12:34:22 UTC
Permalink
Raw Message
Hi,

SMPE has a convention that the DDDEF name match the LLQ for the dataset in the TARGET & DLIB zones.

It doesn't care about the qualifiers.

JCLIN requires that in the dummy DD card the LLQ matches the DDDEF, not the actual dataset name.

So for different zones you can have different datasets for the same LLQ/DDDEF.

In our case we like to extend the dataset name to include a product identifier (as the 2nd qualifier)
and a target zone identifier as the 3rd qualifier.

It does make things a little easier when going from the dataset name to locate the correct target zone.

Regards
Bruce Hewson

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-10-02 13:54:41 UTC
Permalink
Raw Message
On Mon, 2 Oct 2017 10:13:41 +0200, R.S. wrote:
>
>Interesting. How does it relate to dataset merge? During ServerPac
>installation process one can merge several libraries (with like
>attributes) into single library.
>
From the ISV's point of view, IBM kindly provides the tool (GIMZIP) for
packaging for RECEIVE FROMNETWORK/FROMNTS, but not for ShopZ
nor for ServerPac, so I have no familiarity with those. I suppose more
sophisticated tools might be available at a price. Further, mainframe
software was a minority LoB for my employer and we could not get
an exception from packaging standards required that any software
product or service be delivered in a *.zip archive containing a README.*
file and an unspecified collection of payload files. We delivered a
.zip archive containing the README, the GIMZIP package and installation
instructions and JCL samples.

-- gil

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