Re: [EXTERNAL] Re: HLQ change of SMP/E files

[CM Poncelet]

 Hi Simon,
 
 No, aliasing would not help: the original SMP/E datasets could then be
 updated via their aliases.
 
 I'm guessing that the CSI and its associated SMP/E datasets are for a
 production system. If the intention is only to read them, this can be
 done directly from the production CSI SMP/E environment without cloning.
 
 But if the intention is to update these datasets (e.g. by RECEIVE'ing,
 APPLYing APARs PTFs or USERMODs, or REJECTing them etc.) - without
 impacting the production system itself - then the production CSI and all
 its SMP/E datasets need to be cloned. This way any updates can be
 applied and 'run-time' checked via the cloned CSI and its SMP/E
 datasets, without 'hitting' the production system.
 
 Consider the following. Suppose that PTF001 to PTF500 have been applied
 in production. Applying PTF501 results in a QA regression test failure
 and is rejected. PTF501's code changes show it could not be causing the
 QA failure. Hence a previous PTF is in error (PE) but was not detected
 until PTF501 was applied. The objective now is not to fix PTF501, but to
 find which previous PTF introduces the error. A quick way to do this is
 to clone the production system's *original* CSI and SMP/E datasets,
 APPLY its PTFs (typically PTF001 to PTF250 first, etc.) until the PTF
 that introduces the error is found. It can then be marked PE in
 production. Next, create a HIPER to fix it, include PTF501 and, if
 QA-checked now all OK, apply and distribute.
 
 This works only if the cloned CSI and its datasets are physically
 separate from the original production ones - not aliases of them (or
 vice versa).
 
 Cheers, Chris Poncelet



On 04/05/2018 14:34, Wheeler, Simon wrote:
> Hi,
>
> Maybe it would be possible to rename the datasets as desired and create 
> dataset aliases for the old names, so no SMP/E changes would be required?
>
> thanks,
> Simon
>  
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of CM Poncelet
> Sent: 03 May 2018 16:27
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: HLQ change of SMP/E files
>
> Hi Vignesh,
>  
> Yes, all the existing datasets can be copied - i.e. 'cloned' - to new 
> datasets with new names. Both the DZONE and TZONE of the new CSI then need to 
> be renamed and pointed at each other, and all the new CSI's DDDEFs need to be 
> pointed at their new dataset names. It is all done via UCL.
>  
> Bear in mind that a cloned CSI's GLOBAL zone is still pointing at the 
> original CSI's DZONE and TZONE, and this needs to be changed to point it at 
> the cloned CSI's DZONE and TZONE.
>  
> Cheers, Chris Poncelet
>  
>  
>
> On 03/05/2018 05:17, Sankaranarayanan, Vignesh wrote:
>> Hi Chris,
>>
>> Is it not possible to move the existing datasets into their new names 
>> (rename), and do the required UCL work.
>>
>> – Vignesh
>> Mainframe Infrastructure
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of CM Poncelet
>> Sent: Thursday 03-May-2018 09:06
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: [EXTERNAL] Re: HLQ change of SMP/E files
>>
>> There is more to it than that if you are cloning (copying) a CSI into 
>> another CSI. E.g.
>>  
>> "ZONEEXPORT, UCLIN, ZONEDELETE, DEL/ADD/REP ZONEINDEX GZONE/DZONE/TZONE,"
>> "ENDUCL, ZONEIMPORT ... RELATED() etc. and then"
>> "DEL/REP/ADD DDDEF() DA() SHR to point at"
>> "the DDDEF 'WHYNOT' DSNs in the GZONE/DZONE/TZONE."
>>
>> You need also to relate your cloned DZONE and TZONE to each other in the 
>> cloned CSI, as in e.g.
>>
>> SET BOUNDARY(DZONE)
>> .
>> ZONEIMPORT (DZONE) INFILE(IMPORTDZ) INTO(DZONE) RELATED(TZONE) .
>> SET BOUNDARY(TZONE)
>> .
>> ZONEIMPORT (TZONE) INFILE(IMPORTTZ) INTO(TZONE) RELATED(DZONE) .
>>
>> All the original CSI's SMP/E datasets should be IEBCOPY'd or IEBGENER'd to 
>> 'WHYNOT.*' datasets - and the cloned CSI's DDDEFs then updated to point at 
>> the 'WHYNOT.*' datasets in its GLOBAL, DZONE and TZONE.
>> (Otherwise any RECEIVE, APPLY and ACCEPTs would be applied to the 
>> original CSI's SMP/E datasets.)
>>  
>> Chris Poncelet (retired sysprog)
>>  
>>  
>>
>>
>> On 02/05/2018 18:27, Sankaranarayanan, Vignesh wrote:
>>> Hi Kurt,
>>>
>>> Thanks for this; the product is in its own target and dlip zones, product 
>>> has its own CSI.
>>> So the ZONEINDEX is for consideration only when TGT and DLIB have their own 
>>> zones, or even if they're all in a single product CSI?
>>>
>>> PS: Big fan of getting replies from various IBM development teams!!
>>>
>>> – Vignesh
>>> Mainframe Infrastructure
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>>> On Behalf Of Kurt Quackenbush
>>> Sent: Wednesday 02-May-2018 18:03
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: [EXTERNAL] Re: HLQ change of SMP/E files
>>>
>>> On 5/1/2018 9:51 AM, Sankaranarayanan, Vignesh wrote:
>>>
 So will a 

Re: [EXTERNAL] Re: HLQ change of SMP/E files

[CM Poncelet]

Hi Simon,
 
No, aliasing would not help: the original SMP/E datasets could then be
updated via their aliases.
 
I'm guessing that the CSI and its associated SMP/E datasets are for a
production system. If the intention is only to read them, this can be
done directly from the production CSI SMP/E environment without cloning.
 
But if the intention is to update these datasets (e.g. by RECEIVE'ing,
APPLYing APARs PTFs or USERMODs, or REJECTing them etc.) - without
impacting the production system itself - then the production CSI and all
its SMP/E datasets need to be cloned. This way any updates can be
applied and 'run-time' checked via the cloned CSI and its SMP/E
datasets, without 'hitting' the production system.
 
Consider the following. Suppose that PTF001 to PTF500 have been applied
in production. Applying PTF501 results in a QA regression test failure
and is rejected. PTF501's code changes show it could not be causing the
QA failure. Hence a previous PTF is in error (PE) but was not detected
until PTF501 was applied. The objective now is not to fix PTF501, but to
find which previous PTF introduces the error. A quick way to do this is
to clone the production system's *original* CSI and SMP/E datasets,
APPLY its PTFs (typically PTF001 to PTF250 first, etc.) until the PTF
that introduces the error is found. It can then be marked PE in
production. Next, create a HIPER to fix it, include PTF501 and, if
QA-checked now all OK, apply and distribute.
 
This works only if the cloned CSI and its datasets are physically
separate from the original production ones - not aliases of them (or
vice versa).
 
Cheers, Chris Poncelet



On 04/05/2018 14:34, Wheeler, Simon wrote:
> Hi,
>
> Maybe it would be possible to rename the datasets as desired and create 
> dataset aliases for the old names, so no SMP/E changes would be required?
>
> thanks,
> Simon
>  
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of CM Poncelet
> Sent: 03 May 2018 16:27
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: HLQ change of SMP/E files
>
> Hi Vignesh,
>  
> Yes, all the existing datasets can be copied - i.e. 'cloned' - to new 
> datasets with new names. Both the DZONE and TZONE of the new CSI then need to 
> be renamed and pointed at each other, and all the new CSI's DDDEFs need to be 
> pointed at their new dataset names. It is all done via UCL.
>  
> Bear in mind that a cloned CSI's GLOBAL zone is still pointing at the 
> original CSI's DZONE and TZONE, and this needs to be changed to point it at 
> the cloned CSI's DZONE and TZONE.
>  
> Cheers, Chris Poncelet
>  
>  
>
> On 03/05/2018 05:17, Sankaranarayanan, Vignesh wrote:
>> Hi Chris,
>>
>> Is it not possible to move the existing datasets into their new names 
>> (rename), and do the required UCL work.
>>
>> – Vignesh
>> Mainframe Infrastructure
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of CM Poncelet
>> Sent: Thursday 03-May-2018 09:06
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: [EXTERNAL] Re: HLQ change of SMP/E files
>>
>> There is more to it than that if you are cloning (copying) a CSI into 
>> another CSI. E.g.
>>  
>> "ZONEEXPORT, UCLIN, ZONEDELETE, DEL/ADD/REP ZONEINDEX GZONE/DZONE/TZONE,"
>> "ENDUCL, ZONEIMPORT ... RELATED() etc. and then"
>> "DEL/REP/ADD DDDEF() DA() SHR to point at"
>> "the DDDEF 'WHYNOT' DSNs in the GZONE/DZONE/TZONE."
>>
>> You need also to relate your cloned DZONE and TZONE to each other in the 
>> cloned CSI, as in e.g.
>>
>> SET BOUNDARY(DZONE)
>> .
>> ZONEIMPORT (DZONE) INFILE(IMPORTDZ) INTO(DZONE) RELATED(TZONE) .
>> SET BOUNDARY(TZONE)
>> .
>> ZONEIMPORT (TZONE) INFILE(IMPORTTZ) INTO(TZONE) RELATED(DZONE) .
>>
>> All the original CSI's SMP/E datasets should be IEBCOPY'd or IEBGENER'd to 
>> 'WHYNOT.*' datasets - and the cloned CSI's DDDEFs then updated to point at 
>> the 'WHYNOT.*' datasets in its GLOBAL, DZONE and TZONE.
>> (Otherwise any RECEIVE, APPLY and ACCEPTs would be applied to the 
>> original CSI's SMP/E datasets.)
>>  
>> Chris Poncelet (retired sysprog)
>>  
>>  
>>
>>
>> On 02/05/2018 18:27, Sankaranarayanan, Vignesh wrote:
>>> Hi Kurt,
>>>
>>> Thanks for this; the product is in its own target and dlip zones, product 
>>> has its own CSI.
>>> So the ZONEINDEX is for consideration only when TGT and DLIB have their own 
>>> zones, or even if they're all in a single product CSI?
>>>
>>> PS: Big fan of getting replies from various IBM development teams!!
>>>
>>> – Vignesh
>>> Mainframe Infrastructure
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>>> On Behalf Of Kurt Quackenbush
>>> Sent: Wednesday 02-May-2018 18:03
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: [EXTERNAL] Re: HLQ change of SMP/E files
>>>
>>> On 5/1/2018 9:51 AM, Sankaranarayanan, Vignesh wrote:
>>>
 So will a ZONEEDIT be all, or are there 

Re: MF Application source control?

[John McKown]

On Fri, May 4, 2018 at 3:37 PM, Jerry Callen  wrote:

> On Fri, 4 May 2018 13:00:55 +, Rob Scott 
> wrote:
>
>  Dave
>
>  As someone who is a complete dinosaur and used to source control
>  systems like SCLM, it took a bit of getting used to for me.
>
>  I found that once I abandoned PDS datasets and used z/OS unix
>  file systems on z/OS to store the source I was working on, all
>  things began to fall into place.
>
>  For build processes that need PDS input/output, OPUTX/OGETX are
>  your friends.
>
>  Rob.
>
> [Disclaimer: I work at Rocket Software, and have interacted
>  a fair amount with Rob.]
>
> Rob, if you're a dinosaur, the species must be "velociraptor". :-)
>

​Hum, they really got "good press" from Jurassic Park. In reality, they
were small, vicious, fast, and stupid. I love how one YouT​uber's described
their IQ: "About as smart as a board with a nail in it."

-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

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: Interesting computer coding story [OT to mainframe -- it IS Friday]

[Mike Schwab]

On three specific days of year on a Wednesday or Saturday, so like once a year.

On Fri, May 4, 2018 at 8:16 PM, Tom Brennan  wrote:
> Thanks, when I first heard about this I wondered why those machines don't
> use some kind of truly random input, such as temperature or radio signal
> noise.  So it turns out they do!  But this guy just wrote code to bypass
> that input :)
>
> Charles Mills wrote:
>>
>> https://nyti.ms/2KvNzZf
>> The Times has a partial paywall. I apologize if you are unable to read the
>> story.
>>
>> Charles
>> --
>> 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



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Interesting computer coding story [OT to mainframe -- it IS Friday]

[Tom Brennan]

Thanks, when I first heard about this I wondered why those machines 
don't use some kind of truly random input, such as temperature or radio 
signal noise.  So it turns out they do!  But this guy just wrote code to 
bypass that input :)


