Goodbye.

2020-08-03 Thread Vernooij, Kees (ITOP NM) - KLM
After more than 41 years working as a mainframe systems programmer, the time 
has come for me to say goodbye.
I enjoyed the mainframe world in all the aspects that I worked with, from SVS 
1.7 to z/OS 2.4, from a 370/158 to a z13s and all other flavours that came and 
went in the past decades.

It was a pleasure and an honour to participate in the ibm-main group, with all 
its high technical skills, that gave me so many answers and where I could 
answer some questions too.
But most I enjoyed the company of this global community, where I met people 
from all over the world, with their unlimited willingness to help others, their 
humour, their rants and their Friday afternoon subjects. I am really gonna miss 
all this.

I will retire on the 11th and unsubscribe then.
I wish you all the best!

Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Beware: OA54815:SINGLE SYSTEM SCOPE COUPLE DATA SET and GDPS V4R1.

2020-07-29 Thread Vernooij, Kees (ITOP NM) - KLM
Do not try to use the beautiful z/OS V2R4 enhancement OA54815: NEW FUNCTION - 
SINGLE SYSTEM SCOPE COUPLE DATA SET, if you still run GDPS V4R1.

GDPS 4.1 does not know this type of Couple Datasets and takes 2 irritating 
actions:

-  Cancel IXGLOGR as soon as GPDS sees it

-  GDPS option Sysplex Resource Management display a pink line about an 
unsupported/invalid CDS type.

Reverting to not using this enhancement (not start IXGLOGR) on GDPS K-systems 
solves problem 1, but does not solve problem 2.
This is (probably) due to the fact that the LOGRY/LOGRZ CDSs are still known in 
the Sysplex administration (D XCF,CPL displays them).
We are currently investigating how to solve this, probably with a Sysplex Wide 
IPL with new Sysplex Couple Datasets without any memory of the LOGRY/LOGRZ 
CDS's.

There is support for the new CSD types in GDPS V4R2, but not in V4R1. This way 
it appears that GDPS V4R2 is a pre-req for z/OS V2R4, but it is not explicitly 
stated this way.
We find this very irritating and annoying.

Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: SORT Capacity Exceeded

2020-07-29 Thread Vernooij, Kees (ITOP NM) - KLM
General recommendation: in most situations DFSORT is well able to calculate its 
SORTWK's. 
Remove SORTWK's from JCL, update parms: remove DYNALLOC=N, check the DFSORT 
defaults and use the where possible.

Kees

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Richards, Robert B.
Sent: 29 July 2020 13:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SORT Capacity Exceeded

I am out of my element trying to figure out the following SORT issue. Job runs 
normally when the number of SORTIN records is much less. JCL contains 16 SORTWK 
datasets. If memory serves, isn't there a way to let SORT figure out how much 
it needs?

 ICE000I 1 - CONTROL STATEMENTS FOR 5650-ZOS, Z/OS DFSORT V2R3  - 05:24 ON TUE 
JUL 28, 2020 -
   SORT FIELDS=(5,1,CH,A,9,35,CH,A,44,8,CH,D)
ICE193I 0 ICEAM1 INVOCATION ENVIRONMENT IN EFFECT - ICEAM1 ENVIRONMENT SELECTED
ICE088I 0 RACFRPD1.STEP02  ., INPUT LRECL = 32672, BLKSIZE = 32676, 
TYPE = VB
ICE093I 0 MAIN STORAGE = (MAX,67108864,67108864)
ICE156I 0 MAIN STORAGE ABOVE 16MB = (67051504,67051504)
ICE127I 0 OPTIONS: OVFLO=RC0 ,PAD=RC0 ,TRUNC=RC0 
,SPANINC=RC16,VLSCMP=N,SZERO=Y,RESET=Y,VSAMEMT=Y,DYNSPC=256
ICE128I 0 OPTIONS: 
SIZE=67108864,MAXLIM=5242880,MINLIM=524880,EQUALS=Y,LIST=Y,ERET=RC16 
,MSGDDN=SYSOUT
ICE129I 0 OPTIONS: VIO=N,RESDNT=ALL ,SMF=NO   
,WRKSEC=Y,OUTSEC=Y,VERIFY=N,CHALT=N,DYNALOC=N ,ABCODE=MSG
ICE130I 0 OPTIONS: RESALL=4096,RESINV=0,SVC=109 
,CHECK=Y,WRKREL=Y,OUTREL=Y,CKPT=N,COBEXIT=COB2
ICE131I 0 OPTIONS: 
TMAXLIM=6291456,ARESALL=0,ARESINV=0,OVERRGN=65536,CINV=Y,CFW=Y,DSA=64
ICE132I 0 OPTIONS: VLSHRT=N,ZDPRINT=Y,IEXIT=N,TEXIT=N,LISTX=N,EFS=NONE
,EXITCK=S,PARMDDN=DFSPARM ,FSZEST=N
ICE133I 0 OPTIONS: HIPRMAX=OPTIMAL,DSPSIZE=64  
,ODMAXBF=0,SOLRF=Y,VLLONG=N,VSAMIO=N,MOSIZE=MAX
ICE235I 0 OPTIONS: NULLOUT=RC0
ICE236I 0 OPTIONS: DYNAPCT=10 ,MOWRK=Y,TUNE=STOR,EXPMAX=600,EXPOLD=200
,EXPRES=100
ICE084I 0 EXCP ACCESS METHOD USED FOR SORTOUT
ICE084I 0 EXCP ACCESS METHOD USED FOR SORTIN
ICE750I 0 DC 0 TC 100121518644 CS DSVTT KSZ 48 VSZ 48
ICE752I 0 FSZ=100121518644 BC  IGN=0 E  AVG=16336 0  WSP=130040639 C  DYN=0 0
ICE805I 1 JOBNAME: RACFRPD1 , STEPNAME: STEP02
ICE802I 0 BLOCKSET TECHNIQUE IN CONTROL
ICE905I 1 I : RF=80,LR=32672,BLK=32676,BCT=3064069
ICE906I 0 ST=ABOVE,SR=67108864,RC=0
ICE907I 0 ST=ABOVE,SA=67108848,NF=1,LF=67108848,SF=67108848
ICE906I 0 ST=BELOW,SR=5218304,RC=4
ICE907I 0 ST=BELOW,SA=4206512,NF=4,LF=4198384,SF=864
ICE992I 0 RA 0 WR 0 TR 0
ICE915I 0 MOFSZ=2894,MOSZ=0,MOSYS=600(5),MOSTG=600,MEML=3877(1)
ICE916I 0 MOFR=0002,MOVR=DD
ICE996I 0 
ESM=153600,ESO=51200,ESR=25600,ESP=4864,ESS=16384,CES=9749504,HSZ=16777216
ICE997I 0 HWSP=61109325,HMAX=153600,MOMAX=0,ASV=153600,EQ=N1,HN=0
ICE898I 0 
OMAX=4529097,NMAX=7751551,ENQT=153600,CMAX=0,HU=0,BUN=0,MD=NK,N6,DU=0,DR=0,HN=0
ICE889I 0 CT=MAX , SB=241, L=0, D=, CCW=1MAM
ICE901I 0 W 01PP17 02PP17 03PP17 04PP17 05PP17 06PP17 07PP17 08PP17
ICE901I 0 W 09PP17 10PP17 11PP17 12PP17 13PP17 14PP17 15PP17 16PP17
ICE902I 0 O JZ11  I JZ11
ICE906I 1 ST=ABOVE,SR=67051504,RC=0
ICE907I 1 ST=ABOVE,SA=67051488,NF=1,LF=67051488,SF=67051488
ICE906I 1 ST=BELOW,SR=55920,RC=0
ICE907I 1 ST=BELOW,SA=47712,NF=1,LF=47712,SF=47712
ICE046A 0 SORT CAPACITY EXCEEDED - RECORD COUNT 37505288
ICE253I 0 RECORDS SORTED - PROCESSED: 37505288, EXPECTED: 612
ICE098I 0 AVERAGE RECORD LENGTH - PROCESSED: 1486, EXPECTED: 16336
ICE751I 1 D8-I58435 D4-BASE   E8-I58435
ICE052I 0 END OF DFSORT

SORT step gets RC=16 and subsequent step gets S413-18 trying to read the passed 
file. A different day read in 69 million records to be sorted and it blew up. 
Ran to RC=0 today reading only 24 million records. For the curious...RACF audit 
records are what is being read and sorted.

Bob



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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286

Re: TS7760 Cache utilization

2020-07-22 Thread Vernooij, Kees (ITOP NM) - KLM
Request the Historial statistics and filter out the TVCSIZE and TVCUSED values.

Kees.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: 22 July 2020 13:49
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TS7760 Cache utilization

Hi,
How can I find out, using a batch job, the TS7760 cache utilization?

Thanks

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: Storage & tape question

2020-07-08 Thread Vernooij, Kees (ITOP NM) - KLM
I agree with your findings.

At one time, one headlight of my car failed. Since it has two headlights, I did 
not make much hurry to replace it, but 2 days later the other one failed. Then 
I was left in almost complete darkness. A SPOF is a SPOF and is subject to 
Murphy's law, which means it will hit you at the most inconvenient momemt.

The TS7740 has several selection criteria for physical tape reclaims: one is 
the period a tape has not been mounted. The max period you can set here was 365 
days (or not do it at all). There must be a good reason to limit this period to 
1 year, not more.

Kees.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bill Ogden
Sent: 08 July 2020 15:27
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage & tape question

Probably many others will chime in on this. I have lost RAID 5 arrays with 
two disk failures within an hour of each other. RAID is nice, but one must 
allow for failures.

Long ago I was involved with reading archived tapes and transferring the 
data to CDs. The programs involved were home-written and the project ended 
up going nowhere. However, we discovered that tapes  kept too long started 
having errors. (At that point, for the CD copy, we just logged the error 
and accepted the corrupt data; what else could we do?) How long is "too 
long"?? It was variable, but measured in a few years. The advice then was 
to minimally read the tapes every year or so to "retension" them. Don't 
know if this would apply to more modern tape media.  (We also discovered 
that locally "burned" CDs are not expected last forever.)

IMHO, the key point for tape backups are (1) off-site storage, (2) 
multiple PiT recovery, (3) logical error recovery. All this can be done 
with disk-only environments involving remote copy and lots of disk space, 
but all that becomes expensive for smaller shops.

Bill Ogden


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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: Does adding real storage require an IPL?

2020-06-25 Thread Vernooij, Kees (ITOP NM) - KLM
That is exactly how it works: in the activation profile you specify the memory 
and reserved memory for an LPAR. That is all it will see after activation with 
that profile.

Kees

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Babcock
Sent: 25 June 2020 15:12
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Does adding real storage require an IPL?

We recently added some unassigned memory to our production LPAR and IPL’d.
The memory did not show.  We had to deactivate the LPAR and reactivate it
to add the memory.This was on a z14-ZR1 with z/OS 2.3.


On Thu, Jun 25, 2020 at 5:31 AM R.S.  wrote:

> W dniu 23.06.2020 o 02:07, Charles Mills pisze:
> > Today is real storage day. Sorry for the elementary questions.
> >
> > The folks that own the box as a whole have added memory to our LPAR. Do
> we
> > need to IPL to pick that up in z/OS, or is there a command or similar
> > process? I thought I heard at a SHARE presentation that it could be done
> > dynamically, but the box owners are telling us an IPL is required.
> >
> > PR/SM, not VM, if that matters.
> >
>
> I don't understand details, so my answer is rather general:
> 1. LPAR can be defined with memory and "reserved" memory. That means it
> is possible to get more memory than assingned during LPAR activation
> (usually IML process).
> 2. OS may or may not support dynamic memory change. z/OS does support
> it. So, it is possible to dynamically add memory to the system.
> Assumpions are: LPAR definition as described above *and* free
> (unassigned) storage in CPC. Free storage may come from deactivated
> (other) LPAR.
> 3. It is also possible to buy memory without physical deactivation of
> CPC. It is memory which is already inside the CPC, but microcode will
> enable it for user. It can be done dynamically, and new memory will
> appear as unassigned to any LPAR. Then you can add it do a system as
> described above.
> 4. Amount of "memory for sale" within CPC depend on many factors. As far
> as I know IBM want to disable this option ("preplanned memory"), however
> AFAIK it is still possible to get a little bit more than ordered and the
> gap can be bought and enabled.
>
> Personally I always define LPARs with reserved memory just to have
> option to for future unknown need. And I had cases when I really needed
> additional memory.
>
>
> HTH
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senat
> orska
> 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy
> dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego,
> KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości)
> według stanu na 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar
> action, violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senat
> orska
> 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District
> Court for the Capital City of Warsaw, 12th Commercial Division of the
> National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up
> share capital amounting to PLN 169.401.468 as at 1 January 2020.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for 

Re: dfdss equivalent to fdr map

2020-06-18 Thread Vernooij, Kees (ITOP NM) - KLM
CA-DISK has a similar function: Volume Map. The report is a little less useful 
(to me) so I process it with SAS to generate an FDR like report.

Kees.


Volume Map by CCH.   
 
Volser=SYSR02
 
Dsname  LengthExtent  CCH
 
  *VTOC*  270   1  16:00 
SYSRECV.TSS.MVST.VSAMBKUP   1   2  40:10 
SYSRECV.TSS.MVSX.VSAMBKUP   1   2  40:11 
SYSRECV.TSS.MVSY.VSAMBKUP   1   2  40:12 
SYSRECV.SAR.PROD.SARRECV1   1  40:13 
SYSRECV.TSS.MVSC.VSAMBKUP   1   2  40:14 
SYSRECV.TSS.MVST.VSAMBKUP  15   1  41:00 
  **FREE SPACE**   14  42:00 
SYSRECV.ICF.VXSYS30.ALIASES.G8056V001   1  42:14 
SYSRECV.ICF.VYSYS30.ALIASES.G8056V001   1  43:00 
  **FREE SPACE**3  43:01 
SYSRECV.ICF.RCVR#C.ALIASES.G6936V00 1   1  43:04 
SYSRECV.ICF.WARE#1.ALIASES.G0460V00 1   1  43:05 
SYSRECV.ICF.WARE#2.ALIASES.G0831V00 1   1  43:06 
SYSRECV.ICF.USER#2.ALIASES.G0014V00 5   1  43:07 
SYSRECV.ICF.DEPT#1.ALIASES.G0012V00 2   1  43:12 
SYSRECV.ICF.PROD#1.ALIASES.G0011V00 1   1  43:14


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian France
Sent: 18 June 2020 15:45
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: dfdss equivalent to fdr map

That's what we're looking for and DFDSS does not seem to have the 
equivalent

On 6/18/2020 9:42 AM, Vernooij, Kees (ITOP NM) - KLM wrote:
> FDR MAP produces a physical map of the volume, with from-to CCHHR for each 
> dataset and their extents.
>
> Kees
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> John McKown
> Sent: 18 June 2020 15:36
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: dfdss equivalent to fdr map
>
> On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote:
>
>>I can't find a dfdss equivalent to fdr's map. I see the print command
>> but can't seem to get a whole volume list of data sets as we do with
>> fdr's map. If it exists would someone please point me to it... THANX!!!
>>
> I don't know what an FDR MAP does. but if you need to know what datasets
> are on a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN'
>
> Something like:
>
> //JS010EXEC  PGM=ADRDSSU,PARM='TYPRUN=NORUN',
> // REGION=0M
> //SYSPRINT DD  SYSOUT=*
> //TAPE1DD  DSN=JES2DISK.ADRDSSU,
> // DISP=OLD
> //SYSINDD  *
>   RESTORE  -
>  DATASET( -
>INCL( -
> **-
>  ) -
> ) -
>  IDD(TAPE1) -
>  ADMINISTRATOR -
>  TOL(ENQF) WAIT(0,0)
>
>
>
>
>> --
>> Brian W. France
>> Systems Administrator (Mainframe)
>> Pennsylvania State University
>> Penn State IT - Infrastructure/SYSARC
>> Rm 25 Shields Bldg., University Park, Pa. 16802
>> 814-863-4739
>> b...@psu.edu
>>
>> There's no such thing as The Cloud - it's just someone else's computer...
>>
>> "To make an apple pie from scratch, you must first invent the universe."
>>
>> Carl Sagan
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
-- 
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

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

For information, services and offers, please visit our 

Re: dfdss equivalent to fdr map

2020-06-18 Thread Vernooij, Kees (ITOP NM) - KLM
FDR MAP produces a physical map of the volume, with from-to CCHHR for each 
dataset and their extents.

Kees


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John McKown
Sent: 18 June 2020 15:36
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: dfdss equivalent to fdr map

On Thu, Jun 18, 2020 at 7:53 AM Brian France  wrote:

>   I can't find a dfdss equivalent to fdr's map. I see the print command
> but can't seem to get a whole volume list of data sets as we do with
> fdr's map. If it exists would someone please point me to it... THANX!!!
>

I don't know what an FDR MAP does. but if you need to know what datasets
are on a DFDSS dump tape, then run a RESTORE with PARM='TYPRUN=NORUN'

Something like:

//JS010EXEC  PGM=ADRDSSU,PARM='TYPRUN=NORUN',
// REGION=0M
//SYSPRINT DD  SYSOUT=*
//TAPE1DD  DSN=JES2DISK.ADRDSSU,
// DISP=OLD
//SYSINDD  *
 RESTORE  -
DATASET( -
  INCL( -
   **-
) -
   ) -
IDD(TAPE1) -
ADMINISTRATOR -
TOL(ENQF) WAIT(0,0)




>
> --
> Brian W. France
> Systems Administrator (Mainframe)
> Pennsylvania State University
> Penn State IT - Infrastructure/SYSARC
> Rm 25 Shields Bldg., University Park, Pa. 16802
> 814-863-4739
> b...@psu.edu
>
> There's no such thing as The Cloud - it's just someone else's computer...
>
> "To make an apple pie from scratch, you must first invent the universe."
>
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
People in sleeping bags are the soft tacos of the bear world.
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 information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: dfdss equivalent to fdr map

2020-06-18 Thread Vernooij, Kees (ITOP NM) - KLM
To be precise, MAP is not an FDR function, it is an ABR function, which also 
came along with COMPAKTR. When we dismissed the latter, we also lost the MAP 
function.

Kees.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Brian France
Sent: 18 June 2020 14:54
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: dfdss equivalent to fdr map

  I can't find a dfdss equivalent to fdr's map. I see the print command 
but can't seem to get a whole volume list of data sets as we do with 
fdr's map. If it exists would someone please point me to it... THANX!!!

-- 
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Penn State IT - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

There's no such thing as The Cloud - it's just someone else's computer...

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: New Mainframe Community

2020-06-15 Thread Vernooij, Kees (ITOP NM) - KLM
And I don't like the fact that I have to subscribe and give (no idea how much 
of) my personal info first, before they even give the slightest information 
about themselves.

Kees.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: 15 June 2020 16:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

I thought the StackOverflow forum was extremely promising but it died on the
vine.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith III
Sent: Sunday, June 14, 2020 6:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

Lionel B Dyck wrote:

>Check this out - looks new but promising

>https://mainframe.community/

 

Just what we need: Yet another nascent mainframe forum that will die on the
vine. Not that community is a bad thing, it's not-but
moving it from this list has been tried repeatedly: mainframezone, SHARE
forums, and a few more I can't remember.

 

While it might in principle be better than this list, it seems a stretch to
expect it to take over. And fragmentation is almost
certainly not a good thing.

 

...phsiii


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

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: System Exit

2020-06-04 Thread Vernooij, Kees (ITOP NM) - KLM
In my experience, changing secondary allocations can create problems, because 
on fragmented volumes it is more difficult to get large secondary extents than 
small extents. We provide dataclasses with DVC for large datasets with or 
without poor secondary allocations.

Kees.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
PINION, RICHARD W.
Sent: 04 June 2020 15:30
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: System Exit

Does anybody have a system exit that has the ability to 
increase the secondary allocation for a data set, after 
"x" number of extents?

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: System Exit

2020-06-04 Thread Vernooij, Kees (ITOP NM) - KLM
> Do you work with your users on how to properly allocate a dataset?

I have given up a long time ago to make users do what I want them to do. I use 
the ACS routines to make them do what I want them to do.

Met vriendelijke groet,
Kees Vernooij
KLM Information Services
z/OS Systems
Tel +31 6 10 14 58 78


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lizette Koehler
Sent: 04 June 2020 15:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: System Exit

Do you have any tools like EASYEXIT?  Or ACC?  Or BMC Tools (use to be Stop-X37 
or PROSMS)?

In ISMF You can set up a class to include dynamic volume count. 

In SMS environment we see Seq and VSAM regularly take up to 100's of extents 
when a dataset is poorly allocated.

Do you use SMS for these datasets?

Do you work with your users on how to properly allocate a dataset?

My rule of thumb is small Primary and large Secondary with RLSE where possible.

Lizette



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
PINION, RICHARD W.
Sent: Thursday, June 4, 2020 6:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: System Exit

Does anybody have a system exit that has the ability to increase the secondary 
allocation for a data set, after "x" number of extents?

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Creating new SMS environment in a monoplex

2020-05-25 Thread Vernooij, Kees (ITOP NM) - KLM
There is regularly confusion about the term Plex and Sysplex. 
There a many Plexes:
JESPLEX (MAS)
GRSPLEX
MIMPLEX
SMSPLEX
SAPLEX and SA-SUBPLEX
IMSPLEX
DB2PLEX
CICSPLEX
Etc.
And there is: SYSPLEX.
Sysplex is often used when one of the others are meant: a SYSPLEX consists of 
the systems controlled by XCF, see the D XCF command.

You can't/shouldn't share Dasd between GDPS P- and K- systems, although they 
are in the same Sysplex, so you can't shouldn't make SMSPLEX = SYSPLEX.

If you really want to and you use MIM, you can make an SMSplex cross Sysplexes, 
with PDSE restrictions.

Kees.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: 21 May 2020 12:10
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Creating new SMS environment in a monoplex

No, not exactly.
First, I meant "regular" sysplex. In that case it is possible and 
recommended to have SMSplex=sysplex.
However it is also possible to have multiple SMSplexes within a sysplex, 
and within GDPS.

And I mean SMSplex can be cross-plex - yes, it is possible. Multiple 
non-sysplexed systems can share SMS.
Correct me if I'm wrong.

-- 
Radoslaw Skorupka
Lodz, Poland






W dniu 20.05.2020 o 19:33, Vernooij, Kees (ITOP NM) - KLM pisze:
> SMSPLEX=SYSPLEX: no, you can't.
> GDPS K-systems cannot share Dasd with GDPS P-systems, so they must have 
> separate SMS plexes.
>
> If you mean: an SMSplex cannot cross Sysplexes: that is true.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> R.S.
> Sent: 20 May 2020 17:14
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Creating new SMS environment in a monoplex
>
> To complement: there is strict requirement to have SMSplex = Sysplex.
>
> SMS, as many other system components does support multihost configurations.
> Multihost could mean several monoplex systems and shared CDS datasets on
> shared volume.
> Multihost could also mean SMSplex which covers some sysplex and few
> monoplexes together.
> SMSplex could also cover part of sysplex, so different sysplex member
> may have different SMS settings.
>
> As usually IBM recommend to keep SMSplex = sysplex.
>
> Note: the above apply to DFSMSrmm, OAM (and tape libraries), etc.
>
> However each system component may have it's own specifics/restrictions.
> AFAIK, in the very old days JES2 MAS could go beyond sysplex. Now it is
> impossible - JES MAS is available only within sysplex boundaries.
> However it is possible to have more than one MAS within sysplex.
> Sometimes sysplex=*plex give some advantages, especially sysplex
> communication and CF structures.
>



==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any

Re: Creating new SMS environment in a monoplex

2020-05-20 Thread Vernooij, Kees (ITOP NM) - KLM
SMSPLEX=SYSPLEX: no, you can't.
GDPS K-systems cannot share Dasd with GDPS P-systems, so they must have 
separate SMS plexes.

If you mean: an SMSplex cannot cross Sysplexes: that is true.

Kees.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: 20 May 2020 17:14
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Creating new SMS environment in a monoplex

To complement: there is strict requirement to have SMSplex = Sysplex.

SMS, as many other system components does support multihost configurations.
Multihost could mean several monoplex systems and shared CDS datasets on 
shared volume.
Multihost could also mean SMSplex which covers some sysplex and few 
monoplexes together.
SMSplex could also cover part of sysplex, so different sysplex member 
may have different SMS settings.

As usually IBM recommend to keep SMSplex = sysplex.

Note: the above apply to DFSMSrmm, OAM (and tape libraries), etc.

However each system component may have it's own specifics/restrictions.
AFAIK, in the very old days JES2 MAS could go beyond sysplex. Now it is 
impossible - JES MAS is available only within sysplex boundaries. 
However it is possible to have more than one MAS within sysplex.
Sometimes sysplex=*plex give some advantages, especially sysplex 
communication and CF structures.

-- 
Radoslaw Skorupka
Lodz, Poland






W dniu 19.05.2020 o 21:22, Vernooij, Kees (ITOP NM) - KLM pisze:
> I can confirm that.
> We have 2 sysplexes (Prod and Test), both with 2 GPDS K-systems.
> GDPS K-systems don's share Dasd with the other systems of the sysplex.
> So we have 6 SMS environments, each with their own SCDS, ACDS and COMMDS.
> We have 1 SMS configuration that covers all systems and in the ACS routines, 
> we route datasets to storage groups, depending on the system it runs on.
> We update the 'source' SMS configuration on the test sysplex systems, 
> activate it on the 3 SMS environments in the Test Sysplex and test it.
> Then we transfer the SCDS to the 3 SMS environments of the Prod Sysplex and 
> activate it there.
> We have no problem with this setup. The advantage is that you don't make 
> typo's when trying to copy the updates in the test-environment to the 
> prod-environment.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Richards, Robert B.
> Sent: 19 May 2020 17:58
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Creating new SMS environment in a monoplex
>
> Thanks, Radoslaw.
>
> My point, and I think you have also confirmed it, is that an SMS environment 
> has no specific dependence on a parallel sysplex, CFs, couple datasets, etc.
>
> All that is left for me is to finish building the system and IPL it.
>
> Bob
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> R.S.
> Sent: Tuesday, May 19, 2020 11:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Creating new SMS environment in a monoplex
>
> W dniu 18.05.2020 o 20:36, Richards, Robert B. pisze:
>> It has been a few decades since I have created a new SMS environment.
>>
>> Current environment is parallel sysplex replete with CFs and lots of lpars.
>>
>> I am trying to create a simple SMS environment that will be part of a 
>> monoplex consisting on one lpar.
>>
>> I did the following:
>>
>>
>> 1.  Defined the new SYSNAME into the base configuration in ISMF and 
>> activated same. D SMS verified it was defined and not active
>> 2.  A REPRO of the SCDS into a new SCDS dataset (Alter/newname to 
>> correct usercat)
>> 3.  Issued a SETSMS SAVEACDS(also using a SSA connector that I 
>> subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected 
>> to a new mastercat)
>> 4.  Defined an empty COMMDS that I also performed an alter/newname to 
>> get the desired COMMDS dataset name.
>>
>> My boss says the ACDS is aware of the original sysplex environment and my 
>> gyrations of trying to make the above work in a monoplex will not succeed.
>>
>> Who is right? Will it work or not?
> Quick and dirty method:
> 1. Add new system name to existing SCDS and ACDS. Don't worry, it is nothing 
> wrong to have non-present system names there.
> 2. Copy all *CDS to disk belonging to new system.
> 3. IPL the system.
>
> Of course this is method for some migration. ACS routines, class definitions 
> and library definitions will be moved. Is that what you want?
> Otherwise there is another method, to start from scratch. ACS routines can be 
> easily imported, class definitions - the only way I know is to re-define them 
> manually.
> BTW: some dummy SMS environment is delivered with ServerPac. I always start 
> from that point. Then IPL

Re: Creating new SMS environment in a monoplex

2020-05-19 Thread Vernooij, Kees (ITOP NM) - KLM
I can confirm that.
We have 2 sysplexes (Prod and Test), both with 2 GPDS K-systems. 
GDPS K-systems don's share Dasd with the other systems of the sysplex.
So we have 6 SMS environments, each with their own SCDS, ACDS and COMMDS.
We have 1 SMS configuration that covers all systems and in the ACS routines, we 
route datasets to storage groups, depending on the system it runs on.
We update the 'source' SMS configuration on the test sysplex systems, activate 
it on the 3 SMS environments in the Test Sysplex and test it. 
Then we transfer the SCDS to the 3 SMS environments of the Prod Sysplex and 
activate it there.
We have no problem with this setup. The advantage is that you don't make typo's 
when trying to copy the updates in the test-environment to the prod-environment.

Kees.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Richards, Robert B.
Sent: 19 May 2020 17:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Creating new SMS environment in a monoplex

Thanks, Radoslaw.

My point, and I think you have also confirmed it, is that an SMS environment 
has no specific dependence on a parallel sysplex, CFs, couple datasets, etc.

All that is left for me is to finish building the system and IPL it.

Bob


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Tuesday, May 19, 2020 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Creating new SMS environment in a monoplex

W dniu 18.05.2020 o 20:36, Richards, Robert B. pisze:
> It has been a few decades since I have created a new SMS environment.
>
> Current environment is parallel sysplex replete with CFs and lots of lpars.
>
> I am trying to create a simple SMS environment that will be part of a 
> monoplex consisting on one lpar.
>
> I did the following:
>
>
>1.  Defined the new SYSNAME into the base configuration in ISMF and 
> activated same. D SMS verified it was defined and not active
>2.  A REPRO of the SCDS into a new SCDS dataset (Alter/newname to correct 
> usercat)
>3.  Issued a SETSMS SAVEACDS(also using a SSA connector that I 
> subsequently ALTER NEWNAME the new ACDS into a new usercat that is connected 
> to a new mastercat)
>4.  Defined an empty COMMDS that I also performed an alter/newname to get 
> the desired COMMDS dataset name.
>
> My boss says the ACDS is aware of the original sysplex environment and my 
> gyrations of trying to make the above work in a monoplex will not succeed.
>
> Who is right? Will it work or not?

Quick and dirty method:
1. Add new system name to existing SCDS and ACDS. Don't worry, it is nothing 
wrong to have non-present system names there.
2. Copy all *CDS to disk belonging to new system.
3. IPL the system.

Of course this is method for some migration. ACS routines, class definitions 
and library definitions will be moved. Is that what you want?
Otherwise there is another method, to start from scratch. ACS routines can be 
easily imported, class definitions - the only way I know is to re-define them 
manually.
BTW: some dummy SMS environment is delivered with ServerPac. I always start 
from that point. Then IPL with CPAC system name, then add my name to ACDS then 
reIPL with my system name. Then *CDS datasets can be imported (copied). Piece 
of cake.

--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.


Re: Catalogs in parallel sysplex ECS vs RLS

2020-04-24 Thread Vernooij, Kees (ITOP NM) - KLM
>While RLS catalog sharing require more effort to establish, it wasn't 
>introduced just for fun. It seems customers needed some enhancement over 
>ECS.

IIRC from the course, it was for performance reasons. RSL provides better 
performance for heavily used catalogs.

Met vriendelijke groet,
Kees Vernooij
KLM Information Services
z/OS Systems
Tel +31 6 10 14 58 78


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: 24 April 2020 11:20
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Catalogs in parallel sysplex ECS vs RLS

W dniu 23.04.2020 o 16:29, Peter Vander Woude pisze:
> Ok, building parallel sysplex.  For the catalogs I am planning on using ECS 
> for the shared catalogs (which is all of them).
>
> What is the recommended method for handling the catalogs in a parallel 
> sysplex, ECS or VSAM RLS?

What is recommended method? It depends. :-)
WHAT DO YOU NEED?

"Legacy" catalog sharing is worse than ECS.
ECS is relatively easy to implement.
However many years later IBM introduced catalog sharing with RLS. It is 
more effective for extensive sharing of given BCS, however Master 
Catalog cannot be shared that way.
While RLS catalog sharing require more effort to establish, it wasn't 
introduced just for fun. It seems customers needed some enhancement over 
ECS.

Again, YMMV, we don't know your workload, etc.
If you are starting with that, think about VLF (it's not related to 
sharing), then ECS. However if you are using RLS, you have the 
infrastructure up and ready, so RLS catalog sharing seem to be low 
hanging fruit.

Last, but not least: sharing outside sysplex is completely different 
animal, and you should avoid it as possible. In that case absolutely 
don't try to use ECS or RLS.

-- 
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Catalogs in parallel sysplex ECS vs RLS

2020-04-24 Thread Vernooij, Kees (ITOP NM) - KLM
I recall from a z/OS update course, a couple of years ago already, the 
recommendation that RLS for Catalogs was the way to go.

Kees.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Vander Woude
Sent: 23 April 2020 16:29
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Catalogs in parallel sysplex ECS vs RLS

Ok, building parallel sysplex.  For the catalogs I am planning on using ECS for 
the shared catalogs (which is all of them).

What is the recommended method for handling the catalogs in a parallel sysplex, 
ECS or VSAM RLS?

Thanks,
Peter

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Opinions/experience on sharing catalogs outside plex

2020-04-20 Thread Vernooij, Kees (ITOP NM) - KLM
2 notes:
You need not regress to pre-GRS, you need to regress to pre-Hyperswap, which 
required the elimination of Reserves by converting them to global enqueus with 
GRS.
CA-MIM provided (when we used it) GRS functionality across Sysplexes.

Kees.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Allan Staller
Sent: 20 April 2020 14:45
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Opinions/experience on sharing catalogs outside plex

Yes, it can be done. I reiterate,  IMO,  this is most likely not a good idea.
In order to accomplish this safely, you  also need to regress GRS to pre-GRS 
functionality.
Everything affecting this catalog must be handled w/Reserve/Release, and not 
normal processing
VSAM Sharoptions for the catalog need to be changed. IIRC when I "undid" this 
the catalog hand Shareoptions (2,3) (or was it 4,3?).
This option tells z/OS that the user is responsible for Catalog seriailization.
SYSDSN, SYSIGGV2, SYSVTOC, SYSZVSAM (?) and the SPF* queues need to be excluded 
from GRS processing.

In my case that led to various deadly embraces that usually led to manual 
intervention.

My $0.02 USD on this is: Why point the shotgun at your foot?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Monday, April 20, 2020 3:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Opinions/experience on sharing catalogs outside plex

[CAUTION: This Email is from outside the Organization. Do not click links or 
open attachments unless you trust the sender.]

W dniu 09.04.2020 o 02:11, Rob Schramm pisze:
> I am considering sharing some usercats outside of a sysplex.  What I
> can find is that sysiggv2 must be kept as a reserve to do so.
>
> Looking for others that have had to do this.
>
> One question I had was, what happens on a ispf 3.4 when the data set
> is part of the catalog but exists in another system?  Ief238d?

My €0.02

1. You can share catalogs between sysplexes. Note: we mean BCS, which is 
usually called catalog.
2. The less activity on the BCS the better.
3. The above means:
3.1. Avoid keeping non-shared datasets in the BCS. Use another BCS for that.
3.2. It is not bad idea to have multiple "small" shared BCSes.
4. You cannot use any sophisticated catalog sharing features like RLS or ECS.

Regarding you last question: I understand it as you have entry in the BCS, but 
the dataset reside on volume which is not share, that mean it is unavailable 
for one system. It's nothing exotic. It's like orphan catalog entry, which 
sometimes may happen even without BCS sharing (usually as result of human 
error).
However that also means the sharing is not done correctly. The best scenario is 
when all datasets cataloged in shared BCS reside on volumes which are also 
shared. Preferably the BCS is also on the volume from that group.
Keep it simple.

--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mbank.pl%2Fdata=02%7C01%7Callan.staller%40HCL.COM%7C713bf3ba05ee48822fd708d7e5074106%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637229691688462036sdata=yVU69jxSqL3eUaQBzQrjAJf41Ro%2FWUQ12ueSnw0%2Fhu0%3Dreserved=0,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 
169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mbank.pl%2Fdata=02%7C01%7Callan.staller%40HCL.COM%7C713bf3ba05ee48822fd708d7e5074106%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637229691688462036sdata=yVU69jxSqL3eUaQBzQrjAJf41Ro%2FWUQ12ueSnw0%2Fhu0%3Dreserved=0,
 e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th 
Commercial Division of the National Court Register, KRS 025237, NIP: 

Re: Opinions/experience on sharing catalogs outside plex

2020-04-09 Thread Vernooij, Kees (ITOP NM) - KLM
Do you use ECS or VLF catalog caching? That sounds like a road to problems.

Kees.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Schramm
Sent: 09 April 2020 02:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Opinions/experience on sharing catalogs outside plex

I am considering sharing some usercats outside of a sysplex.  What I can
find is that sysiggv2 must be kept as a reserve to do so.

Looking for others that have had to do this.

One question I had was, what happens on a ispf 3.4 when the data set is
part of the catalog but exists in another system?  Ief238d?

Thanks,

Rob Schramm

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: adrdssu utility

2020-03-25 Thread Vernooij, Kees (ITOP NM) - KLM
A Mistake I made many times: you should not put filtlist names in quotes, only 
strings.
So in your routine,  is compared to the string ''
To compare  to the filtlist , you should code: ( EQ )

Met vriendelijke groet,
Kees Vernooij
KLM Information Services
z/OS Systems
Tel +31 6 10 14 58 78


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shelia Chalk
Sent: 25 March 2020 15:52
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: adrdssu utility

has anyone ever use adrdssu utility to restore a dataset from tape and rename 
then dataset. here is my problem  see jcl below
I am trying to use the sms routines.  I want the renameu dataset q2vo.slc.*** 
to go to a different volume  then the include dataset. in the sms routines I 
have   in the  I have in the filtlist the q2vo.** dataset..

 
IF (( EQ 'RECOVER') AND ( EQ ''))  
THEN 
  DO 
SET  = 'FIST'   
EXIT 
  END  

 

JCL I AM RUNNING

 //D2REST   EXEC PGM=ADRDSSU,REGION=8M  
//SYSPRINT DD SYSOUT=* 
//OUTDDDD UNIT=SYSDA,DISP=(NEW,CATLG,CATLG)
//INDD DD DSN=Q2SC.GN.GN.P010.GNTAPE.Q2BKUP(0),
//DISP=SHR 
//DUMMYDD   DUMMY  
//SYSINDD   *  
 RESTORE INDD(INDD) OUTDD(OUTDD) - 
DATASET( - 
INCLUDE(-  
Q2VO.GN.GN.P010.GNCDE.V -  
   ) - 
  ) -  
   RENAMEU((Q2VO.GN.GN.P010.GNCDE.V-   
Q2VO.SLC.**   )) - 
CANCELERROR -  
CATALOG -  
TGTGDS(ACTIVE)-
REPLACE-   
SHR SPHERE 



any ideas???

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: OT: Mandatory Work From Home at my company

2020-03-23 Thread Vernooij, Kees (ITOP NM) - KLM
About a decade ago, we switched to company mobile phones. At the same time, 
most of the internal fixed telephone network was dismantled. I think the 
justified the mobiles business case for a great deal.

Kees.


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: 23 March 2020 14:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OT: Mandatory Work From Home at my company

I don't remember when I observed pagers in US last time, but it was 
definitely after 2000, maybe 2002 or 2004. Earlier I observed many IT 
folks equipped with the pager, not the cell phone. Note: it's nothing 
wrong, it is just a difference which put my attention, like many other 
things is US. Do you know you have differend curbs and pavements in 
cities? Not worse, but different ;-)

Some of you write about private phone. Well. In Poland it is completely 
unusual to use private phone for business. Maybe the explanation is 
(was!) the tariff. Personally I have never had private cell phone. Yes, 
I use it for private calls, I'm allowed to. In the past (2008, Lehman 
Bros...) some beancounter wanted to make savings on the calls. After 
analysis my boss took me to the conversation and obliged me to use the 
cell phone ...more. Yes, MORE. My monthly bill was approx. 2-3 dollars. 
Both: private and business calls together. Our company tariff were good.
Now I have Samsung S9 which allows to use two SIM cards, however many 
coworkers still use two phones - private and business. Not to talk about 
mobile app. developers - some of them have even 8 phones.
Back to the topic: it is completely unusual to use private phone for 
company calls. Rather one gets the phone for that purpose.
Mobile phones are quite cheap nowadays.

The other difference I observed is company car. My observation is this 
is popular in Poland and Europe, but not so popular in US. Obviously 
company car is not so common as comany phone or company laptop.

Disclaimer: I talk about IT & financial niche, not about every business.

-- 
Radoslaw Skorupka
Lodz, Poland