Charles Mills wrote:
https://nyti.ms/2KvNzZf 


The Times has a partial paywall. I apologize if you are unable to read the
story.

Charles 


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

Interesting computer coding story [OT to mainframe -- it IS Friday]

[Charles Mills]

https://nyti.ms/2KvNzZf 

The Times has a partial paywall. I apologize if you are unable to read the
story.

Charles 

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

Re: unexpected tape issue with RETAIN

[Tony Thigpen]

I currently think it has to do with a combination of a faulty tape and a 
mis-configuration in the IODEF, and a testing environment.


Normally, this CPU has no powered-up real tape drives, just a VTL. For 
some testing of new back-up procedures, they wanted me to use a real 
3590 so as to not add a bunch of data to the VTL that would then have to 
be replicated.


So, I powered-up and varied on some tape drives. The IODEF thinks they 
have auto-loaders, but they do not. So, I have get a configuration error 
when I run the job on just the first file.


And, since we don't have a lot of spare real 3590 tapes, I have been 
using the same two tapes repeatedly.


I have noticed that the errors only occur on one of the tapes. I think 
the recovery process wants to re-index the tape position but without the 
autoloader, it is failing then the operating system is switching to a 
new drive.


Tony Thigpen

Lizette Koehler wrote on 05/04/2018 06:12 PM:

I am not sure if this was covered,

But would the combination of

VOL=REF=*  and DISP=(,PASS) not work at keeping the tape up?

Lizette



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Tony Thigpen
Sent: Friday, May 04, 2018 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: unexpected tape issue with RETAIN

No go. Unit=Aff is only applicable within the same job step.

Tony Thigpen

Chris Hoelscher wrote on 05/04/2018 04:05 PM:

Unit=aff=step.ddname  ???

Chris Hoelscher
Technology Architect, Database Infrastructure Services Technology
Solution Services Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Tony Thigpen
Sent: Friday, May 4, 2018 3:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] unexpected tape issue with RETAIN

I have a 50+ step backup job (using real 3590s) that has steps like:

//STEP049 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD4
//BACKUP   DD  DSN=DR.T.DSS.HKYTD4.,DISP=(NEW,KEEP,DELETE),
// UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP),
// LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSINDD  *
DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*
//*
//STEP050 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD5
//BACKUP   DD  DSN=DR.T.DSS.HKYTD5.,DISP=(NEW,KEEP,DELETE),
// UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP),
// LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSINDD  *
DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*

This job always worked on OS/390 2.10, but under z/OS 1.13, randomly, when

going to a new step, it wants the current tape mounted on a different 3590.
Additionally, it does not unload the tape from the first drive.


Also: If I have only one drive online, it runs to completion. If I have two

drives, but the other one is busy, it runs to completion.


Info: This system is using RMM as a tape manager, but the files being

created on the tape are not defined in any storage group or RMM.


It is driving me batty. I have to be 'not seeing' something.


--
Tony Thigpen



--
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: unexpected tape issue with RETAIN

[Steely.Mark]

I usually use UNIT=AFF=SMFIN - Maybe you can try that instead.  

Not sure of the syntax but it always works for me.