W dniu 22.03.2020 o 18:41, Bob Bridges pisze:
> I'm with David on this one.  A few days ago someone in this conversation said 
> he wouldn't use a personal cell phone for company business, and I didn't say 
> anything about it at the time.  But I put my phone on an unlimited plan years 
> ago, and never since thought twice about using it for business and personal.  
> (Besides, I'm totally unwilling to carry around two cell phones.)
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* When their love was strong they could sleep on the edge of a sword, but 
> now when they have forgotten, a bed sixty feet across is not sufficient.  
> -Rab Akiva, quoted in _The Source_ by James Michener */
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Jousma, David
> Sent: Friday, March 20, 2020 12:53
>
> I haven’t seen a pager since I started in this business.  When was the last 
> time you were over here Radoslaw, you might be aging yourself there...    
> Pretty much everyone has cell phones, but I doubt that many are company 
> issued any more.   For us they are not.  No biggie, I'd have one anyway, and 
> cell minutes are no longer a metered item.  I do have company apps on my 
> phone, not an employer requirement, more for my own convenience.


==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up 

Re: RUCSA

2020-03-13 Thread Vernooij, Kees (ITOP NM) - KLM
Yes, RUCSA goes in units of 1 MB.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: Thursday, March 12, 2020 6:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RUCSA

That rather implies segment-level protection, rather than page.

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   12/03/2020 16:59
Subject:[EXTERNAL] Re: RUCSA
Sent by:IBM Mainframe Discussion List 



RUCSA has to be allocated on a 1M boundary, so take that into consideration 
when looking at your virtual storage map. A RUCSA allocation below the line, if 
you don't also reduce CSA will result in the below the line private being 
reduced by 1M. Extended private isn't usually much of a concern.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key -
https://urldefense.proofpoint.com/v2/url?u=https-3A__api.protonmail.ch_pks_lookup-3Fop-3Dget-26search-3Dmarkjacobs-40protonmail.com=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=lNiQeZuiD4Q6umXm_yMCJWEXWafS72oqVI88BoMIYB8=3Ic9ZT6StCzl4I0XY0hY1sJAM4AoTn_emnlZJULRPI0=
 


‐‐‐ Original Message ‐‐‐
On Thursday, March 12, 2020 12:11 PM, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> Thanks for clarifying Jim!
>
> Dave Jousma
>
> AVP | Manager, Systems Engineering
>
> Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, 
MI 49546
>
> 616.653.8429 | fax: 616.653.2717
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf 
of Jim Mulder d10j...@us.ibm.com
> Sent: Thursday, March 12, 2020 11:38:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RUCSA
>
> CAUTION EXTERNAL EMAIL
>
> DO NOT open attachments or click on links from unknown senders or 
unexpected emails
>
> For releases earlier than z/OS 2.4, RUCSA is provided by APAR OA56180.
>
> R790 PSY UA98722 UP19/03/28 P F903
> R7A0 PSY UA98723 UP19/03/28 P F903
> R7B0 PSY UA98724 UP19/03/28 P F903
>
> publibz.boulder.ibm.com/zoslib/pdf/OA56180.pdf
>
> Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
> Poughkeepsie NY
>
> "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU wrote on
> 03/12/2020 11:07:04 AM:
>
> > From: "Jousma, David" 01a0403c5dc1-dmarc-requ...@listserv.ua.edu
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 03/12/2020 11:34 AM
> > Subject: Re: RUCSA
> > Sent by: "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU
>
> > The problem with RUCSA "feature" not being available in prior
> > version (maybe it is, I just don’t see it), is that there is no path
> > to convert into that prior to rolling V2.4. I guess all the
> > prep work could be done (SAF rules, etc) ahead of time, but that
> > would surely be a "must check out". The other problem with RUCSA
> > is that if your offending/affected app requires below-the-line CSA,
> > the minimum amount of RUCSA is 1MB, even if you only needed a few K
> > for whatever you are doing. That will affect below-the-line
> > private for sure.
>
> --
>
> 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.
>
>
> 

Re: RUCSA

2020-03-13 Thread Vernooij, Kees (ITOP NM) - KLM
We have it running on V2.2.
Remember: it only remediates the userkey (E)CSA problem, nog the userkey 
dataspace problem.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Thursday, March 12, 2020 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RUCSA

Yea.   The idea is to remediate.  We had one home grown automation tool that we 
retired (finally), and one vendor (FiServ) banking application that they have 
remediated, so we are clear to roll V2.4 to prod.  

The problem with RUCSA "feature" not being available in prior version (maybe it 
is, I just don’t see it), is that there is no path to convert into that *prior* 
to rolling V2.4.I guess all the prep work could be done (SAF rules, etc) 
ahead of time, but that would surely be a "must check out".   The other problem 
with RUCSA is that if your offending/affected app requires below-the-line CSA, 
the minimum amount of RUCSA is 1MB, even if you only needed a few K for 
whatever you are doing.   That will affect below-the-line private for sure.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Thursday, March 12, 2020 10:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RUCSA

**CAUTION EXTERNAL EMAIL**

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

Well, any product that requires ALLOWUSERKEYCSA(YES) won't run on z/OS
2.4 until you do install it.

On Thu, Mar 12, 2020 at 7:54 AM Dana Mitchell  wrote:
>
> Is anyone using RUCSA yet?  We currently have a very old ISV product that 
> requires running with ALLOWUSERKEYCSA(YES)   on z/OS 2.2.   As we prepare for 
> new hardware to support upgrade to z/OS 2.4,  I'm faced with the possibility 
> of needing to run 2.4 with RUCSA  if we cannot get an upgrade for this old 
> ISV product  in time.
>
> I see RUCSA as orderable on ShopZ,  just wondering,  can it be ordered and 
> installed seperately or does it need to be ordered at the same time as the 
> z/OS 2.4 order?
>
> Thanks
> Dana
>
> On Wed, 6 Nov 2019 19:38:33 +, Jousma, David  wrote:
>
> >Folks,
> >
> >Remind me, is RUCSA support a chargeable feature?  I find nothing in the 
> >manual, the only clue I find is it is a separate line-item in ShopZ, so 
> >thinking it may be chargeable, and enabled via IFAPRDxx?   Just looking for 
> >a bit of confirmation
> >
> >_
> >
> >Dave Jousma
> >AVP | Manager, Systems Engineering
> >[cid:image003.png@01D4F915.C9E34050]
>
> --
> 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 **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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke 

Re: RUCSA

2020-03-13 Thread Vernooij, Kees (ITOP NM) - KLM
Yes, it runs on V2.2.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Thursday, March 12, 2020 2:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RUCSA

From the z/OS V2.4 announcement.  Reading between the lines, I don’t think you 
can install this on lower version of z/OS, but maybe a quick support ticket 
would be in order.  Also it is chargeable feature.

Removal of user key common storage

User key common storage is memory that can be updated by any unauthorized 
program. z/OS V2.4 no longer supports unrestricted user key common storage, 
thereby improving application isolation and security. PTFs for APARs OA53355 
and OA56180 are available at lower releases to assist in migration and 
identification of programs accessing user key common storage.

Removal of support of YES setting for VSM ALLOWUSERKEYCSA DIAGxx parmlib 
parameter: z/OS V2.3 will be the last release of z/OS to support the YES 
setting for the VSM ALLOWUSERKEYCSA DIAGxx parmlib parameter. If you run any 
software that requires the setting of this parameter to YES, the software will 
need to be changed to no longer require the setting of this parameter to YES or 
the optional priced RUCSA feature will be required.

All IBM provided software should not require this setting. If you have any 
other non-IBM provided software that requires this setting, contact the owner 
of the software regarding this usage.

Removal of support for obtaining user key CSA/ECSA storage: z/OS V2.4 does not 
support the usage of the GETMAIN, CPOOL, and STORAGE OBTAIN interfaces to 
obtain user key (8-15) CSA/ECSA storage. If you have any software that obtains 
user key CSA/ECSA storage, the software will need to be changed to no longer 
require this capability or the optional priced RUCSA feature will be required.

Removal of support for obtaining user key CSA/ECSA storage: z/OS V2.4 does not 
support the usage of the GETMAIN, CPOOL, and STORAGE OBTAIN interfaces to 
obtain user key (8-15) CSA/ECSA storage. If you have any software that obtains 
user key CSA/ECSA storage, the software will need to be changed to no longer 
require this capability or the optional priced RUCSA feature will be required.

Removal of support for changing Common ESQA (Subpool 247-248) storage to user 
key: z/OS V2.4 does not support the usage of the CHANGKEY interface to change 
Common ESQA (Subpool 247-248) storage to user key (8-15). If you have any 
software that changes Common ESQA (Subpool 247-248) storage to user key, the 
software will need to be changed to no longer require this capability.

Removal of support of YES setting for ALLOWUSERKEYCADS DIAGxx parmlib 
parameter: z/OS V2.4 does not support the YES setting for the ALLOWUSERKEYCADS 
DIAGxx parmlib parameter. On prior releases, when ALLOWUSERKEYCADS(YES) is in 
effect, usage of the DSPSERV CREATE interface to create a SCOPE=COMMON data 
space in user key (8 -15) is supported. If you run any software that requires 
the setting of this parameter to YES, the software will need to be changed to 
no longer require the setting of this parameter to YES. All IBM provided 
software should not require this setting. If you have any other non-IBM 
provided software that requires this setting, contact the owner of the software 
regarding this usage.

Removal of support for creating SCOPE=COMMON data spaces in user key: z/OS V2.4 
does not support the usage of the DSPSERV CREATE interface to create a 
SCOPE=COMMON data space in user key (8 -15). If you have any software that 
creates a SCOPE=COMMON data space in user key, the software will need to be 
changed to no longer require this capability.

Restricted Use Common Service Area (RUCSA) feature

A new optional priced feature, RUCSA, is offered to enable clients to define a 
restricted use CSA (RUCSA) and manage it through SAF security protection. While 
avoiding user key common storage entirely is recommended, this feature enables 
clients who cannot update their applications that allocate user key CSA to gain 
enhanced protection without the need for application changes. Additionally, new 
health checks and instrumentation are added to track usage of this area. PTFs 
for APARs OA53355 and OA56180 are available at lower releases to assist in 
migration and identification of programs accessing user key common.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Richards, Robert B.
Sent: Thursday, March 12, 2020 9:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RUCSA

**CAUTION EXTERNAL EMAIL**

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

Does it come 

Re: RUCSA

2020-03-13 Thread Vernooij, Kees (ITOP NM) - KLM
Yes, we do on V2.2, for the same reason: preparation for V2.4, for 2 
applications that require userkey CSA.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Thursday, March 12, 2020 1:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RUCSA

Is anyone using RUCSA yet?  We currently have a very old ISV product that 
requires running with ALLOWUSERKEYCSA(YES)   on z/OS 2.2.   As we prepare for 
new hardware to support upgrade to z/OS 2.4,  I'm faced with the possibility of 
needing to run 2.4 with RUCSA  if we cannot get an upgrade for this old ISV 
product  in time.

I see RUCSA as orderable on ShopZ,  just wondering,  can it be ordered and 
installed seperately or does it need to be ordered at the same time as the z/OS 
2.4 order?

Thanks
Dana

On Wed, 6 Nov 2019 19:38:33 +, Jousma, David  wrote:

>Folks,
>
>Remind me, is RUCSA support a chargeable feature?  I find nothing in the 
>manual, the only clue I find is it is a separate line-item in ShopZ, so 
>thinking it may be chargeable, and enabled via IFAPRDxx?   Just looking for a 
>bit of confirmation
>
>___
>__
>Dave Jousma
>AVP | Manager, Systems Engineering
>[cid:image003.png@01D4F915.C9E34050]

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Old joke realism

2020-02-25 Thread Vernooij, Kees (ITOP NM) - KLM
Interesing material. Is 'old' equal to 'adult'? My company firewall protects me 
with the message:

Sorry, you don't have permission to visit this site.
Not allowed to browse Adult Material category
You tried to visit: http://bofh.bjash.com/

Kees


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: 25 February 2020 17:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Old joke realism

The BOFH and User Friendly cartoons are funny but like nothing I've ever seen 
IRL. Dilbert, OTOH, leaves me with an eerie sense of familiarity. 


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



From: IBM Mainframe Discussion List  on behalf of 
Adam Jacobvitz <02b29b762ea6-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, February 25, 2020 9:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Old joke realism

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I know this isn't mainframe related, but how realistic are the old computer 
jokes? e g.

http://secure-web.cisco.com/1f2K4lkajzTKLo5c1rk3zVrtIrQsDcMOwmwySvMKhcI4rmltQY6WMVzc61COVPYp7_qm5pSiEYAjhjjxS0MhgSFKfvoloKx_40_s7pg1xzIpHlZkC6l64qBm1yuAU_HvaIhc0QgbpNj3ZRQVzi5c4S55yGnzeym0tpPp2CNcnHa824kWiikxJBxhqeSWOiApDgPOZ3IjmGk-a2HNbB5V-C7jmkU4WJjiGYgirgkQDT6dIAqsG6dVmPhp2OstOQ3lozL0wKUZnO7Fzl7tX93b8qTftq3cgJysQY3kaHTYj90SLgCW9BWab-PgMfcdQYCfM1fw5fEbNGqt7ylCJsJNafhwlhEJJR7ZaKP96liQ4u6LOgGDLTVrxyILYhlWGWZS0Bcm98oHKIjk7o4WqV_fJwx6vbXRGDENHyA3xt6JF3lJHn11tbvLz53QQXY9pXttG/http%3A%2F%2Fbofh.bjash.com



Sent from ProtonMail mobile



\ Original Message 
On Feb 25, 2020, 5:58 AM, Seymour J Metz < sme...@gmu.edu> wrote:

>
>
>
> I may have done that in the old days, but isn't everything interesting in the 
> CONSOLE address space these days?
>
>
> \--
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> From: IBM Mainframe Discussion List \[IBM-MAIN@LISTSERV.UA.EDU\] on behalf of 
> Chuck Arney \[ch...@arneycomputer.com\]
> Sent: Tuesday, February 25, 2020 8:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Finding and replying to outstanding reply
>
> Tony, I did this in assembler many years ago for the ZEKE Automatic Reply
> feature. It has been too many years to remember all the details but
> basically you search the ORE (Operator Reply Element) chain to find the task
> you want and extract the reply id from the ORE.
>
> Chuck Arney
> Arney Computer Systems
>
>
> \-Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Tony Thigpen
> Sent: Tuesday, February 11, 2020 7:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Finding and replying to outstanding reply
>
> We have an in-house written automated shutdown program that does everything
> but shutdown NPF. That is because NPF leaves an open reply message during
> start-up to which I must replay xx,STOP to make it shutdown. Within our
> shutdown program, I would like it to programmatically find the outstanding
> reply number so that it can issue the correct response.
>
> Can someone point me to any doc or examples that will help me get started on
> this?
>
> \--
> 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
>
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBmBAEBCAAQBQJeVSnnCRBiYga9B/zq3QAKCRBiYga9B/zq3UADB/0dZhRp
UcRRDfmrpuMmNjoaaSQvP+ZtTqWJKOzVuFtHhluzRYjv22D4o6mNNow/k15D
OSEI8Nx3PowV5jAy2aPGM+LgXACwrVQiNU8lIxYNQ87xFhhH4cm+ivTAe/vi
kpZbye8szCz42/va67DWlkG72FV63eYB80DClQKgvjW0bGcbS7V+fQMPg9a7
kUTUSLPAdb9n+mhQtsx7dojZIMyeL4mssSOJZ3Wpo08aH/2A3PNAYuaCZB8K
lOLthtry4c/fL0WOKHdHh7NsXcStjb4VDROJJn7b4amWR2tOWmzzskiAYlIc
DzTJN6Nh7j8PsR2i/XcpI4s3FlL/0jeRR68g
=8JGu
-END PGP SIGNATURE-

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


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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is 

Re: ALLOC command releasing space

2020-02-10 Thread Vernooij, Kees (ITOP NM) - KLM
I wonder why space is being released with the TSO ALLOC command in the first 
place, this ALLOC command does not do this by itself. 
It must be defined somewhere in the mgmtclas definitions and/or ACS routines.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Fred Kaptein
Sent: 11 February 2020 01:27
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ALLOC command releasing space

Hello,
I have a user that is allocating a data set in TSO and REXX using the following 
command

ALLOC DA('ABCD.EFG') NEW CATALOG UNIT(SYSALLDA) DSNTYPE(LIBRARY) LRECL(121) 
RECFM(F B A)  CYL SPACE(9)   BLOCK(27951) DIR(100)

The data set is allocated, but the unused space is released, so the data set is 
only 6 tracks.
I allocate the same data set in ISPF 3.2 and the data set is allocated with 9 
cylinders.

The same SMS management class and data class is assigned for both allocations.

Is it possible not to release unused space when using the TSO ALLOC command?
 

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Determine if running under Secondary Subsystem

2020-02-09 Thread Vernooij, Kees (ITOP NM) - KLM
The answers given so far imply that you know the names of the primary/secondary 
subsystems and from that determine under which you run.
As far as I remember, there is a pointer to *the* subsystem, which is the 
primary subsystem. I can't dig up where that pointer is.

Kees

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Szura
Sent: 07 February 2020 21:37
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Determine if running under Secondary Subsystem

Is there a way to tell if you application is running under a Secondary 
JES?  We have common code that is used in several products that needs to 
check the JES it is running under.  If I look at the chain of SSCTs it 
will only tell me there are more than one JES running but I can't find a 
way to determine under which the application started.

j

-- 
John Szura
Lead Mainframe Product Developer
Tone Software Corp.
+1(714)507-2354

  IMPORTANT NOTICE:

This is a private message. The information in this email (including any 
attachments) is confidential and proprietary to Tone Software
Corporation, and is provided solely for the use of the individual or entity to 
which it is addressed. Any review, reliance upon, printing,
distribution, or forwarding without express permission of its sender is 
strictly prohibited. If you are not its intended recipient, please
immediately delete this email without copying and kindly advise me by email of 
the mistaken delivery.

  

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: WLM Guidance/Suggestions ! ! !

2020-02-03 Thread Vernooij, Kees (ITOP NM) - KLM
Your problem is probably caused by the faster CPs, combined with the definition 
of Velocity.
- Velocity in fact means that a job receives nn% of what it wants. CPU hungry 
jobs will therefor get much CPU if their imp os high enough.
- On the 5 CP machine, the jobs probably did not 'monopolize' all the engines, 
leaving room for other jobs, while on the 2 CP machine they are now able to 
monopolize it, leaving nothing for other jobs.

If the jobs are important, you can start with keeping their imp, but lowering 
their velocity, until they receive what you want them to, leaving capacity for 
other jobs.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pesce, Andy
Sent: 30 January 2020 15:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: WLM Guidance/Suggestions ! ! !

I have recently replace an IBM-2828 that had 5 GP's to a newer model machine 
IBM-3907-ZR1 with only 2 GP's.
Does anyone know of a guide or paper or something that might have some things 
to look at or modify when reducing the number of GP's.
I have 2 classes of service for my batch jobs.One runs with a velocity and 
importance of "2".   This is a grouping we have called our
critical path jobs that are time sensitive and they must run.Then I have 
another class that runs with a velocity, but has an importance of "3".
This grouping is for jobs that are not time sensitive, but they do need to run 
and get service.

The behavior that I am seeing is that the class that has the IMP-2 dominates 
the box until they are finished.  The other jobs will sit in the
initiator for 30mins up to an hour and I never see any service being consumed.  
 Then once the IMP-2 jobs finish, then the other jobs
will take off and get service.

My goal is to have the IMP-2 take 80-90%, but give the IMP-3 a small chunk of 
service.   The only way that I have been able to come close
is to make both classes the same importance level.

Any thoughts, documents, white papers, experiences with dealing with the 
reduction of GP's would be greatly appreciated.

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: Tape problem

2020-01-15 Thread Vernooij, Kees (ITOP NM) - KLM
You can run the CA-1 CTSSYNC utility, to synchronize the TCDB from the TMC.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nai, Dean
Sent: 15 January 2020 18:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Tape problem

Anyone ever run into a problem where the CA-1 catalog and the volcat seem to be 
out of sync? We keep getting the below messages and aren’t able to eject tapes. 
Thought it was 3494 hardware related by IBM doesn’t thing so. Any suggestions?

CBR3770I Volume T00xxx misplaced in library TAPELIB1
CBR3769I Misplaced volume T00xxx found in library TAPELIB1


Dean Nai




>

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: it was 20 years ago today

2020-01-03 Thread Vernooij, Kees (ITOP NM) - KLM
Correct. 
And then I see yesterday on a local news site an article with a suggestive 
title like: a lot of fuzz, but hardly any problems really occurred.

The article itself has a little more nuance, but it is still nice food for 
title hunters (useful if your business model exists of getting as much people 
as possible to generate advertisement hits).

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jeremy Nicoll
Sent: 03 January 2020 15:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: it was 20 years ago today

On Fri, 3 Jan 2020, at 00:49, Joel C. Ewing wrote:

> The problem for us was not "how" to fix a single instance of the 
> problem, but finding "where" to fix an unknown number of instances of 
> the problem in 1000's of lines of in-house code and in associated data sets.

I think how complex this was depended a lot on how old a site's applications
were.  It also depended on how long the 'tail' or archived data was.

Suppose you identified all the instances of a single date data column in a 
single 
current file that might be read and rewritten by umpteen programs.  If you 
changed all the programs you'd also need either to change the data in all
the archived files as well, or make the program able to decide whether it 
was running in pre-change or post-change mode.

But you'd also need to change all the other programs that also read those
old archive files.  And that might have knpck-on effects on other files that
they manipulated.

While doing this, you also had to make sure that - if your change failed - 
you could back it out and create/recreate all the related files.

It's rapidly obvious that you can't change all old files in sync with a series
of program changes and still allow all your old, or not-yet-changed
programs to process the old files (because you changed those).

That's why the date-window approach got  used.  The as-yet-unchanged 
programs could contine to read all the archived data, while the updated
programs could handle the old-format data more intelligently.

If I remember correctly, one of the changes that happened (to customer 
TS) was that we no longer supported customers aged > 100.  I have
no idea what they were meant to do with their money.

Where I worked (a UK bank), Y2K was a big deal.  A colossal amount of work
was done in the two or so years beforehand, and on the night the computer
centre was heavily staffed - not quite as many of us as on a normal day, but 
nevertheless lots.

We had by then run simulated workloads back and forth across the date
change many times, as well as checking things like how end-of-financial/
tax year/calendendar year processing could be expected to go (at eg end
of March 2000, 5/6 April 2000, 31 Dec 2000) and I expect beyond that as 
eg programmes doing 2-year, 5-year etc historical reports and those doing
forecasting that might not run until some months later also needed to be 
thought to be ok.

-- 
Jeremy Nicoll - my opinions are my own.

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: it was 20 years ago today ....

2020-01-03 Thread Vernooij, Kees (ITOP NM) - KLM
*That* seems like a lifetime ago...

Kees


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rupert Reynolds
Sent: 03 January 2020 13:17
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: it was 20 years ago today 

. . . "Sgt Pepper taught the band to play" :-)

On Tue, 31 Dec 2019, 18:26 Chris Hoelscher,  wrote:

> Has it been 20 years since Y2K?? sometimes it seems like last year, other
> times seems like another lifetime .
>
> Thank You,
> Chris Hoelscher| Lead Database Administrator | IBM Global Technical
> Services| T 502.476.2538  or 502.407.7266
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Looking for a utility to create a master listing of all PDS members on a system

2019-12-10 Thread Vernooij, Kees (ITOP NM) - KLM
If you have SAS I would use this, because then you can produce all kinds of 
statistics on the PDSs and members.
- Use PROC SOURCE to produce a memberlist of each PDS.
- Create a database with the PDS / member info.
- Produce all desired statistics and cross checks from that database.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: 10 December 2019 14:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Looking for a utility to create a master listing of all PDS members on 
a system

I am looking for a utility that will take a list of PDS libraries and 
generate a list of all members in the PDS.

I have hundreds of PDSs on an old system I have to maintain and all the 
old staff with any knowledge are gone. There are hundreds of PDS 
libraries and no doc as to where anything is stored. I want, as a one 
time job, to create a listing with a single line per member/PDS set:
Member_name PDS_name

I figure there is something already available before I start writing 
something new.

This system does *not* have any PDSE libraries as it is OS/390 02.10.

-- 
Tony Thigpen

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: Most-used instructions? Just for fun.

2019-12-09 Thread Vernooij, Kees (ITOP NM) - KLM
I suppose IBM has done this, in order to further tune their systems into more 
decimals.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Binyamin Dissen
Sent: 09 December 2019 11:52
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Most-used instructions? Just for fun.

How would one measure this?

On Mon, 9 Dec 2019 10:05:26 + Rupert Reynolds  wrote:

:>Has anyone seen a list of the most-used machine instructions?

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: Misuse of the word hexadecimnal (Was RE: COPYING PDS TO PDS ...)

2019-12-08 Thread Vernooij, Kees (ITOP NM) - KLM
Thanks. 
Again, one is never too old to learn, even at 98.5% of one's mainframe career.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: 05 December 2019 19:49
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Misuse of the word hexadecimnal (Was RE: COPYING PDS TO PDS ...)

The industry has long been afflicted by people slinging around words whose 
meanings they don't know. "Hexadecimal value" is just the tip of the iceberg.


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



From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Wednesday, December 4, 2019 1:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Misuse of the word hexadecimnal (Was RE: COPYING PDS TO PDS ...)

"Hexadecimal" might be the most misused word in our industry. "Any hexadecimal 
character" -- umm, can you give me an example of a non-hexadecimal character? 
Is x'C1' a hexadecimal character? Sure looks like hex to me.

Hexadecimal is a *method of representation*. If I have a byte that contains 
b'0101 1010' that is kind of a tedious way of writing it. The industry formerly 
used octal and wrote it as 0132 but that is kind of tedious and maps poorly to 
8-bit (as opposed to 6-bit) characters. x'5A' conveys it fairly well. That 
method of conveyance is called hexadecimal. The byte is not hexadecimal: it's 
the same byte as it was when I wrote it as b'0101 1010'.

"Non-printable" (or sometimes non-alphanumeric/national) is the word people are 
looking for. No byte is hexadecimal. All byte values may be represented in 
hexadecimal.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, December 4, 2019 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COPYING PDS TO PDS ...

On Wed, 4 Dec 2019 07:18:11 +, Vernooij, Kees (ITOP NM) - KLM wrote:

>Jeez Gil,
>
>There is nothing restrictive to 'hexadecimal', only to 'any' or 'some'.
>Between quotes you can put *any* hex char in a dsname, without quotes you can 
>use only the *alphanumeric* hex chars. (And you *can* of course use all 256, 
>if you accept JCL errors).
>
What meaning does "hexadecimal" add in "any hexadecimal character"  Is it any
different from "any character"?  If not, "hexadecimal" is a noise word.

I'm similarly perplexed by IBM's frequent usage, as in:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa200/ENQ_Description.htm
... The name can contain any valid hexadecimal character. ...

I visualize a Venn diagram:  
https://secure-web.cisco.com/1PM-B8kCix2WWZn6q1Vh6voOtKz7viyNw8ESZv-Aq5bojVqDLWvaBjXct5iS4oPcA185iDTfCohjIpNC-fWu8MvNQ0vJb5vItF7ZlPeUEeOIB_Rk1NSMnlSUEcA2ycq7v_x-IB6Ou1uCNNaqzvU_lVHbpYViDMTc7pkBR2V-1ariNB4Q62_cBw66z81wq3M6ETjSNnfRZAbUlNIIg1OgbAvGUWqoQRoVC2oTzmuA-eyYSLt1cxQ-kAgQ9_PqPzxBRQkSnnsVenuXrRUUtLtCiiHJBcoFCfQNaFbnOtqcbQ6Tkes8JvhUlI6P0hwD7aV_YXZjF5S-S5W3uDJ8rdQt87UuMoClaZNHuXjQQtJ1aYAPCa3_4I9TdNxiI-849oi9iSR1kTPUvE4Qh3HbS8welLlsRUUjX6vKhC7yVjGDx8i53KFggUxCu4tLCItjAHHaP/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FVenn_diagram
where invalid hexadecimal characters and valid non-hexadecimal characters
are prohibited.

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


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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: A minimum of 8 GB of real memory is required to IPL

2019-12-05 Thread Vernooij, Kees (ITOP NM) - KLM
Related question: and does it not apply to a z13?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: 05 December 2019 15:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: A minimum of 8 GB of real memory is required to IPL

  *   For z/OS V2R3 with the IBM z14(tm) (z14) server, a minimum of 8 GB of 
real memory is required to IPL.

Does this statement only apply only to the z14 or all models *after* it?  For 
example, the z14_ZR1 and the z15?

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: Syslog Message Normalization

2019-12-05 Thread Vernooij, Kees (ITOP NM) - KLM
I think there is a difference in multi-line messages (where each line is 
identified by an id, '808' in the example below) and long messages that are 
spread in syslog over more than 1 line. I think your example belongs to the 
latter.

MR000 MVSC 19339 09:30:47.49 ACTWRK02   .HASP003 RC=(52),D 808  
  
DR808   .HASP003 RC=(52),D JOBQ 
 - NO SELECTABLE ENTRIES FOUND MATCHING   
ER808   .HASP003   
SPECIFICATION  

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Matt Hogstrom
Sent: 05 December 2019 02:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Syslog Message Normalization

I’m processing syslog messages and I’d like to combine multi-line messages into 
a single entry before processing the entries.  For instance, these messages

N 002 PROD 19111 16:00:40.08 JOB08657 0090  +=== SUSPEND PROGRAM 
FOR 02 SECONDS. ===
N 0004000 PROD 19111 16:00:40.08 JOB08657 0290  -STIMER   
00  4  0  0.20  0.000.0   
S31  JES2 0 
0 0 0


Would become
002 PROD 19111 16:00:40.08 JOB08657 0090  +=== SUSPEND PROGRAM FOR 
02 SECONDS. ===
0004000 PROD 19111 16:00:40.08 JOB08657 0290  -STIMER   00  
4  0  0.20  0.000.031  JES2 0 0 0   
  0

Given there are a number of subtle rules I was wondering if anyone had written 
or was aware of a general purpose normalizer.


Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom


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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Syslog Message Normalization

2019-12-05 Thread Vernooij, Kees (ITOP NM) - KLM
No, 31 is the continuation of the message text. The id is always 3 digits and 
is more to the left. "808" in the example below.


MR000 MVSC 19339 09:30:47.49 ACTWRK02   .HASP003 RC=(52),D 808  
  
DR808   .HASP003 RC=(52),D JOBQ 
 - NO SELECTABLE ENTRIES FOUND MATCHING   
ER808   .HASP003   
SPECIFICATION  

Met vriendelijke groet,
Kees Vernooij
KLM Information Services
z/OS Systems
Tel +31 6 10 14 58 78


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: 05 December 2019 05:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Syslog Message Normalization

"31" in your sample is the correlation id of the original message. I can't see 
it in the original line in your sample, but it is there. it is not part of the 
message and you have to drop it from the concatenated line.

ITschak

On Thu, Dec 5, 2019 at 3:28 AM Matt Hogstrom  wrote:

> I’m processing syslog messages and I’d like to combine multi-line 
> messages into a single entry before processing the entries.  For 
> instance, these messages
>
> N 002 PROD 19111 16:00:40.08 JOB08657 0090  +=== SUSPEND
> PROGRAM FOR 02 SECONDS. ===
> N 0004000 PROD 19111 16:00:40.08 JOB08657 0290  -STIMER
>00  4  0  0.20  0.000.0
> S31  JES2
>0 0 0 0
>
>
> Would become
> 002 PROD 19111 16:00:40.08 JOB08657 0090  +=== SUSPEND PROGRAM
> FOR 02 SECONDS. ===
> 0004000 PROD 19111 16:00:40.08 JOB08657 0290  -STIMER
>  00  4  0  0.20  0.000.031  JES2 0
>  0 0 0
>
> Given there are a number of subtle rules I was wondering if anyone had 
> written or was aware of a general purpose normalizer.
>
>
> Matt Hogstrom
> m...@hogstrom.org
> +1-919-656-0564
> PGP Key: 0x90ECB270
> Facebook   LinkedIn < 
> https://linkedin/in/mhogstrom>  Twitter 
>
> “It may be cognitive, but, it ain’t intuitive."
> — Hogstrom
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for 
Legacy **|  *

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Misuse of the word hexadecimnal (Was RE: COPYING PDS TO PDS ...)

2019-12-05 Thread Vernooij, Kees (ITOP NM) - KLM
Hilarious, this is what I like about this forum.

Throw any digital bone into the this group of dogs (no offence intended) and 
they will all jump on it, analyze it, cut it into pieces, rephrase it, write 
their solution, convince all others of their personal findings and branch off 
into any possible hexadecimal direction, where the process is iterated.

And it even ain't Friday yet.

Thanks,
Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: 04 December 2019 19:52
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Misuse of the word hexadecimnal (Was RE: COPYING PDS TO PDS ...)

On Wed, 4 Dec 2019 10:01:36 -0800, Charles Mills wrote:

>"Non-printable" (or sometimes non-alphanumeric/national) is the word 
>people are looking for.

I disagree. "non-printable" is a term that has little meaning. 
Even if you mean "non-printable using a TN print train", for example, that is 
only a subset of the 256 possible values in a byte.

The point of using a term like "any hexadecimal character" is to indicate that 
all 256 possible values in the byte are acceptable. 
It could just as well be "a byte with any hexadecimal value", or "a byte with 
any binary value".

--
Tom Marchant

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Misuse of the word hexadecimnal (Was RE: COPYING PDS TO PDS ...)

2019-12-05 Thread Vernooij, Kees (ITOP NM) - KLM
See my answer to Gil about Venn diagrams.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: 04 December 2019 19:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Misuse of the word hexadecimnal (Was RE: COPYING PDS TO PDS ...)

"Hexadecimal" might be the most misused word in our industry. "Any hexadecimal 
character" -- umm, can you give me an example of a non-hexadecimal character? 
Is x'C1' a hexadecimal character? Sure looks like hex to me.

Hexadecimal is a *method of representation*. If I have a byte that contains 
b'0101 1010' that is kind of a tedious way of writing it. The industry formerly 
used octal and wrote it as 0132 but that is kind of tedious and maps poorly to 
8-bit (as opposed to 6-bit) characters. x'5A' conveys it fairly well. That 
method of conveyance is called hexadecimal. The byte is not hexadecimal: it's 
the same byte as it was when I wrote it as b'0101 1010'.

"Non-printable" (or sometimes non-alphanumeric/national) is the word people are 
looking for. No byte is hexadecimal. All byte values may be represented in 
hexadecimal.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, December 4, 2019 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COPYING PDS TO PDS ...

On Wed, 4 Dec 2019 07:18:11 +0000, Vernooij, Kees (ITOP NM) - KLM wrote:

>Jeez Gil,
>
>There is nothing restrictive to 'hexadecimal', only to 'any' or 'some'.
>Between quotes you can put *any* hex char in a dsname, without quotes you can 
>use only the *alphanumeric* hex chars. (And you *can* of course use all 256, 
>if you accept JCL errors).
> 
What meaning does "hexadecimal" add in "any hexadecimal character"  Is it any 
different from "any character"?  If not, "hexadecimal" is a noise word.

I'm similarly perplexed by IBM's frequent usage, as in:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa200/ENQ_Description.htm
... The name can contain any valid hexadecimal character. ...

I visualize a Venn diagram:  https://en.wikipedia.org/wiki/Venn_diagram
where invalid hexadecimal characters and valid non-hexadecimal characters are 
prohibited.

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: COPYING PDS TO PDS ...

2019-12-05 Thread Vernooij, Kees (ITOP NM) - KLM
In my Venn diagram, there are (a.o.) alphanumeric and hexadecimal characters. 
One is a subset of the other, so sometimes you can use only 'some' hexadecimal 
characters, sometimes you can use 'all' hexadecimal characters / 'any' 
hexadecimal character.

Since English is not my native language, my words might not express exactly 
what I mean.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: 04 December 2019 18:39
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COPYING PDS TO PDS ...

On Wed, 4 Dec 2019 07:18:11 +, Vernooij, Kees (ITOP NM) - KLM wrote:

>Jeez Gil,
>
>There is nothing restrictive to 'hexadecimal', only to 'any' or 'some'.
>Between quotes you can put *any* hex char in a dsname, without quotes you can 
>use only the *alphanumeric* hex chars. (And you *can* of course use all 256, 
>if you accept JCL errors).
> 
What meaning does "hexadecimal" add in "any hexadecimal character"  Is it any 
different from "any character"?  If not, "hexadecimal" is a noise word.

I'm similarly perplexed by IBM's frequent usage, as in:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa200/ENQ_Description.htm
... The name can contain any valid hexadecimal character. ...

I visualize a Venn diagram:  https://en.wikipedia.org/wiki/Venn_diagram
where invalid hexadecimal characters and valid non-hexadecimal characters are 
prohibited.

I'm tempted to submit an RCF requesting a clarification.

-- gil

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: COPYING PDS TO PDS ...

2019-12-03 Thread Vernooij, Kees (ITOP NM) - KLM
As we are dealing with details and detailed terminology: 'nonstandard' 
according to whom? Not to the PDS standards, only to JCL and ISPF standards.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sri h Kolusu
Sent: 03 December 2019 17:15
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COPYING PDS TO PDS ...

>>How is it possible to have a lower-case character in a PDS member name?

Bob,

Here is an example of Creating A Nonstandard member name in a PDS

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/pdsnsam.htm


Thanks
Kolusu

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: COPYING PDS TO PDS ...

2019-12-03 Thread Vernooij, Kees (ITOP NM) - KLM
Why not? Just like you can put any membername in a PDS with STOW, you can put 
any dsname in a catalog with the correct utilities, like CAMLIST etc.
I remember such a dsname, which the user could not delete with ISPF, because of 
the syntax checking. But it did make its way into the catalog.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: 03 December 2019 10:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COPYING PDS TO PDS ...

And if you use quotes, the dataset name is not cataloged and you must include 
the volser.

On Tue, Dec 3, 2019 at 8:43 AM Lennie Dymoke-Bradshaw 
 wrote:
>
> Well I have tried all sorts of settings for that but I cannot get it to work. 
> If you place the entire DSNAME and member including brackets, then the system 
> looks for a DSCB matching it. If you just place the member in quotes then you 
> get a JCL error. So I don't think JCL will support it.
>
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> Web:  www.rsmpartners.com
> ‘Dance like no one is watching. Encrypt like everyone is.’
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Vernooij, Kees (ITOP NM) - KLM
> Sent: 03 December 2019 11:16
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] COPYING PDS TO PDS ...
>
> In JCL you can put any hexadecimal character in a dsname if you enter it 
> between quotes. Never tried it for PDS membernames, but I suppose it will 
> work too.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lennie Dymoke-Bradshaw
> Sent: 03 December 2019 12:11
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COPYING PDS TO PDS ...
>
> You can store non-standard member names in PDS datasets using STOW macros.
> IBM used to do this in the forerunner of SMP/E called SMP. They used large 
> PDSs with member names that were unprintable hex characters.
>
> I have not found a way to reference member names that are not upper-case 
> printable characters in JCL. But maybe someone knows better!
>
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> Web:  www.rsmpartners.com
> ‘Dance like no one is watching. Encrypt like everyone is.’
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Lionel B Dyck
> Sent: 03 December 2019 10:48
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] COPYING PDS TO PDS ...
>
> I'm not aware standard services allow mixed case member names - but as far as 
> I know PDS only works with IBM standard and I was not able, using PDS to 
> create a member name with lower case.
>
> Get it and try it - it's free.  So kick the tires and see if it does what you 
> want.
>
>
> Lionel B. Dyck <
> Website: http://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is 
> what you are, reputation merely what others think you are." - John 
> Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Paul Gilmartin
> Sent: Monday, December 2, 2019 7:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COPYING PDS TO PDS ...
>
> On Mon, 2 Dec 2019 18:57:08 -0600, Lionel B Dyck  wrote:
>
> >The pds command is case insensitive in this area - dataset names and member 
> >names are all converted to upper case as is standard for z/OS. The commands 
> >as well are case insensitive.
> >
> >Try it - you'll love it.
> >
> So if I have two members whose names differ only in the case of some 
> character, I can't distinguish between them with the pds command.  I don't 
> think I'd love that.
>
> Are the commands case insensitive with respect to names in the PDS directory, 
> or only in commands?  That is, suppose I have carelessly created a member 
> name containing a lower case character, can I use the pds command to rename 
> it to something more conventional?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ***

Re: COPYING PDS TO PDS ...

2019-12-03 Thread Vernooij, Kees (ITOP NM) - KLM
Jeez Gil, 

There is nothing restrictive to 'hexadecimal', only to 'any' or 'some'.
Between quotes you can put *any* hex char in a dsname, without quotes you can 
use only the *alphanumeric* hex chars. (And you *can* of course use all 256, if 
you accept JCL errors).

Kees.

On Tue, 3 Dec 2019 11:15:38 +, Vernooij, Kees (ITOP NM) - KLM wrote:

>In JCL you can put any hexadecimal character in a dsname if you enter 
>it between quotes. ..
>
I'm always perplexed by the apparently restrictive adjective, "hexadecial".  Of 
the 256 EBCDIC code points, which are non-hexadecimal?

-- gil

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: COPYING PDS TO PDS ...

2019-12-03 Thread Vernooij, Kees (ITOP NM) - KLM
In JCL you can put any hexadecimal character in a dsname if you enter it 
between quotes. Never tried it for PDS membernames, but I suppose it will work 
too.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lennie Dymoke-Bradshaw
Sent: 03 December 2019 12:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COPYING PDS TO PDS ...

You can store non-standard member names in PDS datasets using STOW macros. 
IBM used to do this in the forerunner of SMP/E called SMP. They used large PDSs 
with member names that were unprintable hex characters.

I have not found a way to reference member names that are not upper-case 
printable characters in JCL. But maybe someone knows better!

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
Web:  www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B Dyck
Sent: 03 December 2019 10:48
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] COPYING PDS TO PDS ...

I'm not aware standard services allow mixed case member names - but as far as I 
know PDS only works with IBM standard and I was not able, using PDS to create a 
member name with lower case.

Get it and try it - it's free.  So kick the tires and see if it does what you 
want.


Lionel B. Dyck <
Website: http://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Monday, December 2, 2019 7:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COPYING PDS TO PDS ...

On Mon, 2 Dec 2019 18:57:08 -0600, Lionel B Dyck  wrote:

>The pds command is case insensitive in this area - dataset names and member 
>names are all converted to upper case as is standard for z/OS. The commands as 
>well are case insensitive.
>
>Try it - you'll love it.
> 
So if I have two members whose names differ only in the case of some character, 
I can't distinguish between them with the pds command.  I don't think I'd love 
that.

Are the commands case insensitive with respect to names in the PDS directory, 
or only in commands?  That is, suppose I have carelessly created a member name 
containing a lower case character, can I use the pds command to rename it to 
something more conventional?

-- gil

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

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

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Sysplex

2019-11-28 Thread Vernooij, Kees (ITOP NM) - KLM
I had another idea of your 'customer'. Together with Matt's speculation, I 
suspect you provide info to all address spaces in an LPAR in SP 213 and the 
customer wants to see  this information from all LPARs. This looks like 
Martin's RDMA or maybe a Logstream or a System Logger Notepad or a shared CF 
structure (or a shared Dasd dataset).

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: 28 November 2019 16:29
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sysplex

Kees,

I deal with customers who have questions and as i stated I am not a Sysplex guy.
Secondly, we are a ISV so we have help our customers and this one is huge.
The point it was their question. You can’t expect everyone to know what you 
know, everyone has a different frame of reference.

Scott

On Thu, Nov 28, 2019 at 9:33 AM Martin Packer 
wrote:

> Then, of course, there's RDMA.
>
> Cheers, Martin
>
> Martin Packer
>
> zChampion, Systems Investigator & Performance Troubleshooter, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>
> Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/ 
> or
>
>
> https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id112
> 7943573?mt=2
>
>
> Youtube channel: 
> https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
>
>
> From:   Matt Hogstrom 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   28/11/2019 14:17
> Subject:[EXTERNAL] Re: Sysplex
> Sent by:IBM Mainframe Discussion List 
>
>
>
> Speculation on my part but it I suspect they heard the term data 
> sharing and sysplex and assumed that data (in-memory) could be shared 
> like a subpool (231 in this case CSA / ECSA) across LPARs.
>
> Matt Hogstrom
> PGP key 0F143BC1
>
> > On Nov 28, 2019, at 04:11, David Crayford  wrote:
> >
> > Sorry to nitpick Scott but "Sysplex" is a poor subject line for
> newsgroup thread!
> >
> > You should try to write more specific subject lines such as "Sharing
> storage subpools in a Sysplex" which makes it much easier to 
> understand the context of threads.
> >
> >> On 2019-11-28 12:33 AM, scott Ford wrote:
> >> I have a question related to storage subpool. If you running a 
> >> sysplex
> do
> >> you share one set of subpool, I.e., sp 1 ,,etc. or does each LPAR 
> >> have
> its
> >> own ?
> >> I assumed the later.
> >>
> >>
> >> Scott
> >
> > 
> > -- 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
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
> 3AU
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Scott Ford
IDMWORKS
z/OS Development

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Sysplex

2019-11-27 Thread Vernooij, Kees (ITOP NM) - KLM
I am curious to learn what he meant with the question. Either he has no idea 
what he is talking about or he means something completely different.

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: 27 November 2019 18:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sysplex

We use one of the system subpool SP 231 for holding messages we build from 
various ESMs. The customer asked if we could share SP231 across LPARs.
My take was no because I understood sp231 was unique until each LPAR .

Scott

On Wed, Nov 27, 2019 at 11:56 AM Allan Staller 
wrote:

> Each LPAR has their own.
>
> SYSPLEX does not share (virtual or real) storage.
> Selected information is shared by XCF using CTC or Coupling Facility.
>
> HTH,
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of scott Ford
> Sent: Wednesday, November 27, 2019 10:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Sysplex
>
> I have a question related to storage subpool. If you running a sysplex 
> do you share one set of subpool, I.e., sp 1 ,,etc. or does each LPAR 
> have its own ?
> I assumed the later.
>
>
> Scott
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
Scott Ford
IDMWORKS
z/OS Development

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: SMFPRMFxx SYS SUBSYS and EXITs question

2019-11-26 Thread Vernooij, Kees (ITOP NM) - KLM
Check:
Initialization and Tuning Guide
SMFPRMxx description
Statements and parameters for SMFPRMxx
the SUBSYS parameter 

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nick Varley
Sent: 26 November 2019 13:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMFPRMFxx SYS SUBSYS and EXITs question

In an SMFPRMxx member if you have this:

...
SYS(NOTYPE(4,5,20,34,35,40)
EXITS(IEFU83,IEFU84,IEFU85,IEFACTRT,IEFUJV,IEFUSI,
   IEFUJP,IEFUSO,IEFUJI,IEFUTL))
SUBSYS(STC,EXITS(IEFUJP,IEFUSO))
...

then why would the IEFU83/84/85 exits not fire for SMF records coming from STCs?
Documentation seems to imply that the SYS settings are the default/back-stop 
for all things.

We needed to make the last line read like this to make it work:

...
 SUBSYS(STC,EXITS(IEFU83,IEFU84,IEFU85,IEFUJP,IEFUSO))
...

The question:
  Does the list of exits in the SUBSYS specification overwrite all those in 
SYS, that is, in this case, it reduces the list of exits from the ten in the 
SYS specification to just the two that are explicitly listed?

Any pointers would be welcome!

Thanks,
Nick.

Nick Varley
Director, Customer Support
p +44 (0) 1823 226012 | m +44 (0) 7766 806780 nick.var...@syncsort.com

We organise data everywhere,
to keep the world working
Syncsort Limited
2 Tangier Central
Castle Street
Taunton
TA1 4AS
UK
www.syncsort.com--
ATTENTION: --
Syncsort Limited is a limited company registered in England and Wales. 
Registered number: 01373158. Registered office: 3rd Floor, The Pinnacle, 20 
Tudor Road, Reading, RG1 1NH. VAT: GB295525177 The information contained in 
this message (including any files transmitted with this message) may contain 
proprietary, trade secret or other confidential and/or legally privileged 
information. Any pricing information contained in this message or in any files 
transmitted with this message is always confidential and cannot be shared with 
any third parties without prior written approval from Syncsort. This message is 
intended to be read only by the individual or entity to whom it is addressed or 
by their designee. If the reader of this message is not the intended recipient, 
you are on notice that any use, disclosure, copying or distribution of this 
message, in any form, is strictly prohibited. If you have received this message 
in error, please immediately notify the sender and/or Syncsort and destroy all 
copies of this message in your possession, custody or control.

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: Share Website

2019-11-21 Thread Vernooij, Kees (ITOP NM) - KLM
Yes, no problem.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs
Sent: 21 November 2019 15:01
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Share Website

Is www.share.org loading for you? I'm getting an internal server error message.

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Peter Relson Article

2019-11-12 Thread Vernooij, Kees (ITOP NM) - KLM
Great article, and yes, nice to see his face. 
He looks much friendlier than what I had in my mind from this list, where he 
was more the friendly but strict school teacher, correcting us patiently every 
time we were wrong.

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: 12 November 2019 20:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Peter Relson Article

Thanks for posting this!  If not for anything else, but to put a face with 
Peter's name!

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Dale R. Smith
Sent: Tuesday, November 12, 2019 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Peter Relson Article

**CAUTION EXTERNAL EMAIL**

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

Not sure how many people on the list read the Mainframe Edition of the IBM 
Systems Magazine, but I saw this article recently in the September/October 2019 
edition online:

https://ibmsystemsmag.com/IBM-Z/09/2019/peter-relson

I assume his outside-of-work passion has helped him deal with the "wildlife" on 
this list also!  :-)>

--
Dale R. Smith

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Zfs from 1 LPAR to another

2019-11-07 Thread Vernooij, Kees (ITOP NM) - KLM
Thanks Bruce for still helping us.

So if IEBGENER cannot reliably process them, nor can ftp apparently, who can? 
Why can AMATERSE?
Where is all this documented?

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: 07 November 2019 16:41
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zfs from 1 LPAR to another

On Thu, 7 Nov 2019 02:21:29 -0600, Barbara Nitz wrote:

>"We don't document that you cannot wash dishes with a CPU!"

That's a good one, Barbara!

This discussion has come up before, and I thought I remembered someone saying 
that DFDSS will write blocks up to 64K bytes, so I looked and found the 
following post from Bruce Black. IMO, he is one of the more knowledgeable who 
has been here. Perhaps this explains some of the issues with using FTP to 
transport untersed DFDSS dumps.

On Wed, 20 Jul 2005 12:41:01 -0400, Bruce Black  
wrote:

>SDB does not work for RECFM=U, which can't be blocked by definition.
>The application (DSS in this case) controls the actually blocksize.
>
>In any case, DSS writes blocks up to 64K (even though the DCB info says 
>32760).  You can't copy a DSS backup (or an FDR backup) with IEBGENER, 
>the output will not be usable).
>
>--
>Bruce A. Black
>Senior Software Developer for FDR

--
Tom Marchant

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Zfs from 1 LPAR to another

2019-11-07 Thread Vernooij, Kees (ITOP NM) - KLM
Ok, back with ftp then. It keeps thing a little simple.

As Americans, they should know that they must document that you cannot dry your 
cat in the microwave.
If ftp cannot handle the standard recfm=u format, it should be corrected or 
documented, not left to the customer to discover it (crashing a system or a 
migrationproject).

Can anyone from IBM comment on this?

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barbara Nitz
Sent: 07 November 2019 09:21
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zfs from 1 LPAR to another

>Did you transport the catalog dump dataset with ftp? 
Yes.  I started out just adrdssu dumping the catalog, then ftp'ing. After 
restore and import the catalog was broken. Putting terse between the dump and 
ftp fixed the problem.

>If yes, this might again point to ftp.
>If not, the problem must be in the dump dataset. Then DFdss dump produces (can 
>produce) a non-standard recfm=u dataset, that will be processed correctly by 
>dfdss restore, but might confuse other programs reading it. This should be 
>documented with DFdss in my opinion.
I believe that I later checked about the difference between the untersed dump 
and the tersed dump with regard to ftp. But I had already lost enough time 
trying to get things working, so I just blamed ftp.

As for documentation - IBM does not document what doesn't work. It always 
reminds me of my IBM level2 days when I sat beside an IBM developer trying to 
figure out a problem. It turned out that the customer did something he should 
not have done, so the developer said "We don't document that you cannot wash 
dishes with a CPU!"

Barbara

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Zfs from 1 LPAR to another

2019-11-06 Thread Vernooij, Kees (ITOP NM) - KLM
Barbara,

Did you transport the catalog dump dataset with ftp? 
If yes, this might again point to ftp.
If not, the problem must be in the dump dataset. Then DFdss dump produces (can 
produce) a non-standard recfm=u dataset, that will be processed correctly by 
dfdss restore, but might confuse other programs reading it. This should be 
documented with DFdss in my opinion.

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barbara Nitz
Sent: 07 November 2019 06:30
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zfs from 1 LPAR to another

>For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR that 
>needed it.  Worked fine, until it didn't.  IBM's response to the PMR that I 
>opened is that the only 100% reliable way to FTP a DFDSS dump file was to 
>terse it first.  IBM does not support direct FTP of a DFDSS dump file.  So I 
>now terse every DFDSS dump file before FTPing it to other systems, and I 
>haven't had another failure in 6 years.  As I said, it will work until it 
>doesn't.

And just to add my two cents: A few years back I tried to migrate a (user) 
catalog from one RDT lpar (where I had things customized) to another RDT lpar 
(at a higher z/OS level). The dump (RC=0) got restored with RC=0, IDCAMS 
imported the catalog with RC=0, but the content was completely unusable. Trying 
to access any data set in that catalog on the DASD (that had also been 
migrated, but not via ftp) resulted in a plethora of strange rc/rsn 
combinations that really didn't make any sense. I eventually tersed the catalog 
dump and untersed/restored/imported on the other side. Now the data sets were 
accessible without any problems.
I did not open any PMR with IBM but I learned to always terse a DFDSS dump if I 
need to send it somewhere via ftp otherwise the results could get 
unpredictable. I don't think there's anything worse than a dataset that may or 
may not have been altered subtly. Don't take any chances, even if this is not 
clearly documented anywhere.