Thank You 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Friday, May 04, 2018 2:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: unexpected tape issue with RETAIN

I have a 50+ step backup job (using real 3590s) that has steps like:

//STEP049 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD4
//BACKUP   DD  DSN=DR.T.DSS.HKYTD4.,DISP=(NEW,KEEP,DELETE),
// UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP),
// LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSINDD  *
  DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*
//*
//STEP050 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD5
//BACKUP   DD  DSN=DR.T.DSS.HKYTD5.,DISP=(NEW,KEEP,DELETE),
// UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP),
// LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSINDD  *
  DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*

This job always worked on OS/390 2.10, but under z/OS 1.13, randomly, 
when going to a new step, it wants the current tape mounted on a 
different 3590. Additionally, it does not unload the tape from the first 
drive.

Also: If I have only one drive online, it runs to completion. If I have 
two drives, but the other one is busy, it runs to completion.

Info: This system is using RMM as a tape manager, but the files being 
created on the tape are not defined in any storage group or RMM.

It is driving me batty. I have to be 'not seeing' something.


-- 
Tony Thigpen

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

*** Disclaimer ***
This communication (including all attachments) is solely for the use of the 
person to whom it is addressed and is a confidential AAA communication. If you 
are not the intended recipient, any use, distribution, printing, or copying is 
prohibited. If you received this email in error, please immediately delete it 
and notify the sender.

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

Re: unexpected tape issue with RETAIN

[Lizette Koehler]

I am not sure if this was covered,

But would the combination of 