Regards, Barbara

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Zfs from 1 LPAR to another

2019-11-06 Thread Vernooij, Kees (ITOP NM) - KLM
Yes, but what is the problem with recfm=u? Treat it as defined/documented: 
physical blocks, with undefined internal logic. So don't try to find logic in 
it. Is this what FTP tries to do?

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: 06 November 2019 16:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zfs from 1 LPAR to another

On Wed, Nov 6, 2019 at 9:18 AM Vernooij, Kees (ITOP NM) - KLM < 
kees.verno...@klm.com> wrote:

> So do we.
>
> And I wonder what the actual problem is? If the DFDSS dump dataset has 
> such a special (internal) format, that FTP cannot always handle it 
> correctly, why can AMATERSE do this without problems?
>

A DFDSS dump dataset is RECFM=U. Each "logical record" is simply a block on 
DASD, with no imbedded (in the data) of where the record ends. This is a 
artifact of the ECKD format that only the IBM z (as far as I know) uses.
AMATERSE encodes the length of each physical block actually read into its data 
stream. And it produces FB output. So when you send it somewhere, the LRECL is 
always known. AMATERSE uses the encoded data in the FB to restore the data onto 
disk in the same PHYSICAL format that it was unloaded, making it usable once 
again by DFDSS. IMO, DFDSS should just have used VB or VBS format.



>
> If it FTP only, what is the special problem for FTP? What other 
> dataset formats are a problem for FTP?
>

Not FTP only.



>
> Questions, Fear, Uncertainty and Doubt...
>
> Kees.
>
>
--
People in sleeping bags are the soft tacos of the bear world.
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 information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Zfs from 1 LPAR to another

2019-11-06 Thread Vernooij, Kees (ITOP NM) - KLM
So do we.

And I wonder what the actual problem is? If the DFDSS dump dataset has such a 
special (internal) format, that FTP cannot always handle it correctly, why can 
AMATERSE do this without problems? 

If it FTP only, what is the special problem for FTP? What other dataset formats 
are a problem for FTP?

Questions, Fear, Uncertainty and Doubt...

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: 06 November 2019 16:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zfs from 1 LPAR to another

I have always FTP a DFDSS dump of "things"  - What I was told to do long ago 
and far away was to include BLKSIZE=32760 on the dump file in DFDSS.

This has never caused an issue (DFDSS ignores the Blksize).  And my Transfer 
have (knock wood) not failed.  And I have always been able to restore from the 
DFDSS dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Wednesday, November 06, 2019 8:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Zfs from 1 LPAR to another
> 
> Can you point to where that is documented?
> We FTP a lot b.m.o. DFDSS between Sysplexes.
> 
> Kees.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tom Conley
> Sent: 06 November 2019 15:46
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Zfs from 1 LPAR to another
> 
> On 11/5/2019 6:54 PM, Jousma, David wrote:
> > Terse, dont terse, your call.  I have 100% reliability as long as 
> > the
> destination disk dataset for the ftp is newly created.  If the 
> destination dataset already exists, then yes, there have been problems.
> >
> > As you mention there are some specific options on the transfer to 
> > specify,
> and as long as you do, it will work fine.
> >
> > Sending the dump file outside the company, probably not bad idea to 
> > terse
> since we are all familiar with it.
> >
> > 
> > __
> > ___
> >
> > Dave Jousma
> >
> > AVP | Manager, Systems Engineering
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> > Rapids, MI 49546
> >
> > 616.653.8429  |  fax: 616.653.2717
> > 
> > From: Tom Conley 
> > Sent: Tuesday, November 5, 2019 5:17 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Zfs from 1 LPAR to another
> >
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or 
> > unexpected emails**
> >
> > On 11/5/2019 3:11 PM, Wayne Bickerdike wrote:
> >> I always terse the dump file too. Had issues with Restore if the 
> >> file wasn't  tersed.
> >>
> >> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud  wrote:
> >>
> >>> Dave,
> >>>   I'll do that. The files are not big.
> >>>   They can be sent as ZIP files.
> >>> Thanks, Pierre
> >>>
> >>> --
> >>> --
> >>> -- 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
> >>
> >
> > Wayne beat me to it.  Terse any DFDSS file before sending.  You may 
> > get away with DFDSS with mode block and EBCDIC.  Until you don't.
> > Terse it for 100% reliability.
> >
> > Regards,
> > Tom Conley
> >
> 
> Dave,
> 
> For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR 
> that needed it.  Worked fine, until it didn't.  IBM's response to the 
> PMR that I opened is that the only 100% reliable way to FTP a DFDSS 
> dump file was to terse it first.  IBM does not support direct FTP of a 
> DFDSS dump file.  So I now terse every DFDSS dump file before FTPing 
> it to other systems, and I haven't had another failure in 6 years.  As 
> I said, it will work until it doesn't.
> 
> Regards,
> Tom Conley
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, se

Re: Zfs from 1 LPAR to another

2019-11-06 Thread Vernooij, Kees (ITOP NM) - KLM
Can you point to where that is documented?
We FTP a lot b.m.o. DFDSS between Sysplexes.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: 06 November 2019 15:46
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Zfs from 1 LPAR to another

On 11/5/2019 6:54 PM, Jousma, David wrote:
> Terse, dont terse, your call.  I have 100% reliability as long as the 
> destination disk dataset for the ftp is newly created.  If the destination 
> dataset already exists, then yes, there have been problems.
> 
> As you mention there are some specific options on the transfer to specify, 
> and as long as you do, it will work fine.
> 
> Sending the dump file outside the company, probably not bad idea to terse 
> since we are all familiar with it.
> 
> __
> ___
> 
> Dave Jousma
> 
> AVP | Manager, Systems Engineering
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> Rapids, MI 49546
> 
> 616.653.8429  |  fax: 616.653.2717
> 
> From: Tom Conley 
> Sent: Tuesday, November 5, 2019 5:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Zfs from 1 LPAR to another
> 
> 
> **CAUTION EXTERNAL EMAIL**
> 
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
> 
> On 11/5/2019 3:11 PM, Wayne Bickerdike wrote:
>> I always terse the dump file too. Had issues with Restore if the file 
>> wasn't  tersed.
>>
>> On Wed, Nov 6, 2019, 03:53 Pierre Fichaud  wrote:
>>
>>> Dave,
>>>   I'll do that. The files are not big.
>>>   They can be sent as ZIP files.
>>> Thanks, Pierre
>>>
>>> 
>>> -- 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
>>
> 
> Wayne beat me to it.  Terse any DFDSS file before sending.  You may 
> get away with DFDSS with mode block and EBCDIC.  Until you don't.  
> Terse it for 100% reliability.
> 
> Regards,
> Tom Conley
> 

Dave,

For over a year, I FTP'd a DFDSS dump of my IODF file to every LPAR that needed 
it.  Worked fine, until it didn't.  IBM's response to the PMR that I opened is 
that the only 100% reliable way to FTP a DFDSS dump file was to terse it first. 
 IBM does not support direct FTP of a DFDSS dump file.  So I now terse every 
DFDSS dump file before FTPing it to other systems, and I haven't had another 
failure in 6 years.  As I said, it will work until it doesn't.

Regards,
Tom Conley

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Set change bit after DFdss restore

2019-11-03 Thread Vernooij, Kees (ITOP NM) - KLM
Robert,

Yes it is.

However your remark lit a light in the back of my brain: if dss sets the 
changebit on a newname, what would it do when I renamed the dataset to itself?
RENANMEU((dsname,dsname))
Yes, it restores the dataset to its original name, but it does set the 
changebit.

A wonderful, I guess unintended, feature!

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert2 Gensler
Sent: 01 November 2019 16:15
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Set change bit after DFdss restore

Is it a requirement that the data sets being restored in the other sysplex have 
the same name as when they were dumped? When dss restore data sets with new 
names, it turns the changed bit on.

Robert

DFSMSdss Architecture and Development
Tucson, AZ
1-720-349-5211
rgen...@us.ibm.com

IBM Mainframe Discussion List  wrote on
11/01/2019 03:42:50 AM:

> From: "Vernooij, Kees (ITOP NM) - KLM" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 11/01/2019 03:46 AM
> Subject: [EXTERNAL] Re: Set change bit after DFdss restore Sent by: 
> IBM Mainframe Discussion List 
>
> Not exactly my situation: the change bits are off correctly then the 
> datasets are dumped, but I want them turned on when the datasets are 
> restored in the new sysplex.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU ] 
> On Behalf Of Michael Stein
> Sent: 01 November 2019 07:04
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Set change bit after DFdss restore
>
> This might be old news and fixed (or documented?) but I remember that 
> ADRDSSU dump of a full volume turned off the DSCB change bits *IN THE 
> DUMP*.
>
> So you have a slightly bad/failing disk.  You dump it to tape.
> IBM replaces the HDA.  You restore the tape image to the new disk.
> Then you toss the tape...
>
> NO, you just lost information...
>
> That volume is in an incremental backup scheme and you just turned off 
> the change flag on an unknown number of datasets which now won't be 
> backed up by the next incremental backup run...
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> https://urldefense.proofpoint.com/v2/url?
> u=http-3A__www.klm.com=DwIFAg=jf_iaSHvJObTbx-
> siA1ZOg=4IouVQcajkz0Xk8aBQYNyp4CJn0tmfX31FiYrnNQujA=bV02HP-
>
KIeF0jjGCothMYLqKXOfGgJCWRYLlwMtqSow=SzpSHlfsDy6aEqIlkc7one3I8c21RZz16MUS-

> IDFDJ4= . This e-mail and any attachment may contain confidential 
> and privileged material intended for the addressee only. If you are 
> not the addressee, you are notified that no part of the e-mail or any 
> attachment may be disclosed, copied or distributed, and that any other 
> action related to this e-mail or attachment is strictly prohibited, 
> and may be unlawful. If you have received this e-mail by error, please 
> notify the sender immediately by return e-mail, and delete this 
> message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/ or 
> its employees shall not be liable for the incorrect or incomplete 
> transmission of this e-mail or any attachments, nor responsible for 
> any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal 
> Dutch Airlines) is registered in Amstelveen, The Netherlands, with 
> registered number 33014286
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
emp

Re: Set change bit after DFdss restore

2019-11-01 Thread Vernooij, Kees (ITOP NM) - KLM
Not exactly my situation: the change bits are off correctly then the datasets 
are dumped, but I want them turned on when the datasets are restored in the new 
sysplex.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Michael Stein
Sent: 01 November 2019 07:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Set change bit after DFdss restore

This might be old news and fixed (or documented?) but I remember that ADRDSSU 
dump of a full volume turned off the DSCB change bits *IN THE DUMP*.

So you have a slightly bad/failing disk.  You dump it to tape.
IBM replaces the HDA.  You restore the tape image to the new disk.  Then you 
toss the tape...

NO, you just lost information...

That volume is in an incremental backup scheme and you just turned off the 
change flag on an unknown number of datasets which now won't be backed up by 
the next incremental backup run...

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: Set change bit after DFdss restore

2019-10-31 Thread Vernooij, Kees (ITOP NM) - KLM
Yes, I already mentioned the ca-disk tool: set the changebit.

Talking about ca-disk: it does have the option to SET the changebit at restore 
time. No one has apparently requested this for dfdss.
And to answer the question: why don't I use ca-disk? Like HSM, it administers 
it archives/backups in its index. Restoring requires the index records to be 
available in the new sysplex. This is possible, but equally complex as other 
solutions.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: 31 October 2019 12:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Set change bit after DFdss restore

As a last resort, post process the restore list and create dataset backup 
commands from that. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOP NM) - KLM
Sent: Thursday, October 31, 2019 6:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Set change bit after DFdss restore

Robert,

CA-DISK has a similar function, but unfortunately both this one and the hsm one 
will not work in this situation. 
The dataset already exists in the target sysplex and therefor already has a 
backup. It will be overwritten with a new one by DFDSS with the changebit off. 
This scenario will not cause hsm nor ca-disk to take a backup, because a backup 
already exists.

Kees.

-Original Message-
From: Vernooij, Kees (ITOP NM) - KLM
Sent: 31 October 2019 11:07
To: IBM Mainframe Discussion List 
Subject: RE: Set change bit after DFdss restore

No, I don't have hsm unfortunately, this option looks what I need.
We have CA-DISK and I think it has a similar function, I will check that. This 
might be the golden tip.

What ADRSSSU does at dump is not important, we want to transfer a specific set 
of data sets and they should all be selected.
However at restore in the other sysplex, I want the changebit set and this 
seems impossible.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: 31 October 2019 10:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Set change bit after DFdss restore

Kees,

Do you have DFSMShsm? If so, specify:   INCREMENTALBACKUP(ORIGINAL) 

INCREMENTALBACKUP(ORIGINAL) specifies that DFSMShsm creates an initial backup 
version (if one does not exist) for all non-VSAM and integrated catalog 
facility VSAM data sets on a primary volume when incremental backup takes 
place, regardless of the setting of the change bit in the data set VTOC entry.

Using ADRSSSU with some combination of filtering. For instance:

DUMP DATASET(INCLUDE(**)  -
  BY((DSCHA,EQ,NO)) )  -


>From the manual:

The BY parameter can filter for the following data set characteristics:

ALLOC - Allocation type (cylinder, track, block, absolute track, or movable) 
CATLG - Whether a data set is cataloged or not (using the standard catalog 
search order) CREDT - Creation date (absolute or relative) DATACLAS - Data 
class for SMS DSCHA - Whether the data-set-changed indicator is on DSORG - Data 
set organization (SAM, PAM, PDS, PDSE, BDAM, EXCP, HFS, ISAM, VSAM, or zFS) 
EXPDT - Expiration date (absolute or relative) EXTNT - Number of extents FSIZE 
- Data set size (number of allocated or used tracks) MGMTCLAS - Management 
class for SMS MULTI - Whether the VTOC shows that the data set is single-volume 
or multivolume (allocated single-volume data sets that have never been opened 
and are not cataloged may be selected as multivolume).
REFDT - Last-referenced date (absolute or relative) STORCLAS - Storage class 
for SMS



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOP NM) - KLM
Sent: Wednesday, October 30, 2019 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Set change bit after DFdss restore

Hello group,

We use DFSMSdss to move datasets from one sysplex to another.
The method is:
Dump the datasets with DFdss to a dumpdataset.
FTP the dumpdataset to the other sysplex.
Restore the datasets in the other sysplex.

The problem is that the datasets that have the changebit OFF in the original 
sysplex, will be restored with the changebit OFF. Therefor no backup will be 
taken at the target sysplex.
DFdss has some options to RESET or not RESET the changebit, but not to SET the 
changebit ON.

I checked FDR, but that doesn't have any options to manipulate the changebit.

We have a CA-DISK utility to SET the changebit on individual datasets, but 
takes an extra step in each move action and can be easily forgotten.
I prefer to have this done automatically.
How can we easily and automatically set the changebit ON? Any ideas?

Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may cont

Re: Set change bit after DFdss restore

2019-10-31 Thread Vernooij, Kees (ITOP NM) - KLM
Robert,

CA-DISK has a similar function, but unfortunately both this one and the hsm one 
will not work in this situation. 
The dataset already exists in the target sysplex and therefor already has a 
backup. It will be overwritten with a new one by DFDSS with the changebit off. 
This scenario will not cause hsm nor ca-disk to take a backup, because a backup 
already exists.

Kees.

-Original Message-
From: Vernooij, Kees (ITOP NM) - KLM 
Sent: 31 October 2019 11:07
To: IBM Mainframe Discussion List 
Subject: RE: Set change bit after DFdss restore

No, I don't have hsm unfortunately, this option looks what I need.
We have CA-DISK and I think it has a similar function, I will check that. This 
might be the golden tip.

What ADRSSSU does at dump is not important, we want to transfer a specific set 
of data sets and they should all be selected.
However at restore in the other sysplex, I want the changebit set and this 
seems impossible.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: 31 October 2019 10:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Set change bit after DFdss restore

Kees,

Do you have DFSMShsm? If so, specify:   INCREMENTALBACKUP(ORIGINAL) 

INCREMENTALBACKUP(ORIGINAL) specifies that DFSMShsm creates an initial backup 
version (if one does not exist) for all non-VSAM and integrated catalog 
facility VSAM data sets on a primary volume when incremental backup takes 
place, regardless of the setting of the change bit in the data set VTOC entry.

Using ADRSSSU with some combination of filtering. For instance:

DUMP DATASET(INCLUDE(**)  -
  BY((DSCHA,EQ,NO)) )  -


>From the manual:

The BY parameter can filter for the following data set characteristics:

ALLOC - Allocation type (cylinder, track, block, absolute track, or movable) 
CATLG - Whether a data set is cataloged or not (using the standard catalog 
search order) CREDT - Creation date (absolute or relative) DATACLAS - Data 
class for SMS DSCHA - Whether the data-set-changed indicator is on DSORG - Data 
set organization (SAM, PAM, PDS, PDSE, BDAM, EXCP, HFS, ISAM, VSAM, or zFS) 
EXPDT - Expiration date (absolute or relative) EXTNT - Number of extents FSIZE 
- Data set size (number of allocated or used tracks) MGMTCLAS - Management 
class for SMS MULTI - Whether the VTOC shows that the data set is single-volume 
or multivolume (allocated single-volume data sets that have never been opened 
and are not cataloged may be selected as multivolume).
REFDT - Last-referenced date (absolute or relative) STORCLAS - Storage class 
for SMS



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOP NM) - KLM
Sent: Wednesday, October 30, 2019 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Set change bit after DFdss restore

Hello group,

We use DFSMSdss to move datasets from one sysplex to another.
The method is:
Dump the datasets with DFdss to a dumpdataset.
FTP the dumpdataset to the other sysplex.
Restore the datasets in the other sysplex.

The problem is that the datasets that have the changebit OFF in the original 
sysplex, will be restored with the changebit OFF. Therefor no backup will be 
taken at the target sysplex.
DFdss has some options to RESET or not RESET the changebit, but not to SET the 
changebit ON.

I checked FDR, but that doesn't have any options to manipulate the changebit.

We have a CA-DISK utility to SET the changebit on individual datasets, but 
takes an extra step in each move action and can be easily forgotten.
I prefer to have this done automatically.
How can we easily and automatically set the changebit ON? Any ideas?

Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
li

Re: Set change bit after DFdss restore

2019-10-31 Thread Vernooij, Kees (ITOP NM) - KLM
No, I don't have hsm unfortunately, this option looks what I need.
We have CA-DISK and I think it has a similar function, I will check that. This 
might be the golden tip.

What ADRSSSU does at dump is not important, we want to transfer a specific set 
of data sets and they should all be selected.
However at restore in the other sysplex, I want the changebit set and this 
seems impossible.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: 31 October 2019 10:58
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Set change bit after DFdss restore

Kees,

Do you have DFSMShsm? If so, specify:   INCREMENTALBACKUP(ORIGINAL) 

INCREMENTALBACKUP(ORIGINAL) specifies that DFSMShsm creates an initial backup 
version (if one does not exist) for all non-VSAM and integrated catalog 
facility VSAM data sets on a primary volume when incremental backup takes 
place, regardless of the setting of the change bit in the data set VTOC entry.

Using ADRSSSU with some combination of filtering. For instance:

DUMP DATASET(INCLUDE(**)  -
  BY((DSCHA,EQ,NO)) )  -


>From the manual:

The BY parameter can filter for the following data set characteristics:

ALLOC - Allocation type (cylinder, track, block, absolute track, or movable) 
CATLG - Whether a data set is cataloged or not (using the standard catalog 
search order) CREDT - Creation date (absolute or relative) DATACLAS - Data 
class for SMS DSCHA - Whether the data-set-changed indicator is on DSORG - Data 
set organization (SAM, PAM, PDS, PDSE, BDAM, EXCP, HFS, ISAM, VSAM, or zFS) 
EXPDT - Expiration date (absolute or relative) EXTNT - Number of extents FSIZE 
- Data set size (number of allocated or used tracks) MGMTCLAS - Management 
class for SMS MULTI - Whether the VTOC shows that the data set is single-volume 
or multivolume (allocated single-volume data sets that have never been opened 
and are not cataloged may be selected as multivolume).
REFDT - Last-referenced date (absolute or relative) STORCLAS - Storage class 
for SMS



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOP NM) - KLM
Sent: Wednesday, October 30, 2019 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Set change bit after DFdss restore

Hello group,

We use DFSMSdss to move datasets from one sysplex to another.
The method is:
Dump the datasets with DFdss to a dumpdataset.
FTP the dumpdataset to the other sysplex.
Restore the datasets in the other sysplex.

The problem is that the datasets that have the changebit OFF in the original 
sysplex, will be restored with the changebit OFF. Therefor no backup will be 
taken at the target sysplex.
DFdss has some options to RESET or not RESET the changebit, but not to SET the 
changebit ON.

I checked FDR, but that doesn't have any options to manipulate the changebit.

We have a CA-DISK utility to SET the changebit on individual datasets, but 
takes an extra step in each move action and can be easily forgotten.
I prefer to have this done automatically.
How can we easily and automatically set the changebit ON? Any ideas?

Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notif

Re: Set change bit after DFdss restore

2019-10-31 Thread Vernooij, Kees (ITOP NM) - KLM
Yes I did. And no, it only provides what the parameters do: to RESET of not to 
RESET the changebit. No SETting it.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roger Lowe
Sent: 30 October 2019 19:57
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Set change bit after DFdss restore

On Wed, 30 Oct 2019 15:51:28 +, Vernooij, Kees (ITOP NM) - KLM 
 wrote:

>Hello group,
>
>We use DFSMSdss to move datasets from one sysplex to another.
>The method is:
>Dump the datasets with DFdss to a dumpdataset.
>FTP the dumpdataset to the other sysplex.
>Restore the datasets in the other sysplex.
>
>The problem is that the datasets that have the changebit OFF in the original 
>sysplex, will be restored with the changebit OFF. Therefor no backup will be 
>taken at the target sysplex.
>DFdss has some options to RESET or not RESET the changebit, but not to SET the 
>changebit ON.
>
>I checked FDR, but that doesn't have any options to manipulate the changebit.
>
>We have a CA-DISK utility to SET the changebit on individual datasets, but 
>takes an extra step in each move action and can be easily forgotten.
>I prefer to have this done automatically.
>How can we easily and automatically set the changebit ON? Any ideas?
>
>Kees.
>
Have you checked out ADRPATCH (DFSMSdss patch area)? - it may do what you want

Roger

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Set change bit after DFdss restore

2019-10-30 Thread Vernooij, Kees (ITOP NM) - KLM
Hello group,

We use DFSMSdss to move datasets from one sysplex to another.
The method is:
Dump the datasets with DFdss to a dumpdataset.
FTP the dumpdataset to the other sysplex.
Restore the datasets in the other sysplex.

The problem is that the datasets that have the changebit OFF in the original 
sysplex, will be restored with the changebit OFF. Therefor no backup will be 
taken at the target sysplex.
DFdss has some options to RESET or not RESET the changebit, but not to SET the 
changebit ON.

I checked FDR, but that doesn't have any options to manipulate the changebit.

We have a CA-DISK utility to SET the changebit on individual datasets, but 
takes an extra step in each move action and can be easily forgotten.
I prefer to have this done automatically.
How can we easily and automatically set the changebit ON? Any ideas?

Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: Power failure