VOL=REF=*  and DISP=(,PASS) not work at keeping the tape up?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Tony Thigpen
> Sent: Friday, May 04, 2018 1:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: unexpected tape issue with RETAIN
> 
> No go. Unit=Aff is only applicable within the same job step.
> 
> Tony Thigpen
> 
> Chris Hoelscher wrote on 05/04/2018 04:05 PM:
> > Unit=aff=step.ddname  ???
> >
> > Chris Hoelscher
> > Technology Architect, Database Infrastructure Services Technology
> > Solution Services Humana Inc.
> > 123 East Main Street
> > Louisville, KY 40202
> > Humana.com
> > (502) 476-2538 or 407-7266
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Tony Thigpen
> > Sent: Friday, May 4, 2018 3:35 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [IBM-MAIN] unexpected tape issue with RETAIN
> >
> > I have a 50+ step backup job (using real 3590s) that has steps like:
> >
> > //STEP049 EXEC PGM=ADRDSSU
> > //SYSPRINT DD  SYSOUT=*
> > //DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD4
> > //BACKUP   DD  DSN=DR.T.DSS.HKYTD4.,DISP=(NEW,KEEP,DELETE),
> > // UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP),
> > // LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
> > //SYSINDD  *
> >DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
> > /*
> > //*
> > //STEP050 EXEC PGM=ADRDSSU
> > //SYSPRINT DD  SYSOUT=*
> > //DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD5
> > //BACKUP   DD  DSN=DR.T.DSS.HKYTD5.,DISP=(NEW,KEEP,DELETE),
> > // UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP),
> > // LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
> > //SYSINDD  *
> >DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
> > /*
> >
> > This job always worked on OS/390 2.10, but under z/OS 1.13, randomly, when
> going to a new step, it wants the current tape mounted on a different 3590.
> Additionally, it does not unload the tape from the first drive.
> >
> > Also: If I have only one drive online, it runs to completion. If I have two
> drives, but the other one is busy, it runs to completion.
> >
> > Info: This system is using RMM as a tape manager, but the files being
> created on the tape are not defined in any storage group or RMM.
> >
> > It is driving me batty. I have to be 'not seeing' something.
> >
> >
> > --
> > Tony Thigpen
> >

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

Re: OA53355 - USERKEY COMMON MIGRATION SUPPORT

[Edward Finnell]

IIRC the ANAL30DD was a user contributed pgm. Without too much labor it was 
modified to produce several very handy reports. Seems like IBM would produce a 
SORT solution for reporting USER key usage. The SLIP on a z14 reduces it from 
boogity, boogity to boog, boog, boog-single step instruction mode? 


In a message dated 4/27/2018 3:41:49 PM Central Standard Time, ba...@mxg.com 
writes:

 
Change 35.212 Support for SMF 30 User Key CSA Audit Enhancements adds

VMAC30 new SMF30_RAXFLAGS to TYPE30_1, TYPE30_V, TYPE30_4 and
Sep 28, 2017 the TYPE30_5 datasets. This code change has been in MXG

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

Re: unexpected tape issue with RETAIN

[Gary Jacek]

Is it possible there is some competing "service" that forces drive maintenance 
(head cleaning?) every xxx tape mounts?

An RMM feature?


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: May 4, 2018 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: unexpected tape issue with RETAIN

I have a 50+ step backup job (using real 3590s) that has steps like:

//STEP049 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD4
//BACKUP   DD  DSN=DR.T.DSS.HKYTD4.,DISP=(NEW,KEEP,DELETE),
// UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP),
// LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSINDD  *
  DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*
//*
//STEP050 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD5
//BACKUP   DD  DSN=DR.T.DSS.HKYTD5.,DISP=(NEW,KEEP,DELETE),
// UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP),
// LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSINDD  *
  DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*

This job always worked on OS/390 2.10, but under z/OS 1.13, randomly, 
when going to a new step, it wants the current tape mounted on a 
different 3590. Additionally, it does not unload the tape from the first 
drive.

Also: If I have only one drive online, it runs to completion. If I have 
two drives, but the other one is busy, it runs to completion.

Info: This system is using RMM as a tape manager, but the files being 
created on the tape are not defined in any storage group or RMM.

It is driving me batty. I have to be 'not seeing' something.


-- 
Tony Thigpen

--
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: unexpected tape issue with RETAIN

[Tony Thigpen]

No go. Unit=Aff is only applicable within the same job step.

Tony Thigpen

Chris Hoelscher wrote on 05/04/2018 04:05 PM:

Unit=aff=step.ddname  ???

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Friday, May 4, 2018 3:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] unexpected tape issue with RETAIN

I have a 50+ step backup job (using real 3590s) that has steps like:

//STEP049 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD4
//BACKUP   DD  DSN=DR.T.DSS.HKYTD4.,DISP=(NEW,KEEP,DELETE),
// UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP),
// LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSINDD  *
   DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*
//*
//STEP050 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD5
//BACKUP   DD  DSN=DR.T.DSS.HKYTD5.,DISP=(NEW,KEEP,DELETE),
// UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP),
// LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSINDD  *
   DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*

This job always worked on OS/390 2.10, but under z/OS 1.13, randomly, when 
going to a new step, it wants the current tape mounted on a different 3590. 
Additionally, it does not unload the tape from the first drive.

Also: If I have only one drive online, it runs to completion. If I have two 
drives, but the other one is busy, it runs to completion.

Info: This system is using RMM as a tape manager, but the files being created 
on the tape are not defined in any storage group or RMM.

It is driving me batty. I have to be 'not seeing' something.


--
Tony Thigpen

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, age, 
disability or
sex. Humana Inc. and its subsidiaries do not exclude people or treat them 
differently
because of race, color, national origin, age, disability or sex.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.


--
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: MF Application source control?

[Jerry Callen]

On Fri, 4 May 2018 13:00:55 +, Rob Scott  wrote:

 Dave
 
 As someone who is a complete dinosaur and used to source control
 systems like SCLM, it took a bit of getting used to for me.
 
 I found that once I abandoned PDS datasets and used z/OS unix
 file systems on z/OS to store the source I was working on, all
 things began to fall into place.
 
 For build processes that need PDS input/output, OPUTX/OGETX are
 your friends.
 
 Rob.

[Disclaimer: I work at Rocket Software, and have interacted
 a fair amount with Rob.]

Rob, if you're a dinosaur, the species must be "velociraptor". :-)

I'm in the Open Source Tools group at Rocket; our goal is to make
the z/OS Unix environment as tool-rich and developer-friendly as
other Unix platforms.

We (the Open Source Tools group) store all of our code in git, using
the Rocket z/OS git port on one side and either BitBucket (internal)
or GitHub (external) on the other. The .gitattributes support we
added to git helps ease the EBCDIC/ASCII impedance mismatch. As Rob
knows, there are still some twitchy spots (ISPF panels can present
problems).

I do nearly all of my work in emacs (shell buffers are a wonderful
thing...), with very ocassional visits to TSO/ISPF and batchland (I
*really* want to be able to run SMP from a shell script; I'll get
there eventually...). While I understand the appeal of tools like
IDz, I personally prefer the somewhat looser integration of emacs,
and use a fair number of browser-based tools for collaboration
(Jira, the Confluence wiki, BitBucket/GitHub). I guess that makes
me the Unix equivalent of a dinosaur...

-- Jerry

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

Re: unexpected tape issue with RETAIN

[Chris Hoelscher]

Unit=aff=step.ddname  ???

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Friday, May 4, 2018 3:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] unexpected tape issue with RETAIN

I have a 50+ step backup job (using real 3590s) that has steps like:

//STEP049 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD4
//BACKUP   DD  DSN=DR.T.DSS.HKYTD4.,DISP=(NEW,KEEP,DELETE),
// UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP),
// LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSINDD  *
  DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*
//*
//STEP050 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD5
//BACKUP   DD  DSN=DR.T.DSS.HKYTD5.,DISP=(NEW,KEEP,DELETE),
// UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP),
// LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSINDD  *
  DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*

This job always worked on OS/390 2.10, but under z/OS 1.13, randomly, when 
going to a new step, it wants the current tape mounted on a different 3590. 
Additionally, it does not unload the tape from the first drive.

Also: If I have only one drive online, it runs to completion. If I have two 
drives, but the other one is busy, it runs to completion.

Info: This system is using RMM as a tape manager, but the files being created 
on the tape are not defined in any storage group or RMM.

It is driving me batty. I have to be 'not seeing' something.


--
Tony Thigpen

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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights 
laws and
do not discriminate on the basis of race, color, national origin, age, 
disability or
sex. Humana Inc. and its subsidiaries do not exclude people or treat them 
differently
because of race, color, national origin, age, disability or sex.

English: ATTENTION: If you do not speak English, language assistance services, 
free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis 
èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.


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

unexpected tape issue with RETAIN

[Tony Thigpen]

I have a 50+ step backup job (using real 3590s) that has steps like:

//STEP049 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD4
//BACKUP   DD  DSN=DR.T.DSS.HKYTD4.,DISP=(NEW,KEEP,DELETE),
// UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP),
// LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSINDD  *
 DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*
//*
//STEP050 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD5
//BACKUP   DD  DSN=DR.T.DSS.HKYTD5.,DISP=(NEW,KEEP,DELETE),
// UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP),
// LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSINDD  *
 DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*

This job always worked on OS/390 2.10, but under z/OS 1.13, randomly, 
when going to a new step, it wants the current tape mounted on a 
different 3590. Additionally, it does not unload the tape from the first 
drive.


Also: If I have only one drive online, it runs to completion. If I have 
two drives, but the other one is busy, it runs to completion.


Info: This system is using RMM as a tape manager, but the files being 
created on the tape are not defined in any storage group or RMM.


It is driving me batty. I have to be 'not seeing' something.


--
Tony Thigpen

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

Re: Rant

[Carmen Vitullo]

That sounds great Susan, and I have the KC server running on an LPAR here, 
(2.2) and using Softcopy Librarian V5 to load the contents, so where are all 
the 'other' books I'd like to load, DB2, MQ, IMS...to name a few? 
those KC books do not appear in any selection, .Boo or .PDF format for me to 
download. 
what am I missing? 



Carmen Vitullo 

- Original Message -

From: "Susan Shumway"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, May 4, 2018 12:13:59 PM 
Subject: Re: Rant 

You're hired, Elardus! ;-) 

Vignesh (and everybody else), Elardus's recommendation to start at the 
z/OS Internet Library ( 
http://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosInternetLibrary 
) is spot-on and what I tell people myself. From there, you can access 
all the different formats of the same product documentation. Every user 
has a favorite format for each situation, for example using the Indexed 
PDF collection for offline search and the KC for quickly navigating 
around and between many different deliverables and products. 

My own broken record statement is that we're constantly trying to 
improve how the Knowledge Center handles the extensive z/OS library of 
content. We always appreciate input, though. Even if your feedback 
regards something that we're already trying to implement, such as 
improved search, it's always welcomed. Let me know if you ever have any 
specific questions. 

-Sue Shumway 

On 05/03/18 6:16 AM, Elardus Engelbrecht wrote: 
> Sankaranarayanan, Vignesh wrote: 
> 
>> Whenever I search for anything mainframe-related on Google, the pages are 
>> almost always to v2r1 KC links. 
>> Although there's not too much difference in documentation between one 
>> release and another, just the non-IBM Plex font in v2r1 makes me manually 
>> change the URL each time. 
>> Sometimes, this doesn't work; the same page for another v2rx doesn't exist! 
> 
> They (other versions) are there. Start at 
> 
> https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosInternetLibrary?OpenDocument
>  
> 
> ... and select your version and then do you searches. 
> 
> Or if you are already in KC from a Google Search, then look at top left the 
> 'Home' and also at the z/OS version being displayed. 
> 
> If your are at a 'wrong' version, look for 'change version'. 
> 
> If you are still having wrong results, please post your keywords used in your 
> searches. 
> 
> Many people including me asked for help on IBM-MAIN about KC. You can search 
> IBM-MAIN about these complaints. You will get many hits. 
> 
> Consider use the 'Feedback' in the KC pages. Hopefully you will get an answer 
> or not. 
> 
> Groete / Greetings 
> Elardus Engelbrecht 
> 
> -- 
> For IBM-MAIN subscribe / signoff / archive access instructions, 
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
> 

-- 
Sue Shumway 
z/OS Product Documentation Lead 
IBM Poughkeepsie 
chale...@us.ibm.com 

-- 
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: Installation Exit routine environment (TCB vs. SRB)

[Charles Mills]

Done.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Friday, May 4, 2018 5:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Installation Exit routine environment (TCB vs. SRB)

It appears that relatively few exits document their TCB vs SRB 
requirements. They should.

While I wouldn't bet that it would get done quickly, a RCF asking for that 
documentation for every exit in the installations exits book seems like a 
good first step.

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

Re: WLM?

[Tom Marchant]

On Fri, 4 May 2018 12:19:14 -0500, Horst Sinram wrote:

>a daemon is a long running task, like an STC.

I wondered about that, but noticed that the Infoprint manual suggests 
using what Anne had described.

>A single period velocity goal is the preferred goal type for a daemon.

It might make sense to use SYSSTC if it is known to use few resources.

-- 
Tom Marchant

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

Re: Installation Exit routine environment (TCB vs. SRB)

[Charles Mills]

I shall do so.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Friday, May 4, 2018 5:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Installation Exit routine environment (TCB vs. SRB)

It appears that relatively few exits document their TCB vs SRB 
requirements. They should.

While I wouldn't bet that it would get done quickly, a RCF asking for that 
documentation for every exit in the installations exits book seems like a 
good first step.

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

Re: AC(1)

[John McKown]

On Fri, May 4, 2018 at 10:24 AM, Seymour J Metz  wrote:

> Why? Wouldn't it be better to put facilities requiring assembler into
> function packages so that other REXX scripts can use them? It's no rocket
> science.
>

​It's Friday. And I hit my head last night on a hard object (stumbling to
b-room). And I'm on vacation today. Three good reasons!


-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

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

[Gibney, Dave]

I guess I should mention that Bookmanager worked very well here.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Susan Shumway
> Sent: Friday, May 04, 2018 10:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Rant
> 
> You're hired, Elardus!  ;-)
> 
> Vignesh (and everybody else), Elardus's recommendation to start at the z/OS
> Internet Library ( https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.ibm.com_servers_resourcelink_svc00100.nsf_pages_zosInternet
> Library=DwICaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-
> Je7sw=u9g8rUevBoyCPAdo5sWE9w=Ws_xY_gt0uNnnTCMaBGoY67fRb
> 67632PRTxMTHQgEig=vCHEcuaSGqQwDNCRckr0ySSOEOIqqb1HNXHyvCdsj
> Bc=
> ) is spot-on and what I tell people myself. From there, you can access all the
> different formats of the same product documentation. Every user has a
> favorite format for each situation, for example using the Indexed PDF
> collection for offline search and the KC for quickly navigating around and
> between many different deliverables and products.
> 
> My own broken record statement is that we're constantly trying to improve
> how the Knowledge Center handles the extensive z/OS library of content.
> We always appreciate input, though. Even if your feedback regards
> something that we're already trying to implement, such as improved search,
> it's always welcomed. Let me know if you ever have any specific questions.
> 
> -Sue Shumway
> 
> On 05/03/18 6:16 AM, Elardus Engelbrecht wrote:
> > Sankaranarayanan, Vignesh wrote:
> >
> >> Whenever I search for anything mainframe-related on Google, the pages
> are almost always to v2r1 KC links.
> >> Although there's not too much difference in documentation between one
> release and another, just the non-IBM Plex font in v2r1 makes me manually
> change the URL each time.
> >> Sometimes, this doesn't work; the same page for another v2rx doesn't
> exist!
> >
> > They (other versions) are there. Start at
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www-
> 2D304.ibm.com
> > _servers_resourcelink_svc00100.nsf_pages_zosInternetLibrary-
> 3FOpenDocu
> > ment=DwICaQ=C3yme8gMkxg_ihJNXS06ZyWk4EJm8LdrrvxQb-
> Je7sw=u9g8rUev
> >
> BoyCPAdo5sWE9w=Ws_xY_gt0uNnnTCMaBGoY67fRb67632PRTxMTHQgE
> ig=_o8igbL
> > Ktvf4Fw5UU9uNMe11a32-cZvGBDUth-AF-NQ=
> >
> > ... and select your version and then do you searches.
> >
> > Or if you are already in KC from a Google Search, then look at top left the
> 'Home' and also at the z/OS version being displayed.
> >
> > If your are at a 'wrong' version, look for 'change version'.
> >
> > If you are still having wrong results, please post your keywords used in 
> > your
> searches.
> >
> > Many people including me asked for help on IBM-MAIN about KC. You can
> search IBM-MAIN about these complaints. You will get many hits.
> >
> > Consider use the 'Feedback' in the KC pages. Hopefully you will get an
> answer or not.
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> 
> --
> Sue Shumway
> z/OS Product Documentation Lead
> IBM Poughkeepsie
> chale...@us.ibm.com
> 
> --
> 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: WLM?

[Horst Sinram]

Anne,
a daemon is a long running task, like an STC. It makes very little sense to use 
multi period goals (with short durations) because it will eventually fall 
through to later periods. A single period velocity goal is the preferred goal 
type for a daemon. 
Only if the daemon would be at risk to loop you would consider a multi period 
goal using a *really huge* duration value. Even in that latter case a resource 
group would be a better safety net.
Horst Sinram - STSM, IBM z/OS Workload and Capacity Management

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

Re: Rant

[Susan Shumway]

You're hired, Elardus!  ;-)

Vignesh (and everybody else), Elardus's recommendation to start at the 
z/OS Internet Library ( 
http://www.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosInternetLibrary 
) is spot-on and what I tell people myself. From there, you can access 
all the different formats of the same product documentation. Every user 
has a favorite format for each situation, for example using the Indexed 
PDF collection for offline search and the KC for quickly navigating 
around and between many different deliverables and products.


My own broken record statement is that we're constantly trying to 
improve how the Knowledge Center handles the extensive z/OS library of 
content. We always appreciate input, though. Even if your feedback 
regards something that we're already trying to implement, such as 
improved search, it's always welcomed. Let me know if you ever have any 
specific questions.


-Sue Shumway

On 05/03/18 6:16 AM, Elardus Engelbrecht wrote:

Sankaranarayanan, Vignesh wrote:


Whenever I search for anything mainframe-related on Google, the pages are 
almost always to v2r1 KC links.
Although there's not too much difference in documentation between one release 
and another, just the non-IBM Plex font in v2r1 makes me manually change the 
URL each time.
Sometimes, this doesn't work; the same page for another v2rx doesn't exist!


They (other versions) are there. Start at

https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosInternetLibrary?OpenDocument

... and select your version and then do you searches.

Or if you are already in KC from a Google Search, then look at top left the 
'Home' and also at the z/OS version being displayed.

If your are at a 'wrong' version, look for 'change version'.

If you are still having wrong results, please post your keywords used in your 
searches.

Many people including me asked for help on IBM-MAIN about KC. You can search 
IBM-MAIN about these complaints. You will get many hits.

Consider use the 'Feedback' in the KC pages. Hopefully you will get an answer 
or not.

Groete / Greetings
Elardus Engelbrecht

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



--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

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

Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

[Seymour J Metz]

An alias entry in a PDS directory doesn't point to the base name, it points to 
the actual member. And, yes, I know about load modules, but what the link 
editor/binder puts in the user halfwords doesn't count.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Thursday, May 3, 2018 2:16 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: [EXTERNAL] Re: IEFA107I when pointing to dataset alias

On Thu, May 3, 2018 at 1:06 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 3 May 2018 15:22:22 +, Seymour J Metz wrote:
>
> >That was my point; if you need it at IPL time and it's cataloged in a
> user catalog, you need an explicit volume serial.
> >
> I'm (slowly) coming to grasp that.  At IPL time, the CAS is not
> initialized and
> user catalogs can not be searched.  So data sets needed during IPL must
> either
> be catalogued in the master cat or accessed by explicit volume serial.
>
> But in the case that impacted me many years ago, I wanted both the alias
> and
> the related DSN in different user cats.  I didn't need either during IPL
> (not my
> job) and in user cats they couldn't be accessed during IPL.  It still
> disconcerts me
> that after CAS initialization a user cat can't be searched for the alias
> and the HLQ
> of that alias could not identify a possibly different user cat to search
> for the
> related DSN.
>
> (Ih another case I would have found it useful to have an alias of an
> alias.  That,
> also, should be supported.)
>
> --gil
>
>
​This is disconcerting to me too. But I can envision what might be
happening. The logic to me would be something like:

1) Find catalog in which A.B.C exists according to the standard search order
2) Read entry for A.B.C in that catalog​.
3) If alias, find the base related-to entry in the catalog.

This reminds me a bit of BPAM. Suppose you have member A, but not B, in
PDS1. Now suppose you have B in PDS2 as an alias to A (in PDS2). If you ask
for member B then you get A in PDS2, not the PDS1 version. Granted, I don't
think that BPAM actually uses the A entry in PDS2 for anything when you
reference B, but I can easily be wrong. I'm speaking conceptually. The way
you & I want it to work is like a UNIX symlink (which can traverse to
another filesystem), but it is working more like a hard link (which cannot
span filesystems).


--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

[Seymour J Metz]

In the last few years I've had better luck using wiki as a search engine than 
using google; even though google allegedly has syntax for restricting the 
search, it still gives lots of hits that don't match;  a "smart" search of the 
"Do what I want in some alternate universe rather than what's in my search 
string" flavor.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Thursday, May 3, 2018 8:35 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Rant

I love Google. I use it all the time, both professionally and personally.

But I'm a realist. I know Google is not in this game out of altruism.

To answer your question more or less, it is sad to say I use about four methods 
of finding z documentation -- not because I like variety, but because each is 
about a 70-80% solution. (BookManager, PDFs resident on my notebook, 
KnowledgeCenter and Google)

Maybe IBM should rename it KnowledgeCensor. (If that name catches on, you heard 
it here first.)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Thursday, May 3, 2018 4:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rant

On 4/05/2018 4:36 AM, Charles Mills wrote:
> I saw the most wonderful quote the other day, regarding free services (like
> Google, but not to pick on them in particular).
>
> "If you're not paying for it, then you're not the customer. And if you're
> not the customer, you're the merchandise."

Most people here would be paying IBM for software licenses, so are
indirectly paying for documentation i.e. Knowledge Center.

Is the search you're paying for better than the free Google one?

--
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: AC(1)

[Seymour J Metz]

Why? Wouldn't it be better to put facilities requiring assembler into function 
packages so that other REXX scripts can use them? It's no rocket science.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Friday, May 4, 2018 7:44 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: AC(1)

On Fri, May 4, 2018 at 6:33 AM, Peter Relson  wrote:

> ...the logic above is done on _every_ OPEN for _every_ DD
> name. Or is it only if the OPEN is for a DCB which is BPAM (i.e. the DD
> concatenation is for libraries)?
> 
>
> I'm not sure, but since APF authorization applies only to load libraries,
> I'd imagine that the OPEN processing is done
> only for cases where it applies.
>
> 
> IPLINFO is a REXX exec.
> 
>
> I believe you. The code that was shown was assembler. Regardless, being an
> exec still means that the choice was made not to use an intended
> programming interface.
>

​I hit my head last night, as will be obvious from:

OOH! OOH! I have an idea for REXX: "embedded assembler". Followed by
"embedded ".​



>
> Peter Relson
> z/OS Core Technology Design
>


--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

--
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: [EXTERNAL] Re: HLQ change of SMP/E files

[Wheeler, Simon]

Hi,

Maybe it would be possible to rename the datasets as desired and create dataset 
aliases for the old names, so no SMP/E changes would be required?

thanks,
Simon
 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CM Poncelet
Sent: 03 May 2018 16:27
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: HLQ change of SMP/E files

Hi Vignesh,
 
Yes, all the existing datasets can be copied - i.e. 'cloned' - to new datasets 
with new names. Both the DZONE and TZONE of the new CSI then need to be renamed 
and pointed at each other, and all the new CSI's DDDEFs need to be pointed at 
their new dataset names. It is all done via UCL.
 
Bear in mind that a cloned CSI's GLOBAL zone is still pointing at the original 
CSI's DZONE and TZONE, and this needs to be changed to point it at the cloned 
CSI's DZONE and TZONE.
 
Cheers, Chris Poncelet
 
 

On 03/05/2018 05:17, Sankaranarayanan, Vignesh wrote:
> Hi Chris,
>
> Is it not possible to move the existing datasets into their new names 
> (rename), and do the required UCL work.
>
> – Vignesh
> Mainframe Infrastructure
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of CM Poncelet
> Sent: Thursday 03-May-2018 09:06
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: HLQ change of SMP/E files
>
> There is more to it than that if you are cloning (copying) a CSI into 
> another CSI. E.g.
>  
> "ZONEEXPORT, UCLIN, ZONEDELETE, DEL/ADD/REP ZONEINDEX GZONE/DZONE/TZONE,"
> "ENDUCL, ZONEIMPORT ... RELATED() etc. and then"
> "DEL/REP/ADD DDDEF() DA() SHR to point at"
> "the DDDEF 'WHYNOT' DSNs in the GZONE/DZONE/TZONE."
>
> You need also to relate your cloned DZONE and TZONE to each other in the 
> cloned CSI, as in e.g.
>
> SET BOUNDARY(DZONE)
> .
> ZONEIMPORT (DZONE) INFILE(IMPORTDZ) INTO(DZONE) RELATED(TZONE) .
> SET BOUNDARY(TZONE)
> .
> ZONEIMPORT (TZONE) INFILE(IMPORTTZ) INTO(TZONE) RELATED(DZONE) .
>
> All the original CSI's SMP/E datasets should be IEBCOPY'd or IEBGENER'd to 
> 'WHYNOT.*' datasets - and the cloned CSI's DDDEFs then updated to point at 
> the 'WHYNOT.*' datasets in its GLOBAL, DZONE and TZONE.
> (Otherwise any RECEIVE, APPLY and ACCEPTs would be applied to the 
> original CSI's SMP/E datasets.)
>  
> Chris Poncelet (retired sysprog)
>  
>  
>
>
> On 02/05/2018 18:27, Sankaranarayanan, Vignesh wrote:
>> Hi Kurt,
>>
>> Thanks for this; the product is in its own target and dlip zones, product 
>> has its own CSI.
>> So the ZONEINDEX is for consideration only when TGT and DLIB have their own 
>> zones, or even if they're all in a single product CSI?
>>
>> PS: Big fan of getting replies from various IBM development teams!!
>>
>> – Vignesh
>> Mainframe Infrastructure
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of Kurt Quackenbush
>> Sent: Wednesday 02-May-2018 18:03
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: [EXTERNAL] Re: HLQ change of SMP/E files
>>
>> On 5/1/2018 9:51 AM, Sankaranarayanan, Vignesh wrote:
>>
>>> So will a ZONEEDIT be all, or are there other things to be mindful of?
>> ZONEEDIT is all you need to update the data set names in the DDDEF 
>> entries for the target and dlib data sets.  However, is this product 
>> installed in its own target and dlib zones?  Are those zones in their 
>> own CSI data sets?  If you'll be renaming the CSI data sets too, then 
>> you'll need to update the ZONEINDEX subentries in the global zone, 
>> like
>> this:
>>
>> SET BDY(GLOBAL).
>> UCLIN.
>> DEL GZONE ZONEINDEX((tgtzonename)).
>> ADD GZONE ZONEINDEX((tgtzonename,WHYNOT.dataset.name.CSI,TARGET)).
>> DEL GZONE ZONEINDEX((dlibzonename)).
>> ADD GZONE ZONEINDEX((dlibzonename,WHYNOT.dataset.name.CSI,DLIB)).
>> ENDUCL.
>>
>> Kurt Quackenbush -- IBM, SMP/E Development
>>
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO 
>> IBM-MAIN
>>
>> MARKSANDSPENCER.COM
>> 
>>  Unless otherwise stated above:
>> Marks and Spencer plc
>> Registered Office:
>> Waterside House
>> 35 North Wharf Road
>> London
>> W2 1NW
>>
>> Registered No. 214436 in England and Wales.
>>
>> Telephone (020) 7935 4422
>> Facsimile (020) 7487 2670
>>
>> www.marksandspencer.com
>>
>> Please note that electronic mail may be monitored.
>>
>> This e-mail is confidential. If you received it by mistake, please let us 
>> know and then delete it from your system; you should not copy, disclose, or 
>> distribute its contents to anyone nor act in reliance on this e-mail, as 
>> this is prohibited and may be unlawful.
>>
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to 

Re: RFE for zfsadm man page enhancement

[Carmen Vitullo]

Done 



Carmen Vitullo 

- Original Message -

From: "Lionel B. Dyck (TRA)"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, May 4, 2018 8:27:13 AM 
Subject: RFE for zfsadm man page enhancement 

Please vote for this RFE 

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=119658 

Description: 
The zfsadm man page is a good start but needs to be enhanced thus: 

1. Enable 'man -k .' to find information within it 
2. Expand to support the various zfsadm sub-commands (e.g. config) 
- suggest following the example of the ssh man pages which have ssh, ssh-add, 
ssh-agent, etc 

Thank you 

Lionel B. Dyck 

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

RFE for zfsadm man page enhancement

[Dyck, Lionel B. (TRA)]

Please vote for this RFE

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=119658

Description:
The zfsadm man page is a good start but needs to be enhanced thus:

1. Enable 'man -k .' to find information within it
2. Expand to support the various zfsadm sub-commands (e.g. config)
- suggest following the example of the ssh man pages which have ssh, 
ssh-add, ssh-agent, etc

Thank you

Lionel B. Dyck

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

Re: MF Application source control?

[Rob Scott]

Dave

As someone who is a complete dinosaur and used to source control systems like 
SCLM, it took a bit of getting used to for me.

I found that once I abandoned PDS datasets and used z/OS unix file systems on 
z/OS to store the source I was working on, all things began to fall into place.

For build processes that need PDS input/output, OPUTX/OGETX are your friends.

Rob.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, May 4, 2018 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MF Application source control?

Thanks Rob.  Already have it downloaded and installed.  :)   It's the knitting 
all the pieces together and making it work that scares me.   Then there is the 
"training" of all of our "legacy programmers".

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Scott
Sent: Friday, May 04, 2018 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MF Application source control?

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Dave,

Rocket Software offer an open source GIT port for z/OS - see 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fzos-open-source%2Ftools=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7Cee18e18d7db54bd6994508d5b1ba2577%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636610335433485805=VFYZZoVSNqeJoXz8FGh1850K4JBCsDo0NcPFk26AN2A%3D=0.

I use it and I like it.

Rob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, May 4, 2018 12:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MF Application source control?

All,

I've seen occasional comments here regarding z/OS GIT, DEVOPS, etc.Just 
wondering if anyone has taken the plunge for mainframe source code management 
that is similar to open systems?  I'm talking about using iDZ as the IDE, GIT, 
GIThub, Jenkins, Urban Code Deploy, etc?   Our open systems folks are already 
headed down this path, although not all the pieces are in place yet, and it 
seems like a logical next step that MF ought to be on this ship as well.

Just looking for someone that's already there, or working on getting there, 
that may be willing to share some back-and-forth sharing of experiences 
offline?  The topic has my interest, but is a really large departure from what 
used to be typical mainframe application management.   I'm having a hard time 
wrapping my head around a lot of this.

Thanks, Dave

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
 Rocket Software, Inc. and subsidiaries ■ 77 
Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 
Contact Customer Support: 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7Cee18e18d7db54bd6994508d5b1ba2577%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636610335433485805=WFXIZMjWtliTkf9qR0YwVize5vLJeB6wnLzHp%2FasVac%3D=0
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7Cee18e18d7db54bd6994508d5b1ba2577%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636610335433485805=Etb058fa%2F0C3JW955dFPCQjE4vRPz7C4xgw4AvyRPTw%3D=0
Privacy Policy - 

Re: MF Application source control?

[Pew, Curtis G]

On May 4, 2018, at 7:01 AM, Rob Scott  wrote:
> 
> Rocket Software offer an open source GIT port for z/OS - see 
> http://www.rocketsoftware.com/zos-open-source/tools.
> 
> I use it and I like it.
> 

Me too. I develop on both z/OS and Unix and my workflow is very similar. (I 
don’t much care for IDEs, though. I do my editing in emacs or vi.)


-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: MF Application source control?

[Jousma, David]

Thanks Rob.  Already have it downloaded and installed.  :)   It's the knitting 
all the pieces together and making it work that scares me.   Then there is the 
"training" of all of our "legacy programmers".

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Scott
Sent: Friday, May 04, 2018 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MF Application source control?

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Dave,

Rocket Software offer an open source GIT port for z/OS - see 
http://www.rocketsoftware.com/zos-open-source/tools.

I use it and I like it.

Rob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, May 4, 2018 12:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MF Application source control?

All,

I've seen occasional comments here regarding z/OS GIT, DEVOPS, etc.Just 
wondering if anyone has taken the plunge for mainframe source code management 
that is similar to open systems?  I'm talking about using iDZ as the IDE, GIT, 
GIThub, Jenkins, Urban Code Deploy, etc?   Our open systems folks are already 
headed down this path, although not all the pieces are in place yet, and it 
seems like a logical next step that MF ought to be on this ship as well.

Just looking for someone that's already there, or working on getting there, 
that may be willing to share some back-and-forth sharing of experiences 
offline?  The topic has my interest, but is a really large departure from what 
used to be typical mainframe application management.   I'm having a hard time 
wrapping my head around a lot of this.

Thanks, Dave

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
 Rocket Software, Inc. and subsidiaries ■ 77 
Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: Dynamic LNKLST SET limitations?

[Tom Marchant]

On Thu, 3 May 2018 14:11:11 -0500, Steve Horein wrote:

>Yes, I used the set name "LNKLSTxx" arbitrarily for demonstration purposes.
>The current PROGxx defines several sets, with the final set activated at
>IPL time having a name similar to 
>
>What I am trying to avoid, in addition to "requiring" an IPL for the sake
>of 1 or 2 products, is the risk of undoing a change performed by someone
>else.
>I think the esteemed Mr. McKown identified some of the potential issues
>involved (re: [UNDEFINE] "fails if LNKLST is in use by some address space".)
>
>Presume LNKLST00 contains both product "A" and product "B".
>
>Time constraints dictate product "B" is upgraded before product "A".
>LNKLST01 is defined with new product "B" data sets, resolving an SD37 abend
>when attempting to reuse the existing LNKLST00 data sets.

When you upgrade a product, you should ALWAYS use new data sets. For the 
LNKLST data sets, a new LNKLST set is created, with the new library replacing 
the old one. You may have to add an entry to the APF list too.

Do not use SETPROG LLA,UPDATE unless it is absolutely necessary that an address 
space have the new LNKLST set. It is better to recycle the address space.

Other data sets, like panels and clists can be accessed using a data set alias 
that is defined with SYMBOLICRELATE. All you have to do is to change the 
symbol and activate the new LNKLST. The window of opportunity for a job to 
start and allocate mixed versions is small.

>Time now allows product "A" be upgraded. LNKLST02 is defined to include
>system specific data sets for the product, resolving the need for
>SYSPLEX-wide product outage whenever the current shared data set needs the
>ole "kill-n-fill" followed by "F LLA..."  approach,

Yes, that is dangerous, and I would never do that on a production system. For 
that matter, I would not do it on a test system either. It is easy to do it the 
safe way, as I described above. 

BTW, when you define a new LNKLST set, LLA refresh or update is not needed, 
though an LLA UPDATE is needed if you want to remove a data set from LLA 
management.

>At this point, should product "B" encounter an error, my preference would
>be to define LNKLST03, with the bigger data sets being deleted after the
>COPYFROM=CURRENT, leaving product "A" intact.

I think you mean add the old data set after the previous new one and delete 
the previous new one from the new LNKLST set. Also change the symbol used 
by SYMBOLICRELATE for other data sets.

>If PTF for product "B" comes along, I suppose going back to LNKLST02 is an
>option, but... suppose someone has upgraded product "C" in the mean time,
>introducing LNKLST04.

Yes, you have to know what has been done and why.
D PROD LNKLST is your friend. There are many variations.

-- 
Tom Marchant

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

Re: MF Application source control?

[Edgington, Jerry]

Dave,

I have working on this very topic for the past year or two.  I have giving 
presentations to IBM zCouncil and there was a presentation on the last SHARE 
conference in Sacramento.  And I will be giving a SHARE Live! Presentation in 
St. Louis in August. 

Here are the tools that I have been working with.  I have built a proof of 
technology for some of them

POT -   Eclipse IDE, using IBM Aqua, Compuware Topaz Workbench, Git, 
Jenkins, Groovy, Java, z/OS Connect EE version 1 and CICS v5.2
On the List -   SonarQube, SonarLint, IBM's DBB and UrbanCopy Deploy.  I have 
worked with IBM's DBB during the alpha and beta trials.
Future -JIRA, Confluence and various other open source tools

To proof out the POT, we were able to develop a RESTFul service for CICS

However, I have since changed jobs, so I had to start over at my new company.  
But, they have purchased IBM's ADDI, and the Analyze client is included with 
IBM Aqua Plugin.

Jerry Edgington

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, May 04, 2018 7:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MF Application source control?

All,

I've seen occasional comments here regarding z/OS GIT, DEVOPS, etc.Just 
wondering if anyone has taken the plunge for mainframe source code management 
that is similar to open systems?  I'm talking about using iDZ as the IDE, GIT, 
GIThub, Jenkins, Urban Code Deploy, etc?   Our open systems folks are already 
headed down this path, although not all the pieces are in place yet, and it 
seems like a logical next step that MF ought to be on this ship as well.

Just looking for someone that's already there, or working on getting there, 
that may be willing to share some back-and-forth sharing of experiences 
offline?  The topic has my interest, but is a really large departure from what 
used to be typical mainframe application management.   I'm having a hard time 
wrapping my head around a lot of this.

Thanks, Dave

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




--
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: Installation Exit routine environment (TCB vs. SRB)

[Peter Relson]

It appears that relatively few exits document their TCB vs SRB 
requirements. They should.

While I wouldn't bet that it would get done quickly, a RCF asking for that 
documentation for every exit in the installations exits book seems like a 
good first step.

Peter Relson
z/OS Core Technology Design


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

Re: MF Application source control?

[Rob Scott]

Dave,

Rocket Software offer an open source GIT port for z/OS - see 
http://www.rocketsoftware.com/zos-open-source/tools.

I use it and I like it.

Rob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, May 4, 2018 12:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MF Application source control?

All,

I've seen occasional comments here regarding z/OS GIT, DEVOPS, etc.Just 
wondering if anyone has taken the plunge for mainframe source code management 
that is similar to open systems?  I'm talking about using iDZ as the IDE, GIT, 
GIThub, Jenkins, Urban Code Deploy, etc?   Our open systems folks are already 
headed down this path, although not all the pieces are in place yet, and it 
seems like a logical next step that MF ought to be on this ship as well.

Just looking for someone that's already there, or working on getting there, 
that may be willing to share some back-and-forth sharing of experiences 
offline?  The topic has my interest, but is a really large departure from what 
used to be typical mainframe application management.   I'm having a hard time 
wrapping my head around a lot of this.

Thanks, Dave

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

MF Application source control?

[Jousma, David]

All,

I've seen occasional comments here regarding z/OS GIT, DEVOPS, etc.Just 
wondering if anyone has taken the plunge for mainframe source code management 
that is similar to open systems?  I'm talking about using iDZ as the IDE, GIT, 
GIThub, Jenkins, Urban Code Deploy, etc?   Our open systems folks are already 
headed down this path, although not all the pieces are in place yet, and it 
seems like a logical next step that MF ought to be on this ship as well.

Just looking for someone that's already there, or working on getting there, 
that may be willing to share some back-and-forth sharing of experiences 
offline?  The topic has my interest, but is a really large departure from what 
used to be typical mainframe application management.   I'm having a hard time 
wrapping my head around a lot of this.

Thanks, Dave

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: Dynamic LNKLST SET limitations?

[Peter Relson]

As with anything that has storage requirements, there is a limit. That 
limit might be enforced or might be "until you run out of the necessary 
storage".
LNKLST sets are no different. There is no enforcement.  The storage in 
this case is ECSA.

Terminology correction: There is a *current* LNKLST set.  There can be any 
number of *active* LNKLST sets.
An active LNKLST was current at some point but is still in use by some 
address space, whether it is still current or not.
Once the last user of a non-current LNKLST set ends, the LNKLST set 
becomes inactive.

It is true that new jobs and new address spaces are associated with the 
current LNKLST set.
That association remains for the life of the job or address space unless 
you do a LNKLST UPDATE.

Doing a LNKLST UPDATE is unpredictably dangerous, and can range from 
having no down side to abends to a wait state.
There is little to no sympathy to be given to those who encounter the 
adverse effects because they did it to themselves..
The only thing that is safe is to let the system do the LNKLST assignments 
as it intends to do.

Peter Relson
z/OS Core Technology Design


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

Re: AC(1)

[John McKown]

On Fri, May 4, 2018 at 6:33 AM, Peter Relson  wrote:

> ...the logic above is done on _every_ OPEN for _every_ DD
> name. Or is it only if the OPEN is for a DCB which is BPAM (i.e. the DD
> concatenation is for libraries)?
> 
>
> I'm not sure, but since APF authorization applies only to load libraries,
> I'd imagine that the OPEN processing is done
> only for cases where it applies.
>
> 
> IPLINFO is a REXX exec.
> 
>
> I believe you. The code that was shown was assembler. Regardless, being an
> exec still means that the choice was made not to use an intended
> programming interface.
>

​I hit my head last night, as will be obvious from:

OOH! OOH! I have an idea for REXX: "embedded assembler". Followed by
"embedded ".​



>
> Peter Relson
> z/OS Core Technology Design
>


-- 
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

AC(1)

[Peter Relson]

...the logic above is done on _every_ OPEN for _every_ DD
name. Or is it only if the OPEN is for a DCB which is BPAM (i.e. the DD
concatenation is for libraries)?


I'm not sure, but since APF authorization applies only to load libraries, 
I'd imagine that the OPEN processing is done 
only for cases where it applies.


IPLINFO is a REXX exec.


I believe you. The code that was shown was assembler. Regardless, being an 
exec still means that the choice was made not to use an intended 
programming interface.

Peter Relson
z/OS Core Technology Design


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

Re: AC(1)

[Rob Scott]

I believe that the "IPLINFO" rexx exec pre-dates the dynamic APF implementation 
and used to show the APF table using the rexx inbuilt storage function by 
traversing the static APF control blocks (I cannot remember if these fields 
were GUPI or not).

When dynamic APF was introduced, someone spent some time attempting to reverse 
engineer the APF control blocks to try and keep IPLINFO a pure REXX exec.

I can understand the motivation to do so, however as more things in z/OS go to 
a second level of abstraction (eg dynamic update functionality) and use OCO 
control blocks this style of reverse engineering could get very difficult to 
maintain.

If it were up to me, I would probably invest the time is composing a suite 
external REXX functions that could invoke supported problem state services like 
"CSVAPF REQUEST=LIST" and return the results in rexx stems using IRXEXCOM.

Using this technique would mean that the code was using standard interfaces for 
the information it wants to display.

Rob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Thursday, May 3, 2018 7:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AC(1)

On 5/3/2018 4:47 AM, Peter Relson wrote:
> ... IPLINFO itself must have been changed when dynamic APF was
> introduced but chose not to use the provided programming interface
> (CSVAPF REQUEST=LIST) to gain access to the data.

Umm... IPLINFO is a REXX exec.

As such, it cannot invoke z/OS system services unless they support a standard 
externally-callable interface.

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.phoenixsoftware.com%2F=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7C8783299e0c434a59727a08d5b1201feb%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C636609673913772392=rOBcpTImD%2FPcDWdrVSu65A1MBpcvHjLkMlkRmn9tmEw%3D=0

This e-mail message, including any attachments, appended messages and the 
information contained therein, is for the sole  use of the intended 
recipient(s). If you are not an intended recipient or have otherwise received 
this email message in error, any use, dissemination, distribution, review, 
storage or copying of this e-mail message and the information contained therein 
is strictly prohibited. If you are not a intended recipient, please contact the 
sender by reply e-mail and destroy all copies of this email message  and do not 
otherwise utilize or retain this email message or any or all of the information 
contained therein. Although this email message and any attachments or appended 
messages are believed to be free of any virus or other defect that might affect 
any computer system into which it is received and opened, it is the 
responsibility of the recipient to ensure that it is virus free and no 
responsibility is accepted by the sender for any loss or damage arising in any 
way from its opening or use.

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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