2019-10-18 Thread Vernooij, Kees (ITOP NM) - KLM
Or: open the floor and check if the power cords are really connected to 
different rails.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Schwab
> Sent: 18 October, 2019 0:02
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Power failure
> 
> I agree.  By mistake both power cords lead to the same UPS, or even
> the same breaker.  Pick a low impact time.  Turn each breaker off for
> 1 minute then turn back on.  Look for anything that went down and
> change outlets as needed.  Then power off each UPS to check for
> different breakers but same UPS.  Or isn't there a device that will
> send a signal over the line and you can determine which outlets are
> wired to that breaker? Or is that only phone / network lines?
> 
> On Thu, Oct 17, 2019 at 10:27 AM Tom Marchant
> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > On Thu, 17 Oct 2019 11:41:24 +0400, Peter wrote:
> >
> > >We have a dual... connectivity from UPS wired to z14.
> > >
> > >Even if one goes down and another would take a control
> >
> > That's what you said.
> >
> > Some of us are skeptical that it is actually implemented the way
> > that you intended that it be implemented.
> >
> > --
> > Tom Marchant
> >
> > --
> > 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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Best way for a task to give up the CPU and let other tasks run?

2019-10-17 Thread Vernooij, Kees (ITOP NM) - KLM
"I'm done for the moment if something else would like to run"
That's not for the task to decide: the dispatcher, under control of WLM, 
decides whether you get the CPU or will be removed from it to allow another 
task to run. All based on WLM directions, which you can influence by selecting 
a Service Class with a certain Goal.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: 17 October, 2019 16:15
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Best way for a task to give up the CPU and let other tasks
> run?
> 
> On Thu, 17 Oct 2019 08:54:11 -0400, Thomas David Rivers wrote:
> 
> >Does anyone happen to know the best way for a running task
> >to give up running and let another task run?
> >
> >But - this isn't "give up" as in ending the task, just giving up
> >the CPU to allow another task to run and then returning to this
> >task.
> >
> >Sorta like "I'm done for the moment if something else would like to run".
> >
> What does "for the moment" mean?  If your process has nothing
> more to do, it should just quit.  If it needs to wait for an event,
> there are various programming interfaces for such things.
> 
> See also setpriority().
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Best way for a task to give up the CPU and let other tasks run?

2019-10-17 Thread Vernooij, Kees (ITOP NM) - KLM
WLM: give the job a Serice Class with Importance=5 and a Velocity=1. It will be 
thankful for each CPU second that is left unused by all other tasks in the 
system.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Thomas David Rivers
> Sent: 17 October, 2019 14:54
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Best way for a task to give up the CPU and let other tasks run?
> 
> Does anyone happen to know the best way for a running task
> to give up running and let another task run?
> 
> But - this isn't "give up" as in ending the task, just giving up
> the CPU to allow another task to run and then returning to this
> task.
> 
> Sorta like "I'm done for the moment if something else would like to run".
> 
>- Thanks -
> - Dave R. -
> 
> --
> riv...@dignus.comWork: (919) 676-0847
> Get your mainframe programming tools at http://www.dignus.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: Power failure

2019-10-17 Thread Vernooij, Kees (ITOP NM) - KLM
Still makes you wonder what *good* reason it had to reboot on its own.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter
> Sent: 17 October, 2019 8:33
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Power failure
> 
> Ibm responded
> 
> Says this  system reboot could be due to at SE level.
> 
> Half of the log collected got corrupted
> 
> Error data not in cache .
> 
> Still wondering if SE can really reboot the machine on its own.
> 
> 
> 
> On Wed, 16 Oct, 2019, 6:21 PM Jousma, David, <
> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > +1 for what Tom says.  I didn’t reply to the earlier email from Peter
> this
> > morning, but did you drill down into the "restarted forcibly" message
> that
> > you presumably saw on the HMC?  I'd also go look for hardware messages
> at
> > the CEC level, there should be events there, that you can also drill
> down
> > into.  While you may not see the shutdown (hopefully there is
> something),
> > you would see more of the startup information.
> >
> >
> >
> __
> ___
> > Dave Jousma
> > AVP | Manager, Systems Engineering
> >
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > Rapids, MI 49546
> > 616.653.8429  |  fax: 616.653.2717
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Tom Marchant
> > Sent: Wednesday, October 16, 2019 10:07 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Power failure
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> > On Wed, 16 Oct 2019 09:51:34 +0400, Peter wrote:
> >
> > >I looked into audit and log messages during those time frames.
> > >
> > >I just see a message as system was restarted forcibly. It doesn't say
> > >what caused it.
> >
> > If power was lost abruptly, there may have been no opportunity to log
> > anything.
> >
> > >Does IBM receives more detailed message ?
> >
> > Have you asked IBM?
> >
> > --
> > Tom Marchant
> >
> > --
> > 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
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: STGADMIN.DPDSRN Confusion

2019-10-16 Thread Vernooij, Kees (ITOP NM) - KLM
A curios message here is IGD17056I. Can this not be the real problem for RENAME?

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mark Jacobs
> Sent: 16 October, 2019 16:16
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: STGADMIN.DPDSRN Confusion
> 
> I'm attempting to rename an inuse non-vsam dataset, even with read access
> to the STGADMIN.DPDSRN.SYS1.* profile, it's failing with these error
> messages.
> 
> IGD17060I DELETE/RENAME FAILED BECAUSE DATA SET IS OPEN
> ON VOLUME Z22C02
> DATA SET IS SYS1.PROD.PARMLIB.NEW
> IEC614I RENAME FAILED - RC 008, DIAGNOSTIC INFORMATION IS (040B0446),
> STEP2,Z22C02,SYS1.PROD.PARMLIB.NEW
> DATA SET NAME IS IN USE BUT YOU HAVE AUTHORITY TO OVERRIDE THIS TEST
> IGD17056I RENAME FAILED, DUPLICATE DATA SET NAME ON VOLUME Z22C02
> DATA SET IS SYS1.PROD.PARMLIB.NEW.ORIG
> 
> X'04' X'0B' ENQRET X'46'
> Validate DADSM RENAME request; enqueue on SYSDSN failed. Also, the caller
> has appropriate RACF READ authority to be able to specify that the data
> set being renamed is not the data set in use.
> See Renaming a Data Set That Might be in Use in z/OS DFSMSdfp Advanced
> Services.Sent from [ProtonMail](https://protonmail.com), Swiss-based
> encrypted email.
> 
> What am I missing here?
> 
> Mark Jacobs
> 
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get=markjacobs@protonmail.c
> om
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: zOS 2.4 migration guide

2019-10-16 Thread Vernooij, Kees (ITOP NM) - KLM
It looks as if you can't escape z/OSMF anymore. From what I read in the past, 
this and many more functions will run (only) under z/OSMF. So this might be the 
time to start running it.

Kees

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Martin Packer
> Sent: 16 October, 2019 10:29
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: zOS 2.4 migration guide
> 
> OK; I'll bite: Why not run z/OSMF?
> 
> But if you prefer to exercise your XSLT skills... :-)
> 
> Cheers, Martin
> 
> Martin Packer
> 
> zChampion, Systems Investigator & Performance Troubleshooter, IBM
> 
> +44-7802-245-584
> 
> email: martin_pac...@uk.ibm.com
> 
> Twitter / Facebook IDs: MartinPacker
> 
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
> 
> Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or
> 
> https://itunes.apple.com/gb/podcast/mainframe-performance-
> topics/id1127943573?mt=2
> 
> 
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
> 
> 
> 
> From:   Jake Anderson 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   16/10/2019 09:06
> Subject:[EXTERNAL] zOS 2.4 migration guide
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> Hi
> 
> I understand starting from 2.4 there won't be any migration guide. We will
> have to look in GitHub to get XML file into zosmf to look into migration
> steps .
> 
> We don't run zOSMF and how do i view the migration steps for zOS 2.4 from
> 2.2 ?
> 
> Jake
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: Power failure

2019-10-15 Thread Vernooij, Kees (ITOP NM) - KLM
Sure. Some time ago we did a check of the power connections before a major 
action on one of the power rails and we also found a couple of devices that had 
their redundant power plugs connected to the same rail.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: 15 October, 2019 14:30
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Power failure
> 
> My point about the UPS's is that while I am sure you know they are fine,
> do you KNOW for sure your z14 is wired to both?   Only your facilities
> guys can answer that.   We've been known to see a few servers go down when
> our facilities guys take a PDU offline to do some maintenance, only to
> find that some servers had both of their power feeds coming off the
> same...
> 
> __
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Peter
> Sent: Tuesday, October 15, 2019 8:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Power failure
> 
> **CAUTION EXTERNAL EMAIL**
> 
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
> 
> We have checked our local UPS and they are fine ..
> 
> Not sure why SE didn't write anything about this failure and there was no
> IBM call made from box.
> 
> There should be somewhere this kind of failure notification would be
> recorded ?
> 
> On Tue, 15 Oct, 2019, 3:51 PM Jousma, David, < 01a0403c5dc1-dmarc-
> requ...@listserv.ua.edu> wrote:
> 
> > Assuming  you have the box properly installed, and reporting "home" to
> > IBM, I'd suspect something local.  These boxes have redundant power
> > supplies, and if one fails, it will phone home.  Maybe what you think
> > is true about your redundant connections is not really the case?
> >
> >
> >
> >
> > __
> > ___
> > Dave Jousma
> > AVP | Manager, Systems Engineering
> >
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > Rapids, MI 49546
> > 616.653.8429  |  fax: 616.653.2717
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Peter
> > Sent: Tuesday, October 15, 2019 7:47 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Power failure
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> > Hi
> >
> > We had a power failure on our z14 zr1. I couldn't find any reason on
> > the log or hardware message on why it had power failure. Also our z14
> > box is connected to two different UPS and they never went down .
> >
> > Where can we find the root cause of this power outage? When i checked
> > our Support element was initialising and not sure what made this power
> outage.
> > As other machines were all working intact.
> >
> > Any clue or suggestions to look into this?
> >
> > Peter
> >
> > --
> > 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
> >
> 
> --
> 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 

Re: Power failure

2019-10-15 Thread Vernooij, Kees (ITOP NM) - KLM
Ask IBM to dial in on the box and check the logs.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter
> Sent: 15 October, 2019 14:24
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Power failure
> 
> We have checked our local UPS and they are fine ..
> 
> Not sure why SE didn't write anything about this failure and there was no
> IBM call made from box.
> 
> There should be somewhere this kind of failure notification would be
> recorded ?
> 
> On Tue, 15 Oct, 2019, 3:51 PM Jousma, David, <
> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > Assuming  you have the box properly installed, and reporting "home" to
> > IBM, I'd suspect something local.  These boxes have redundant power
> > supplies, and if one fails, it will phone home.  Maybe what you think is
> > true about your redundant connections is not really the case?
> >
> >
> >
> >
> >
> __
> ___
> > Dave Jousma
> > AVP | Manager, Systems Engineering
> >
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > Rapids, MI 49546
> > 616.653.8429  |  fax: 616.653.2717
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Peter
> > Sent: Tuesday, October 15, 2019 7:47 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Power failure
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> > Hi
> >
> > We had a power failure on our z14 zr1. I couldn't find any reason on the
> > log or hardware message on why it had power failure. Also our z14 box is
> > connected to two different UPS and they never went down .
> >
> > Where can we find the root cause of this power outage? When i checked
> our
> > Support element was initialising and not sure what made this power
> outage.
> > As other machines were all working intact.
> >
> > Any clue or suggestions to look into this?
> >
> > Peter
> >
> > --
> > 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
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: DR Sysplex Procedure

2019-10-09 Thread Vernooij, Kees (ITOP NM) - KLM
"Do both LPARs need to be down (not desirable) before IPLing either of them 
with the new CF and XCF?"

I would try to test the real situation as much as possible.

Besides, I think it will not work. LPAR's don't join each other, they join a 
Sysplex. After ipling one system with the new definitions, it runs from 
different Couple datasets and is a Sysplex of its own, but with XCF connections 
to the other LPAR that runs from the old Couple Datasets, so in the old 
Sysplex. This seems asking for unexpected problems.

Kees

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elaine Beal
> Sent: 09 October, 2019 16:17
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DR Sysplex Procedure
> 
> We are planning to test a remote copy sysplex environment and I would like
> to test it in our home DEV environment
> PROD data will not be accessible during the DR test so PROD sysplex should
> not be affected
> 
> To test in DEV I have defined a new XCF and CFRM since I will need to do
> that for DR
> to account for the different CPU serial number.
> In DEV I have not changed the serial number for the test, I'm just trying
> out the procedure.
> 
> At DR we will IPL the sysplex LPARs one at a time so I'm not concerned
> about the order, the files or the join.
> 
> I'm not sure about the order for DEV.
> 
> Do both LPARs need to be down (not desirable) before IPLing either of them
> with the new CF and XCF?
> Or is one at a time okay since one is removed from the sysplex at shutdown
> and just won't be able to join the current one at IPL
> 
> I am not planning to create new LOGR and WLM files at DR but I will need
> to create them for the test as they are shared.
> 
> so, the plan is-
> 
> 1. create new XCF and CFRM DR files (new LOGR and WLM for testing DEV at
> home but not at DR)
> 
> 2. update COUPLXX with new files
> 
> 3. shutdown LPAR1
> 
> 4. IPL LPAR1 with new COUPLxx and respond toinitialize new files
> 
> 5. Shutdown LPAR2 and IPL with new COUPLxx (no initialize)
> 
> Thanks,
> Elaine
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Planned ESQA change and HealthCheck

2019-10-02 Thread Vernooij, Kees (ITOP NM) - KLM
Maybe it is not that bad: I did not know the word either and maybe Radoslaw 
also had to look the English translation of the Polish word. But I might just 
as well be part of his English vocabulary -;)

Kees

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Richards, Robert B.
> Sent: 01 October, 2019 19:02
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Planned ESQA change and HealthCheck
> 
> Skip,
> 
> I have found that a lots of "English as a second language" folks speak
> better English than the rest of us. I had to refresh my memory using the
> dictionary when Radoslaw trotted out "anathematized". I *hate* it when
> people do that! 
> 
> I stand in awe behind you.  :-)
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: Tuesday, October 1, 2019 12:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Planned ESQA change and HealthCheck
> 
> I stand in awe of the Polish guru who can both entertain and educate.
> Including English vocabulary. No anathematization here.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of R.S.
> Sent: Tuesday, October 1, 2019 7:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Planned ESQA change and HealthCheck
> 
> (I will be anathematized for the text below) Simple solution:
> stop HZSPROC
> delete HZSDATA dataset
> create it again using plain IEFBR14 or any other method - just empty PS
> dataset start HZSPROC
> 
> It works. No animal will be injured by deletion of the dataset. No climate
> change will happen when you create new dataset using cursed method as the
> above. Some prophets say it may happen badly, but it had never happened
> yet...
> 
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> W dniu 2019-10-01 o 13:25, Jousma, David pisze:
> > Ok, I answered the first question.  How to get it back, F
> HZSPROC,ADDNEW.   But how do I reset the history is still outstanding.
> >
> > Thanks, Dave
> >
> > __
> > ___
> > Dave Jousma
> > AVP | Manager, Systems Engineering
> >
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > Rapids, MI 49546
> > 616.653.8429  |  fax: 616.653.2717
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Jousma, David
> > Sent: Tuesday, October 1, 2019 7:20 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Planned ESQA change and HealthCheck
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> > Ok,  This is one of those dumb moments...IPLed one of my tech systems
> last night with a planned increase of ESQA.   The associated health check
> popped after the IPL  CHECK(IBMVSM,VSM_CSA_CHANGE) because of the decrease
> in EPVT.   It's not clear to me how to reset the history for this
> healthcheck so that it doesn't show as a critical problem.   In my
> guessing, I ended up deleting that check.
> >
> > So how do I get it back(short of IPLing), and how do I reset the history
> since this was a planned change?
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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

Re: MVS logger [-Internal-]

2019-09-30 Thread Vernooij, Kees (ITOP NM) - KLM
One possible solution that is not mentioned in the below docs is the new 
ALLOCAHEAD Logstream parameter.
https://www.ibm.com/developerworks/community/blogs/43ea8e78-acbe-49f5-9290-379e4f4569cb/entry/Logger_allocate_ahead_log_stream_advanced_current_offload_data_sets?lang=en

Kees



> -Original Message-
> From: Vernooij, Kees (ITOP NM) - KLM
> Sent: 30 September, 2019 15:37
> To: IBM Mainframe Discussion List 
> Subject: RE: MVS logger [-Internal-]
> 
> I found:
> https://www.ibm.com/support/pages/dfhlg0777-mvs-logger-codes-x0008-
> x0865-dfhlog-or-dfhshunt
> https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.5.0/reference/sit/
> dfha2_csdrecov.html
> 
> this should explain your situation.
> 
> Kees
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Lopez, Sharon
> > Sent: 30 September, 2019 15:27
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: MVS logger [-Internal-]
> >
> > Data Classification: [-Internal-]
> > Hello,
> >
> > Can anyone help with this or offer any type of suggestion?  A few weeks
> > ago we started getting this message in our CICS DFHLOG log streams that
> > are on dasd.  We are not aware of any conditions that changed that could
> > have caused this.  Thanks in advance.
> >
> > +DFHLG0777 PRODAORD 338
> >  A temporary error condition occurred during MVS logger operation
> > IXGWRITE  for log stream PRODAORD.DFHLOG. MVS logger codes:
> >  X'0008', X'0867'.
> >
> > Sharon Lopez
> > Software Systems Programming Specialist
> > BB - IT Production Engineering - Mainframe OS
> > 3200 Beechleaf Ct Ste 200 | Raleigh, NC 27604
> > Office (919) 327-6369
> > sharon.lo...@bbandt.com<mailto:sharon.lo...@bbandt.com>
> >
> >
> >
> > The information in this transmission may contain proprietary and non-
> > public information of BB or its affiliates and may be subject to
> > protection under the law. The message is intended for the sole use of
> the
> > individual or entity to which it is addressed. If you are not the
> intended
> > recipient, you are notified that any use, distribution or copying of the
> > message is strictly prohibited. If you received this message in error,
> > please delete the material from your system without reading the content
> > and notify the sender immediately of the inadvertent transmission.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: MVS logger [-Internal-]

2019-09-30 Thread Vernooij, Kees (ITOP NM) - KLM
I found:
https://www.ibm.com/support/pages/dfhlg0777-mvs-logger-codes-x0008-x0865-dfhlog-or-dfhshunt
https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.5.0/reference/sit/dfha2_csdrecov.html

this should explain your situation.

Kees

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lopez, Sharon
> Sent: 30 September, 2019 15:27
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: MVS logger [-Internal-]
> 
> Data Classification: [-Internal-]
> Hello,
> 
> Can anyone help with this or offer any type of suggestion?  A few weeks
> ago we started getting this message in our CICS DFHLOG log streams that
> are on dasd.  We are not aware of any conditions that changed that could
> have caused this.  Thanks in advance.
> 
> +DFHLG0777 PRODAORD 338
>  A temporary error condition occurred during MVS logger operation
> IXGWRITE  for log stream PRODAORD.DFHLOG. MVS logger codes:
>  X'0008', X'0867'.
> 
> Sharon Lopez
> Software Systems Programming Specialist
> BB - IT Production Engineering - Mainframe OS
> 3200 Beechleaf Ct Ste 200 | Raleigh, NC 27604
> Office (919) 327-6369
> sharon.lo...@bbandt.com
> 
> 
> 
> The information in this transmission may contain proprietary and non-
> public information of BB or its affiliates and may be subject to
> protection under the law. The message is intended for the sole use of the
> individual or entity to which it is addressed. If you are not the intended
> recipient, you are notified that any use, distribution or copying of the
> message is strictly prohibited. If you received this message in error,
> please delete the material from your system without reading the content
> and notify the sender immediately of the inadvertent transmission.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: Tracing RACF?

2019-09-25 Thread Vernooij, Kees (ITOP NM) - KLM
We have TSS and it can tell exactly where a user gets/inherits a certain 
authorization from. Can't RACF do the same?

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Sean Gleann
> Sent: 25 September, 2019 13:06
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Tracing RACF?
> 
> Following a set of somewhat distressing events here, I discovered - the
> hard way - that our master catalog was poorly protected, and so I now have
> to fix it. The situation is that all users of the my system can create,
> read, write, update, delete files that are cataloged in the MasterCat.
> 
> The original intention was that each user-id is defined in the MCat as an
> alias that points to one of several User Catalogs, depending on the user's
> 'department' within the company. That way, user id 'X1' creates 'X1.TEST',
> and it gets cataloged in a UCAT.
> 
> So far, so good.
> 
> Now I've found that if 'X1' creates file 'TEST1', it gets cataloged in the
> MCAT. In order to prevent this, I've used existing information to act as a
> model for
> permit 'MASTERV.CATALOG' generic id(X1) access(read)
> and specified that.
> 
> Now, if user X1 tries to create 'X1.TEST', the result is a RACF
> authorisation failure.
> 
> Again, so far, so good
> 
> Taking the test a bit further though, I've now found that user X1 is
> allowed to delete file 'TEST1' from the MCat!
> 
> My conclusion so far is that X1 must be getting the required access rights
> from another user id/group/etc, but I can't see anything apposite in any
> examination I do of the RACF rules (I use output from the DBSYNC Rexx
> procedure for this).
> 
> 
> So... Can anyone spot my error and suggest a different 'permit' command,
> please?
> Alternatively, I looked at the idea of tracing RACF activity on behalf of
> a
> specific user with
> SET TRACE(USERID(X1)) - but I can't see where generated output goes to nor
> how to interrogate it. I *have* seen mention of using GTF for this
> purpose,
> along with IPCS, but my experience with both those tools is so limited
> that
> I didn't look much further in those references - skipped on past them,
> looking for other possibilities but not finding any.
> 
> Any help gratefully appreciated
> Sean
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: VIO dataset problem

2019-09-24 Thread Vernooij, Kees (ITOP NM) - KLM
Ron,

I must have been in the pre-SMS time. 
We do use SMS now.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ron Hawkins
> Sent: 24 September, 2019 9:20
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VIO dataset problem
> 
> Kees,
> 
> Possibly a redundant and risky method, given the ease and granularity of
> the DFSMS approach.
> 
> Ron
> 
> 
> RON HAWKINS
> Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
> m+61 400029610| t: +1 4085625415 | f: +1 4087912585
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Tuesday, 24 September 2019 16:32
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] VIO dataset problem
> 
> When we already ran from 3390, we kept the VIO device a 3380, in order to
> limit the amount of VIO data.
> 
> Kees.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Ron Hawkins
> > Sent: 24 September, 2019 7:52
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: VIO dataset problem
> >
> > Allen,
> >
> > I like to think that most sights would manage this with DFSMS, and
> > define a 3390 device as the VIO model.
> >
> > I'm not sure what the smallest supported device type is nowadays, but
> > the
> > 2314 disappeared as the device of choice for throttling VIO size a
> > long time ago.
> >
> > Having one track geometry makes life easier, even with SDB.
> >
> >
> > RON HAWKINS
> > Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
> > m+61 400029610| t: +1 4085625415 | f: +1 4087912585
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Allan Staller
> > Sent: Monday, 23 September 2019 22:35
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [IBM-MAIN] VIO dataset problem
> >
> > Typically, the vio default (installation set) is much smaller than the
> > max. The OP might investigate the size of the specific files involved.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Steve Thompson
> > Sent: Saturday, September 21, 2019 10:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: VIO dataset problem
> >
> > If I remember correctly, the limit for a VIO Data set is 65535 tracks.
> >
> > Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr.
> > Expct mistaks
> >
> >
> > > On Sep 21, 2019, at 9:22 PM, Shivang Sharma 
> wrote:
> > >
> > > Hi ,
> > >
> > > We are not storage constraint . We hardly page .The idea behind
> > > using
> > VIO is to reduce hard I/O for BDAM . When you say the file size is
> > excessive is there a limit ? Job is not looping that's for sure .
> > >
> > > Thanks
> > >
> > > 
> > > -- 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
> > ::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
> 

Re: VIO dataset problem

2019-09-24 Thread Vernooij, Kees (ITOP NM) - KLM
When we already ran from 3390, we kept the VIO device a 3380, in order to limit 
the amount of VIO data.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ron Hawkins
> Sent: 24 September, 2019 7:52
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VIO dataset problem
> 
> Allen,
> 
> I like to think that most sights would manage this with DFSMS, and define
> a 3390 device as the VIO model.
> 
> I'm not sure what the smallest supported device type is nowadays, but the
> 2314 disappeared as the device of choice for throttling VIO size a long
> time ago.
> 
> Having one track geometry makes life easier, even with SDB.
> 
> 
> RON HAWKINS
> Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
> m+61 400029610| t: +1 4085625415 | f: +1 4087912585
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Allan Staller
> Sent: Monday, 23 September 2019 22:35
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] VIO dataset problem
> 
> Typically, the vio default (installation set) is much smaller than the
> max. The OP might investigate the size of the specific files involved.
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Steve Thompson
> Sent: Saturday, September 21, 2019 10:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VIO dataset problem
> 
> If I remember correctly, the limit for a VIO Data set is 65535 tracks.
> 
> Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr.
> Expct mistaks
> 
> 
> > On Sep 21, 2019, at 9:22 PM, Shivang Sharma  wrote:
> >
> > Hi ,
> >
> > We are not storage constraint . We hardly page .The idea behind using
> VIO is to reduce hard I/O for BDAM . When you say the file size is
> excessive is there a limit ? Job is not looping that's for sure .
> >
> > Thanks
> >
> > --
> > 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
> ::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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




Re: [EXT] Re: VIO dataset problem

2019-09-24 Thread Vernooij, Kees (ITOP NM) - KLM
Jim,

It is obvious that pages must be paged out for Journaling, but must they also 
be paged in, can't they be reclaimed when plenty memory is available?

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jim Mulder
> Sent: 23 September, 2019 18:00
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXT] Re: VIO dataset problem
> 
>  The purpose of journaling is to allow a job to be restarted.
> 
>   In order to restart a job which is using VIO, the VIO data sets need
> to be preserved.
> 
>  In order for the VIO data sets to be preserved, they must be written
> out to page data sets,  Real storage owned by a job is not
> preserved.
> 
>   The system is behaving exactly as intended.  If your job does not
> require restart capability, you should run it in a job class which is
> defined with JOURNAL=NO.
> 
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> Poughkeepsie NY
> 
> 
> David Betten/Gaithersburg/IBM@IBMUS wrote on 09/23/2019 11:15:05 AM:
> 
> > From: David Betten/Gaithersburg/IBM@IBMUS
> > To: ibm-main@listserv.ua.edu
> > Date: 09/23/2019 11:53 AM
> > Subject: Re: [EXT] Re: VIO dataset problem
> >
> > Just for clarification, I've been working with Shivang on this and he's
> > since opened a PMR on the problem.  When his job uses VIO even for a
> very
> > small file, it automatically pages out for the writes and pages in for
> the
> > reads.   With RMF we clearly see there is plenty of available memory.
> > We've since tied this to the use of journaling (JOURNAL=YES specified
> for
> > the job class).  Without journalling, the same job does no VIO paging.
> > We'll let the normal support process play out and post back the eventual
> > determination of what's causing this.
> >
> >
> > Have a nice day,
> > Dave Betten
> > z/OS Performance Specialist
> > Cloud and Systems Performance
> > IBM Corporation
> > email:  bet...@us.ibm.com
> >
> > IBM Mainframe Discussion List  wrote on
> > 09/23/2019 09:58:15 AM:
> >
> > > From: "Mullen, Patrick" 
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Date: 09/23/2019 10:03 AM
> > > Subject: [EXTERNAL] Re: [EXT] Re: VIO dataset problem
> > > Sent by: IBM Mainframe Discussion List 
> > >
> > > I've heard "my job is paged out" when what is meant is "my job is
> > > swapped out", perhaps this is the OP's situation.
> > >
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Ron Hawkins
> > > Sent: Sunday, September 22, 2019 7:39 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: [EXT] Re: VIO dataset problem
> > >
> > > Shivang,
> > >
> > > My first thought is you have not described a problem. Page outs are
> > > a response to memory conditions, but they don't slow anything down.
> > > Page-ins and the page-in rate for all address are indications of a
> > > potential problem, and you do not mention page-ins.
> > >
> > > You said you are no memory constrained, but how are you verifying
> > > that? You can check AFQ and UIC values during the interval when you
> > > saw the page-outs happening. SMF Type 71 is usually the starting
> > > place for looking for memory contention, especially the page-in rate.
> > >
> > > Is there a resource class limit on the service class for these jobs?
> > >
> > >
> > >
> > > RON HAWKINS
> > > Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
> > > m+61 400029610| t: +1 4085625415 | f: +1 4087912585
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Shivang Sharma
> > > Sent: Sunday, 22 September 2019 19:47
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: [IBM-MAIN] VIO dataset problem
> > >
> > > Hi,
> > >
> > > My dataset is less the max limit . VIO has support for BDAM as well.
> > > Not sure on what is left to check?
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is 

Re: ZEKE - ZENA

2019-09-24 Thread Vernooij, Kees (ITOP NM) - KLM
Since you mention z/OS in your question, this is a correct place. This a 
generous forum of technical people, eager to dive into almost any technical 
problem.
However, I can't help you further.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nai, Dean
> Sent: 23 September, 2019 20:36
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ZEKE - ZENA
> 
> Not sure if this is just for IBM related products but I'll ask the
> question anyway. We are converting over 2000 jobs from ZEKE on Z/OS to
> ZENA on a ZLINUX box. Anyone go through this process and if so any tips or
> scripts to accomplish this that they know of? Thanks in advance for your
> thoughts:)
> 
> 
> Dean Nai
> 
> 
> 
> 
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: VIO dataset problem

2019-09-23 Thread Vernooij, Kees (ITOP NM) - KLM
IIRC, the limit of a VIO dataset is the size of the emulated Dasd volume.
Non-extended datasets also have the limit of 65535 tracks.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Thompson
> Sent: 22 September, 2019 5:16
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VIO dataset problem
> 
> If I remember correctly, the limit for a VIO Data set is 65535 tracks.
> 
> Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr.
> Expct mistaks
> 
> 
> > On Sep 21, 2019, at 9:22 PM, Shivang Sharma  wrote:
> >
> > Hi ,
> >
> > We are not storage constraint . We hardly page .The idea behind using
> VIO is to reduce hard I/O for BDAM . When you say the file size is
> excessive is there a limit ? Job is not looping that's for sure .
> >
> > Thanks
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Can you update WLM via a batch program?

2019-09-23 Thread Vernooij, Kees (ITOP NM) - KLM
When I had to add a large amount of Scheduling Environments, I created a 
macro/script for my terminal emulator and let it run for more than an hour to 
do the 'manual' work. It takes some time to create it, but when you have it 
running, it does its work without typo's, which is what I cannot gurarantee for 
real manual work.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jim Horne
> Sent: 16 September, 2019 18:41
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Can you update WLM via a batch program?
> 
> Like many of you I suspect, I sometimes want to make changes to WLM that
> would be so easy if I could put everything into a batch job and submit it
> to update my policy.  I get especially frustrated when I want to create
> report classes for something like DDF, CICS or WAS transactions.  I can
> design everything, get all the names the way I want - but then, instead of
> being able to submit a batch job and verify it did what I wanted, I have
> to go into ISPF and enter everything by hand, one line at a time.
> 
> Does anyone know of a way to make this easier?  zOSMF WLM management seems
> to take the same issue and only change where you perform the data entry by
> hand.
> 
> Thanks in advance,
> Jim Horne
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: APAR OA56180 / RUCSA

2019-09-12 Thread Vernooij, Kees (ITOP NM) - KLM
My colleague found out, but he is not in, so I cannot ask hem where.
The charge is MSU dependent and for our situation quite acceptable.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dana Mitchell
> Sent: 12 September, 2019 16:05
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APAR OA56180 / RUCSA
> 
> If you absolutely cannot change the application or ISV that insists on
> key8 csa, implement RUCSA you can at least control what users have access
> to it,  although not necessarily preventing one authorized RUCSA user from
> accessing another's storage.
> 
> Does anyone know what the charge is going to be for RUCSA?
> 
> Dana
> 
> On Thu, 12 Sep 2019 08:35:19 -0400, Steve Smith  wrote:
> 
> >You ignored the context of my statement, and your response doesn't
> address
> >it. I don't see much added value of a new and complicated way of
> bypassing
> >the restriction, when there was already a nice simple way.  While it may
> be
> >intended for particular customers, the "feature" is public.  And while
> it's
> >common knowledge big customers tend to get what they want, I'm not clear
> >why RUCSA is what they wanted (vs. the parm).
> >
> >Regardless, I'm only idly curious, this has no effect on my business.
> >
> >sas
> >
> >On Wed, Sep 11, 2019 at 5:48 PM Mark Zelden  wrote:
> >
> >> On Tue, 10 Sep 2019 12:06:59 -0400, Steve Smith 
> wrote:
> >>
> >>
> >> > So, I'm not sure why
> >> >IBM is going to all this trouble to ban it, then unban it a little
> bit.
> >> >
> >>
> >> I think I alluded to it in my OP and IBM also responded that it was for
> "a
> >> particular set
> >> of customers".  It wasn't because IBM thought "hey, this sounds like a
> >> good idea" and
> >> did all the development work to take a step backwards.
> >>
> >> Big customers paying IBM big money have big voices.  It may have just
> been
> >> one big
> >> customer, who knows (other than IBM).
> >>
> >> Regards,
> >>
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Erase On Scratch

2019-09-11 Thread Vernooij, Kees (ITOP NM) - KLM
Ron,

Was EOS intended for disks that are removed to make sure they contain no 
valuable data or was it intended to prevent deleted data from being read again 
by another application? I thought the latter. Disks are usually removed because 
they break down, with valuable, undeleted data on them.

Does you proposal cover dumping a disk with DFdss/FDR and searching the tape 
for interesting data?

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ron Hawkins
> Sent: 11 September, 2019 3:54
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Erase On Scratch
> 
> Larre,
> 
> EOS operates on the basis that you overwrite the only location where the
> data has existed on the backend media in your storage. That's was an
> outdated concept back in the Iceberg/RVA days, and has become even more so
> with in-system and remote replication, load balancing and migration with
> thin provisioning, and write levelling in flash storage.
> 
> The reality of EOS is it is a dead concept for data at rest, and vendors
> are providing encryption and erasure processing to scrub media before
> removing it. I see the only goal of EOS as making the contents of the data
> set unavailable to z/OS, which does not require overwriting all the
> contents of the data set.
> 
> With that in mind, I suggest that an option for EOS that nerfs HAR0 to an
> empty track, and leave it that. I believe all three vendors now keep HAR0
> in a table with good locality of reference, so from the storage
> perspective this would be very efficient. It also eliminates the often
> huge amount of data transfer required to overwrite the old data, for the
> same resulting security from the host, which in turns reduces the latency
> of EOS when you delete a dataset. In all cases the data transfer reduction
> would flow on to replication.
> 
> Move out of the past, and stop fooling ourselves that EOS is erasing
> anything, and optimise it to obfuscate the data from CKD host only, as
> that is all it is doing anyway.
> 
> 
> RON HAWKINS
> Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
> m+61 400029610| t: +1 4085625415 | f: +1 4087912585
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Larre Shiller
> Sent: Wednesday, 11 September 2019 04:11
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] Erase On Scratch
> 
> Starting with z/OS 2.1 and continuing with z/OS 2.2, IBM has improved the
> performance of the Erase-On-Scratch (EOS) function over the pre-z/OS 2.1
> releases by increasing the number of tracks that can be "erased" in each
> channel program from 1 to 255 to 12,240.  The good news is that with those
> changes (on the software side) there was a drastic reduction in both
> elapsed time as well as an I/O count reduction, but these I/O operations
> are asynchronous and as such, most customers are concerned about suffering
> the performance hit that it takes to implement EOS, especially with
> replicated DASD.  IBM believes that there is a lot of latent interest in
> using this function, but most customers are simply not using it because of
> the potential performance impact, including myself.  And even if customers
> are using it, they are using it only for a subset of data sets.  IBM would
> like to drive the use Erase-On-Scratch use up and get most, if not all
> customers using it because of the security exposure that exists and that
> IBM would like to eliminate.
> 
> IBM has been having some internal discussions about improvements that
> revolve around a combination of hardware/microcode and z/OS software
> changes that, if implemented in z/OS and the DASD subsystem, would bring
> the overhead of using EOS down to the point where the overhead would not
> be noticed.
> 
> But... the folks involved in bringing that to market need our help.
> There's an RFE that we can vote for that would show the level of interest
> in this function.  If your Auditors or internal security folks are
> concerned about residual data on DASD and would like to see you using EOS
> but you are concerned about the overhead, please consider voting for the
> following enhancement to help bring this new functionality to market:
> 
> https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=1340
> 47
> 
> Thanks!
> 
> Larre Shiller
> US Social Security Administration
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain 

Re: APAR OA56180 / RUCSA

2019-09-10 Thread Vernooij, Kees (ITOP NM) - KLM
Compared to what was, access is now limited to the members of a  restricted 
club, accessing a restricted part of CSA. 
The club administration can select trusted members for the club. I think this 
is quite acceptable.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Martin Packer
> Sent: 10 September, 2019 9:55
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APAR OA56180 / RUCSA
> 
> Up to a point:
> 
> If you are enabled to use User-Key CSA via RUCSA I believe you "have a
> ticket to THE party", the ONE AND ONLY party. Meaning you can access other
> users' allocations of User Key CSA.
> 
> Someone correct me if I've got this wrong.
> 
> If I'm right auditors might not be quite so happy.
> 
> Thanks, Martin
> 
> Martin Packer
> 
> zChampion, Systems Investigator & Performance Troubleshooter, IBM
> 
> +44-7802-245-584
> 
> email: martin_pac...@uk.ibm.com
> 
> Twitter / Facebook IDs: MartinPacker
> 
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
> 
> Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or
> 
> https://itunes.apple.com/gb/podcast/mainframe-performance-
> topics/id1127943573?mt=2
> 
> 
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
> 
> 
> 
> From:   "Vernooij, Kees (ITOP NM) - KLM" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   10/09/2019 08:37
> Subject:Re: APAR OA56180 / RUCSA
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> I think security auditors should be happy, provided they have done their
> homework.
> CSA was wide open to everybody since the beginning, the option to close
> the gate (userkeycsa(no)) is available for a decade already and now the
> gate can be controlled in detail.
> 
> Kees.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Paul Gilmartin
> > Sent: 09 September, 2019 21:21
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: APAR OA56180 / RUCSA
> >
> > On Mon, 9 Sep 2019 13:19:40 -0400, Tom Conley wrote:
> >
> > >On 9/9/2019 1:04 PM, Mark Zelden wrote:
> > >> On Mon, 9 Sep 2019 07:55:29 -0500, Peter Fatzinger wrote:
> > >>
> > >>>   The 1M increment for RUCSA storage was not chosen haphazardly.  We
> > understand the scarcity of below-the-line memory, but in order to
> provide
> > the isolation needed to adequately protect the area we couldn't use any
> > increment smaller than 1M.
> > >>
> > >> I pretty much assumed that, but thanks for the confirmation.
> > >>
> > >>>   Also, in case anyone is unaware, beginning in z/OS V2R4 RUCSA is a
> > separately ordered paid feature.
> > >
> > >Youse wants to break da rules, youse gotta pay.
> > >
> > How might security auditors look at RUCSA which:
> >
> >
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2
> > r3.ieae100/ieae1-rucsa.htm
> > Accessible only from address spaces that are running under user IDs
> > that have
> > SAF READ authority to the IARRSM.RUCSA profile in the FACILITY
> class,
> > or
> > on z/OS(r) V2R3 or earlier systems that have the VSM
> > ALLOWUSERKEYCSA(YES)
> > parameter specified
> >
> > I suppose it depends on the breadth of the exposure.
> >
> > This is vaguely similar to the changes introduced by IO11698:  IBM found
> > it
> > impractical to make the facility secure so they wrapped it with SAF so
> the
> > onus can be placed on the customer.
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.klm.com=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-
> WOWZjlZ0NwmcFSpQCLphNznBSDQ=6Vh6B4IO9HnM8cMs55Vw5QY7Q0pcsq9sd3OqA2UDMu8&
> s=tDEyoxIOWwL4a9MCwt9GvM-X80I5rNFskT6bOxgCiLk=
> . This e-mail and any attachment may contain confidential and privileged
> material intended for the addressee only. If you are not the addressee,
> you are notified that no part of the e-mail or any attachment may be
> disclosed, copied or distributed, and that any other action related t

Re: APAR OA56180 / RUCSA

2019-09-10 Thread Vernooij, Kees (ITOP NM) - KLM
I think security auditors should be happy, provided they have done their 
homework.
CSA was wide open to everybody since the beginning, the option to close the 
gate (userkeycsa(no)) is available for a decade already and now the gate can be 
controlled in detail. 

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: 09 September, 2019 21:21
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: APAR OA56180 / RUCSA
> 
> On Mon, 9 Sep 2019 13:19:40 -0400, Tom Conley wrote:
> 
> >On 9/9/2019 1:04 PM, Mark Zelden wrote:
> >> On Mon, 9 Sep 2019 07:55:29 -0500, Peter Fatzinger wrote:
> >>
> >>>   The 1M increment for RUCSA storage was not chosen haphazardly.  We
> understand the scarcity of below-the-line memory, but in order to provide
> the isolation needed to adequately protect the area we couldn't use any
> increment smaller than 1M.
> >>
> >> I pretty much assumed that, but thanks for the confirmation.
> >>
> >>>   Also, in case anyone is unaware, beginning in z/OS V2R4 RUCSA is a
> separately ordered paid feature.
> >
> >Youse wants to break da rules, youse gotta pay.
> >
> How might security auditors look at RUCSA which:
> 
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2
> r3.ieae100/ieae1-rucsa.htm
> Accessible only from address spaces that are running under user IDs
> that have
> SAF READ authority to the IARRSM.RUCSA profile in the FACILITY class,
> or
> on z/OS® V2R3 or earlier systems that have the VSM
> ALLOWUSERKEYCSA(YES)
> parameter specified
> 
> I suppose it depends on the breadth of the exposure.
> 
> This is vaguely similar to the changes introduced by IO11698:  IBM found
> it
> impractical to make the facility secure so they wrapped it with SAF so the
> onus can be placed on the customer.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: z/OS 2.1 to 2.4 [EXTERNAL]

2019-09-09 Thread Vernooij, Kees (ITOP NM) - KLM
Until Jan 27 2020.
https://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/8/897/ENUS919-038/index.html=en_locale=en


Kees

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dana Mitchell
> Sent: 06 September, 2019 16:28
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4 [EXTERNAL]
> 
> Does anyone know for sure how long V2R3 will remain orderable?   My guess
> would be end of September 2019 when 2.4 goes GA?
> 
> Sorry, my question was sort of buried underneath a previous reply.
> 
> Dana
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Using COBOL on ZIIP via SRB etc

2019-09-06 Thread Vernooij, Kees (ITOP NM) - KLM
Playing LPs backwards, revealed many things, a.o. "Paul is dead".

Kees

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Chris Hoelscher
> Sent: 06 September, 2019 15:31
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Using COBOL on ZIIP via SRB etc
> 
> If you play this email backwards you will hear:
> 
> Burn Neon, dead man ... Burn Neon, dead man
> 
> Thank You,
> Chris Hoelscher| Lead Database Administrator | IBM Global Technical
> Services| T 502.476.2538  or 502.407.7266
> 
> -Original Message-----
> From: IBM Mainframe Discussion List  On Behalf
> Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Friday, September 6, 2019 8:59 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Using COBOL on ZIIP via SRB etc
> 
> Check the story of IBM vs Neon Software.
> 
> Kees.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Steve Smith
> > Sent: 06 September, 2019 14:52
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Using COBOL on ZIIP via SRB etc
> >
> > Well, if you can get your COBOL to run in an SRB successfully, you've
> > established that it could run on a zIIP.  But it's not at all
> > "automatic", and you have to know the secrets to make that happen.
> > Which IBM only reveals under cover of an NDA, so they're the only
> > legitimate source.  But first you'd have to convince them your usage
> > is "legitimate" by their rules.
> >
> > sas
> >
> > On Fri, Sep 6, 2019 at 6:24 AM Gerry Anstey <
> > 00da33bf43f1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Yes, I thought as much but the method does seem to be there to code
> > > so I was a little puzzled as to how the restrictions are enforced.
> > >
> > > 
> > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO
> > > IBM-MAIN
> > >
> >
> >
> > --
> > sas
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.c
> omdata=02%7C01%7Cchoelscher%40humana.com%7C3b77187d6e4b4cb7431e08d732
> cd9d4b%7C56c62bbe85984b859e511ca753fa50f2%7C1%7C0%7C637033731007109938
> ;sdata=grig8vJy7%2BUsaFP5pZd%2FysaZlRzd92q4cBbHcFS8Hy4%3Dreserved=0.
> This e-mail and any attachment may contain confidential and privileged
> material intended for the addressee only. If you are not the addressee,
> you are notified that no part of the e-mail or any attachment may be
> disclosed, copied or distributed, and that any other action related to
> this e-mail or attachment is strictly prohibited, and may be unlawful. If
> you have received this e-mail by error, please notify the sender
> immediately by return e-mail, and delete this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in
> receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> 
> 
> 
> --
> 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, sex,
> sexual orientation, gender identity, or religion. Humana Inc. and its
> subsidiaries do not
> exclude people or treat them differently because of race, color, national
> origin, age,
> disability, sex

Re: Using COBOL on ZIIP via SRB etc

2019-09-06 Thread Vernooij, Kees (ITOP NM) - KLM
Check the story of IBM vs Neon Software.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Smith
> Sent: 06 September, 2019 14:52
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Using COBOL on ZIIP via SRB etc
> 
> Well, if you can get your COBOL to run in an SRB successfully, you've
> established that it could run on a zIIP.  But it's not at all "automatic",
> and you have to know the secrets to make that happen.  Which IBM only
> reveals under cover of an NDA, so they're the only legitimate source.  But
> first you'd have to convince them your usage is "legitimate" by their
> rules.
> 
> sas
> 
> On Fri, Sep 6, 2019 at 6:24 AM Gerry Anstey <
> 00da33bf43f1-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > Yes, I thought as much but the method does seem to be there to code so I
> > was a little puzzled as to how the restrictions are enforced.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> 
> 
> --
> sas
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: Migration from z114 to z14ZR1, CF structure sizes

2019-09-06 Thread Vernooij, Kees (ITOP NM) - KLM
What is the source of these figures? In my experience many CF level upgrades 
did not require a structure increment and others had specific requirements. 
E.g. add nn MBs i.s.o. increment by nn %.
75% is a guess and in my opinion too much.

We are at level 21 now. If my docs are reliable, the last increase required by 
CF level was at level 15.
So if level 22 does not require a structure increase, level 17 structures are 
probably OK.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Mike Schwab
> Sent: 06 September, 2019 14:34
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Migration from z114 to z14ZR1, CF structure sizes
> 
> I would multiply.  Example 1.1 * 1.2 * 1.1 * 1.1 * 1.1 = 1.75692
> instead of 1.6 by addition.
> 
> On Fri, Sep 6, 2019 at 12:17 PM Vernooij, Kees (ITOP NM) - KLM
>  wrote:
> >
> > You can ask IBM for the information about CF levels 18 - 22. If
> structure sizes need to be increased during a CF level upgrade, this is
> documented with the CF level. Add up the increments and you have a good
> estimate of the Level 22 sizes.
> >
> > Kees.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> > > Behalf Of Juergen Kehr
> > > Sent: 06 September, 2019 13:47
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Migration from z114 to z14ZR1, CF structure sizes
> > >
> > > Hello,
> > >
> > > we’re planning a migration from our z114 to a z14ZR1, therefore we
> have to
> > > bring our CF policy from one which supports CFLEVEL=17 to one for
> > > CFLEVEL=22.
> > >
> > > Because of hardware dependencies there is no way to have a z/OS system
> > > which has one CF with the old CFLEVEL and one with the new CFLEVEL up
> and
> > > running. On the old z114 one we could attach the old CF, on the z14ZR1
> on
> > > the new one. But as far as we understand this would be a requirement
> for
> > > using the SIZER tool (see CFSizer alternate sizing methods:
> > > https://www.ibm.com/support/pages/cfsizer-alternate-sizing-
> techniques).
> > >
> > > Using  CFSizer in our case would be fairly complicate, because we
> don’t
> > > know the input values used in former CFSizer runs to lead to the
> existing
> > > values in our policy. Furthermore we can’t reproduce this, because
> CFSizer
> > > only supports the current CFLEVEL=23, so we can’t try to reproduce the
> old
> > > input values for CFLEVEL=17 via looking to the results they produce.
> > >
> > > So we urgently would need any good idea, how to get the new structure
> size
> > > values when migrating from CFLEVEL=17 to CFLEVEL=22.
> > >
> > > Thanks in advance for any help.
> > >
> > > Kind regards.
> > > Juergen Kehr
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > 
> > For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and
> may be unlawful. If you have received this e-mail by error, please notify
> the sender immediately by return e-mail, and delete this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> its employees shall not be liable for the incorrect or incomplete
> transmission of this e-mail or any attachments, nor responsible for any
> delay in receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> > 
> >
> >
> > --
> > 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?
&

Re: Migration from z114 to z14ZR1, CF structure sizes

2019-09-06 Thread Vernooij, Kees (ITOP NM) - KLM
You can ask IBM for the information about CF levels 18 - 22. If structure sizes 
need to be increased during a CF level upgrade, this is documented with the CF 
level. Add up the increments and you have a good estimate of the Level 22 sizes.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Juergen Kehr
> Sent: 06 September, 2019 13:47
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Migration from z114 to z14ZR1, CF structure sizes
> 
> Hello,
> 
> we’re planning a migration from our z114 to a z14ZR1, therefore we have to
> bring our CF policy from one which supports CFLEVEL=17 to one for
> CFLEVEL=22.
> 
> Because of hardware dependencies there is no way to have a z/OS system
> which has one CF with the old CFLEVEL and one with the new CFLEVEL up and
> running. On the old z114 one we could attach the old CF, on the z14ZR1 on
> the new one. But as far as we understand this would be a requirement for
> using the SIZER tool (see CFSizer alternate sizing methods:
> https://www.ibm.com/support/pages/cfsizer-alternate-sizing-techniques).
> 
> Using  CFSizer in our case would be fairly complicate, because we don’t
> know the input values used in former CFSizer runs to lead to the existing
> values in our policy. Furthermore we can’t reproduce this, because CFSizer
> only supports the current CFLEVEL=23, so we can’t try to reproduce the old
> input values for CFLEVEL=17 via looking to the results they produce.
> 
> So we urgently would need any good idea, how to get the new structure size
> values when migrating from CFLEVEL=17 to CFLEVEL=22.
> 
> Thanks in advance for any help.
> 
> Kind regards.
> Juergen Kehr
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: MPF Exit calling System REXX - S0C4 abend

2019-09-06 Thread Vernooij, Kees (ITOP NM) - KLM
Possible, but still this must run serialized, so both exits cannot run together 
and modify each other's view of the message.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Sebastian Welton
> Sent: 06 September, 2019 11:49
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: MPF Exit calling System REXX - S0C4 abend
> 
> For some reason, the message being trapped was also defined in EDGRMM with
> the MNTMSG command which if I understand the manual correctly, updates the
> message so presumably it must be intercepting the message at some point to
> make the changes.
> 
> Seb.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: MPF Exit calling System REXX - S0C4 abend

2019-09-06 Thread Vernooij, Kees (ITOP NM) - KLM
Yes, and as s consequence, if he does not receive an 0C4, he will probably be 
clearing someone else's storage.

however the relation with 'the other subsystem' is also interesting.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Binyamin Dissen
> Sent: 06 September, 2019 11:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: MPF Exit calling System REXX - S0C4 abend
> 
> Actually, you are incorrect.
> 
> The code is modifying storage beyond its area. Depending on how storage is
> set
> up, it is possible that the area will be on a page that is resolvable or
> not.
> 
> On Fri, 6 Sep 2019 04:08:37 -0500 Sebastian Welton 
> wrote:
> 
> :>Thanks to everyone who responded and although he tried out all the
> options provided, nothing actually worked however it looks like it is
> working now. The first step was to implement the original it was based
> upon from the Redbook and that worked fine out of the box. I then looked
> at what messages he was processing via MPF and saw a couple that looked
> familiar as being used by another subsystem which also 'traps' messages.
> Once I removed the startup of the STC and all references to it in PARMLIB
> (IEFSSN in particular), no more abends occurred. So it basically wasn't
> the fault of the code (apparently he has coded MPF exits before, just
> wanted to try a different method and to use System REXX) but the
> interaction with other subsystems. Personally I could have done this with
> System Automation in a couple of minutes but this is a good learning curve
> for both of us in particular during the investigation. Once again, many
> thanks to everyone who took the time and effort to reply, it
>   was
> much
> :>appreciated and did help in furthering our education (particularly me.)
> :>
> :>Seb.
> :>
> :>--
> :>For IBM-MAIN subscribe / signoff / archive access instructions,
> :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
> 
> Director, Dissen Software, Bar & Grill - Israel
> 
> 
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
> 
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: MPF Exit calling System REXX - S0C4 abend

2019-09-06 Thread Vernooij, Kees (ITOP NM) - KLM
Interesting twist in the problem.

Good to know how you eliminated the problem, but as a real sysprog I am curious 
what the cause of the problem was. How could the other subsystem interfere with 
the MPF exit? How does it 'trap' the message? It looks like it is not 
serialized with the MPF exit, so it could change things, while the MPF exit was 
working on it.
Can you give a clue?

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Sebastian Welton
> Sent: 06 September, 2019 11:09
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: MPF Exit calling System REXX - S0C4 abend
> 
> Thanks to everyone who responded and although he tried out all the options
> provided, nothing actually worked however it looks like it is working now.
> The first step was to implement the original it was based upon from the
> Redbook and that worked fine out of the box. I then looked at what
> messages he was processing via MPF and saw a couple that looked familiar
> as being used by another subsystem which also 'traps' messages. Once I
> removed the startup of the STC and all references to it in PARMLIB (IEFSSN
> in particular), no more abends occurred. So it basically wasn't the fault
> of the code (apparently he has coded MPF exits before, just wanted to try
> a different method and to use System REXX) but the interaction with other
> subsystems. Personally I could have done this with System Automation in a
> couple of minutes but this is a good learning curve for both of us in
> particular during the investigation. Once again, many thanks to everyone
> who took the time and effort to reply, it was much appreciated and did
> help in furthering our education (particularly me.)
> 
> Seb.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


Re: MPF Exit calling System REXX - S0C4 abend

2019-09-05 Thread Vernooij, Kees (ITOP NM) - KLM
The offset in the module is 0DA. In your assembler listing you can see which 
instruction it is.
The failing instruction is 4110 D088: LA R1,136(R13)
This is loading the address of a fullword at +136 the workarea. The savearea 
goes to +132, so this is @ARGLST.
Not exactly a reason for a 0C4. Do you have the register values of the abend, 
especially R13?

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Sebastian Welton
> Sent: 05 September, 2019 15:21
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: MPF Exit calling System REXX - S0C4 abend
> 
> Definitely, see below (formatting is probably stuffed I'm afraid),
> compiled using the standard ASMAC found in PROCLIB (no overriding ASMAOPT
> or other parameters) and link with RENT, INCLUDE(ASMAOBJ) and SETCODE
> AC(0). I have now found out where the original came from and am doing
> further research on it as well, thanks.
> 
> Sebastian.
> 
> GENMSGTR TITLE 'GENMSGTR'
> GENMSGTR CSECT
> GENMSGTR RMODE 31
> GENMSGTR AMODE ANY
> R0   EQU   0   REGISTER 0
> R1   EQU   1   REGISTER 1
> R2   EQU   2   REGISTER 2
> R3   EQU   3   REGISTER 3
> R4   EQU   4   REGISTER 4
> R5   EQU   5   REGISTER 5
> R6   EQU   6   REGISTER 6
> R7   EQU   7   REGISTER 7
> R8   EQU   8   REGISTER 8
> R9   EQU   9   REGISTER 9
> R10  EQU   10  REGISTER 10
> R11  EQU   11  REGISTER 11
> R12  EQU   12  REGISTER 12
> R13  EQU   13  REGISTER 13
> R14  EQU   14  REGISTER 14
> R15  EQU   15  REGISTER 15
>  STM   R14,R12,12(R13) SAVE CALLERS REGS
>  USING GENMSGTR,R12ADDRESSABILITY
>  LRR12,R15 SET BASE ADDRESS
>  LRR2,R1   SAVE PARAMETER REGISTER
>  L R1,=A(@DSECTE-@DSECT)   CALCULATE STORAGE LENGTH
>  STORAGE OBTAIN,LENGTH=(R1)GET SOME VS
>  STR1,8(,R13)  FORWARD POINTER
>  STR13,4(,R1)  BACKWARD POINTER
>  LRR13,R1  POINT TO SAVE AREA
>  LRR1,R2   RESTORE PARAMETER REGISTER
>  B EYEBALLESKIP CONSTANTS
> EYEBALL  DS0H
>  DCC'=> GENMSGTR D= T= ROB '
> EYEBALLE DS0H
>  USING @DSECT,R13  ADDRESSABILITY
>  SRR11,R11 CLEAR RETURN CODE
> *
>  L R9,0(,R1)   POINT TO CTXT
>  USING CTXT,R9 ADDRESSABILITY
>  L R8,CTXTTXPN WAS THERE A MESSAGE?
>  LTR   R8,R8   SINGLE OR FIRST LINE WTO?
>  BNZ   RETURN  NO - EXIT
>  L R8,CTXTTXPJ POINT TO MAJOR
>  USING CTXTATTR,R8 ADDRESSABILITY
>  LAR7,@ARGLST  POINT TO AXREXX ARG LIST
>  USING AXRARGLST,R7ADDRESSABILITY
>  MVI   @ARGLST,X'00'
>  MVC   @ARGLST+1(AXRARGLST_LEN),@ARGLST
>  MVC   AXRARGLSTID,=A(AXRARGLSTACRO) MOVE IN EYECATCHER
>  LAR1,AXRARGLSTCURVER  VERSION 0
>  STR1,AXRARGLSTVER SAVE VERSION
>  LAR1,1SINGLE ARGUMENT
>  STH   R1,AXRARGLSTNUMBER  SAVE NUMBER OF ARGUMENTS
>  SLR   R1,R1   CLEAR ERROR FLAG
>  STH   R1,AXRARGLSTENTRYINERROR SAVE ERROR FLAG
>  STR1,AXRARGLSTRSV2SAVE RESERVED VALUE
>  LAR6,@ARG1POINT TO ARGUMENT 1
>  USING AXRARGENTRY,R6  ADDRESSABILITY
>  MVI   @ARG1,X'00'
>  MVC   @ARG1+1(AXRARGENTRY_LEN),@ARG1
>  SLR   R1,R1   CLEAR ADDRESS HIGH
>  STR1,AXRARGADDRHIGH   SAVE ADDRESS HIGH
>  LAR1,CTXTTMSG POINT TO WTO
>  STR1,AXRARGADDRLOWSAVE ADDRESS
>  LAR1,L'CTXTTMSG   POINT TO LENGTH OF WTO
>  STR1,AXRARGLENGTH SAVE LENGTH
>  MVI   AXRARGTYPE,AXRARGTYPECHAR SET ARGUMENT TYPE TO CHAR
>  OIAXRARGINPUTFLGS1,AXRARGINPUT FLAG INPUT ARGUMENT
>  AXREXX REQUEST=EXECUTE,   X
>SECURITY=BYAXRUSER, X
>TSO=YES,X
>SYNC=NO,X
>NAME=VNAME, X
>REXXARGS=@ARGLST,   X
>MF=(E,AXREXXL)  

Re: Assembler :- PC Instruction

2019-08-30 Thread Vernooij, Kees (ITOP NM) - KLM
Peter,
Ok, than I misunderstood what was or could be put into the PC microcode.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Relson
> Sent: 30 August, 2019 14:25
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Assembler :- PC Instruction
> 
> 
> From what I understood of the PC instruction: with 1 instruction you can
> now execute a 'function' that might have taken pages of assembler
> instructions before.
> 
> 
> I'm not sure where this thought comes from. The PC instruction is not
> magic. It does not execute a "function" beyond the function of the
> instruction itself.
> It passes control somewhere, may change state, may create an entry on the
> linkage stack.
> 
> 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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


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


Re: z/OS 2.1 to 2.4

2019-08-30 Thread Vernooij, Kees (ITOP NM) - KLM
Yes, then it is the end for this application. 
But from your description I understand that there must be more customers who 
will have the 2.4 problem. Is this still no reason for the company to start 
converting to the current standards?

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: 30 August, 2019 13:18
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> Well, my excitement was short-lived.In the text of OA56180 I read:
> 
> Note: This APAR only applies to user key CSA storage.  Both
>   user key (8-15) SCOPE=COMMON data spaces and the usage of
>   the CHANGKEY service to change the storage key of common
>   storage to a key of 8-15 are not affected by this APAR,
>   and will no longer be supported after z/OS V2R3.
> 
> 
> Sadly, this application is creating UserKey Common data space and using it
> as a high-perf "data base" within the application for their batch jobs.
> I've known about it since IBM enabled reporting via SMF30 records.
> 
> __
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
> 
> 
> 
> -----Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Friday, August 30, 2019 7:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> **CAUTION EXTERNAL EMAIL**
> 
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
> 
> It does, because 2.4 does not support userkeycsa(yes) anymore. It is also
> discussed in the 2.4 migration guide.
> 
> It seems to me the feature will stay, because IBM has fulfilled its goal
> to block CSA from being used by unauthorized users with full read/write
> access. Now you must selectively permit userkey csa to users and it is now
> your responsibility.
> 
> Kees.
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Jousma, David
> > Sent: 30 August, 2019 12:47
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > Yea...  Funny thing it is a pretty major/well known Financial
> Application
> > vendor.   Every 4-6 months for the last two years I've been pinging them
> > on their status.   I just don’t think they understand the gravity of the
> > situation they are creating here.
> >
> > Also, I did open a PMR on this PTF.   It's not clear to me that the
> > support it discusses continues into V2.4?
> >
> > __
> > 
> > ___
> > Dave Jousma
> > AVP | Manager, Systems Engineering
> >
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > Rapids, MI 49546
> > 616.653.8429  |  fax: 616.653.2717
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Mike Schwab
> > Sent: Friday, August 30, 2019 6:34 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> > I would ask they cover your cost for this as part of their product,
> > since they are the only product you use that needs it.
> >
> > On Fri, Aug 30, 2019 at 5:20 AM Jousma, David <01a0403c5dc1-dmarc-
> > requ...@listserv.ua.edu> wrote:
> > >
> > > This is the first I have seen this!   That is good news.  We have one
> > particular Financial Business application, written/distributed by
> > outside vendor that I have been bugging now since I put V2.3 in almost 2
> years ago
> > to remediate.   They still have not yet remediated there code, and I was
> > thinking this was going to hold up my implementation.
> > >
> > > 
> > > __
> > > ___
> > > Dave Jousma
> > > AVP | Manager, Systems Engineering
> > >
> > > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > > Rapids, MI 49546
> > > 616.653.8429  |  fax: 616.653.2717
> > >
> > >
> > >
>

Re: z/OS 2.1 to 2.4

2019-08-30 Thread Vernooij, Kees (ITOP NM) - KLM
It does, because 2.4 does not support userkeycsa(yes) anymore. It is also 
discussed in the 2.4 migration guide.

It seems to me the feature will stay, because IBM has fulfilled its goal to 
block CSA from being used by unauthorized users with full read/write access. 
Now you must selectively permit userkey csa to users and it is now your 
responsibility.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: 30 August, 2019 12:47
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> Yea...  Funny thing it is a pretty major/well known Financial Application
> vendor.   Every 4-6 months for the last two years I've been pinging them
> on their status.   I just don’t think they understand the gravity of the
> situation they are creating here.
> 
> Also, I did open a PMR on this PTF.   It's not clear to me that the
> support it discusses continues into V2.4?
> 
> __
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Mike Schwab
> Sent: Friday, August 30, 2019 6:34 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> **CAUTION EXTERNAL EMAIL**
> 
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
> 
> I would ask they cover your cost for this as part of their product, since
> they are the only product you use that needs it.
> 
> On Fri, Aug 30, 2019 at 5:20 AM Jousma, David <01a0403c5dc1-dmarc-
> requ...@listserv.ua.edu> wrote:
> >
> > This is the first I have seen this!   That is good news.  We have one
> particular Financial Business application, written/distributed by outside
> vendor that I have been bugging now since I put V2.3 in almost 2 years ago
> to remediate.   They still have not yet remediated there code, and I was
> thinking this was going to hold up my implementation.
> >
> > __
> > ___
> > Dave Jousma
> > AVP | Manager, Systems Engineering
> >
> > Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> > Rapids, MI 49546
> > 616.653.8429  |  fax: 616.653.2717
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Vernooij, Kees (ITOP NM) - KLM
> > Sent: Friday, August 30, 2019 4:20 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > **CAUTION EXTERNAL EMAIL**
> >
> > **DO NOT open attachments or click on links from unknown senders or
> > unexpected emails**
> >
> > IBM has a payed feature called Restricted Use CSA, that allows you to
> keep your applics with userkeycsa running in 2.4.
> > Check OA56180.
> >
> > Kees.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gibney, Dave
> > > Sent: 30 August, 2019 10:06
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS 2.1 to 2.4
> > >
> > > Just monoplexes. Some limited sharing of DASD. Not even GRS.
> > > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting.
> > > Our Natural Global Buffer Pool is one such use.
> > > We are quite back level with both Natural and Adabas.
> > >
> > >
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List  On
> > > > Behalf Of Brian Westerman
> > > > Sent: Thursday, August 29, 2019 11:53 PM
> > > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > > Subject: Re: z/OS 2.1 to 2.4
> > > >
> > > > IS your a Parallel sysplex or just LPAR environment?  If not
> > > > parallel
> > > sysplex,
> > > > then you have nothing to worry about, except for the fact that the
> > > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't
> > > > using
> > > it
> > > > now), everything else is fairly minor.  If your running a sysplex,
> > > > then
> > > you
> > > > probably are okay, but it will depend on a lot 

Re: z/OS 2.1 to 2.4

2019-08-30 Thread Vernooij, Kees (ITOP NM) - KLM
We discovered it in Cheryl's newsletter 2019 no.1.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jousma, David
> Sent: 30 August, 2019 12:20
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> This is the first I have seen this!   That is good news.  We have one
> particular Financial Business application, written/distributed by outside
> vendor that I have been bugging now since I put V2.3 in almost 2 years ago
> to remediate.   They still have not yet remediated there code, and I was
> thinking this was going to hold up my implementation.
> 
> __
> ___
> Dave Jousma
> AVP | Manager, Systems Engineering
> 
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
> 
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Vernooij, Kees (ITOP NM) - KLM
> Sent: Friday, August 30, 2019 4:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> **CAUTION EXTERNAL EMAIL**
> 
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
> 
> IBM has a payed feature called Restricted Use CSA, that allows you to keep
> your applics with userkeycsa running in 2.4.
> Check OA56180.
> 
> Kees.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Gibney, Dave
> > Sent: 30 August, 2019 10:06
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > Just monoplexes. Some limited sharing of DASD. Not even GRS.
> > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting.
> > Our Natural Global Buffer Pool is one such use.
> > We are quite back level with both Natural and Adabas.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Brian Westerman
> > > Sent: Thursday, August 29, 2019 11:53 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS 2.1 to 2.4
> > >
> > > IS your a Parallel sysplex or just LPAR environment?  If not
> > > parallel
> > sysplex,
> > > then you have nothing to worry about, except for the fact that the
> > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't
> > > using
> > it
> > > now), everything else is fairly minor.  If your running a sysplex,
> > > then
> > you
> > > probably are okay, but it will depend on a lot of factors which I
> > > don't
> > have
> > > enough information to tell you about.
> > >
> > > You can contact me offline if you want and we can discuss it, but I
> > suspect
> > > that so long as you are not running some pretty old vendor software
> > > or
> > some
> > > really crappy home grown code that you will have very few (if any)
> > issues.
> > >
> > > Brian
> > >
> > > 
> > > -- For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send
> > email to
> > > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and
> may be unlawful. If you have received this e-mail by error, please notify
> the sender immediately by return e-mail, and delete this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in
> receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Nethe

Re: z/OS 2.1 to 2.4

2019-08-30 Thread Vernooij, Kees (ITOP NM) - KLM
RUCSA is available for z/OS 2.1, so you can implement on you current systems 
and move it out of the migration path.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Martin Packer
> Sent: 30 August, 2019 10:37
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS 2.1 to 2.4
> 
> Note: With RUCSA there are still migration actions - because of the new
> way of allowing an address space to use it.
> 
> Cheers, Martin
> 
> Martin Packer
> 
> zChampion, Systems Investigator & Performance Troubleshooter, IBM
> 
> +44-7802-245-584
> 
> email: martin_pac...@uk.ibm.com
> 
> Twitter / Facebook IDs: MartinPacker
> 
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
> 
> Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or
> 
> https://itunes.apple.com/gb/podcast/mainframe-performance-
> topics/id1127943573?mt=2
> 
> 
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
> 
> 
> 
> From:   "Vernooij, Kees (ITOP NM) - KLM" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   30/08/2019 09:21
> Subject:Re: z/OS 2.1 to 2.4
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> IBM has a payed feature called Restricted Use CSA, that allows you to keep
> your applics with userkeycsa running in 2.4.
> Check OA56180.
> 
> Kees.
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Gibney, Dave
> > Sent: 30 August, 2019 10:06
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: z/OS 2.1 to 2.4
> >
> > Just monoplexes. Some limited sharing of DASD. Not even GRS.
> > But, I had forgot about ALLOWUSERKEYCSA(YES). We do use that setting.
> > Our Natural Global Buffer Pool is one such use.
> > We are quite back level with both Natural and Adabas.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List  On
> > > Behalf Of Brian Westerman
> > > Sent: Thursday, August 29, 2019 11:53 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: z/OS 2.1 to 2.4
> > >
> > > IS your a Parallel sysplex or just LPAR environment?  If not parallel
> > sysplex,
> > > then you have nothing to worry about, except for the fact that the
> > > ALLOWUSERKEYCSA(YES) change (which won't affect you if you aren't
> using
> > it
> > > now), everything else is fairly minor.  If your running a sysplex,
> then
> > you
> > > probably are okay, but it will depend on a lot of factors which I
> don't
> > have
> > > enough information to tell you about.
> > >
> > > You can contact me offline if you want and we can discuss it, but I
> > suspect
> > > that so long as you are not running some pretty old vendor software or
> > some
> > > really crappy home grown code that you will have very few (if any)
> > issues.
> > >
> > > Brian
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to
> > > lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> For information, services and offers, please visit our web site:
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.klm.com=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-
> WOWZjlZ0NwmcFSpQCLphNznBSDQ=gpOagelfUQirHhAYLM5OLW3X-fZoRpaYVr-
> LlHpuVHg=SH5PyIj6HoznFA_qBtRu5lZhtUhNauWGIZeJ5AXpEjU=
> . This e-mail and any attachment may contain confidential and privileged
> material intended for the addressee only. If you are not the addressee,
> you are notified that no part of the e-mail or any attachment may be
> disclosed, copied or distributed, and that any other action related to
> this e-mail or attachment is strictly prohibited, and may be unlawful. If
> you have received this e-mail by error, please notify the sender
> immediately by return e-mail, and delete this message.
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in
&

  1   2   3   >